Subject: Re: Series of minor questions about OpenPGP 4

From: Peter Thomas <[email-masked]>
Date: Sun, 1 Feb 2009 19:06:44 +0100

On Sun, Feb 1, 2009 at 4:17 AM, David Shaw <[email-masked]> wrote:
>>> That's a good question.  The RFC specifies that a subkey may have one
>>> (and only one) binding signature, and zero or one revocations.
>> Wow,.. uhm could you please point me to the location that mandates this?
> 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.
Uhm,.. ok I think I don't fully understand the whole issue.
As you've said, section 11.1 is just about transportation, and nothing more:
So in principle the following would be ok and allowed (AND they key
would be valid and ussable) by the standard:
Subkey
0x18 timestamp 1
0x28 timestamp 2 => revokes 0x18 from timestamp 1
0x18 timestamp 3
Right?
You just wouldn't be allowed to transport it.
But what does this actually mean? Would it follow from this, that if
an implementation or keyserver deletes the whole subkey, or just the
unrevoked part?
I must admit that I consider the standard to be a little bit unclear
in this issue, (don't take this personally of course ;-) ).

>>> Not exactly - it revokes one signature.  However if there is more than
>>> one signature, the earlier signature should be superseded by the later
>>> one.
>> 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 ;-) )?
> The RFC specifies the signature target which lets a revocation indicate
> which signature is being revoked.
Ok with signature targets it's clear.... but we talk when having no
signature targets, which seems to be currently the case in all
implementations, right?

> 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.
Ok,. but it MUST be an earlier one?

>  It's not most recent, it's not least recent, it's simply not specified.
Wow... this means in principle,... that there is a "hole" in the RFC,
for those cases where an implementation doesn't follow the
recommendation to use the most recent self-signature, or am I wrong?

I mean if an implementation follows the advice to only use the most
recent self-signature the following example would be ok:
UserID
0x13 timestamp 1
0x13 timestamp 2
0x30 timestamp 3

The key holder wants obviously that both is revoked and it works the following:
1st: the timestamp 1 sig is replaced ("revoked") by the timestamp 2 sig
2nd: no there's only one left (the timestamp2 sig) which is than
revoked by the timestamp 3 sig

Right so far?

Even with reordering the packets an attacker could do nothign, e.g.:
UserID
0x13 timestamp 1
0x30 timestamp 3
0x13 timestamp 2
This could still be resolved as above.

But if an implementation doesn't follow that advice we could end up
with the following:
UserID
0x13 timestamp 1
0x13 timestamp 2
0x30 timestamp 3
No which one is revoked by the timestamp 3 sig? #1 or #2?

Even in such a case an implementation could do stupid things:
UserID
0x13 timestamp 1
0x30 timestamp 2
0x13 timestamp 3
0x30 timestamp 4

It could think that #4 revokes #1 (it is an earlier signature), then
#2 would be ineffective and #3 would remain.

I think I'm a little bit confused now xD

Cheers and thanks in advance,
Peter

---

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

On Sun, 2009-02-01 at 00:41 +0100, Peter Thomas wrote:
> > Thus you cannot resign a subkey to un-revoke it.
> Uhm what do you mean with this?
He probably meant re-sign ;-)

> > 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)
> 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?
Personally I'm using my primary key just for signing other keys...

> 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.
Well I'm actually a little bit surprised about how revocation actually
works. This was not clear to me before, and without signature targets I
consider it somewhat wishy-washy.

> > 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?
Well my opinion is - don't forget that I'm by no means an expert - that
this issue is not very dangerous at least in practice.
But on the other hand, I agree that _without_ signature targets there is
a chance for problems, especially when applications have their own
mechanism how to resolve ambiguities with multiple-self-sigs.

Even if an implementation follows the RFC RECOMMENDATION it could be
stupid:
Public Key
time 1: 0x1F on that key
time 2: 0x1F on that key
time 3: 0x30 on that key/0x1F's

In that order,.. the application might perhaps work (even then it could
be very stupid ^^) but consider the following order that an attacker
might give you:
Public Key
time 2: 0x1F on that key
time 1: 0x1F on that key
time 3: 0x30 on that key/0x1F's

Isn't this what Daniel had in mind?

But again, the practical impact is probably little as most
implementations behave reasonable (I assume gpg always orders all
signatures by time, before it looks at them?).
And that's probably why David sees not much of a problem here :-)
However I'd be curious what the other experts are thinking ;-)

So when will we see Signature Targets support in PGP and gnupg?! XD
Any voluntary to code? *G*

-- 
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München

[email-masked]
[email-masked]

---

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

On Sat, 2009-01-31 at 22:36 -0500, David Shaw wrote:
> > I've seen you other mail that for subkeys this isn't possible at  
> > all, as
> > only one 0x18 and corresponding revocation is allowed.
> Unless you strip off the old 0x18 and revocation.
Ok,.. but this is not really possible due to the keyservers,... they'd
bring it back, correct?
Now what would e.g. gnupg do if it enounters:
Subkey
0x18 subkey binding (timestamp 1)
0x28 subkey revocation (timestamp 2)
0x18 subkey binding (timestamp 3)
?

Or what if it for example has:
Subkey
0x18 subkey binding (timestamp 3)

And with via an update from the keyservers it gets:
0x18 subkey binding (timestamp 1)
0x28 subkey revocation (timestamp 2)
in addition.

> 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.
Ok I see. While I don't consider this to be a big problem in practice, I
think that this is an aesthetic problem with the spec as even an, in the
strict sense, conforming application could run into this problem.
I think this underlines Peter's and my point of view, that some future
RFC should clarify all this:
1. What MUST an implementation do with multiple self-sigs (and not what
is it RECOMMENDED to do).
2. Revocations SHOULD contain signature target subpackets.
3. And specifying the a revocation signature always applies to the
signature most recently to its own timestamp

(Of course 3. would be implied by 1.)

> 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.
Yea, of course,.. I fully know and agree with you! Please don't think
that I want to be annoying or offend your something like this :-)
I'm just a perfectionist ;-)

> > 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?
> I'm not sure I understand the question here.
I meant:
If I do a 0x30 certification revocation it _either_ applies only to
0x10s and 0x11s and 0x12s and 0x13s ... _or_ to 0x1Fs.
These two groups cannot be mixed, as they're calculated over different
data, and thus the revocation signature too.

Ok,... I think we have the same opinion now (ok, one of us is a little
bit more pedantic,.. don't wanna say names,..let's call him "Christoph
M." ;-) ) so we can stop this discussion here ^^.

Greets,

---

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

On Sat, 2009-01-31 at 22:36 -0500, David Shaw wrote:
> > 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.

> 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.
Oh my god :-O
Surely? I thought that the 0x30 says it only applies to _earlier_
sigs...

Hmm,.. that's bad ^^ such applications should be forbidden,.. and their
programmers be imprisoned xD
Well seriously,.. that's a point.

So if an implementation doesn't behave like this,.. the above would work
(expect it behaves in some other very obscure way) and would be in
accordance with the RFC?
I just ask to see whether my understanding of the revocations and so on
is now "correct".
Or at least, the above is the way it would work in gnupg, as you've said
before.

> 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.
Of course, the whole thing (at least from my point of view) was more a
theoretical discussion, in the sense if this would give us the tools to
handle implementations which don't follow the RFC's advice.

> 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.
Actually I don't intend to use this revocation-trick....
I've already thought about doing so, but now that you've said, an
_conforming_ implementation might treat a UID invalid forever after a
single revocation,... I'm not so sure anymore ;)

Ok,.. thanks for the enormous effort you spend on this,
-- 
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 01 Feb 2009 15:55:57 -0500

On 01/30/2009 06:39 PM, Peter Thomas wrote:
> On Fri, Jan 30, 2009 at 9:06 PM, Daniel Kahn Gillmor
>> this assumes that the policies are machine-parseable in a form that
>> 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
>> reading of the RFC is that there is no restriction on what can be
>> contained in the policy URI.
> I don't see that point why this would have to be machine-readable.

Hrm, thinking about this now, i'm not sure why it would necessarily need
to be machine-readable.  I think i was thinking that there would be ways
to mechanize your interpretations of various signatures based on the
policy decisions.

This would require some good work sorting out common policies that could
then be referred to by URL, sort of like how Creative Commons has sorted
out some common licensing arrangements which can be identified by URL:

 http://creativecommons.org/licenses/by-sa/3.0

uniquely identifies a well-known license, and people are building tools
to automatically assemble indexes of content that's been licensed that way.

If a group did the same type of work for certification policies that CC
has done in regard to content licensing, then you could begin to build
similar sorts of tools to interpret human-centered policy preferences
through the web of trust.

This is a more ambitious project, though, and you're right to question
the need for every policy to be machine-interpretable.

	--dkg

---

From: Ian G <[email-masked]>
Date: Mon, 02 Feb 2009 13:00:16 +0100

> to automatically assemble indexes of content that's been licensed that way.

Yes, that works because the tech supports the document, which is primary 
and the rest is secondary.

However if you look at it from the OpenPGP context, the tech now has to 
support more things;  a signature, a document and a "CPS" or statement 
of legal semantics.  This starts to get complex.  For example, if a 
signature over a document has a complicated meaning, dependent on a CPS, 
and the CPS disappears from view after a few years, the tech will have 
trouble explaining it to the reader.

For a view of how this was addressed in machine-readable financial 
contracts, have a look at the Ricardian Contract.  It basically 
re-combined the three elements back into one document.  Any "CPS" was 
within the document or left unsaid, as were all the keys, and the 
clear-text OpenPGP signature was used.  We called this the rule of one 
document.

> the need for every policy to be machine-interpretable.

It's also about other disciplines, so one should be careful to bring in 
the elements of those disciplines that can be trusted to understand and 
help the project.  One of the reasons CC succeeds is that it was done by 
lawyers from universities copying a thing called open source.  One of 
the reasons CPSs "failed" or turned out to do something other than what 
"we expected" was that they weren't done that way.

iang

---

From: Jon Callas <[email-masked]>
Date: Mon, 2 Feb 2009 11:07:00 -0800

>>
> 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.

Yes, but if an implementation both does not interoperate and does not  
follow a recommendation that would make it interoperate, then while  
that implementation is conforming, it has *chosen* not to interoperate.

	Jon