Subject: Re: Diffs for next draft

From: Jon Callas <[email-masked]>
Date: Thu, 23 Aug 2001 11:42:53 -0700

Late last night, I replied to Werner, not to the list. Here's my reply to
him, and his reply to me (with permission).

	Jon

To: Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft

In our last episode ("Re: Diffs for next draft", shown on 8/23/01), Werner
Koch said:

>On Wed, 22 Aug 2001 15:52:12 -0700, Jon Callas said:
>
>> Here's everything I have. If there's something you want me to do and I've
>> been obtuse, let me know again, and it'll get in. I'm planning on
>
>Did someone else also checked that the OIDs for SHA-xxx are correct?
>

I haven't, myself. I'll put that on my list.

>I am a little bit curious, can you give a rational why the feature
>flags are not bit encoded?
>

No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
vector. Does anyone else have an opinion.

>What about the Klima/Rosa attack?  If this draft is going to be the
>next RFC we should do something about it.  IIRC, we had not much
>discussion about it. The obvious fix would be use a hash instead of
>the simple checksum.  The problem is how to indicate the use of this
>new format.
>
>The correct solution would be to introduce a version 5 of the secret
>key packet - this is a major change as we may also want to also
>introduce a v5 public key packet for symmetry reasons.  I guess this
>will break a lot of code.
>
>The hackish solution is to define a new S2K type identical to type 3
>(iterated and salted) which would then trigger the use of the new
>SHA-1 checksum.  It should be made clear that this S2K type is only to
>be used for the protection of the secret key and not for conventional
>encryption.
>
>I don't like any of these solutions but the latter one is easier to
>implement. Any other ideas?

Let's put this on the list of things to do after this draft for the next one.

John wants to push to a new RFC. Here are three open issues.

	Jon

To: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[email-masked]
Date: 23 Aug 2001 10:00:48 +0200
Lines: 25

Jon,

[It seems that you didn't post to the list.]

On Thu, 23 Aug 2001 00:26:17 -0700, Jon Callas said:

> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

I have no problem with that, it is just that other attributes use bit
vectors.  Let's keep it as it is.  Can we start to use it and change
our keys to include feature flags?

> Let's put this on the list of things to do after this draft for the next one.

> John wants to push to a new RFC. Here are three open issues.

Okay.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: "Michael Young" <[email-masked]>
Date: Thu, 23 Aug 2001 23:51:01 -0400

-----BEGIN PGP SIGNED MESSAGE-----

> vector. Does anyone else have an opinion.

At first, I accepted the explanation in the current draft, that this act like
other "preferences".  But the only preferences encoded that way are
algorithms lists; but algorithms are already encoded as bytes, and in
the lists, order matters.  Features feel more like the keyserver or key
flags, which are bit-encoded.

---

From: "Michael Young" <[email-masked]>
Date: Fri, 24 Aug 2001 00:06:09 -0400

-----BEGIN PGP SIGNED MESSAGE-----

The description of the "Primary User ID" subpacket says:

>    If more than one user id in a key is marked as primary, the
>    implementation may resolve the ambiguity in any way it sees fit.

It seems that the most likely reason for a second "primary"
is that it has been updated.  If so, it seems that one should
defer to the most recent valid signature.  Can we say
that an implementation "SHOULD" do that, rather than leaving
it open?

I suppose it would be possible to revoke the old signature with a
"primary" subpacket, and then issue a new signature for both the old
and new name.  (The "Reason for Revocation" values include one to
indicate the *key* being superceded, and one to indicate that the user
ID information is no longer valid, but not one to indicate that the
signature has been superceded.)  This seems like a long way to
go to deal with a lack of a firm disambiguation policy.

---

From: Jon Callas <[email-masked]>
Date: Thu, 23 Aug 2001 21:08:30 -0700

>flags, which are bit-encoded.

Good point. Anyone else want to weigh in? I'm now leaning to changing it.

	Jon

---

From: David Shaw <[email-masked]>
Date: Fri, 24 Aug 2001 00:43:24 -0400

> vector. Does anyone else have an opinion.

I think this would be better as a bit vector.  Most everything else
that is of this type of list-of-something data (key server prefs, key
flags) uses bits.  Also, many years down the road we could have a lot
of feature flags, and bits are neater.

Incidentally, in 2440bis-02, the key server subpacket is defined as "N
octets of flags" and the key flags subpacket is defined as "Octet
string".  These should probably be the same. :)

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: David Shaw <[email-masked]>
Date: Fri, 24 Aug 2001 00:59:06 -0400

> that an implementation "SHOULD" do that, rather than leaving

The draft does say "...an implementation SHOULD allow the user to
rewrite the self-signature, and important information in it, such as
preferences and key expiration", which implies that the implementation
should be able to rewrite the self-signatures to remove the primary
subpacket from one and place it onto the other.

That said, there is certainly going to be an implementation that just
merges things together so there is more than one self-signature on a
given user ID.  The keyservers do this now, I believe.

Perhaps (in addition to what you suggest), it would be good to include
language that suggests that in cases of multiple self-signatures on a
single user ID, the most recent should be followed.

David

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Aug 2001 16:42:36 -0700

>that an implementation "SHOULD" do that, rather than leaving

As I remember it, when we introduced this, there were people who thought it
should be a MUST that there be exactly one of them. I thought this was a
bit fussy, myself -- as it requires the implementations to verify that
there's only one.

I came up with the present wording as a way to subtly admonish the practice
without presuming to know the answer. The simple and obvious way to deal
with the problem of multiple primaries is don't do that. This is the Henny
Youngman Solution (from the old joke: HY goes into the doctor and says,
"Doc, it hurts when I do this," waving an arm. The doctor replies, "Then
don't do that"). The penalty for writing multiple primaries is that the
receiver may do something perverse, and you can't use the standard as a
stick. Don't do that.

Secondarily, one way I look at it is as a receiver. I fetch a key from a
server and it has multiple primaries. How do I resolve this? Yeah, there's
been one recommendation in the last 24 hours since I started writing this
reply that it be the first one that counts. Why? Why the first? Why not the
last? I can make a convincing argument that it should be the last one, too.
But why the last. Why not the one with the latest date? I think I can argue
that the latest date is even more correct than either the first or the
last, unless of course it's in the future. Perhaps an even better answer is
to have the implementation ask the user which one to use.

This is my point: I don't see an obvious best answer. Furthermore, 2440 is
a data specification standard, not a user interface guide or software
construction manual. It tells implementers the things they have to do to be
compliant. What this really says that if you ever see a key with multiple
primary user names, then your guess is as good as mine, and I'm not going
to wag my finger at you for whatever rationale makes sense for you.

	Jon

---

From: David Shaw <[email-masked]>
Date: Fri, 24 Aug 2001 23:23:58 -0400

> to wag my finger at you for whatever rationale makes sense for you.

What do you think about adding some text to help resolve multiple
self-signatures?  Multiple primary user names are one thing, but
self-signatures can carry subpackets with serious implications.

For example: take a key with two self-signatures, one with a
revocation key set and one without.  Which is right?  Granted, it is
very hard to tell for all the reasons you gave above, but the penalty
for guessing wrong here is much worse.  If I add a revocation key to
my key and the revocation key is later compromised, I would want to
ensure the compromised key could not revoke mine.  Without even a
recommendation on how to resolve two self-signatures, the result could
be that my key would be revocable on some implementations, but not
others.  It's a great denial of service attack against the key owner.

Similarly, let's say that a few years down the road someone manages to
break one of the symmetric ciphers.  The solution is for the user to
not accept that cipher via the "preferred algorithms" packet.  With
two self-signatures and no way to disambiguate them, the broken cipher
may be used, which can compromise the secrecy of the message.

I strongly favor a recommendation to use the most recent
self-signature.  Picking the first or last doesn't make much sense to
me, as the signature packets could be placed in any order or
rearranged at any time.  It may not be a perfect way to resolve
conflicts, but it should be able to resolve a large majority of them.

If recommending to use the most recent isn't possible, even a line or
two to mention that this is not a casual question and that there are
security implications to picking the wrong self-signature would be
good.  At least it would remind people of the issue.

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

---

From: Werner Koch <[email-masked]>
Date: 25 Aug 2001 13:03:40 +0200

> construction manual. It tells implementers the things they have to do to be

I really agree with you here.  There are already so many
implementation details in OpenPGP which frankly don't belong there but
can be justified due to the fact that OpenPGP is the specification of
a long standing de-facto standard.

Adding more of these implementation stuff will eventually make OpenPGP
as complicated and bloated as SET.  There are already a lot of concerns
on the complexity of OpenPGP saying that this won't increase security.

The secret key protection is a flaw in the standard and has to be
addressed. Well, the most simple way of addressing it is to say: an
implementation should never send a secret key packet without and
additonal layer of encryption. OTOH, we have the protection and we
should make sure that it this gives us a real protection.

---

From: "Michael Young" <[email-masked]>
Date: Sat, 25 Aug 2001 10:46:14 -0400

-----BEGIN PGP SIGNED MESSAGE-----

Florian Weimer wrote:
> This should probably go into a separate RFC.  Currently, RFC 2440 and
> RFC 2440bis deal only with syntactic issues 

> a data specification standard, not a user interface guide or software

I understand that the specification primarily covers syntax, but
if it doesn't cover at least some interpretation issues, then
interoperation is seriously hampered.  Who cares how the bits
are ordered if a sender and receiver interpret wildly different things?
We need to have a meeting of the minds on more than just formatting.

> server and it has multiple primaries. How do I resolve this? Yeah, there's

On this specific issue, I want to know what a *sender* must do
to change its "primary" marking such that a receiver will
understand.  The same applies to any material in the self-signature,
and this need may arise several times over a key/userId lifetime.

I'd be willing to issue a revocation on the old self-signature.  Which
of the "reason" values should be used?  Neither "key is superceded"
nor "userId information is no longer valid" is quite right.  I want
"signature is superceded".  How do people feel about adding such a reason?

While on the subject: the section on "Computing Signatures"
doesn't say what the "signature data" is for a certification
revocation (0x30).  Can we add a description there?

But I also offered a "most recent prevails" policy as an alternative.
One advantage to this approach is that it works even if the sender
has lost an old self-signature.  Another is that it is more compact --
extra revocation packets aren't necessary.

> reply that it be the first one that counts. Why? Why the first? Why not the

If I said that, I misspoke.  I strongly believe that "most recent prevails"
is the only sensible recommendation (if we make one at all).  But again,
an agreed revocation scheme would satisfy me.

> to have the implementation ask the user which one to use.

That's always an option, regardless what the specification suggests.

But, I don't want to *force* user interface pop-ups (or even receiver
policy decisions) when the creator has clear intentions.

---

From: David Shaw <[email-masked]>
Date: Mon, 27 Aug 2001 09:48:50 -0400

> and this need may arise several times over a key/userId lifetime.

The draft does specify have a way to do this - rewriting the
signature(s) in place ("Since a self-signatures contain important
information about the key's use, an implementation SHOULD allow the
user to rewrite the self-signature...").  Both PGP and GnuPG do this.

The problem arises later, when the key with the new self-signatures is
added to a keyserver or sent to someone else who already has the key.
Most current implementations in the field will merge their existing
copy with the new one, resulting in two self-signatures.  It could be
argued that they should not do this, but since it's going to happen,
we should at least make a provision for it.

Like you, I favor a "most recent prevails" recommendation.  I think
that revoking and re-making self-signatures is going to result in some
massive keys if every time someone changes their preferences it means
a new revocation packet and self-signature.

I don't think that this is just a syntax issue, and therefore
inappropriate for 2440bis.  2440bis makes a point of covering syntax
issues that relate to security.  Since the information in a
self-signature can affect the security of messages sent to the key,
I'd say this is an appropriate issue to address in 2440bis.

"Most recent prevails" makes a lot of sense.  It can even be a SHOULD,
like the sample wording I sent out a couple of days ago, rather than a
MUST.  In fact, SHOULD describes it nicely (e.g. "We recommend you do
it this way, but you can do it any way you like if you think about the
implications first.").

> policy decisions) when the creator has clear intentions.

Yes.

David

---

From: Florian Weimer <[email-masked]>
Date: 27 Aug 2001 16:28:51 +0200

Jon Callas <[email-masked]> writes:

> construction manual.

Yes, and I strongly suggest to keep it that way.  I might have uttered
a different opinion in the past, but after a closer look at the USEFOR
draft and the associated process I came to the conclusion that one
better clearly separates syntax and basic semantics on the one side
and higher level semantics (even layer 8 stuff) on the other side.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: Werner Koch <[email-masked]>
Date: 27 Aug 2001 16:55:20 +0200

> "Most recent prevails" makes a lot of sense.  It can even be a SHOULD,

Except for key revocation - any valid revocation (which is a
self-signature) counts.  For subkeys it should be okay to allow
overriding of subkey revocations but it is practically worthless.
Revoking user ID revocations should definitely be possible.

Well, these rules should be obvious.

Ciao,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: 27 Aug 2001 11:01:10 -0400

Keep in mind that you DON'T want to over-ride a revocation
self-signature.  That would be bad.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Florian Weimer <[email-masked]>
Date: 27 Aug 2001 17:45:44 +0200

> self-signature.  That would be bad.

It depends on the revocation reason.  If the revocation says 'user ID
no longer in use', it makes perfect sense to override it.

---

From: David Shaw <[email-masked]>
Date: Mon, 27 Aug 2001 11:50:17 -0400

> self-signature.  That would be bad.

Absolutely.  I am referring only to self certification signatures.
Revocation signatures should not be overridden.  "Bad", indeed.

David

---

From: David Shaw <[email-masked]>
Date: Mon, 27 Aug 2001 12:35:40 -0400

> Revoking user ID revocations should definitely be possible.

The certification revocation signature is applied to the user id,
rather than to the signature that is being revoked, so there is no way
to really revoke a revocation.  I assume you mean revoking a user ID
revocation by re-signing the user ID?

It is an interesting problem how to work out the results when given a
list of certifications and revocations which may have oddball dates.
I'm only trying to make a case for what happens if after everything is
worked out and the implementation ends up with more than one valid
self-signature.

David

---

From: Derek Atkins <[email-masked]>
Date: 27 Aug 2001 12:58:54 -0400

True.  I was implying a Key Revocation, not a UserID revocation.
My appologies for being ambiguous.

-derek

---

From: Werner Koch <[email-masked]>
Date: 27 Aug 2001 20:48:32 +0200

> revocation by re-signing the user ID?

Yes. I talked with Florian about this recently.

> worked out and the implementation ends up with more than one valid

There shouldn't be any date conflicts with self-signatures - but it
may happen.  The way to handle it for a general purpose implemention is
to ignore all signatures during key import which are older than
existing one. That you ignore all self-signatures which are invalid
should be clear.

So I do not see a problem before the year 2106 and most of us won't see
it ever.

Ciao,

   Werner

---

From: David Shaw <[email-masked]>
Date: Mon, 27 Aug 2001 16:59:00 -0400

> existing one. That you ignore all self-signatures which are invalid

This is effectively the same thing as the "use the latest" suggestion.
Either way, you are picking the most recent signature.  I like your
idea a bit more as it seems more elegant - resolving the problem once
at key import time rather than each time the key is used.  It also
keeps the key small - no long trail of signatures from each preference
change.

It does share a gotcha with the "use the latest" suggestion - if the
user who makes one of those signatures has a wonky clock that thinks
it is 2010, then they could find themselves with a self-signature that
can't be replaced because the implementations will always favor the
signature from the future.  The implementation will need to do some
sort of sanity checking there.  Either way, I think it's safe to say
that incorrect clocks are out of the scope of 2440!

> So I do not see a problem before the year 2106 and most of us won't see

Around 2090, the OpenPGP WG of the future will have to make a key
packet version 58 or so that has an 8 byte time. :)

David

---

From: Werner Koch <[email-masked]>
Date: 28 Aug 2001 09:47:24 +0200

> that incorrect clocks are out of the scope of 2440!

Keyserver may want to discard signature which are timestamped more
than a few days in the future.  This should greatly help not to spread
erroneous signatures.

  Werner

---

From: David Shaw <[email-masked]>
Date: Tue, 28 Aug 2001 09:38:49 -0400

> than a few days in the future.  This should greatly help not to spread

Yes, indeed.

I've often thought it would be good if keyservers could trim keys on
the way out - leaving off invalid signatures, expired subkeys, expired
signatures, etc.

It would be optional and allow someone to request the complete key if
they want it.  Computer programs that try to be "smart" often raise
unforseen problems.

David

---

From: "Michael Young" <[email-masked]>
Date: Tue, 28 Aug 2001 17:54:05 -0400

-----BEGIN PGP SIGNED MESSAGE-----

In the ensuing discussion of self-signature revocations, I didn't see an
answer to a fundamental question: what does one hash in a certification
revocation (type 0x30)?  The specification is explicit for all of the
other types, but not this one.

I skimmed the GnuPG source, and it would appear to hash the target key
and userID, and the usual trailing matter (including the hashed
subpackets from the revocation certificate, (*not* the original).
Is my reading correct, and is that what the specification intends?

I note that this does not identify *which* certification is being revoked,
if there is more than one.  If I created multiple signatures (with
different signature type, timestamp, or subpackets) for the same
key/name pair, I see no way to revoke just one of them.  Are multiple
signatures illegal?  (Clearly, multiple self-signatures are legal,
and the same problem comes up there, as per the recent discussion.)

This seems broken.  A certification revocation should identify the
original certification, and hash the same material as the original
(followed by the revocation certificate material).  The identification
is desirable, but not strictly required -- a receiver could test all
possible certifications.  It would seem that a new subpacket would be
in order.  The original contents are absolutely essential, though.

I suppose one interpretation might be that a revocation should match
an original that has *exactly* the same subpackets (except for the
"revocation reason").  How does this work for these things
[with my guess as to an answer in brackets for each one]?
    v3 signatures, which use an explicit creation time instead of
     subpackets [use v3 revocation with same creation time];
    different signature types (e.g., "persona" vs. "casual")
     [do not permit distinction on this];
    other subpackets that might apply to both the original and the
     revocation (e.g., notation data) [there may not be any]; or,
    revocation of an earlier revocation (as Florian Weimer suggested
     might be valid for "no longer in use" reasons) [disallow this].
In any case, if this was the intention, the specification should say
so (and GnuPG should make it easier to generate an exact match :-).

I'm really not out to be pedantic here.  I think it really is important
to have clear rules for revocation.  If multiple certifications for a
key or key/name are to be allowed, or are the *recommended* way to
update preferences/qualities, then it is essential that a revocation
be able to target the proper one.

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 29 Aug 2001 09:06:33 +0200

On 2001-08-28 17:54:05 -0400, Michael Young wrote:

>I'm really not out to be pedantic here.  I think it really is 
>important to have clear rules for revocation.  If multiple
>certifications for a key or key/name are to be allowed, or are the 
>*recommended* way to update preferences/qualities, then it is 
>essential that a revocation be able to target the proper one.

Of course, the trivial solution would be to assign a unique serial 
number to each certificate, and to include that serial number with 
the revocation.

-- 
Thomas Roessler                        http://log.does-not-exist.org/