Subject: Re: Series of minor questions about OpenPGP 4

From: [email-masked] ("Hal Finney")
Date: Wed, 28 Jan 2009 10:48:24 -0800 (PST)

Hello Peter -

I will answer your questions on the assumption that you are writing
OpenPGP compliant software. You are therefore asking about how you should
implement your software.

> 1) gnupg (and as far as I can see other implementations, too) don't
> set the critical bit on much signature subpackets by default. The RFC
> (AFAIK) doesn't demand any subpacket to be understood by applications.
> Unknown subpackets should be ignored, except the critical bit is set.
> Correct so far?
> Now when I go through the currently defined signature subpackets, I
> see several which are or at least could be critical for security and
> for the correct evaluation of signatures:
> 2, 3: a signature might not be valid yet, or might be expired already
> 7: an attacker might manage to revoke an irrevocable signature
> 9: they key is expired and the owner does not want it to be used any
> longer (maybe also due to security reasons)
> 12: if an implementation doesn't understand this, it might not notice,
> that a key/UID is already revoked
> 26: the policy may contain critical information for security (e.g.
> "this key signs any applicant without validating his personal data)
> 27: it might be a security issue, if a key that was marked for
> certification-only (0x01) has signed some casual data
> 31: required for revocation signatures and thus possibly security critical
> 32: required for the signing subkey backsigs (0x19)
>
> I'd even consider the following as critical:
> 28: the signer might want to express that a specific role/UID made the
> signature, and this might be security critical depending on the policy
>
> Of course no one can force the user to actually read and follow these
> subpackets (the policy (26) is the best example for this ^^), but
> wouldn't it make sense that the RFC _REQUIRES_ these subpackets to be
> understood by conforming implementations?
> Just an idea, though :-)

I would certainly encourage you to set the critical bit on these and
other signature subpackets that you view as critical to the security. You
might also want to require the critical bit to be set on those packets,
although that will impair interoperability.

> 2) Selfsignatures and possible ambiguities:
> In an email before David told me that it's fully ok that some
> signature subpackets are on 0x13 and/or 0x1F self signatures. I said
> I'll come back to this; here it is.
> The RFC is very clear (5.2.3.3) about which signature types may be
> self-signatures, namely 0x10-0x13, 0x1F and 0x18 (I assume 0x19 is let
> out, as it's made by the subkey, right?).
> This chapter also says that an implementation should interpret it as
> narrowly as possible.
> a) That's by the way the first "problem" which _could_ lead to
> secrutiy issues, as the standard doesn't define for every case what
> "as narrowly as possible" mean. Of course everyone could say "just
> follow the common human sense" but this is always problematic, isn't
> it? ;-)

In your software, you should make your own judgements about this.

> b) What for example, if a 0x13 and a 0x1F have conflicting key
> expiration times? Should an implementation use the time in the most
> recent of the two? Should it use the information from the 0x1F, as key
> expiration time is "clearly" related to the key, and not the the User
> ID? Should it just use the smallest value of the two? Should it use
> the value accordingly by which the key was found (if by Key ID -> use
> 0x1F, if by User ID -> use 0x13).

I would encourage you to make sure your software does not create keys
which have this problem. If you do receive keys with this kind of
inconsistency, you should decide for yourself how to interpret it.
There is no one right answer for what to do with keys with this problem.

> One can easily think of similar examples for other subpacket types,
> and its easy to think of examples where this could lead to security
> problems (Imagine a user resets the expiration time of his key to
> denote that it should not longer be used. His implementation updates
> only the 0x13 self-signature but not the "unlimited" in the 0x1F, made
> by some other implementation. A third implementation may now choose
> the "right one" or not.)

I hope you will write your software not to make this mistake.

> c) It's nowhere clearly specified if and what meaning these supackets
> have on the subkey binding self-signature (0x18)

You should probably not put subpackets into such signatures which do
not have clearly defined meanings.

> A solution would be, that the RFC clearly specifies which subpackets
> MAY go to which self-signature, which one takes priority, and for
> which the implementation is allowed to choose itself (e.g. according
> to the way the key was found).

That is probably not going to happen. It took us many years to come up
with the latest RFC. I doubt that we would see another revision before
2012 at the earliest.

> btw: The example on page 27 "If the key is located via Key ID => use
> the subpacket from the primary User ID self-signature also shows the
> conflict with 0x1F signatures that could arise in that case.
>
> 3) This is probably clear for everybody, but the part on revocation
> signatures should perhaps highlight, that all subpackets in revoked
> signatures MUST NOT be used, e.g. imagine the key expiration time is
> only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets
> revoked, the key has no longer an expiration time.

I would recommend that your software follow this principle.

> btw: Is it specified what happens when possibly security critical
> subpackets like the expiration time or key usage are absent?
>
> 4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration
> time is reset by a user (of course this cannot be prevented as the key
> expiration time is no longer part of the key itself). Isn't this
> possibility comparable to revoke a revocation?
> I mean the creators states: "This key SHOULD NOT be used after <key
> expiration>." for example because he thinks an RSA786 key SHOULD no
> longer be used in 10 years. An attacker might simply revoke this
> (implicit) revocation by issuing a new self-signature with an updated
> date.

If the attacker got the private key.

> 5) Chapter 5.2.3.3. also says what should happen when multiple
> self-signatures are encountered by an implementation.
> Wouldn't it be more secure to require that ONLY the most recent self
> signature of a given type (per primary key in the case of 0x1F, per
> User ID in the case of 0x10-0x13 and per subkey in the case of 0x18)
> may be used and if that one could not be parsed (e.g. because of
> unknown subpackets with the critical bit set) no self-signature MUST
> be considered as valid?

I would encourage you to consider this design concept in your software.

> My idea is about this:
> Imagine a very old self-signature that still uses MD5 (which is now
> broken, isn't it?) and a newer (in the sense of it's signature
> creation time) self-signature which uses say SHA512. Both
> self-signatures specify a designated revoker (subpacket 12).
> Now an implementation doesn't understand SHA512 signatures and thus
> uses the older one with MD5 (as far as I understand the RFC allows to
> do so). But than one is probably a forged one by an attacker which
> doesn't contain the subpacket 12.
> See what I mean? I think it's quite easy to create similar examples
> with other subpackets involved.
>
> So a solution would be that the RFC requires, that always and only the
> most recent self-signature is used.

Again, there will be no new RFC, not for many years at least. You must
solve them in your software using the current RFC. If you want to ask
more specific and practically oriented questions, like, what should I
do when I see this kind of key, we can try to give you more specific
advice.

> Ok,.. enough for now,.. but I fear that I'm still not finished :-(
> Is it possible to donate a few bugs to gnupg in order to compensate
> the time you spend for answering my questions?

Feel free to ask more, but I think on this list, for me at least the
information I can give you is limited to advice along the lines I have
outlined above. Maybe you can persuade David or someone else to change
his software to be more to your liking, or failing that you can write
your own to address your concerns.

Hal Finney

---

From: Peter Thomas <[email-masked]>
Date: Thu, 29 Jan 2009 18:42:22 +0100

Hi Hal.

> OpenPGP compliant software. You are therefore asking about how you should
Yes and no.
I'm actually thinking about writing an OpenPGP key editor (perhaps
using parts of gnupg as backend) which can do nearly everything that
the RFC allows to give geeks and freaks the opportunity to try out
everything which shouldn't be possible for the average user (that said
I fully like the way gnupg - and probably other implementations -
"guide" the user).

But my discussion here is more about how could the RFC be improved.
Please don't get me wrong, I don't wanna say the RFC is crap or anyone
here did make wrong things or so and I'm fully aware that I'm really a
newbie here.
But what I see is that X.509 based PKIs which are based on a strict
hierarchical trust model are spread more and more. And personally I
dislike it and consider hierarchical trust models inferior to what
OpenPGP allows.
Most governments fully set on X.509 based PKIs and don't consider or
even support OpenPGP and even most technical standards or applications
are only X.509 aware (see SSL/TLS, although we have RFC 5081).

What it all comes down to is: I think there are places where the RFC
and thus OpenPGP could be improved maybe I'm wrong but nevertheless
I'll tell this list my ideas.
Of course some of them would be difficult to implement or even break
compatibility. I'm aware of the time that was needed for this RFC and
fully respect the effort the WG put in it and I'm also aware that a
new RFC won't come up tomorrow, but anyway I'd like to tell you what I
think.
You still can say shut up and go away ;-)

> other signature subpackets that you view as critical to the security.
Unfortunately I have no idea how to do this with gnupg (my used
implementation)... perhaps David can comment on this. But even if
would do modifications to set the critical bit on them I fear
compatibility issues with other implementations.

> You
What do you mean with this? Require it by the RFC?

> not have clearly defined meanings.
But this is the point. Which have clearly defined meanings? Hast the
policy URI a meaning on 0x18s (e.g. as the policy for signatures made
by that subkey)?

> I would recommend that your software follow this principle.
Oh my mistake,... an absent key expiration time means unlimited ;-)
Anyway I think the original problem remains,.. what is the semantical
meaning e.g. when there are different key expiration time values on
(perhaps even multiple) 0x13s and a 0x1F?

> If the attacker got the private key.
What was the reason that the key expiration time was taken out of the
key itself (I think it was there before?)?

> do when I see this kind of key, we can try to give you more specific
Thanks again for your advices. But if you're interested in and find
the time I'd like to see your comments and ideas about the "issues"
themselves.
Of course it's possible to find and implement a reasonable solution,
which is what you suggested me in most of your comments :-)
At some point the RFC says that it's a little bit "vague". In my
opinion (and I really don't want to offend anybody) this is bad for a
cryptologic. Everything should be exactly defined.
For example I'd like to see those possible (at leas in my opinion)
security critical subpackets to be REQUIRED by an future RFC. Of
course no one can force an implementation to really adhere to the
standard, but that's always the case.

Would be nice if you and perhaps even the other authors of the RFC
(David for example has give me already some very deep insight) could
comment on the "issues" themselves. I promise that I don't request you
to write a new RFC immediately ;-)

> Maybe you can persuade David or someone else to change
Well this would be great,.. I mean the current MAIN implementations of
OpenPGP are probably GnuPG and PGP. I think David and Werner who
represent GnuPG are reading this list and you, are you still at PGP
Corporation?
If some or all of you find suggestions that I made or will make worth
to implement (e.g. that critical bit issues) we could put this in
practice even before having (perhaps at some day) a new RFC.

Thanks for allowing me to ask additional questions, I have "plenty" left ;-)
But I'll start new threads for them.

Best wishes,
Peter

---

From: Peter Thomas <[email-masked]>
Date: Thu, 29 Jan 2009 19:42:59 +0100

One probably stupid idea on this *G*

> I would encourage you to consider this design concept in your software.

I thought about how this "issue" could be solved with the current
means of the standard. I mean how can I secure that only the most
recent self-signature (no matter whether 0x10-0x13, 0x1F or 0x18) is
used by ANY conforming implementation.

Perhaps this is really stupid, so better sit down ;-)

What if I'd revoke the old self-signatures to mark them clearly as
superseded and to force ANY conforming OpenPGP implementation not to
use them.
0x10-0x13 self-sigs could be revoked with a 0x30 certification
revocation signature
0x18 self-sigs could be revoked with a 0x28 subkey revocation signautre
0x1F: which one would I have to use for that? A 0x20 key revocation
signature? Or would the completely revoke the whole key.

What would be the most fitting reasons for revocation?
For 0x10-0x13 probably 32 (user id information no longer valid), but
for the others? Or should one use 0 (no reason specified).

Does the whole thing make sense anyway? I mean would it be a clean or
at least working way to force ANY implementation to use only the most
recent self-signatures?

Would it work with the mayor implementations, PGP and GnuPG?

Lots of thanks for your comments and ideas,
Peter :-) *who is now going home*

---

From: Jon Callas <[email-masked]>
Date: Thu, 29 Jan 2009 11:37:25 -0800

> You still can say shut up and go away ;-)

On the contrary, I think you should start discussing things here and  
start writing drafts.

> What do you mean with this? Require it by the RFC?

No, the critical bit means that you want an operation to be 100%  
correct or to fail. If there is any doubt in anyone's mind, you want  
the system to halt with an unrecoverable error.

Hal points out that this will mar interoperability.

> key itself (I think it was there before?)?

Because in PGP 3, a number of attributes were moved to the self-sigs  
with the thought that you might have a key with different user ids and  
different features. For example, I might have a user id in which a  
cipher is allowed, and one in which it is not. You might also want to  
have different expirations on those user ids.

> represent GnuPG are reading this list and you, are you still at PGP

Yes.

> Peter

To you too! It's nice to see enthusiastic new blood.

	Jon

---

From: David Shaw <[email-masked]>
Date: Thu, 29 Jan 2009 15:38:09 -0500

> compatibility issues with other implementations.

That's basically the point of the critical bit.  You can think of it
as a way to force a (quasi) compatibility break.  The critical bit
means "This subpacket is so important to the signature that I'd rather
you treat the whole signature is invalid than you not understand this
subpacket".

For example, GPG sets the critical bit on signatures that have an
expiration date set.  Thus, if the signature is read by an
implementation that doesn't understand expiring signatures, the whole
signature is invalid.  This was deemed better than the alternative - a
"expired" signature being treated as still usable because the
recipient implementation didn't know to ignore it.

> policy URI a meaning on 0x18s (e.g. as the policy for signatures made

It is the policy under which the subkey itself was certified.  The
Policy URI for signatures made by that subkey would be in those
signatures.

> (perhaps even multiple) 0x13s and a 0x1F?

Section 5.2.3.3:

  An implementation that encounters multiple self-signatures on the
  same object may resolve the ambiguity in any way it sees fit, but
  it is RECOMMENDED that priority be given to the most recent self-
  signature.

I suspect that most software follows this recommendation.  GPG does.

> standard, but that's always the case.

The problem here is that what one use case requires as security
critical may not be what another one does.  The critical bit is a more
flexible way for an implementation to require which subpackets are
understood.

David

---

From: David Shaw <[email-masked]>
Date: Thu, 29 Jan 2009 15:53:21 -0500

> signature? Or would the completely revoke the whole key.

You revoke a 0x1F with a 0x30, same as you would use to revoke a
0x10-0x13.  0x1F is a certification.

> at least working way to force ANY implementation to use only the most

I suspect it wouldn't hurt, but wouldn't help much either.  For
example, given this:

  Signature === January 1
  Signature === January 3
  Signature === January 5

it is clear that the January 5 signature is the latest and the one to
use.  Given this:

  Signature  === January 1
  Revocation === January 2
  Signature  === January 3
  Revocation === January 4
  Signature  === January 5

It's still clear which signature is the right one.

I suppose if you had an implementation that insisted on using the
first signature, regardless of the date, then the revocations would
force it to look at the last signature.. but then, an implementation
that did that may have other odd semantics elsewhere.  It may conclude
that there is no signature at all (after all, the one signature it was
looking at is revoked).

> Would it work with the mayor implementations, PGP and GnuPG?

It would work in GnuPG.

David

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Thu, 29 Jan 2009 23:02:42 +0100

> 0x10-0x13.  0x1F is a certification.

Hold on here. What you write here obviously follows from the text of the RFC, so
I do not question it, but it does raise a semantic question.

Obviously, one reason for attaching certifications directly to a key rather than
to particular user IDs is to make them stick even if any particular user ID is
revoked or expires (or even all of them). So, if I want to make a statement
about a certain person rather than a user ID (concerning, e.g., his/her
trustworthiness as a certifier), I'd attach it directly to the key. There may be
several certifications by several people saying different things about the person.

The question: how does one revoke one of them? A 0x30 computed directly on the
key (as the RFC specifies) revokes all of them (for which it is a designated
revoker), doesn't it? Is there no way to revoke just one?

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Thu, 29 Jan 2009 17:30:45 -0500

On Thu, Jan 29, 2009 at 11:02:42PM +0100, Daniel A. Nagy wrote:
> Hold on here. What you write here obviously follows from the text of
> the RFC, so I do not question it, but it does raise a semantic
> question.
> 
> Obviously, one reason for attaching certifications directly to a key
> rather than to particular user IDs is to make them stick even if any
> particular user ID is revoked or expires (or even all of them). So,
> if I want to make a statement about a certain person rather than a
> user ID (concerning, e.g., his/her trustworthiness as a certifier),
> I'd attach it directly to the key. There may be several
> certifications by several people saying different things about the
> person.
> 
> The question: how does one revoke one of them? A 0x30 computed
> directly on the key (as the RFC specifies) revokes all of them (for
> which it is a designated revoker), doesn't it? Is there no way to
> revoke just one?

It doesn't actually revoke all of them.  A 0x30 revocation on a 0x1F
signature revokes (potentially) all of them that are a) from the same
issuer (or from that issuer's designated revoker), and b) timestamped
earlier than the revocation.  It cannot revoke ones that come after
it.

Even then there is the possibility of confusion of which signature you
intend to revoke.  In those cases, you can always specify a particular
signature to revoke using the Signature Target subpacket in the
revocation.  Arguably, you could even revoke multiple signatures with
one revocation by using multiple subpackets.

Not, it should be pointed out, that many (any?) implementations
support Signature Targets yet.  But the semantics are there.

David

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Fri, 30 Jan 2009 01:02:08 +0100

> earlier than the revocation.  It cannot revoke ones that come after

Of course. Sorry for the sloppy wording of my email. This is what I meant.

> support Signature Targets yet.  But the semantics are there.

Thank you, this answers my question. Haven't paid attention to Signature
Targets, because I haven't seen a single one in the wild. But they are, indeed,
truly useful and as such worth implementing as soon as OpenPGP gets used for
serious legal purposes. I might do it myself.

-- 
Daniel

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2009 10:30:28 -0500

> that there is no signature at all (after all, the one signature it was

This would be a particularly odd implementation because "the first
signature regardless of date" has no meaning in OpenPGP, iiuc.  There's
nothing stopping a re-ordering of signature packets, and a certificate
that looks like this:

 primary_key
  \-uid
    +--sigX
    \--sigY

Is semantically equivalent to this:

 primary_key
  \-uid
    +--sigY
    \--sigX

And in fact, keyservers will often have to re-order signature packets if
they gather data from disparate sources.

	--dkg

---

From: David Shaw <[email-masked]>
Date: Fri, 30 Jan 2009 11:03:29 -0500

> nothing stopping a re-ordering of signature packets, and a certificate

Yes, it was particularly odd.  I've seen it happen, but it's broken
for all the reasons you say.

David

---

From: Peter Thomas <[email-masked]>
Date: Fri, 30 Jan 2009 19:05:02 +0100

> On the contrary, I think you should start discussing things here and
I don't believe I'm technically skilled enough for doing this. And I
must admit that I've borrowed some (of course not all) ideas here from
some threads I've found on the gnupg mailing lists. I've already
contacted the author (Christoph Mitterer) of that threads and I hope
he'll have a look at the currently ongoing discussion.

> the system to halt with an unrecoverable error.
Would you guys here, I mean Hal/Jon from PGP and David from gnupg
suggest, that I set critical bits on the subpackets I listed before?
Would your implementations (PGP/GnuPG) support this?
Would you (and of course the other list members) support the idea of
having the security critical subpackets REQUIRED per default by a
future RFC?

> Hal points out that this will mar interoperability.
We'll but that was the idea. An implementation that does not support
e.g. signature expiration should better fail at all.

> have different expirations on those user ids.
Well my idea is the following: We have the key expiration time, we
have the User ID self-signatures and we have signature expiration.
- If a user wants to just expire the key with one specific User ID, he
could either revoke the corresponding self-signature or set an
signature expiration time on it.
He could even re-set it later by creating a new self-signature.
- If all self-signatures (0x10-0x13 and 0x1F) are expired or revoked
it's basically the same as if the whole key expired/revoked.

So I think the key expiration flags somehow doubles that functionality
and to me it made more sense when it was part of the key itself and
thus kind of a promise that could not be changed later (e.g. by
issuing a new self-signature)

>> represent GnuPG are reading this list and you, are you still at PGP
Great, so you can comment whether you'd support such changes as I
propose for the criticality of signature subpackets.

Cheers,
Peter

---

From: Peter Thomas <[email-masked]>
Date: Fri, 30 Jan 2009 19:15:32 +0100

> you treat the whole signature is invalid than you not understand this
Yes :-)

> recipient implementation didn't know to ignore it.
Ok that's already great,.. what do you think about the other
subpackets that I've suggested for being critical in my initial post?
Would you for example change gpg, that for example it issues the
critical bit with the signature creation time, key expiration and key
usage, too?

> Policy URI for signatures made by that subkey would be in those
Ah, you're right ^^ I'm always messing this up.
But by the way: This would be another thing that one could think of in
future revisions of the RFC.
Policy-URI on self-signatures:
0x10-0x13: The policy that is used for signing, with the corresponding UserID.
0x1F: The global policy for the whole key, when signing anything
(especially other keys/UIDs) with that key
0x18: The policy used when making signatures with this key

Policy-URI on other signatures:
The policy under which this signature was issued. (Just like it is
interpreted now)

> I suspect that most software follows this recommendation.  GPG does.
Of course,.. and in principle this is fine,.. but I'd even go so far
to change this recommendation to a MUST.

> flexible way for an implementation to require which subpackets are
Hm, ok you're the expert :-)
I just thought that the subpackets from my initial posting would be
critical in ANY case ^^

Best wishes,
Peter

---

From: Peter Thomas <[email-masked]>
Date: Fri, 30 Jan 2009 19:24:47 +0100

> 0x10-0x13.  0x1F is a certification.
Ooops XD

> It's still clear which signature is the right one.
Yes, but it's not only clear. It is the ONLY way when following the RFC.
But in the example from above (I've added some information to it):
Signature using MD5 === January 1
Signature using MD5 === January 3
Signature using SHA256 === January 5
and implementation could say "oh I just understand MD5 and SHA1, but
not SHA256... well the MD5 from 03.01. isn't the most recent, but at
leas I understand it"

> that did that may have other odd semantics elsewhere.
Of course...

> It may conclude
Well,... even better than perhaps using the "dangerous" signature from
January the 1st, isn't it?

>> Would it work with the mayor implementations, PGP and GnuPG?

Hal, Jon, would it work with PGP?

And would you experts here suggest to do the whole
revoke-old-self-sigs-trick in order to prevent that kind of "downgrade
attacks" (and possibly other evil things) I tried to describe above?

Thanks for your advice,
Peter

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2009 13:37:45 -0500

> The policy under which this signature was issued. (Just like it is

I'd disagree with such a change, if only because it seems to force a
semantic change on signatures that may already be in existence.  It'd be
weird if i made a signature that i knew meant "foo", and then came back
later to find that according to the new RFC, i'd actually stated "bar".

If you want to propose a new subpacket with the above semantics (perhaps
one that would be invalid on anything but a self-sig), i wouldn't be
opposed, though i'm not sure how useful it would be.

And how would you interpret the following situation:

 Key A has a self-sig with policy X

  Key A signs B's key,uid pair and includes a with policy-URI Y.

which policy governs the A's signature on B?  why?

	--dkg

---

From: Peter Thomas <[email-masked]>
Date: Fri, 30 Jan 2009 20:17:41 +0100

> earlier than the revocation.  It cannot revoke ones that come after
Uhm? Why this? I'd thought it would only revoke the specifically
revoked signature, as "the signature is computed over the same data as
the certificate that it revokes".
Am I missing something?

> support Signature Targets yet.  But the semantics are there.
Uhm ok,.. so how does an implementation figure out which certificate
is revoked by a revocation signature?

---

From: Peter Thomas <[email-masked]>
Date: Fri, 30 Jan 2009 20:38:06 +0100

> later to find that according to the new RFC, i'd actually stated "bar".
I'm not sure if I understand what you mean.
Currently policy URI subpackets are allowed on any signature, right?
Their meaning is "The policy under which that signature was maid",
right?
Ok for signatures on other keys or data I didn't propose a semantical change.

For policy-URIs on self-sigs: What would this mean at the moment: "The
policy under which I signed my own key", right?
Does this make any sense? I mean what could one tell in such a policy?
"I trust myself", "I checked my own identity"?
That was the idea why I suggested that idea, because I think otherwise
it does not make much sense at all.
Or do you know anything I didn't think ok? :-)

> which policy governs the A's signature on B?  why?
This is actually a problem.
Currently the Policy URI is only meaningful for the signature itself
("The Policy under which the signature was maid").
If my suggestions for policy URIs on self-signatures would be
implemented, conflicts could arise, just as you showed in your example
above.
I think it would be actually worse, as one could have different
self-signatures (0x13,0x1F,0x18) that might apply in addition to the
signature on the data iself.

While conflicts are possible they "should" be unlikely in practice as
all these policies are under the control of the key holder (and
hopefully he have set them up without conflicts).
If not one could specify the following:
In case of a conflict:
1) Look at all policies whether they specify how to resolve conflicts.
2) If the actual conflict remains, or if the conflict resolution
processes of the different policies are in conflict, the policies have
priority in the following order:
a) the policy specified in the signature of the signed data
b) the policy on the User ID self-signature,.. IF the signers user ID
was specified in the signature on the actual data
c) the policy on the (most recent) 0x1F signature
d) the policy on the 0x18 signature, from the key that was used to
create the signature on the actual data

Of course one would have to discuss which order fits best.

Peter

---

From: David Shaw <[email-masked]>
Date: Fri, 30 Jan 2009 14:59:17 -0500

> the certificate that it revokes".

Take this example:

  User ID
   0x10 signature on that user ID (timestamp 1)
   0x10 signature on that user ID (timestamp 2)
   0x30 revocation                (timestamp 3)

Which signature is being revoked?  Without a signature target, it's
not clear.

> is revoked by a revocation signature?

I can't speak to any other program, but GPG finds the latest
(i.e. most recent) signature or revocation from the issuer.  If that
turns out to be a revocation, then there is effectively no signature.

Note that using the example above (sig+sig+revoke), this would result
in there being effectively no signature.  That is intentional, not a
bug: the second signature superseded the first signature, and then the
revocation revoked the second.  End result: no signature.

David

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2009 15:06:12 -0500

> it does not make much sense at all.

I don't have an immediate example (i haven't used policy URIs on
self-sigs or anywhere else).  But simply saying "these two policy-type
statements don't make sense" is different from saying "there could be no
possible policy statement that you would like to reference in a
self-signature."

For example, here's a policy statement: "This identity is found on
official government documents in the legitimate possession of the keyholder"

Say Margaret has two user IDs:

 "Margaret Kantor <[email-masked]>"
 "Maggie Kantor <[email-masked]>"

Since her gov't id doesn't have anything with "Maggie Kantor" on it (but
she's known by all of her friends as maggie) she might want to assert
the above policy for the former self-sig but not the latter.

I'm not saying it's a great use case, but it would be really unfortunate
if she had done that and then later found that it meant that all
signatures issued by the Margaret Kantor uid (if she used a Signer's
User ID subpacket, for example) suddenly meant that she had verified
specific gov't-issued ID.

> 1) Look at all policies whether they specify how to resolve conflicts.

this assumes that the policies are machine-parseable in a form that
includes conflict resolution, no?  what form are you proposing?  my
reading of the RFC is that there is no restriction on what can be
contained in the policy URI.

> Of course one would have to discuss which order fits best.

Wow, that sounds like a lot of heavy, fairly arbitrary work and hassle
to hash out the spec, let alone an implementation.

If we're ok with saying something like: "well-implemented clients should
be configured well enough to know to not make any conflicts", why not
just tell the well-implemented clients to embed the policy URI subpacket
in every signature they make, and not introduce this special case at
all?  That seems simpler all around to me, and wouldn't require any
retroactive changes to the specification.

btw, please don't take my opposition to this particular idea as
opposition to you proposing changes to the OpenPGP specification in
general.  It's great to see this sort of discussion.  Thanks for raising it!

	--dkg

---

From: Peter Thomas <[email-masked]>
Date: Sat, 31 Jan 2009 00:39:17 +0100

> possible policy statement that you would like to reference in a
Uhm,... well I'm not sure what the others are thinking.
Of course I see your point in preserving compatibility, but even if
this semantical change would be introduced in a future version of the
RFC it wouldn't probably hurt that much, would it? I mean policy URIs
are quite rare and everybody could still interpret it as he wants ;-)

> specific gov't-issued ID.
Not sure if I understand what you mean.
A goverment could simply just sign the first UID and specify perhaps
the governmental policy that was used (but this is of course not on
the self signature).
Which information would you exactly put in the policy from the
self-signature's Policy URI?
(I actually believe that there might be reasonable cases, and just
want to understand yours correctly :-) )

> includes conflict resolution, no?
Why? All policies might have a human readable chapter "X. In case of
policy conflicts", where they explain what should happen.

> what form are you proposing?  my
I don't see that point why this would have to be machine-readable.

> all?
This is actually a good point and in principle you're right (and this
could be done without changing the RFC at all).
But my model would allow to implement a more mighty policy model
imagine the following:
The policy "in" the self-signature is used as I proposed above. It
could contain information like the following:
- How is the key secured (security building, fences, safes, guards)
- What are the procedures in case of a security compromise
- How are other key/UIDs certified (e.g. when is a 0x10, 0x11, 0x12 or
0x13 issued)
All these are very general information.

The policy of the non-self-signatures could contain additional
information about just that single signed document (for example).

> That seems simpler all around to me, and wouldn't require any
Well that's a point.
But the whole idea with the semantic addition/change to the policy URI
was just an idea, that I wanted to be discussed by all these wonderful
experts here.
I don't claim that I have the proof that it makes sense or is the best
and only solution ;-)

> opposition to you
Oh and I was just about to add you to my deadly enemy list ;-) (just kidding)

> proposing changes to the OpenPGP specification in
Thank you :-) ... but again I was inspired by some threads I've found
on the gnupg-lists,... so I must thank Christoph Mitterer ;-)

Cheers,
Peter

---

From: Peter Thomas <[email-masked]>
Date: Sat, 31 Jan 2009 01:04:33 +0100

> Which signature is being revoked?  Without a signature target, it's
Ahhhh....
First of all,.. the different types of revocation signatures are NOT
calculated of the signature they revoke, but the data the signature to
be revoked was calculated over, right?
Ok then it's clear.
Why is it not simply calculated over the signature to be revoked?

But the following is still unclear:
a) when I use a 0x20 key revocation signature:
Am I correct that the explanation on page 21 says: A key having a
revocation signature is completely invalid including all it's UIDs,
subkeys, etc. and this cannot be undone in any way?
(Of course the subkeys could still be used attached to another primary.)

I mean the following doesn't work, right?
Primary key
|->UID
|--->0x13 on that UID
|->Subkey
|--->0x18 on that subkey

now I add a:
|-> 0x20 key revocation at 12:00 making the key unusable (forever?)

at 13:00 I add new UID's/0x13s/Subkeys/0x18s
|->UID2
|--->0x13 on that UID2
|->Subkey2
|--->0x18 on that subkey2

But the whole thing would still be revoked, right?

b) when I use a 0x28 key revocation signature:
Does this (according to the RFC) make the subkey forever unusable, as
above with the 0x20s?
Or would issuing a subkey binding signature more recent than the 0x28
bring it (the subkey) back?

c) when I use a 0x30 certification revocation signautre.
Here the whole thing is different to a) and b) (as far as I understand).
The RFC says "This signature revokes an EARLIER User ID certification
signature..."
Does this now exactly mean,.. that it revokes ALL earlier user id
certification signatures?

> revocation revoked the second.  End result: no signature.
Ok I see.

And what does this now mean for my idea on how to force an
implementation to use only the most recent signatures?
Will the following work, as long as the signature creation times are
correct? And I mean would it be correct even when strictly following
the RFC?

Public Key
UID1
0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30 below)
UID2
0x13 signature on that user ID (timestamp 1)
0x13 signature on that user ID (timestamp 2)
0x30 revocation      (timestamp 3) (revokes every
0x10,0x11,0x12,0x13,0x1F on UID2    BUT NOT    on UID1      BEFORE
timestamp 3
0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30 above)

Thanks for your help,
Peter

---

From: Jon Callas <[email-masked]>
Date: Fri, 30 Jan 2009 17:04:32 -0800

> he'll have a look at the currently ongoing discussion.

Of course you are skilled enough.

And so what that you've borrowed ideas. Shakespeare borrowed all his  
plots.

	Jon

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 31 Jan 2009 02:36:23 +0100

Hello WG and Peter.

I'm constantly following what's happening here on the WG's list and also
gnupg's lists, well at least more or less.

I've already read most of your threads and I wonder whether you can read
my minds or so ;) ... well we seem to have at least many common ideas.

I'm especially happy with your suggestions in "improving" the usage of
User Attributes =)

On Fri, 2009-01-30 at 19:05 +0100, Peter Thomas wrote:
> I don't believe I'm technically skilled enough for doing this.
We'll I wouldn't consider myself to be skilled enough, too. At least I
haven't looked into to the process of writing ID's yet.

But I'd have a strong interest in doing so :-) of course only if the WG
supports this.

> And I
> some threads I've found on the gnupg mailing lists.
I should sue you, what?! ;-P

> I've already
See above.
I'm currently on some official trip (I miss it being a student ;) ) but
when I'm back I could put together a list with the ideas the were
discussed here. Of course everybody may add topics.

Afterwards the WG could discuss which points would find broad support in
a future RFC, wouldn't break backward-compatibility too much (or even
better not at all), et cetera.

I think it's much easier to split things up a little bit and discuss
each point on its own, than writing a new draft-RFC that contains all
the ideas presented here. Especially because probably not everything
will find support ;)

In the meantime: Happy discussing =)
-- 
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München

[email-masked]
[email-masked]

---

From: David Shaw <[email-masked]>
Date: Fri, 30 Jan 2009 22:48:40 -0500

> be revoked was calculated over, right?

Right.

> subkeys, etc. and this cannot be undone in any way?

Yes.  However note that you can un-revoke a key by removing the
revocation signature.  That's very difficult to do in practice
(keyservers would have the revoked copy).

> (Of course the subkeys could still be used attached to another primary.)

Right.

> But the whole thing would still be revoked, right?

Right.

> bring it (the subkey) back?

That's a good question.  The RFC specifies that a subkey may have one
(and only one) binding signature, and zero or one revocations.  Thus
you cannot resign a subkey to un-revoke it.  I don't recall if that is
the reason the key grammar enforces exactly one binding signature, but
it would seem to follow naturally from that grammar.

Of course, you could strip off both the binding sig and revocation sig
and just make a new signature, but then you're back in the
distribution problem I mentioned earlier with un-revoking whole keys.

Part of the design of OpenPGP is that subkeys are cheap - you should
be able to make new ones easily.  In fact, there was a proposal for
perfect forward security in OpenPGP a few years ago that involved
generating new subkeys very frequently (even to the point of a new
subkey per message): http://www.apache-ssl.org/openpgp-pfs.txt

> certification signatures?

Not exactly - it revokes one signature.  However if there is more than
one signature, the earlier signature should be superseded by the later
one.

> 0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30 above)

This will work in GPG, but I don't think it is necessary - the same
thing would happen even if you removed the revocations (Note,
though, that you can't have a 0x1F on a UID.  0x1F is a direct key
signature and is not issued on a UID).

David

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 31 Jan 2009 21:59:15 +0100

Hi.

> Which signature is being revoked?  Without a signature target, it's
In a future revision of the RFC I'd suggest to add a "implementations
SHOULD use signature targets when revoking one or more signatures".

But the current way should still be allowed. I'd even clarify that it
works like this in the text.

btw: As far as I understand this works the following way:
- a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the
revocation signature AND with an earlier timestamp than the revocation
signature
BUT ONLY when calculated over the same data, which effectively means:
* Either all the 0x1Fs from the specific key (primary or sub)
* Or ALL 0x10,0x11,0x12,0x13s from the specific User ID
but NOT:
* from all User IDs or even all 0x10-0x13s and 0x1Fs

- a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME
creator as the revocation signature AND with an earlier timestamp than
the revocation signature
BUT ONLY when calculated over the same data, which effectively means:
* Only on the specific subkey, not from the other subkeys

- a 0x20 recovers everything and cannot be undone (with timestamp
tricks)

Is this correct?

Do these timestamp tricks work with subkeys and 0x28 revocation
signatures (and 0x18 subkey binding signatures)?
The RFC doesn't say anything whether the 0x28 should only affect
signatures BEFORE its own timestamp.

> revocation revoked the second.  End result: no signature.
This is in my opinion the "best" and probably "only" way it should be
handled.

Peter's idea that only the most recent valid signature per class (where
0x10-0x13 is one class, 0x1F is one, and 0x18 is one) MUST be used by an
implementation has a very little problem:
What if the most recent is revoked? This would mean, that the earlier
signature is used which is possibly bad.

So I'd suggest the way of gnupg (and perhaps other implementations?) to
be mandatory in a future RFC:
Let me copy it from David:
> the second signature superseded the first signature, and then the
> revocation revoked the second.  End result: no signature

Regards,

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 31 Jan 2009 22:17:08 +0100

On Thu, 2009-01-29 at 15:53 -0500, David Shaw wrote:
> I suspect it wouldn't hurt, but wouldn't help much either.
Why not? It would solve the problem! Or am I wrong?

> For
> force it to look at the last signature..
Yes and this is the point here, isn't it?! ;)

> that there is no signature at all (after all, the one signature it was
Well and I think that's what Peter actually wants. And that's what I'd
suggest, too.
Better to fail at all than using something probably evil, just like you
at gnupg decided with the critical bit at the signature expiration time.

I tried to think a little bit about the whole issue with revoking
previous self-sigs. I'm not sure so pleas help me with the following:
One dangerous type of attack in cryptosystems are downgrade attacks.
I build some examples in order to find out whether an attacker could do
downgrade attacks on self-sigs (e.g. with different hash algorithms and
other different and security critical subpackets) and if this would be
prevented by _generally_ revoking old self-sigs that were replaced by
new ones.

I think for these kind of attacks, revoking the old self-sigs wouldn't
help anything, would it?
Because an attacker could always strip of newer self-signatures and
revocation signatures as he likes, and thus users and actually the whole
OpenPGP-PKI really _RELY_ on functional keyservers the distribute the
complete and up-to-date version of the key.

Or do you see anything that I've missed?

Anyway, as long as the RFC allows implementations the choose which
self-signature they use (and "just" RECOMMEND to use the most recent),
I'd vote to suggest to use that revocation trick. At least if it would
work at all ^^
Have we already found a definite answer here?

Best wishes,

---

From: David Shaw <[email-masked]>
Date: Sat, 31 Jan 2009 16:39:24 -0500

> - a 0x20 recovers everything and cannot be undone (with timestamp

Not exactly.  A revocation revokes *one* signature.  Given this:

   Signature (timestamp 1)
   Signature (timestamp 2)
   Revocation (timestamp 3)

The end result is no signature - but the reason is not because the  
revocation has revoked both signatures.  The reason is because the  
signature at timestamp 2 has replaced the signature at timestamp 1,  
leaving this:

   Signature (timestamp 2)
   Revocation (timestamp 3)

And then the revocation revokes the one remaining signature.

David

---

From: David Shaw <[email-masked]>
Date: Sat, 31 Jan 2009 16:50:00 -0500

> Well and I think that's what Peter actually wants. And that's what I'd

The point I was trying to make is a little different.  The RFC  
specifies a (RECOMMENDed) way to handle this problem, so that the  
extra revocations are not needed for any implementation that is  
compliant with that advice.  This method with extra revocations is an  
attempt to force non-compliant implementations into doing the right  
thing.  I suspect this may be tilting at windmills.  These  
implementations are already disregarding the RFC advice.  It is  
difficult to use RFC advice to get a non-RFC advice following  
implementation to do the right thing.

In other words, why should they follow the RFC with regards to these  
extra revocations?  They're already disregarding the RFC advice with  
regards to signature selection.  Applications that follow the RFC  
advice don't need the extra revocations.  Applications that don't  
follow the RFC advice anyway can't be expected to follow a new piece  
of advice.

> complete and up-to-date version of the key.

Exactly right.

David

---

From: Peter Thomas <[email-masked]>
Date: Sun, 1 Feb 2009 00:41:20 +0100

> (keyservers would have the revoked copy).
Of course,...

> (and only one) binding signature, and zero or one revocations.
Wow,.. uhm could you please point me to the location that mandates this?

> Thus you cannot resign a subkey to un-revoke it.
Uhm what do you mean with this?

> I don't recall if that is
Ok,.. uhm let me think. This would also mean, that it's not possible
to later change the properties of a subkey (e.g. preferred algorithms
or it's key flags) while all this IS possible for the primary key and
for UIDs, right?

> distribution problem I mentioned earlier with un-revoking whole keys.
Yeah,.. the keyservers would prevent this.

> be able to make new ones easily.
That's true, of course. But it could be annoying if people expect
particular (sub)key ids, as they're used to it (e.g. when using a
subkey for a special role like "work" or "home").

> In fact, there was a proposal for
> generating new subkeys very frequently (even to the point of a new subkey per message)
Wouldn't this actually create new security problems? I'm by no means a
crypto-expert, but AFAIK the more one uses a key to sign/encrypt data,
the more it is likely that someone can use all this data for
statistical attacks.
And this would be especially bad for the primary key, as far as I understand?

> one signature, the earlier signature should be superseded by the later
I must apologize myself,.. but I don't understand this.
The RFC must somehow specify which of the earlier self-signatures is
revoked by it, or not? Or does it always revoke the MOST RECENT found
signature BEFORE its own timestamp? If so where is this specified (I'm
just curious, not that I wouldn't believe you ;-) )?
And if that's the case we must remember that an implementation is
allowed to use any self-signature, it's just RECOMMENDED to use the
most recent.
This would mean the following:

Public Key
User ID
0x13 timestamp 1
0x13 timestamp 2
0x30 revokes the 0x13 from timestamp 2

or:

Public Key
User ID
0x13 timestamp 1
0x30 still revokes the 0x13 from timestamp 2
0x13 timestamp 2

but now it's effectively as if we'd just have:
Public Key
User ID
0x13 timestamp 1

(isn't this what gnupg does when doing a minimize? removing all
unusable signatures?)

And even if not actually removed, an implementation would now be
allowed (as far as I understand the RFC) to use the 0x13 from
timestamp 1? Ok gnupg doesn't do this like this, as you explained in
that (sig+sig+revoc) example before, but other could.

I think I become mad ^^

> This will work in GPG, but I don't think it is necessary -
Sorry when I'm nasty, but just think of the example directly above
this text? Or the other examples I gave (with the older self-signature
using MD5 and the new SHAsomething, or other differing subpackets).
Of course probably any reasonable implementation will follow the
recommendation and just use the most recent self-sig like gnupg does
(sig+sig+revoc), but others might not.

What's the opinion on the others on this?

> the same thing would happen even if you removed the revocations
Ok but for this we have the keyservers... (thank god) ^^

> (Note,
Oopps,.. of course,.. that was a typo ;-)

Thanks again in advance,
Peter

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sun, 01 Feb 2009 01:29:24 +0100

Sorry, I haven't seen that Peter has nearly asked the same...

> > * Only on the specific subkey, not from the other subkeys
I've seen you other mail that for subkeys this isn't possible at all, as
only one 0x18 and corresponding revocation is allowed.

> And then the revocation revokes the one remaining signature.
OK I'm a little bit confused on how this works when an implementation
doesn't follow the recommendation to use the most recent self-sig,
because then it would matter whether "Revocation (timestamp 3)" applies
to "Signature (timestamp 1)" or "Signature (timestamp 2)".
But I've seen that Peter has asked nearly the same before (this time
I've got his mail in time ;) ) and so I watch there for an answer.

But on more thing: What I wrote above, with the "classes" and that it
applies only to the specific UID,.. this is actually true, right?

Greets,

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sun, 01 Feb 2009 02:18:33 +0100

On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote:
> compliant with that advice.
Ok,.. in that case (if an implementation follows that advice, we don't
have to talk, as you're right and everything is fine :-)

>   This method with extra revocations is an  
Ok I got your point,.. and the following is probably a little bit
pedantic and quibbling. The point I was trying to make is:
As this "use the most recent" is "only" a RECOMMENDS, an implementation
might not follow this advice, and would be still conforming, right?
As you've said, it's only an advice.

We cannot do anything about really-non-conforming implementations (the
ones that breaks the MUSTs and so on), so lets forget about them.

But the just plain (very) stupid ones which are compliant (and thus
would follow the revocations of the previous self-sigs, as Peter
suggested) but don't follow that advice/recommendation would break and
possibly do bad things.
And this could be avoided by following Peters ideas.

To conclude:

Public Key
0x1F (timestamp 1)
0x30 (timestamp 2) revokes ONLY the 0x1F from timestamp 1
0x1F (timestamp 3)
0x30 (timestamp 4) revokes ONLY the 0x1F from timestamp 3
0x1F (timestamp 5)
UID
0x13 (timestamp 1)
0x30 (timestamp 2) revokes ONLY the 0x13 from timestamp 1
0x13 (timestamp 3)
0x30 (timestamp 4) revokes ONLY the 0x13 from timestamp 3
0x13 (timestamp 5)

would work as I described in the example, and ONLY:
0x1F (timestamp 5)
0x13 (timestamp 5)
would be usable, right?

But something like:
Subkey
0x18 (timestamp 1)
0x28 (timestamp 2) revokes ONLY the 0x13 from timestamp 1
0x18 (timestamp 3)
doesn't work, and the subkey will still be revoked.

Is this correct so far, and something we can agree on? :-)

I don't want to judge whether this is really necessary for the real
world, as probably most sane implementations follow the advice, to use
the most recent only, and thus the sig+sig+revoc thingy will work.
(Of course for all of this, a working key server infrastructure is
needed)

Personally I'd prefer that a future version of the RFC really enforces
that advice, in order to be 100% sure, that in every conforming
application, the sig1+sig2+revoc example or sig1+sig2 example works as
expected.

> > complete and up-to-date version of the key.
Excellent :-)

Good night (at least in my time zone ;) ),
-- 
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München

---

From: David Shaw <[email-masked]>
Date: Sat, 31 Jan 2009 22:17:58 -0500

> Wow,.. uhm could you please point me to the location that mandates  

Section 11.1.  But notice what that section is: Transferable Public  
Keys.  This doesn't really mean you *can't* re-sign a subkey.  It just  
means that once you *have* re-signed a subkey, you need to remove the  
old signature (and revocation, if any) before you give the key to  
anyone else.

> subkey for a special role like "work" or "home").

Subkeys aren't really usable for roles.  User IDs make great roles.   
Subkeys can be used by anyone who cares to, so if you have two  
encryption keys, even though you intend one for "home" and one for  
"work", you have no way to tell me which one you want me to use, and  
even if you did, I could use the other one if I wanted to.

> just curious, not that I wouldn't believe you ;-) )?

The RFC specifies the signature target which lets a revocation  
indicate which signature is being revoked.  Aside from that, there is  
no indication at all beyond that the revocation is issued over the  
same data as the signature being revoked, and that it is dated after  
the original signature.  It's not most recent, it's not least recent,  
it's simply not specified.

David

---

From: David Shaw <[email-masked]>
Date: Sat, 31 Jan 2009 22:36:38 -0500

> only one 0x18 and corresponding revocation is allowed.

Unless you strip off the old 0x18 and revocation.

> to "Signature (timestamp 1)" or "Signature (timestamp 2)".

If an implementation doesn't follow the recommendation, then most of  
the bets are off.  You can't really predict what it will do.  Will it  
decide that signature 2 is revoked, and thus act on signature 1?   
Maybe.  Will it decide that signature 1 is revoked, and thus act on  
signature 2?  Maybe.

Again, though, I have to stress that this is RFC pedantic nitpickery.   
In the real world, no implementation does this, as it would make  
little sense.

> applies only to the specific UID,.. this is actually true, right?

I'm not sure I understand the question here.

David

---

From: David Shaw <[email-masked]>
Date: Sat, 31 Jan 2009 22:36:20 -0500

> Is this correct so far, and something we can agree on? :-)

No, because that implementation, completely in accordance with the  
RFC, does not have to regard that user ID as valid after seeing a  
single revocation.  An implementation is free to treat any user ID  
with a revocation on it as permanently dead.

I understand what you're trying to accomplish, I really do.   
Unfortunately, the RFC doesn't give you the tools to do what you  
want.  Luckily, the problem you're trying to solve isn't actually a  
problem with any known implementation of OpenPGP.

If you want to generate extra revocations, go right ahead (it should  
work fine), but understand it is not a "RFC safe" way of doing things.

David

From: David Shaw <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: Ideas on new user attribute types and image formats
Date: Sat, 31 Jan 2009 22:46:55 -0500
Sender: [email-masked]

On Jan 31, 2009, at 11:27 AM, Daniel Kahn Gillmor wrote:

> * I'd like to see better cryptographic verification tools that take
> advantage of OpenPGP's WoT to display human-comprehensible  
> descriptions
> of relevant trust paths to an attempted validation.  Since most people
> use graphical environments, and most people recognize people by their
> faces even more quickly than by their names, it would be great to show
> such trust paths with images in them (e.g. "Mary says that this is  
> Joe"
> is useful, but a picture of Mary saying "this is Joe" would be even  
> more
> appealing to many users).

I like this one in particular.  The WoT is one of the least understood  
parts of OpenPGP.  Doing it graphically would help.

> Plus, it would be cool ;)

Yes.

David

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
Date: Sat, 31 Jan 2009 22:36:38 -0500
Sender: [email-masked]

David

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
Date: Sat, 31 Jan 2009 22:36:20 -0500
Sender: [email-masked]

> Is this correct so far, and something we can agree on? :-)

No, because that implementation, completely in accordance with the  
RFC, does not have to regard that user ID as valid after seeing a  
single revocation.  An implementation is free to treat any user ID  
with a revocation on it as permanently dead.

I understand what you're trying to accomplish, I really do.   
Unfortunately, the RFC doesn't give you the tools to do what you  
want.  Luckily, the problem you're trying to solve isn't actually a  
problem with any known implementation of OpenPGP.

If you want to generate extra revocations, go right ahead (it should  
work fine), but understand it is not a "RFC safe" way of doing things.

David

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
Date: Sat, 31 Jan 2009 22:17:58 -0500
Sender: [email-masked]

David

Subject: Re: Series of minor questions about OpenPGP 4
From: Christoph Anton Mitterer <[email-masked]>
To: OpenPGP <[email-masked]>
Date: Sun, 01 Feb 2009 02:18:33 +0100
Sender: [email-masked]

--=-ejjO4YdNwXfBCtVKk5DF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote:
> The point I was trying to make is a little different.  The RFC =20
> specifies a (RECOMMENDed) way to handle this problem, so that the =20
> extra revocations are not needed for any implementation that is =20

>   This method with extra revocations is an =20
> attempt to force non-compliant implementations into doing the right =20
> thing.  I suspect this may be tilting at windmills.  These =20
> implementations are already disregarding the RFC advice.  It is =20
> difficult to use RFC advice to get a non-RFC advice following =20

To conclude:

Public Key
0x1F (timestamp 1)

But something like:
Subkey
0x18 (timestamp 1)

> > revocation signatures as he likes, and thus users and actually the =20
> > whole
Excellent :-)

Good night (at least in my time zone ;) ),
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

--=-ejjO4YdNwXfBCtVKk5DF
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

--=-ejjO4YdNwXfBCtVKk5DF--

Cc: Christoph Anton Mitterer <[email-masked]>
From: Wim Lewis <[email-masked]>
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
Date: Sat, 31 Jan 2009 16:30:10 -0800
To: [email-masked]
Sender: [email-masked]

(Attention Conservation Notice: non-expert explaining why he thinks  
the current system is almost-good-enough without securing keyservers)

This is an interesting point. After thinking about it a little,  
though, I think that securing the keyserver (or the communication  
with the keyserver) isn't quite the right approach. One of the  
strengths of the PGP setup, I think, is that you don't have to trust  
the keyserver; all it's doing is making it easier for you to get  
information that you can in theory get elsewhere.

An end-to-end approach is better, IMHO. (It also protects against the  
opposite side of the equation: is Mallory secretly stripping the  
revocation certificate out of your friend's uploads to the keyserver?  
Also, I don't want to have to make trust/policy decisions based on  
how much I trust the people running the keyserver, how strong my  
trust path is to their key, and so on. That way lies X.509...)  
Notionally, I want some sort of periodic, signed communication from  
other keyholders, saying, "The official state of my key-and- 
subpackets is X. Expect another message before date Y". However, not  
all of the subpackets are really important: if I'm missing a  
signature from someone else, or an alternate user ID, I'm not going  
to trust you any *more* than if I have it. So this thing only needs  
to cover packets which reduce trust --- revocations, I guess. (Am I  
missing a scenario here?)

But is this actually any different from periodically renewing a set  
of expiring signatures? (I don't think so, but I could easily be  
missing stuff.) In which case, OpenPGP already supplies everything  
needed to prevent this sort of denial-of-key-distribution attack.

For this to work, the spec has to follow a principle: any subpacket  
must either (a) only increase trust, not decrease it; or (b) be more- 
or-less equivalent to early expiration of another subpacket. How  
close is OpenPGP to this?

Actual implementations might get in the way, on the other hand. In  
the past I have tried maintaining a key with a non-expiring signature  
on the signing key and a rotating, expiring signature on the (sole)  
encryption subkey. A lot of software seemed to dislike this, and  
seemed to assume that if the encryption subkey had *any* expired  
signatures, it was invalid, even if it had a later, still-valid  
signature.

As a UI detail, it might be nice to have a bit on an expiring  
signature indicating whether a renewed signature is expected,  
possibly in the form of an "expiration reason" field a la  
RFC4880-5.2.3.23. This shouldn't, I think, be acted upon by the trust- 
computation code, but might be useful to help decide whether to try  
to refresh that key. On the other hand, maybe the software should  
just infer this bit from the existence of previous, expired  
signatures in the keyring.

> One possibility would be do static_cast<keyservers>(DNSSEC) and  
> implement a secured keyserver protocol.

Of course I think securing the keyserver communication is *also*  
good, as long as the trust model doesn't depend on it. :) If nothing  
else, doing a keyring refresh broadcasts to a listener or MITM the  
contents of your keyring, which you might consider sensitive  
information.

Subject: Re: Series of minor questions about OpenPGP 4
From: Christoph Anton Mitterer <[email-masked]>
To: OpenPGP <[email-masked]>
Date: Sun, 01 Feb 2009 01:29:24 +0100
Sender: [email-masked]

--=-Y+ib95DYU5whaLgBOtzE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>=20
>=20
>=20
> The end result is no signature - but the reason is not because the =20
> revocation has revoked both signatures.  The reason is because the =20
> signature at timestamp 2 has replaced the signature at timestamp 1, =20
> leaving this:
>=20
>    Signature (timestamp 2)
>    Revocation (timestamp 3)
>=20

Greets,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

--=-Y+ib95DYU5whaLgBOtzE
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

--=-Y+ib95DYU5whaLgBOtzE--

Date: Sun, 1 Feb 2009 00:41:20 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Of course,...

Public Key
User ID
0x13 timestamp 1
0x13 timestamp 2

or:

Public Key
User ID
0x13 timestamp 1

I think I become mad ^^

Thanks again in advance,
Peter

Subject: Do we need to secure our keyservers against kind of DoS Attacks
From: Christoph Anton Mitterer <[email-masked]>
To: [email-masked]
Date: Sat, 31 Jan 2009 23:54:48 +0100
Sender: [email-masked]

--=-fI4cA5PVR5NpFuKeqTKZ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi.

I having the following issue on my OpenPGP "TODO" list for some very
long time now, and David just remembered me on it.

On Fri, 2009-01-30 at 22:48 -0500, David Shaw wrote:=20
> (keyservers would have the revoked copy).

Keyservers are very critical for any PKI to work, aren't they?
I mean there are plenty of "attacks" which would be possible without
them:
- we couldn't get revocations
- we prone to attacks where someone simply removes some subpackets (e.g.
a revocation signature, or a newer and updated self-signature)
- there might be even more cases I can't think of

Of course our keyservers work quite well, I can to some "upgrade my
keyring" command and get the new keys and all added packets.
And the big advantage is that no one can remove anything from them (it's
even difficult for the admins, though probably not impossible).

But there is the possibility of a kind of a DoS-Attack; service in the
sense of "deliver the whole key and everything belonging to it to the
requester".
Imagine that my ISP is evil, tracks my connections and always removes
some revocation signatures when I get the data.

Are there currently working means to prevent this?

One possibility would be do static_cast<keyservers>(DNSSEC) and
implement a secured keyserver protocol.
Of course we should use OpenPGP for this :-)
A keyring could always sign the data he sends to a user, and the user
could have the public key from that keyserver set up somewhere in his
implementation as valid for acting as keyserver.

Of course one could build trust-paths to the keyserver's public keys, et
cetera, et cetera.

Now the ISP could only block the whole keyserver, but at least I'd
notice it and an implementation could WARN me if for example regularly
updates of the keyrings don't work.

Just an idea,... :-)

Regards,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

--=-fI4cA5PVR5NpFuKeqTKZ
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

--=-fI4cA5PVR5NpFuKeqTKZ--

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
Date: Sat, 31 Jan 2009 16:50:00 -0500
Sender: [email-masked]

Exactly right.

David

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
Date: Sat, 31 Jan 2009 16:39:24 -0500
Sender: [email-masked]

   Signature (timestamp 1)
   Signature (timestamp 2)
   Revocation (timestamp 3)

   Signature (timestamp 2)
   Revocation (timestamp 3)

David

Subject: Re: Series of minor questions about OpenPGP 4
From: Christoph Anton Mitterer <[email-masked]>
To: [email-masked]
Date: Sat, 31 Jan 2009 22:17:08 +0100
Sender: [email-masked]

--=-x5emVcJYmKLf9v7gskHU
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> For
> example, given this:
>=20
>   Signature =3D=3D=3D January 1
>   Signature =3D=3D=3D January 3
>   Signature =3D=3D=3D January 5
>=20
>=20
>   Signature  =3D=3D=3D January 1
>   Revocation =3D=3D=3D January 2
>   Signature  =3D=3D=3D January 3
>   Revocation =3D=3D=3D January 4
>   Signature  =3D=3D=3D January 5
>=20
>=20

Best wishes,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

--=-x5emVcJYmKLf9v7gskHU
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

--=-x5emVcJYmKLf9v7gskHU--

Subject: Re: Series of minor questions about OpenPGP 4
From: Christoph Anton Mitterer <[email-masked]>
To: [email-masked]
Date: Sat, 31 Jan 2009 21:59:15 +0100
Sender: [email-masked]

--=-Gx8EiQTEsNPhwrfamHlI
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi.

Is this correct?

> revocation revoked the second.  End result: no signature

Regards,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

--=-Gx8EiQTEsNPhwrfamHlI
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

--=-Gx8EiQTEsNPhwrfamHlI--

Date: Sat, 31 Jan 2009 11:27:29 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: Jon Callas <[email-masked]>
CC: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: Ideas on new user attribute types and image formats
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5D1905824B75BAAC23BDF3CE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/30/2009 07:54 PM, Jon Callas wrote:
> I'll add in that I think adding PNG is fine with me, and that's why =20
> I'll also be devil's advocate. So what?
>=20
> I think that "because it would be cool" is a fine answer. We should =20
> say it, if that's why.

Good point!  FWIW, i actually have a couple specific implementation
possibilities in mind, because i'm interested in seeing an expansion of
places where OpenPGP is used [0].  The following ideas don't have
anything close to a concrete implementation yet, but transparent PNGs
would make them even more aesthetically appealing.

 * instant messaging: OTR [1] is a platform-agnostic IM
encryption/authentication layer, which currently uses RSA keys for
mutual authentication.  I'd love to see OTR be able to use the OpenPGP
web of trust to handle the actual authentication (though it currently
does not).  If it did, then PNG User Attribute support would allow
graphical OTR-compliant IM implementations to automatically select
hackergotchi-style images for pretty IM conversation displays (think
"word-balloon" style).

 * I'd like to see better cryptographic verification tools that take
advantage of OpenPGP's WoT to display human-comprehensible descriptions
of relevant trust paths to an attempted validation.  Since most people
use graphical environments, and most people recognize people by their
faces even more quickly than by their names, it would be great to show
such trust paths with images in them (e.g. "Mary says that this is Joe"
is useful, but a picture of Mary saying "this is Joe" would be even more
appealing to many users).

Plus, it would be cool ;)

These are just some ideas to chew on.  i wish i had more time to work on
such craziness.

	--dkg

[0] http://web.monkeysphere.info/ is the furthest advanced
implementation of any push to extend the reach of the OpenPGP
web-of-trust that i'm involved in.

[1] http://www.cypherpunks.ca/otr/

--------------enig5D1905824B75BAAC23BDF3CE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5D1905824B75BAAC23BDF3CE--

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 6
Date: Fri, 30 Jan 2009 23:04:04 -0500
Sender: [email-masked]

On Jan 30, 2009, at 5:14 PM, Peter Thomas wrote:

(skipping the ones Jon answered)

> I tried to create the following example and wonder whether my
> interpretation is always correct:
> Given is a public key, with several User IDs signed with 0x13s, a
> direct key signature 0x1F and several subkeys signed with an 0x18:
> (look closely as there are minor differences between the stuff  
> below ;-) )
>
> I) Subpackets on the 0x1F direct key signature (there should be only  
> one of it):
> - signature creation/expiration time
> In principle it has only a meaning for the 0x1F itself, but it might
> also expire the key as described int I) 1 and I) 2 above.
>
> - key expiration time
> The expiration time of the WHOLE key with all UIDs, subkeys, etc.
> An implementation MAY decide when to use the key expiration from the
> 0x1F. Reasonable ways would be:
> * when no other self-sig specify one (thus it works globally for the  
> key)
> * when the key was found/selected by the KeyID (this is  
> questionable, isn't it?)
> * or it may even take priority in favor of all other key expiration
> times on other signatures, like 0x13's (but not 0x18s because subkeys
> have their own expiration time!!!!)

Use the shortest expiration time.   If the 0x1F says you have 10 days,  
and the 0x13 says you have 5 days, you have 5 days.  As you note, the  
subkeys have their own expiration time - but not if they exceed the  
whole key expiration time.  You can't have a subkey that lives beyond  
its primary key.

> - preferred symmetric/hash/compression algorithm
> An implementation MAY decide when to use these from the 0x1F.
> Reasonable ways would be:
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when the key was found/selected by the Key ID (here I think this is
> NOT questionable as above)
> * or it may even take priority in favor of all other preferred
> algorithms on other signatures, like 0x13's and 0x18's

  If you have preferred algorithms in both the 0x1F and a 0x13, then  
you use the one with the narrowest scope.  So, if the key was chosen  
by a particular user ID, you use the preferred algorithms from that  
user ID's selfsig.  If that selfsig does not have preferred  
algorithms, use the one in the 0x1F.  If the key was chosen by key ID  
(so there is no one particular user ID) you use the preferred  
algorithm from the primary user ID.  As before, if there is no  
preferred algorithm there, use the one from the 0x1F.  If there is  
preferred algorithms on a 0x18, I think I'd take the union of those  
algorithms with the ones from the user ID or 0x1F.

> - key server preferences / preferred key server / key flags / features
> An implementation MAY decide when to use these from the 0x1F.
> Reasonable ways would be:
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when the key was found/selected by the Key ID (here I think this is
> NOT questionable as above)
> * or it may even take priority in favor of all other preferred
> algorithms on other signatures, like 0x13's and 0x18's
>
>
> II) Subpackets on any of the 0x10-0x13 certification signatures:
> - signature creation/expiration time
> In principle it has only a meaning for the 0x10-0x13 itself, but it
> might also expire the specific User ID (if there is no other valid
> self-signature on it).
>
> - key server preferences / preferred key server / key flags / features
> An implementation MAY decide when to use these from the 0x10-0x13.
> Reasonable ways would be:
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when there is no global setting via a 0x1F self-signature
> * when the key was found/selected by the specific User ID (here I
> think this is NOT questionable as above), or it was specified as
> Signers User ID subpacket
>
>
> III) Subpackets on the 0x18 subkey binding signature:
> - signature creation/expiration time
> In principle it has only a meaning for the 0x18 itself, but it might
> also expire the specific subkey (if there is no other valid
> self-signature on it).
>
> - key expiration time
> The expiration time ONLY of the specific subkey, not of any other
> subkey, any User ID or even the whole primary key.
> This only applies to the specifix subkey, so an implementation cannot
> choose anything (as with the key expiration times above)
>
> - preferred symmetric/hash/compression algorithm
> An implementation MAY decide when to use these from the 0x18.
> Reasonable ways would be:
> * when that specific subkey was used for encryption/signing/or
> selected somehow else
> and optionally (the above condition seems nearly mandatory):
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when there is no global setting via a 0x1F self-signature
>
> - key server preferences / preferred key server / key flags / features
> An implementation MAY decide when to use these from the 0x18.
> Reasonable ways would be:
> * when that specific subkey was used for encryption/signing/or
> selected somehow else
> and optionally (the above condition seems nearly mandatory):
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when there is no global setting via a 0x1F self-signature
>
> Is this all correct / ok / within the borders of the CURRENT rfc?
>
> Ok that was a lot ^^
>
>
> Lots of thanks in advance,
> Peter
>

Date: Fri, 30 Jan 2009 22:48:40 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

Right.

Right.

Right.

David

Subject: Re: Series of minor questions about OpenPGP 4
From: Christoph Anton Mitterer <[email-masked]>
To: Peter Thomas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Date: Sat, 31 Jan 2009 02:36:23 +0100
Sender: [email-masked]

--=-a2zdl3WhkIRphpiliK9b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello WG and Peter.

User Attributes =3D)

See above.

In the meantime: Happy discussing =3D)
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

--=-a2zdl3WhkIRphpiliK9b
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

--=-a2zdl3WhkIRphpiliK9b--

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
To: Peter Thomas <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
Date: Fri, 30 Jan 2009 17:04:32 -0800
Sender: [email-masked]

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
To: Peter Thomas <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 6
Date: Fri, 30 Jan 2009 17:02:54 -0800
Sender: [email-masked]

>
> I) General questions about the sematics:
> 1) signature creation time (2)
> Does the RFC imply, that a signature (of any type) is to be considered
> invalid, if the current time is not after the signature creation time?
> If so this would even mean that a key from the future is "unusable" if
> all self-signatures are invalid because of this, right?

In general, we want to let someone sign something for the future.  
There are many times when a signed object needs to be created in  
advance. That we call it "creation time" rather than "not before" is  
an eccentricity with an obvious right thing to do.

So yeah, if someone creates a key that has a creation time of  
tomorrow, it's not valid yet.

>
>
> 2) signature expiration time (3)
> If the signature is expired it is to be considered invalid. It my thus
> have the same effect as key expiration time when all self-signatures
> are invalided because they're expired, right?

Yes.

>
>
> 3) key expiration time (9)
> I've probably asked this before. But, what happens if different key
> expiration times are specified in the self-signatures? Is it left to
> the implementation to decide what to do?

Yes. There are plenty of obvious right things to do. Let's suppose I  
am moving from example.com to foobar.com next Monday, but I quit  
example.com effective today (and set an expiration time that reflects  
that). From now until Monday, neither user name is valid.

>
>
> 4) exportable certification (4)
> Does this have a meaning on subkey binding signatures (0x18)? E.g.
> something like don't import the signature itself and neither the
> subkey?

I have applications for this, myself. Yes.

Here is my example for which this is a possible solution.

PGP Corporation has a public key for "[email-masked]" so people can  
send us security reports that are encrypted. I want to have the  
encryption subkey on my personal key, but I don't want to publish it.  
A non-exportable binding signature is a possible solution.

>
>
> 5) Is it allowed that more than on subpackets of the same type exist
> in the same signature?
> E.g. Two policy URIs in on 0x13, or two preferred key servers. And
> what would it mean?

It makes sense to me to have two preferred keyservers. I don't have an  
opinion about policy URIs, but I wouldn't discount it automatically  
out of hand.

>
>
>
>
>
> I tried to create the following example and wonder whether my
> interpretation is always correct:
> Given is a public key, with several User IDs signed with 0x13s, a
> direct key signature 0x1F and several subkeys signed with an 0x18:
> (look closely as there are minor differences between the stuff  
> below ;-) )

I'm not going to comment further, but only because I'm in a hurry and  
haven't memorized the hex values.

>
>
> I) Subpackets on the 0x1F direct key signature (there should be only  
> one of it):
> - signature creation/expiration time
> In principle it has only a meaning for the 0x1F itself, but it might
> also expire the key as described int I) 1 and I) 2 above.
>
> - key expiration time
> The expiration time of the WHOLE key with all UIDs, subkeys, etc.
> An implementation MAY decide when to use the key expiration from the
> 0x1F. Reasonable ways would be:
> * when no other self-sig specify one (thus it works globally for the  
> key)
> * when the key was found/selected by the KeyID (this is  
> questionable, isn't it?)
> * or it may even take priority in favor of all other key expiration
> times on other signatures, like 0x13's (but not 0x18s because subkeys
> have their own expiration time!!!!)
>
> - preferred symmetric/hash/compression algorithm
> An implementation MAY decide when to use these from the 0x1F.
> Reasonable ways would be:
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when the key was found/selected by the Key ID (here I think this is
> NOT questionable as above)
> * or it may even take priority in favor of all other preferred
> algorithms on other signatures, like 0x13's and 0x18's
>
> - key server preferences / preferred key server / key flags / features
> An implementation MAY decide when to use these from the 0x1F.
> Reasonable ways would be:
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when the key was found/selected by the Key ID (here I think this is
> NOT questionable as above)
> * or it may even take priority in favor of all other preferred
> algorithms on other signatures, like 0x13's and 0x18's
>
>
> II) Subpackets on any of the 0x10-0x13 certification signatures:
> - signature creation/expiration time
> In principle it has only a meaning for the 0x10-0x13 itself, but it
> might also expire the specific User ID (if there is no other valid
> self-signature on it).
>
> - key expiration time
> The expiration time of the WHOLE key with all UIDs, subkeys, etc.
> An implementation MAY decide when to use the key expiration from the
> 0x10-0x13. Reasonable ways would be:
> * when no other self-sig specify one (thus it works globally for the  
> key)
> * when there is no global setting via a 0x1F self-signature
> * when the key was found/selected by the specific User ID (this is
> questionable, isn't it?), or it was specified as Signers User ID
> subpacket
>
> - preferred symmetric/hash/compression algorithm
> An implementation MAY decide when to use these from the 0x10-0x13.
> Reasonable ways would be:
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when there is no global setting via a 0x1F self-signature
> * when the key was found/selected by the specific User ID (here I
> think this is NOT questionable as above), or it was specified as
> Signers User ID subpacket
>
> - key server preferences / preferred key server / key flags / features
> An implementation MAY decide when to use these from the 0x10-0x13.
> Reasonable ways would be:
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when there is no global setting via a 0x1F self-signature
> * when the key was found/selected by the specific User ID (here I
> think this is NOT questionable as above), or it was specified as
> Signers User ID subpacket
>
>
> III) Subpackets on the 0x18 subkey binding signature:
> - signature creation/expiration time
> In principle it has only a meaning for the 0x18 itself, but it might
> also expire the specific subkey (if there is no other valid
> self-signature on it).
>
> - key expiration time
> The expiration time ONLY of the specific subkey, not of any other
> subkey, any User ID or even the whole primary key.
> This only applies to the specifix subkey, so an implementation cannot
> choose anything (as with the key expiration times above)
>
> - preferred symmetric/hash/compression algorithm
> An implementation MAY decide when to use these from the 0x18.
> Reasonable ways would be:
> * when that specific subkey was used for encryption/signing/or
> selected somehow else
> and optionally (the above condition seems nearly mandatory):
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when there is no global setting via a 0x1F self-signature
>
> - key server preferences / preferred key server / key flags / features
> An implementation MAY decide when to use these from the 0x18.
> Reasonable ways would be:
> * when that specific subkey was used for encryption/signing/or
> selected somehow else
> and optionally (the above condition seems nearly mandatory):
> * when no other self-sig specifies them (thus they work globally for  
> the key)
> * when there is no global setting via a 0x1F self-signature
>
> Is this all correct / ok / within the borders of the CURRENT rfc?
>
> Ok that was a lot ^^
>
>
> Lots of thanks in advance,
> Peter
>

From: Jon Callas <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: Ideas on new user attribute types and image formats
Date: Fri, 30 Jan 2009 16:54:01 -0800
Sender: [email-masked]

>>
>
> hpng supports features that jpeg doesn't, including at least:
>
> * indexed colormaps
> * alpha-channel transparency
>
> Both of these are useful features in some not uncommon circumstances
> (e.g. logos and "hackergotchi"/floating-head images that discard
> background/non-identity information).
>
> I'm not suggesting that OpenPGP is worthless without PNG, of course.
> But it would be useful to support it.

I'll add in that I think adding PNG is fine with me, and that's why  
I'll also be devil's advocate. So what?

I think that "because it would be cool" is a fine answer. We should  
say it, if that's why.

	Jon

Date: Sat, 31 Jan 2009 01:04:33 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Ahhhh....

now I add a:

Ok I see.

Public Key
UID1

Thanks for your help,
Peter

Date: Sat, 31 Jan 2009 00:39:17 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

Well that's a point.

Cheers,
Peter

Date: Fri, 30 Jan 2009 23:14:31 +0100
Subject: Series of minor questions about OpenPGP 6
From: Peter Thomas <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Greetings.

I've already threatened that I'd have more questions so here they are ;-)

The following is about the correct interpretation of several signature
subpackets on the different types of self-signatures. It would be
great if you could tell me whether my interpretation of the CURRENT
rfc and thus my interpretations of the semantical meanings are
correct.

I) General questions about the sematics:
1) signature creation time (2)
Does the RFC imply, that a signature (of any type) is to be considered
invalid, if the current time is not after the signature creation time?
If so this would even mean that a key from the future is "unusable" if
all self-signatures are invalid because of this, right?

2) signature expiration time (3)
If the signature is expired it is to be considered invalid. It my thus
have the same effect as key expiration time when all self-signatures
are invalided because they're expired, right?

3) key expiration time (9)
I've probably asked this before. But, what happens if different key
expiration times are specified in the self-signatures? Is it left to
the implementation to decide what to do?

4) exportable certification (4)
Does this have a meaning on subkey binding signatures (0x18)? E.g.
something like don't import the signature itself and neither the
subkey?

5) Is it allowed that more than on subpackets of the same type exist
in the same signature?
E.g. Two policy URIs in on 0x13, or two preferred key servers. And
what would it mean?

I tried to create the following example and wonder whether my
interpretation is always correct:
Given is a public key, with several User IDs signed with 0x13s, a
direct key signature 0x1F and several subkeys signed with an 0x18:
(look closely as there are minor differences between the stuff below ;-) )

I) Subpackets on the 0x1F direct key signature (there should be only one of it):
- signature creation/expiration time
In principle it has only a meaning for the 0x1F itself, but it might
also expire the key as described int I) 1 and I) 2 above.

- key expiration time
The expiration time of the WHOLE key with all UIDs, subkeys, etc.
An implementation MAY decide when to use the key expiration from the
0x1F. Reasonable ways would be:
* when no other self-sig specify one (thus it works globally for the key)
* when the key was found/selected by the KeyID (this is questionable, isn't it?)
* or it may even take priority in favor of all other key expiration
times on other signatures, like 0x13's (but not 0x18s because subkeys
have their own expiration time!!!!)

- preferred symmetric/hash/compression algorithm
An implementation MAY decide when to use these from the 0x1F.
Reasonable ways would be:
* when no other self-sig specifies them (thus they work globally for the key)
* when the key was found/selected by the Key ID (here I think this is
NOT questionable as above)
* or it may even take priority in favor of all other preferred
algorithms on other signatures, like 0x13's and 0x18's

- key server preferences / preferred key server / key flags / features
An implementation MAY decide when to use these from the 0x1F.
Reasonable ways would be:
* when no other self-sig specifies them (thus they work globally for the key)
* when the key was found/selected by the Key ID (here I think this is
NOT questionable as above)
* or it may even take priority in favor of all other preferred
algorithms on other signatures, like 0x13's and 0x18's

II) Subpackets on any of the 0x10-0x13 certification signatures:
- signature creation/expiration time
In principle it has only a meaning for the 0x10-0x13 itself, but it
might also expire the specific User ID (if there is no other valid
self-signature on it).

- key expiration time
The expiration time of the WHOLE key with all UIDs, subkeys, etc.
An implementation MAY decide when to use the key expiration from the
0x10-0x13. Reasonable ways would be:
* when no other self-sig specify one (thus it works globally for the key)
* when there is no global setting via a 0x1F self-signature
* when the key was found/selected by the specific User ID (this is
questionable, isn't it?), or it was specified as Signers User ID
subpacket

- preferred symmetric/hash/compression algorithm
An implementation MAY decide when to use these from the 0x10-0x13.
Reasonable ways would be:
* when no other self-sig specifies them (thus they work globally for the key)
* when there is no global setting via a 0x1F self-signature
* when the key was found/selected by the specific User ID (here I
think this is NOT questionable as above), or it was specified as
Signers User ID subpacket

- key server preferences / preferred key server / key flags / features
An implementation MAY decide when to use these from the 0x10-0x13.
Reasonable ways would be:
* when no other self-sig specifies them (thus they work globally for the key)
* when there is no global setting via a 0x1F self-signature
* when the key was found/selected by the specific User ID (here I
think this is NOT questionable as above), or it was specified as
Signers User ID subpacket

III) Subpackets on the 0x18 subkey binding signature:
- signature creation/expiration time
In principle it has only a meaning for the 0x18 itself, but it might
also expire the specific subkey (if there is no other valid
self-signature on it).

- key expiration time
The expiration time ONLY of the specific subkey, not of any other
subkey, any User ID or even the whole primary key.
This only applies to the specifix subkey, so an implementation cannot
choose anything (as with the key expiration times above)

- preferred symmetric/hash/compression algorithm
An implementation MAY decide when to use these from the 0x18.
Reasonable ways would be:
* when that specific subkey was used for encryption/signing/or
selected somehow else
and optionally (the above condition seems nearly mandatory):
* when no other self-sig specifies them (thus they work globally for the key)
* when there is no global setting via a 0x1F self-signature

- key server preferences / preferred key server / key flags / features
An implementation MAY decide when to use these from the 0x18.
Reasonable ways would be:
* when that specific subkey was used for encryption/signing/or
selected somehow else
and optionally (the above condition seems nearly mandatory):
* when no other self-sig specifies them (thus they work globally for the key)
* when there is no global setting via a 0x1F self-signature

Is this all correct / ok / within the borders of the CURRENT rfc?

Ok that was a lot ^^

Lots of thanks in advance,
Peter

Date: Fri, 30 Jan 2009 15:06:12 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: Peter Thomas <[email-masked]>
CC: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF87E6C5E2432703861AE0346
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

For example, here's a policy statement: "This identity is found on
official government documents in the legitimate possession of the keyhold=
er"

>=20

btw, please don't take my opposition to this particular idea as
opposition to you proposing changes to the OpenPGP specification in
general.  It's great to see this sort of discussion.  Thanks for raising =
it!

	--dkg

--------------enigF87E6C5E2432703861AE0346
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigF87E6C5E2432703861AE0346--

Date: Fri, 30 Jan 2009 14:59:17 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

Take this example:

  User ID

David

Date: Fri, 30 Jan 2009 20:38:06 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

Peter

Date: Fri, 30 Jan 2009 20:17:41 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Date: Fri, 30 Jan 2009 13:37:45 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: Peter Thomas <[email-masked]>
CC: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig00D63C42AC6D682BB8B7BF9C
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/30/2009 01:15 PM, Peter Thomas wrote:
> 0x10-0x13: The policy that is used for signing, with the corresponding =
UserID.
>=20

	--dkg

--------------enig00D63C42AC6D682BB8B7BF9C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig00D63C42AC6D682BB8B7BF9C--

Date: Fri, 30 Jan 2009 19:24:47 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Ooops XD

Of course...

Thanks for your advice,
Peter

Date: Fri, 30 Jan 2009 19:15:32 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Yes :-)

Best wishes,
Peter

Date: Fri, 30 Jan 2009 19:05:02 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

Cheers,
Peter

Date: Fri, 30 Jan 2009 12:42:38 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: [email-masked]
Subject: Re: Ideas on new user attribute types and image formats
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6CD7643A5DEA3431196DB021
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/30/2009 11:23 AM, David Shaw wrote:
> We need (in the abstract) a way to store a picture in an OpenPGP user
> ID, and we have that now.  What does adding a second way to store that
> picture buy us that we don't have already?

hpng supports features that jpeg doesn't, including at least:

 * indexed colormaps
 * alpha-channel transparency

Both of these are useful features in some not uncommon circumstances
(e.g. logos and "hackergotchi"/floating-head images that discard
background/non-identity information).

I'm not suggesting that OpenPGP is worthless without PNG, of course.
But it would be useful to support it.

	--dkg

--------------enig6CD7643A5DEA3431196DB021
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig6CD7643A5DEA3431196DB021--

Date: Fri, 30 Jan 2009 11:23:47 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Ideas on new user attribute types and image formats
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Fri, Jan 30, 2009 at 10:23:47AM -0500, Daniel Kahn Gillmor wrote:
> On 01/29/2009 01:23 PM, Peter Thomas wrote:
> > 1) PNG (ISO 15948, RFC 2083)
> 
> I fully agree that we should be supporting PNG here.  That's long
> overdue, and you don't have to do lossless compression in png, iiuc.

We need (in the abstract) a way to store a picture in an OpenPGP user
ID, and we have that now.  What does adding a second way to store that
picture buy us that we don't have already?

I'm not really for or against PNG in OpenPGP, but I don't yet see the
point here.

David

Date: Fri, 30 Jan 2009 11:03:29 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Date: Fri, 30 Jan 2009 10:30:28 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC0E96254D1723DA3223AF8A1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 primary_key
  \-uid
    +--sigX
    \--sigY

 primary_key
  \-uid
    +--sigY
    \--sigX

	--dkg

--------------enigC0E96254D1723DA3223AF8A1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigC0E96254D1723DA3223AF8A1--

Date: Fri, 30 Jan 2009 10:23:47 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: Peter Thomas <[email-masked]>
CC: [email-masked], Duane Groth <[email-masked]>
Subject: Re: Ideas on new user attribute types and image formats
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig135E313878988A444AA8C823
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/29/2009 01:23 PM, Peter Thomas wrote:
> 1) PNG (ISO 15948, RFC 2083)

I fully agree that we should be supporting PNG here.  That's long
overdue, and you don't have to do lossless compression in png, iiuc.

> 2) JPEG 2000 (ISO/IEC 15444)

Given how ill-specified and implemented this is, i suggest waiting on
this until it is more mature.

> 3) SVG

SVG can potentially contain way more than images; it can contain
javascript, for example, and other semi-executable nastiness.  As much
as i love svg, I think it might be a can of worms best left unopened
until we're prepared to seriously think through the potential security
consequences.

> Second, ideas for user attributes:
> This is more a: "Has anybody ideas how usage of user attributes could
> be extended?" than a "I have this and that proposal.", so I'd really
> love to see your ideas.

Duane Groth has proposed making a new User Attribute type that just maps
to the possible values of the X.509 subjectAltName specification:

http://open-pgp.info/wiki/index.php?title=3DStandardisation_of_OpenPGP_Ke=
ys_for_Server_Purposes#New_User_Attribute_Type_--_subjectAltNames

What's nice about this proposal is that it doesn't require the creation
of a new registry, implementors can potentially piggyback on existing
ASN.1 parsers (they wouldn't need to write their own), and the
specification can cover a range of ideas automatically.

	--dkg

--------------enig135E313878988A444AA8C823
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig135E313878988A444AA8C823--

Date: Fri, 30 Jan 2009 01:02:08 +0100
From: "Daniel A. Nagy" <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8E1FEA9E4A3B02E8F099DA30
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> earlier than the revocation.  It cannot revoke ones that come after

Of course. Sorry for the sloppy wording of my email. This is what I meant=
=2E

Thank you, this answers my question. Haven't paid attention to Signature
Targets, because I haven't seen a single one in the wild. But they are, i=
ndeed,
truly useful and as such worth implementing as soon as OpenPGP gets used =
for
serious legal purposes. I might do it myself.

--=20
Daniel

--------------enig8E1FEA9E4A3B02E8F099DA30
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig8E1FEA9E4A3B02E8F099DA30--

Date: Thu, 29 Jan 2009 17:30:45 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Date: Thu, 29 Jan 2009 23:02:42 +0100
From: "Daniel A. Nagy" <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig919D7290F134DCBE799FC8AA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> 0x10-0x13.  0x1F is a certification.

Hold on here. What you write here obviously follows from the text of the =
RFC, so
I do not question it, but it does raise a semantic question.

Obviously, one reason for attaching certifications directly to a key rath=
er than
to particular user IDs is to make them stick even if any particular user =
ID is
revoked or expires (or even all of them). So, if I want to make a stateme=
nt
about a certain person rather than a user ID (concerning, e.g., his/her
trustworthiness as a certifier), I'd attach it directly to the key. There=
 may be
several certifications by several people saying different things about th=
e person.

The question: how does one revoke one of them? A 0x30 computed directly o=
n the
key (as the RFC specifies) revokes all of them (for which it is a designa=
ted
revoker), doesn't it? Is there no way to revoke just one?

--=20
Daniel

--------------enig919D7290F134DCBE799FC8AA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig919D7290F134DCBE799FC8AA--

Date: Thu, 29 Jan 2009 15:53:21 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

  Signature === January 1
  Signature === January 3
  Signature === January 5

  Signature  === January 1
  Revocation === January 2
  Signature  === January 3
  Revocation === January 4
  Signature  === January 5

It would work in GnuPG.

David

Date: Thu, 29 Jan 2009 15:38:09 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

Section 5.2.3.3:

David

From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
Date: Thu, 29 Jan 2009 11:37:25 -0800
Sender: [email-masked]

Yes.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
To: Peter Thomas <[email-masked]>
Subject: Re: Ideas on new user attribute types and image formats
Date: Thu, 29 Jan 2009 11:28:53 -0800
Sender: [email-masked]

On Jan 29, 2009, at 10:23 AM, Peter Thomas wrote:

>
> Hi list.
>
> This is not an official proposal or request. I haven't read RFC2434  
> yet ;-)
>
> Just wanted to ask about opinions and ideas for new user attribute
> types and image formats.

I think you understand the pros and cons well enough. My personal  
opinion is that there's an argument for PNG, but not much else. And so  
far as I know, JPEG is not encumbered by patents at all, but there are  
people who would like it to be, especially if it's their patent.

I have no idea why you'd want to do SVG, and you seem to know anything  
I could say as to why not. So I'll just say that anything you put in  
would be a MAY, and if you put in something that no one's going to  
implement, you are arguably wasting your time.

However:

Write it up! Especially your thoughts about structured user  
information. The Jabber one is also good, since Jabber directly  
supports OpenPGP.

Do it informally here first, but also start looking at how to edit up  
an Internet Draft. The XML tools make it a lot easier than it used to  
be.

Oh, and you can't do birthday as a time_t. As shocking as it may  
sound, there are still living people who were born before 1-Jan-1970.  
Some of them even use computers.

	Jon

>
>
>
>
> First perhaps the image formats as these are easier to discuss:
> Of course JPEG is in principle enough and it's probably a very bad
> idea to include any image type GIMP can open ;-) but I think the
> following might be worth thinking about:
> 1) PNG (ISO 15948, RFC 2083)
> Advantages:
> - just as JPEG, nearly everybody can open these image format in the
> meantime (even MS IE as far as I know)
> - well standardized (ISO/IETF RFC)
> - "We" call our "product" OpenPGP but JPEPG is - as far as I know -
> patent encumbered, but PGP is fully free.
> - Is providing an alpha-channel an argument?! ;-)
> - lossless compression
>
> Disadvantages:
> - lossless compression leading to much bigger packets than with JPEG
>
> 2) JPEG 2000 (ISO/IEC 15444)
> Advantages:
> - well standardized (ISO) ... ok one could question that ^^
> - provides even better/smaller quality/image sizes than JPEG
> (And I think to keep image-packets small was the main reason for  
> choosing JPEG)
>
> Disadvantages:
> - no widespread support
> - standard is still incomplete (at least some additional parts, but
> that wouldn't hurt "us" anyway)
>
> 3) SVG
> Probably my most adventurous suggestion ^^
> RFC 4880 say in chapter 5.12.1 that the image is not necessarily that
> of the key owner.
> I'm not fully sure what this means, but could it mean that an image
> attribute subpacket is used to store for example an heraldic device
> ("I'm the king of Belgium and I'd like to include my emblem in my key"
> *G*)?
> If so, SVG would be useful file format (see Wikipedia for dozens of
> heraldic devices in hight quality).
>
>
>
>
> Second, ideas for user attributes:
> This is more a: "Has anybody ideas how usage of user attributes could
> be extended?" than a "I have this and that proposal.", so I'd really
> love to see your ideas.
>
> I personally think of the user ID packet (not the user attribute
> packet) as kind of primary key (in the sense of databases).
> The RFC says in chapter 5.11. that it is "intended to represent the
> name and email address of the keyholder"; it doesn't say it must
> (which is good in my opinion).
> That way some organization, a company or university could use the User
> ID like primary keys and set them to some staff or student number.
>
> Most people surely follow the recommendation to use name/email with
> RFC 2822 style.
> This also fit's with my thinking of user IDs as some kind of primary
> key as the email address makes the whole thing unique.
>
> The user attribute packet introduced ways to better represent
> properties of the key-holder.
> Take my name "Peter Thomas" from just the user ID "Peter Thomas"
> <[email-masked]> you cannot definitely say whether "Peter"
> or "Thomas" is the first- or family-name. The naming schemes in other
> cultures might be even "worse", just consider Arabic names
> (http://en.wikipedia.org/wiki/Arabic_name).
> Having attributes like:
> - common name
> - family names
> - given names
> - Kunya (Arabic)
> - Nasab (Arabic)
> may be something worth to implement.
>
> Consider the following two example: My full name would be "Peter  
> Marvolo Thomas"
> a) My User ID only has "Peter Thomas" and my passport has the full
> name "Peter Marvolo Thomas"
> When another person validates my identity he can either sign it and
> accept that it's missing part of my official name, or he can decline
> to do so.
> With the above user attributes, he could decide to just sign the
> family name, but not the given names filed.
> b) The example above vice versa, with full name in the user id, but
> not in the passport.
>
> Think of similar examples with Arabic names where it is much clearer
> that this would be an advantage (as for example most western
> government documents simply drop parts of Arabic names).
>
> Other attributes that might be worth to implement:
> -birthday (perhaps as UNIX time code ^^)
> -birthplace/country/etc.
> -other fixed body attributes like natural color of eyes and hairs
>
> One could even think of stuff like:
> - Jabber ID
> - etc.
>
> When you comment on this please remember that these are just ideas and
> not proposals that I've thought about hours ;-)
>
>
> Looking forward to see your comments,
> Peter
>

Date: Thu, 29 Jan 2009 19:42:59 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: Hal Finney <[email-masked]>, David Shaw <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Date: Thu, 29 Jan 2009 19:23:04 +0100
Subject: Ideas on new user attribute types and image formats
From: Peter Thomas <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Hi list.

This is not an official proposal or request. I haven't read RFC2434 yet ;-)

Just wanted to ask about opinions and ideas for new user attribute
types and image formats.

First perhaps the image formats as these are easier to discuss:
Of course JPEG is in principle enough and it's probably a very bad
idea to include any image type GIMP can open ;-) but I think the
following might be worth thinking about:
1) PNG (ISO 15948, RFC 2083)
Advantages:
- just as JPEG, nearly everybody can open these image format in the
meantime (even MS IE as far as I know)
- well standardized (ISO/IETF RFC)
- "We" call our "product" OpenPGP but JPEPG is - as far as I know -
patent encumbered, but PGP is fully free.
- Is providing an alpha-channel an argument?! ;-)
- lossless compression

Disadvantages:
- lossless compression leading to much bigger packets than with JPEG

2) JPEG 2000 (ISO/IEC 15444)
Advantages:
- well standardized (ISO) ... ok one could question that ^^
- provides even better/smaller quality/image sizes than JPEG
(And I think to keep image-packets small was the main reason for choosing JPEG)

Disadvantages:
- no widespread support
- standard is still incomplete (at least some additional parts, but
that wouldn't hurt "us" anyway)

3) SVG
Probably my most adventurous suggestion ^^
RFC 4880 say in chapter 5.12.1 that the image is not necessarily that
of the key owner.
I'm not fully sure what this means, but could it mean that an image
attribute subpacket is used to store for example an heraldic device
("I'm the king of Belgium and I'd like to include my emblem in my key"
*G*)?
If so, SVG would be useful file format (see Wikipedia for dozens of
heraldic devices in hight quality).

Second, ideas for user attributes:
This is more a: "Has anybody ideas how usage of user attributes could
be extended?" than a "I have this and that proposal.", so I'd really
love to see your ideas.

I personally think of the user ID packet (not the user attribute
packet) as kind of primary key (in the sense of databases).
The RFC says in chapter 5.11. that it is "intended to represent the
name and email address of the keyholder"; it doesn't say it must
(which is good in my opinion).
That way some organization, a company or university could use the User
ID like primary keys and set them to some staff or student number.

Most people surely follow the recommendation to use name/email with
RFC 2822 style.
This also fit's with my thinking of user IDs as some kind of primary
key as the email address makes the whole thing unique.

The user attribute packet introduced ways to better represent
properties of the key-holder.
Take my name "Peter Thomas" from just the user ID "Peter Thomas"
<[email-masked]> you cannot definitely say whether "Peter"
or "Thomas" is the first- or family-name. The naming schemes in other
cultures might be even "worse", just consider Arabic names
(http://en.wikipedia.org/wiki/Arabic_name).
Having attributes like:
- common name
- family names
- given names
- Kunya (Arabic)
- Nasab (Arabic)
may be something worth to implement.

Consider the following two example: My full name would be "Peter Marvolo Thomas"
a) My User ID only has "Peter Thomas" and my passport has the full
name "Peter Marvolo Thomas"
When another person validates my identity he can either sign it and
accept that it's missing part of my official name, or he can decline
to do so.
With the above user attributes, he could decide to just sign the
family name, but not the given names filed.
b) The example above vice versa, with full name in the user id, but
not in the passport.

Think of similar examples with Arabic names where it is much clearer
that this would be an advantage (as for example most western
government documents simply drop parts of Arabic names).

Other attributes that might be worth to implement:
-birthday (perhaps as UNIX time code ^^)
-birthplace/country/etc.
-other fixed body attributes like natural color of eyes and hairs

One could even think of stuff like:
- Jabber ID
- etc.

When you comment on this please remember that these are just ideas and
not proposals that I've thought about hours ;-)

Looking forward to see your comments,
Peter

Date: Thu, 29 Jan 2009 18:42:22 +0100
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Hi Hal.

Yes and no.

Best wishes,
Peter

To: [email-masked], [email-masked]
Subject: Re: Series of minor questions about OpenPGP 4
Date: Wed, 28 Jan 2009 10:48:24 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Hello Peter -

Hal Finney

Date: Tue, 27 Jan 2009 22:54:09 +0100
Subject: Series of minor questions about OpenPGP 4
From: Peter Thomas <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Hello list.

As you can see from the subject this is already the 4th email in a
series of questions about OpenPGP (and in some cases gnupg).
After the first three David Shaw, who perfectly answered my questions
so far (lots of thanks again), asked me to move here, as it became
more and more OpenPGP specific.
For those who are interested (the previous ones also contained
questions about OpenPGP itself, and some very great answers) you can
find the other ones here:
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035445.html
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035458.html
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035467.html

This time it's all about signature subpackets:
Sorry that this got longer, but I think these points are all somehow
connected. So feel free to split up as you like :-)
I know that these questions are more about OpenPGP itself than gnupg,
but perhaps you, David, can have a look at them here, before I post it
on their mailing list (don't want to look stupid there ^^ and I'm
still quite new in OpenPGP's standard).

Cheerio,
Peter

Date: Tue, 13 Jan 2009 11:30:37 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: Daniel Kahn Gillmor <[email-masked]>, IETF OpenPGP Working Group <[email-masked]>, Monkeysphere Developers <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
Sender: [email-masked]

Jon Callas wrote:
> 
> On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote:
> 
>> Jon Callas wrote:
>>> (Let me put on my hash-designer's hat for a moment. In Skein, we
>>> created a one-pass MAC construction that can replace HMAC. It also  
>>> has
>>> a proof of security.
>> I wish people would stop saying that things have "a proof of  
>> security".
>> Rot13 has a proof of security, but I don't want to use it. You need to
>> state what security properties you have proved.
> 
> If we're going to get picky, Rot-13 is not a cipher, it's a code.

So what?

> It  
> has similar security properies to ASCII, which is a related code. But  
> you're right -- on another list I'm on, there was someone who made the  
> comment that there's no theoretically perfect cryptography. I almost  
> replied that the Caesar cipher (which is ROT-N) has perfect security,  
> just an inadequate key space.
> 
> Nonetheless, you're right. Many people including me sneer at security  
> proofs.

Then why mention them?

> The list of things that have had proofs of security and then  
> fallen over is large. There are plenty of proofs of security that have  
> some people raise an eyebrow. For example, we say that HMAC is secure  
> on today's slightly dodgy hash functions because of a proof of  
> security, but that proof relies on properties of the hash function  
> we're not sure they have. (Niels Ferguson was the first person I know  
> to bring this up, and for the most part, we all whistle as we walk by  
> his observations.)
> 
> I think that security proofs are fundamentally lacking in basic  
> foundations. There's a sense in which you can start with the Peano  
> postulates for arithmetic and end up with double entry bookkeeping. We  
> can't do anything like that in security, and it's a huge lack.
> 
> Nonetheless, it's better to have a proof than not to have one.

If the proof proves something useful, then indeed it is better. But once
more, saying "it has a security proof" provides no useful information.

> And I
> didn't want to turn this into a Skein discussion, I was making the  
> aside that there are people looking at verification constructions that  
> have properties programmers like, and I know this because I've worked  
> on one.
> 
> Go read the Skein paper. It's at <http://www.skein-hash.info>. I think  
> we've addressed your comments, because we feel the same way.

I have read the Skein paper.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: A review of hash function brittleness in OpenPGP
Date: Tue, 13 Jan 2009 19:50:10 +1300
Sender: [email-masked]

Ben Laurie <[email-masked]> writes:
>Jon Callas wrote:
>> (Let me put on my hash-designer's hat for a moment. In Skein, we
>> created a one-pass MAC construction that can replace HMAC. It also has
>> a proof of security.
>
>I wish people would stop saying that things have "a proof of security". Rot13
>has a proof of security, but I don't want to use it. You need to state what
>security properties you have proved.

On the subject of provable security, I've just been reading a paper that
provides a rigorous proof that a particular security mechanism is secure
(under appropriate assumptions regarding the cryptographic functions used).
Unfortunately this is a mechanism that's a slight variant of "click-OK-to-
continue", which means that it's close to worthless in practice (this result
both anecdotally and from a number of HCI papers that have evaluated it).  So
this would be a prime example of a rigorous provably-secure crypto mechanism
that thirty seconds of googling or a beer's worth of analysis would show
doesn't actually work.

(I haven't mentioned the paper name because I'm not trying to attack the 
author, just using it as a nice example of a provably secure but practically 
insecure mechanism, I can provide details in private email if anyone really 
wants to know).

Peter.

From: Florian Weimer <[email-masked]>
To: Daniel Kahn Gillmor <[email-masked]>
Cc: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
Date: Sun, 11 Jan 2009 18:04:02 +0100
Sender: [email-masked]

* Daniel Kahn Gillmor:

> Also, it's quite likely that i've missed things in my reading of the
> spec.  If anyone sees any other problematic areas, it would be great to
> air them as soon as possible.

There's the issue of V3 keys.

If packet formats are changed once again, it could make sense to
incorporate random blobs near the start of the packets, so that an
attacker cannot predict the internal state of the hash function when a
signature is created.  OpenPGP does not need the convergent property
of hash functions.

Cc: Daniel Kahn Gillmor <[email-masked]>, IETF OpenPGP Working Group <[email-masked]>, Monkeysphere Developers <[email-masked]>
From: Jon Callas <[email-masked]>
To: Ben Laurie <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
Date: Sat, 10 Jan 2009 13:56:24 -0800
Sender: [email-masked]

On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote:

>
> Jon Callas wrote:
>> (Let me put on my hash-designer's hat for a moment. In Skein, we
>> created a one-pass MAC construction that can replace HMAC. It also  
>> has
>> a proof of security.
>
> I wish people would stop saying that things have "a proof of  
> security".
> Rot13 has a proof of security, but I don't want to use it. You need to
> state what security properties you have proved.

If we're going to get picky, Rot-13 is not a cipher, it's a code. It  
has similar security properies to ASCII, which is a related code. But  
you're right -- on another list I'm on, there was someone who made the  
comment that there's no theoretically perfect cryptography. I almost  
replied that the Caesar cipher (which is ROT-N) has perfect security,  
just an inadequate key space.

Nonetheless, you're right. Many people including me sneer at security  
proofs. The list of things that have had proofs of security and then  
fallen over is large. There are plenty of proofs of security that have  
some people raise an eyebrow. For example, we say that HMAC is secure  
on today's slightly dodgy hash functions because of a proof of  
security, but that proof relies on properties of the hash function  
we're not sure they have. (Niels Ferguson was the first person I know  
to bring this up, and for the most part, we all whistle as we walk by  
his observations.)

I think that security proofs are fundamentally lacking in basic  
foundations. There's a sense in which you can start with the Peano  
postulates for arithmetic and end up with double entry bookkeeping. We  
can't do anything like that in security, and it's a huge lack.

Nonetheless, it's better to have a proof than not to have one. And I  
didn't want to turn this into a Skein discussion, I was making the  
aside that there are people looking at verification constructions that  
have properties programmers like, and I know this because I've worked  
on one.

Go read the Skein paper. It's at <http://www.skein-hash.info>. I think  
we've addressed your comments, because we feel the same way.

	Jon

Date: Sat, 10 Jan 2009 00:16:23 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: Daniel Kahn Gillmor <[email-masked]>, IETF OpenPGP Working Group <[email-masked]>, Monkeysphere Developers <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
Sender: [email-masked]

Jon Callas wrote:
> (Let me put on my hash-designer's hat for a moment. In Skein, we  
> created a one-pass MAC construction that can replace HMAC. It also has  
> a proof of security.

I wish people would stop saying that things have "a proof of security".
Rot13 has a proof of security, but I don't want to use it. You need to
state what security properties you have proved.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Cc: IETF OpenPGP Working Group <[email-masked]>, Monkeysphere Developers <[email-masked]>
From: Jon Callas <[email-masked]>
To: Daniel Kahn Gillmor <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
Date: Fri, 9 Jan 2009 15:28:03 -0800
Sender: [email-masked]

On Jan 8, 2009, at 10:59 AM, Daniel Kahn Gillmor wrote:

> * PGP Signed by an unknown key
>
> Hey folks--
>
> I've been trying to evaluate RFC 4880's resistance to a hash function
> compromise in light of the recent activity exploiting weaknesses  
> MD-5 in
> That Other PKI [0].
>
> I'm quite pleased with the bulk of what i've found.  OpenPGP's use of
> message digests is almost entirely parameterized, leaving the door  
> open
> to forward-looking adoption of new hash algorithms and the smooth
> deprecation as older ones are demonstrated to be weak.

Great comments.

>
>
> So I've been looking for places in the spec where the choice of digest
> function is not parameterized.  In particular, explicit and hardcoded
> reliance on SHA-1 could become problematic as it is already being
> deprecated.  For example, reliance on SHA-1 must be eliminated in  
> all US
> Gov't federal agencies by the end of 2010 [1].
>
> Here are the concerns i've found so far:
>
> MDC
> ---
>
> The modification detection packets (sections 5.13 and 5.14) explicitly
> specify SHA-1, and basically acknowledge that this choice may need  
> to be
> made more flexible in the future.

Yes.

Let me add an historic note. The MDC occupies an odd position.

There is an obvious, easy, supported way to create an integrity- 
protected message: you sign it.

The problem is that an unsigned message is pretty vulnerable to many  
problems from cut-and-paste attacks on. A number of people wanted to  
do something about that problem -- you want an unsigned message that  
has a reasonable guarantee that it arrived whole.

Most people didn't see the threat. Outside this working group, almost  
no one did. Even inside the working group we were ambivalent about it.

The solution as you see it was a compromise among us, and as a  
compromise it means we're all a bit ambivalent about it. In  
retrospect, an MAC would have been a better solution, but brought up a  
new set of issues like what key to use.

HMACs were developed *during* the MDC discussions, and the proof of  
security for HMAC was done *after* we all agreed. The implementors  
didn't want to do an HMAC for performance reasons, especially for  
streaming, and again -- there was no proof of security. HMAC was this  
new thing that Hugo and Shai did. Since then, there are also obvious  
answers for KDFs as well.

Despite this, it's a fine construction. It does what it was intended  
to do, and the known weaknesses of SHA-1 do not affect it at all. We  
are not relying on collision-resistance, we are relying on one- 
wayness. Remember, this is an *unauthenticated*, but whole message. If  
you want to authenticate the message, we have some nice digital  
signatures to offer you.

Since then, there have been several attacks against the OpenPGP  
formats that are thwarted by the MDC. If we want to upgrade the MDC,  
we know how to do it, that's outlined in 4880.

(Let me put on my hash-designer's hat for a moment. In Skein, we  
created a one-pass MAC construction that can replace HMAC. It also has  
a proof of security. I think it would be best to wait a while longer  
to see what comes out of the SHA3 competition, because it's likely  
that it will yield KDFs and hash-based MACs that answer all of the  
concerns that lead us to the present MDC compromise. They'll be fast,  
easy, and one-pass.)

>
>
> Fingerprints
> ------------
>
> Fingerprints (section 12.2) are specified as an SHA-1 computation.
> While this isn't an explicit reliance on SHA-1 for cryptographic
> security (and the RFC makes it clear that there is a non-zero chance  
> of
> fingerprint collisions), the real-world use of fingerprints as unique
> identifiers for keys poses a serious risk to OpenPGP infrastructure
> should SHA-1 become further compromised.

There's a proposal for a new way to do fingerprints. I will do it the  
injustice of summarizing it:

You express a fingerprint as the algorithm number, a colon, and then  
the hexadecimal. Truncations are handled in some obvious manner.  
Presently, for better or worse, a key id is the low-order 64 bits of a  
fingerprint, so we probably have to stick with that, despite the  
gnashing of teeth many of us will have.

Under that proposal, one of my fingerprints (DFA7 517E 2BF4 6834 6C15   
C029 B137 9D59 9383 DE06) could also be expressed as (2:DFA7 517E 2BF4  
6834 6C15  C029 B137 9D59 9383 DE06) because SHA-1 has the algorithm  
number of 2.

All we need is someone to write this up as an I-D -- or code it up  
preemptively.

>
>
> Revocation keys
> ---------------
>
> Section 5.2.3.15 defines a way that key A can allow key B to
> authoritatively issue revocation signatures on A's behalf, including  
> key
> revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and
> certification revocation (sigtype 0x30).  However, this mechanism  
> relies
> on the fingerprint of B being unique.  Since the fingerprint itself is
> bound to SHA-1, this presents a risk to users of this feature of the
> specification should SHA-1 become further compromised.
>

Solved by upgrading fingerprints and three more paragraphs of text.

>
>
> As the IETF working group for OpenPGP, we probably should start  
> actively
> working to resolve these issues so we can have infrastructure in place
> well before SHA-1 is similarly compromised.  Any suggestions?  I'm new
> to the WG, so i don't have any experience addressing concerns like  
> this.
>
> I'm particularly concerned about fingerprints, since they is used  
> widely
> in the real world (e.g. i have my fingerprint on my business card).  I
> can imagine relatively straightforward technical measures to resolve  
> the
> other concerns.
>
> Also, it's quite likely that i've missed things in my reading of the
> spec.  If anyone sees any other problematic areas, it would be great  
> to
> air them as soon as possible.

Are you volunteering to write a document?

>
>
> Regards,
>
> 	--dkg
>
> [0] http://www.phreedom.org/research/rogue-ca/
> [1] http://csrc.nist.gov/groups/ST/hash/statement.html
>
>
> * Unknown Key
> * 0xD21739E9

Date: Fri, 09 Jan 2009 14:51:11 +0000
From: Ben Laurie <[email-masked]>
To: Cryptography <[email-masked]>, OpenPGP <[email-masked]>
Subject: OpenPGP:SDK v0.9 released
Sender: [email-masked]

I thought people might be interested in this now somewhat-complete,
BSD-licensed OpenPGP library...

http://openpgp.nominet.org.uk/cgi-bin/trac.cgi/wiki/V0.9

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Fri, 09 Jan 2009 01:03:48 +0100
From: "Daniel A. Nagy" <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
CC: Monkeysphere Developers <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig38FEE6AF3B222376763F7771
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Daniel Kahn Gillmor wrote:
> The X.509 community was able to respond by further deprecating MD5
> because there was a parameterized method in place to switch to another
> hash function.  OpenPGP currently has this in place almost everywhere a=

> hash function is used.  That's good!

As far as I can judge, X.509 PKI is still in the state of catastrophic fa=
ilure
with no obvious way out.

Right now, if my browser (or yours, or anybody else's) tells me that the =
site I
am browsing presented a certificate issued to it by a legitimate CA, I ca=
nnot be
sure that this assertion is true. Rejecting all certificates with MD5 in =
their
signatures is not a solution (there are too many out there and replacing =
them
requires non-trivial cooperation between different parties; no-one can do=
 it
acting alone). Not issuing any more MD5-based certificates is not a solut=
ion
(who knows how many rogue CAs are already out there?). In fact, I do not =
see an
easy and cheap solution out of this mess.

It is a good thought-experiment to assess the consequences of an existent=
ial
collision attack on SHA1 such as the one we have for MD5 on OpenPGP secur=
ity,
considering all the places where SHA1 is wired in. I haven't checked ever=
y
corner of RFC4880, but I can see no catastrophic failure akin to what hap=
pened
to X.509 PKI.

--=20
Daniel

--------------enig38FEE6AF3B222376763F7771
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig38FEE6AF3B222376763F7771--

Date: Thu, 08 Jan 2009 18:20:33 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
CC: Monkeysphere Developers <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2424D1A17CE941F82629DA06
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/08/2009 05:34 PM, tz wrote:
> To analyze the RFC, the internal structure of the key certificates
> which are signed need to be analyzed (first there has to be a current
> source for new things with MD5 anyway, I'd have to come up with two
> things to be signed, a real one which will be signed and the rogue one
> that has the same MD5 hash). =20

I suppose i should have been more explicit: i'm not concerned about this
specific attack working against OpenPGP.  It just got me to thinking
about various ways that an abused hash function could cause a PKI
failure, and how the community around that PKI could respond to such an
attack.

The X.509 community was able to respond by further deprecating MD5
because there was a parameterized method in place to switch to another
hash function.  OpenPGP currently has this in place almost everywhere a
hash function is used.  That's good!

However, there are a few places where we don't have that agility, which
is what i was trying to highlight.  Actually doing the switch from one
hash algorithm to another within a well-defined parameterized structure
is a chore, but it's doable.  My concern is that there are places in
OpenPGP (fingerprints being the most worrisome place) where we would be
unable to actually make such a transition should there be a
cryptographic result rendering that hash function unusable.

> I don't think there are many such things in place, but I would look if
> there are any legacy signers (including prominent people with older
> keys or implementations).  I think after PGP5 it would be very
> unlikely, but I would look for something that allowed, requested, or
> forced "backward compatibility", i.e. if there are bits or something
> else I can cause the hash algorithm to be MD5.

Doing a test of common implementations of OpenPGP to see if they give
adequate warnings based on use of deprecated algorithms would be good,
though this was not intended to be the point of my initial message.  For
example, the following series of commands generates warnings on
signature creation, but not on signature verification, afaict:

  echo test > test
  gpg --digest-algo MD5 --clearsign test
  gpg --verify test.asc

Is this the desired behavior?  Or should there be a warning during
verification that the signature was based on a deprecated hash?  What
about during certification verification or web of trust calculations?
How do other implementations approach this scenario?

	--dkg

--------------enig2424D1A17CE941F82629DA06
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig2424D1A17CE941F82629DA06--

Date: Fri, 09 Jan 2009 00:04:35 +0100
From: "Daniel A. Nagy" <[email-masked]>
To: Daniel Kahn Gillmor <[email-masked]>
CC: IETF OpenPGP Working Group <[email-masked]>, Monkeysphere Developers <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD37C0D29BCC3DA75DB8EEFFA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

First off, thank you for such a swift reaction to one of the most serious=

cryptographic vulnerabilities discovered in recent times. Let me just com=
ment on
 your comments.

Daniel Kahn Gillmor wrote:

> MDC
> ---
>=20
> The modification detection packets (sections 5.13 and 5.14) explicitly
> specify SHA-1, and basically acknowledge that this choice may need to b=
e
> made more flexible in the future.

We should be very careful here. By being more flexible on MDCs, one makes=
 the
system less secure. After all, it is sufficient to forge ONE of the valid=
 MDC
functions for the MDC-protected packet to check. There is a reason (with =
a good
discussion in the archives of this list, if I am not mistaken) why there =
is no
algorithm agility in OpenPGP MDC.

Also, MDC needs to be secure against second pre-images, not against colli=
sions.
Collision-resistance is not a requirement for MDCs.

> Fingerprints
> ------------
>=20
> Fingerprints (section 12.2) are specified as an SHA-1 computation.
> While this isn't an explicit reliance on SHA-1 for cryptographic
> security (and the RFC makes it clear that there is a non-zero chance of=

> fingerprint collisions), the real-world use of fingerprints as unique
> identifiers for keys poses a serious risk to OpenPGP infrastructure
> should SHA-1 become further compromised.

There are many more problems with current OpenPGP key IDs and fingerprint=
s. I
think that these are in need of a major overhaul. Here are two other prob=
lems
with fingerprints and keyIDs:

Creation date is hashed in the fingerprint, thereby allowing the same key=
 with
different fingerprints of which 31 bits are of the attacker's choosing,
effectively shaving off 31 bits off the attacker's task (in other words, =
making
it 2 billion times easier on average).

Also, fingerprints and key IDs are hexadecimal, which makes them
super-inconvenient with mobile phones with numeric keypads.

> Revocation keys
> ---------------
>=20
> Section 5.2.3.15 defines a way that key A can allow key B to
> authoritatively issue revocation signatures on A's behalf, including ke=
y
>  revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and
> certification revocation (sigtype 0x30).  However, this mechanism relie=
s
> on the fingerprint of B being unique.  Since the fingerprint itself is
> bound to SHA-1, this presents a risk to users of this feature of the
> specification should SHA-1 become further compromised.

Again, collisions don't seem to be a problem here.

> As the IETF working group for OpenPGP, we probably should start activel=
y
> working to resolve these issues so we can have infrastructure in place
> well before SHA-1 is similarly compromised.  Any suggestions?  I'm new
> to the WG, so i don't have any experience addressing concerns like this=
=2E
>=20
> I'm particularly concerned about fingerprints, since they is used widel=
y
> in the real world (e.g. i have my fingerprint on my business card).  I
> can imagine relatively straightforward technical measures to resolve th=
e
> other concerns.

I think, fingerprints should be dealt with as part of the shift to v5 key=
s.
However, formulating reasonable requirements for fingerprints sounds like=
 a good
way to kick off the design process of v5 key format specification. I will=
 write
up a few ideas soon.

Regards,

--=20
Daniel

--------------enigD37C0D29BCC3DA75DB8EEFFA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigD37C0D29BCC3DA75DB8EEFFA--

Date: Thu, 8 Jan 2009 16:34:25 -0600
From: tz <[email-masked]>
To: "Daniel Kahn Gillmor" <[email-masked]>
Subject: Re: A review of hash function brittleness in OpenPGP
Cc: "IETF OpenPGP Working Group" <[email-masked]>, "Monkeysphere Developers" <[email-masked]>
Sender: [email-masked]

The other exploit was also complex and required finding collisions
which was not trivial but possible with MD5.  The key seemed to be
that the separate bits of the certificate were in places which made
the exploit easy, e.g. the top half was either static or predictable,
but there was a comment field (which could be stuffed with the bits to
generate the collision), then the big prime product.

To analyze the RFC, the internal structure of the key certificates
which are signed need to be analyzed (first there has to be a current
source for new things with MD5 anyway, I'd have to come up with two
things to be signed, a real one which will be signed and the rogue one
that has the same MD5 hash).  I think the simplicity of the
certificates might make it more difficult, but that is where I would
look.

I don't think there are many such things in place, but I would look if
there are any legacy signers (including prominent people with older
keys or implementations).  I think after PGP5 it would be very
unlikely, but I would look for something that allowed, requested, or
forced "backward compatibility", i.e. if there are bits or something
else I can cause the hash algorithm to be MD5.

On Thu, Jan 8, 2009 at 12:59 PM, Daniel Kahn Gillmor
<[email-masked]> wrote:
> Hey folks--
>
> I've been trying to evaluate RFC 4880's resistance to a hash function
> compromise in light of the recent activity exploiting weaknesses MD-5 in
> That Other PKI [0].
>
> I'm quite pleased with the bulk of what i've found.  OpenPGP's use of
> message digests is almost entirely parameterized, leaving the door open
> to forward-looking adoption of new hash algorithms and the smooth
> deprecation as older ones are demonstrated to be weak.
>
> So I've been looking for places in the spec where the choice of digest
> function is not parameterized.  In particular, explicit and hardcoded
> reliance on SHA-1 could become problematic as it is already being
> deprecated.  For example, reliance on SHA-1 must be eliminated in all US
> Gov't federal agencies by the end of 2010 [1].
>
> Here are the concerns i've found so far:
>
> MDC
> ---
>
> The modification detection packets (sections 5.13 and 5.14) explicitly
> specify SHA-1, and basically acknowledge that this choice may need to be
> made more flexible in the future.
>
> Fingerprints
> ------------
>
> Fingerprints (section 12.2) are specified as an SHA-1 computation.
> While this isn't an explicit reliance on SHA-1 for cryptographic
> security (and the RFC makes it clear that there is a non-zero chance of
> fingerprint collisions), the real-world use of fingerprints as unique
> identifiers for keys poses a serious risk to OpenPGP infrastructure
> should SHA-1 become further compromised.
>
> Revocation keys
> ---------------
>
> Section 5.2.3.15 defines a way that key A can allow key B to
> authoritatively issue revocation signatures on A's behalf, including key
>  revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and
> certification revocation (sigtype 0x30).  However, this mechanism relies
> on the fingerprint of B being unique.  Since the fingerprint itself is
> bound to SHA-1, this presents a risk to users of this feature of the
> specification should SHA-1 become further compromised.
>
>
>
> As the IETF working group for OpenPGP, we probably should start actively
> working to resolve these issues so we can have infrastructure in place
> well before SHA-1 is similarly compromised.  Any suggestions?  I'm new
> to the WG, so i don't have any experience addressing concerns like this.
>
> I'm particularly concerned about fingerprints, since they is used widely
> in the real world (e.g. i have my fingerprint on my business card).  I
> can imagine relatively straightforward technical measures to resolve the
> other concerns.
>
> Also, it's quite likely that i've missed things in my reading of the
> spec.  If anyone sees any other problematic areas, it would be great to
> air them as soon as possible.
>
> Regards,
>
>        --dkg
>
> [0] http://www.phreedom.org/research/rogue-ca/
> [1] http://csrc.nist.gov/groups/ST/hash/statement.html
>
>

Date: Thu, 08 Jan 2009 13:59:45 -0500
From: Daniel Kahn Gillmor <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
CC: Monkeysphere Developers <[email-masked]>
Subject: A review of hash function brittleness in OpenPGP
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7B8AC4F50DA64063949DE949
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey folks--

I've been trying to evaluate RFC 4880's resistance to a hash function
compromise in light of the recent activity exploiting weaknesses MD-5 in
That Other PKI [0].

I'm quite pleased with the bulk of what i've found.  OpenPGP's use of
message digests is almost entirely parameterized, leaving the door open
to forward-looking adoption of new hash algorithms and the smooth
deprecation as older ones are demonstrated to be weak.

So I've been looking for places in the spec where the choice of digest
function is not parameterized.  In particular, explicit and hardcoded
reliance on SHA-1 could become problematic as it is already being
deprecated.  For example, reliance on SHA-1 must be eliminated in all US
Gov't federal agencies by the end of 2010 [1].

Here are the concerns i've found so far:

MDC
---

The modification detection packets (sections 5.13 and 5.14) explicitly
specify SHA-1, and basically acknowledge that this choice may need to be
made more flexible in the future.

Fingerprints
------------

Fingerprints (section 12.2) are specified as an SHA-1 computation.
While this isn't an explicit reliance on SHA-1 for cryptographic
security (and the RFC makes it clear that there is a non-zero chance of
fingerprint collisions), the real-world use of fingerprints as unique
identifiers for keys poses a serious risk to OpenPGP infrastructure
should SHA-1 become further compromised.

Revocation keys
---------------

Section 5.2.3.15 defines a way that key A can allow key B to
authoritatively issue revocation signatures on A's behalf, including key
 revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and
certification revocation (sigtype 0x30).  However, this mechanism relies
on the fingerprint of B being unique.  Since the fingerprint itself is
bound to SHA-1, this presents a risk to users of this feature of the
specification should SHA-1 become further compromised.

As the IETF working group for OpenPGP, we probably should start actively
working to resolve these issues so we can have infrastructure in place
well before SHA-1 is similarly compromised.  Any suggestions?  I'm new
to the WG, so i don't have any experience addressing concerns like this.

I'm particularly concerned about fingerprints, since they is used widely
in the real world (e.g. i have my fingerprint on my business card).  I
can imagine relatively straightforward technical measures to resolve the
other concerns.

Also, it's quite likely that i've missed things in my reading of the
spec.  If anyone sees any other problematic areas, it would be great to
air them as soon as possible.

Regards,

	--dkg

[0] http://www.phreedom.org/research/rogue-ca/
[1] http://csrc.nist.gov/groups/ST/hash/statement.html

--------------enig7B8AC4F50DA64063949DE949
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7B8AC4F50DA64063949DE949--