Subject: Re: Series of minor questions about OpenPGP 6

From: Peter Thomas <[email-masked]>
Date: Mon, 2 Feb 2009 01:04:37 +0100

Hi Jon,..

Thanks for your answers :-)

On Sat, Jan 31, 2009 at 2:02 AM, Jon Callas <[email-masked]> wrote:
>> 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.
Uhm, may I propose for a future RFC that all this is clarified a
little bit and perhaps tightened up?
I think right now the RFC suggests that in case of multiple subpackets
per signature the last on in the signature takes priority?
But again that's was just a suggestion if I recall correctly and thus
may left space for ambiguities.

> I'm not going to comment further, but only because I'm in a hurry and
> haven't memorized the hex values.
If you'd find time to do so later I'd still welcome it :-)
David made only a few comments (this is definitely not a complaint ;-)
and I'm still not fully sure how this works, or whether it's
completely up to the implementation.

Thanks for your help so far :-)
Peter

---

From: Peter Thomas <[email-masked]>
Date: Mon, 2 Feb 2009 01:25:37 +0100

Hello.

On Sat, Jan 31, 2009 at 5:04 AM, David Shaw <[email-masked]> wrote:
> 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.
Ok,.. but basically this means,... it's left to the implementation by
the RFC, as Jon said, right?
So an implementation could also use the key expiration of the 0x1F
when the key was selected via key ID for example,.. or one of my other
examples from above.
And your answer here is "just" the probably most reasonable advice?!
But in any case,... if the selected expiration time is reached,.. the
WHOLE key is expired, right?

> 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.
Of course :)

>  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.
Ok but again,.. this handling is _not_ enforced by the RFC, and an
implementation could also choose to do it by one of my examples,
right? Of course what you've explained here above is probably the most
reasonable :-)

Ah and did I understand this correct:
When the symmetric/hash/compression algorithm is set on a 0x1F but not
any of the 0x13, the ones from the 0x1F are used? But if the 0x13s
have them _too_ these are used?!
Does gnupg do it like that? I mean that you can set kind of a "global"
default via the 0x1F, expect you re-set it on the 0x13s?

>> - key server preferences / preferred key server / key flags / features
For them it's also up to the implementation right?
Where can I find how gnupg would choose if I'd have them
a) only in the 0x1F but not the 0x13s
b) in both

"Read the sources!"?! xD

>> II) Subpackets on any of the 0x10-0x13 certification signatures:
>> III) Subpackets on the 0x18 subkey binding signature:
Were my assumptions here correct?

Does it make any sense to have keyserverprefs/preferred
keyserver/features on 0x18 subkey binding signatures?

Can anyone here of an example or a semantical meaning, that a
self-signature is a trust-signature?

Wow,... I think I'm going to run out of questions ^^

Thanks,
Peter

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 02 Feb 2009 03:44:23 +0100

On Fri, 2009-01-30 at 17:02 -0800, Jon Callas wrote:
> > 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.
This is a little bit strange, isn't it? Wouldn't one use signature
expiration times on the User ID self-signatures for such move?

> > 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.
Uhm @David (if you read this), does gnupg support creating non
exportable subkey binding signatures? And if so I assume that it doesn't
export the subkey either?!

> opinion about policy URIs, but I wouldn't discount it automatically  
> out of hand.
Doesn't the RFC say that only the last subpacket of a give type of the
same signature must be used? Or was this just a "should"?

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

[email-masked]
[email-masked]

---

From: David Shaw <[email-masked]>
Date: Sun, 1 Feb 2009 22:12:04 -0500

> the RFC, as Jon said, right?

Yes.  A lot of the problem and confusion that seems to be coming out  
of this thread is that people expect the RFC to specify everything  
about OpenPGP semantics.

RFC-4880 (like 2440 before it) is really a format document.  Even the  
title is telling: "OpenPGP Message Format".  The document contains  
enough information to understand the message format, and a lot of the  
semantics follows directly from that, but you won't really find a lot  
of these "what happens if" sort of answers there.  It's not that the  
OpenPGP community doesn't have an answer for them (the existence of  
multiple interoperating implementations shows that), but there is no  
RFC that can be pointed to.

Many of the questions you are asking are of that sort, hence the  
difficulty answering them.  At one point, there was discussion about  
writing a second document to cover these sorts of questions.  Possibly  
it is time to restart that.

Note that the answers I'm giving you are what implementations do, or  
what I would advise if someone wanted to do something different.  This  
is always within the scope what the RFC requires/allows, but may not  
be specifically mandated behavior.  In other words, it's RFC-4880  
compliant, but another implementation could do something else and also  
be RFC-4880 compliant.  The RFC also doesn't stop you from doing  
foolish things (which is a feature, not a bug).

> when the key was selected via key ID for example,.. or one of my other

I would advise against changing the expiration time of the key  
depending on how it is selected.  A key should have one expiration  
time, or you're in for a lot of pain when a user sending to one user  
ID sees the key as expired, but a user sending to a different user ID  
on the same key does not.  If that is the goal, you should be expiring  
the user IDs differently.  Not the key.

> WHOLE key is expired, right?

If you are expiring the whole key, then the whole key - all user IDs,  
all subkeys go with it.

> right? Of course what you've explained here above is probably the most

Yes.

> default via the 0x1F, expect you re-set it on the 0x13s?

No.  GPG ignores preferences on a 0x1F.  In practice, no  
implementation generates 0x1F signatures for anything other than  
designated revokers.

> a) only in the 0x1F but not the 0x13s

Sure: you want the getkey.c file, in the merge_selfsigs_main() function.

The shorter answer is that GPG will take an expiration, a revocation  
key ("designated revoker"), or key flags from an 0x1F.

> keyserver/features on 0x18 subkey binding signatures?

Features, maybe, but we don't currently have any flags that would be  
relevant for subkeys.  In any event, not all of the possible  
subpackets are meaningful in all possible signature types.

> self-signature is a trust-signature?

By definition a self-signature is ultimate trust ("this is me, and I  
trust myself always").  A trust signature is a way of limiting trust,  
which is not appropriate for a self-signature.

David

---

From: David Shaw <[email-masked]>
Date: Sun, 1 Feb 2009 22:23:02 -0500

> export the subkey either?!

No, it does not support this.  I like Jon's idea though.  It's a  
clever way to special-case a particular subkey.

> same signature must be used? Or was this just a "should"?

No.  This is only in case of conflict.  The RFC has a lot of language  
(in section 5.2.4.1) about how people should not automatically take  
the last subpacket without thinking.  Having multiples of certain  
subpackets is correct and reasonable, and does not imply conflict.   
For example you can certainly have multiple keyservers: there are  
multiple places to store a key.

David

---

From: Peter Thomas <[email-masked]>
Date: Mon, 2 Feb 2009 15:45:35 +0100

On Mon, Feb 2, 2009 at 4:12 AM, David Shaw <[email-masked]> wrote:
> Many of the questions you are asking are of that sort, hence the difficulty
> answering them.  At one point, there was discussion about writing a second
> document to cover these sorts of questions.  Possibly it is time to restart
> that.
Yes I see, and fully understand ;-)
I hope I didn't get to much on your nerves,... but I think it showed
that there's really an interest in such kind of a document :-)

> The
> RFC also doesn't stop you from doing foolish things (which is a feature, not
> a bug).
Well I'm not sure about this ;-)
>From a cryptosystem I'd expect that nearly everything is as strictly
defined as possible, in order to avoid ambiguities or conflicts
between implementations, which could lead to security issues.
But of course this is just my opinion, and it's not my intention to
offend the way it's handled right now :)

> I would advise against changing the expiration time of the key depending on
> how it is selected.  A key should have one expiration time, or you're in for
> a lot of pain when a user sending to one user ID sees the key as expired,
> but a user sending to a different user ID on the same key does not.  If that
> is the goal, you should be expiring the user IDs differently.  Not the key.
Of course,.. but this is just the problem I want to show. An
implementation could call itself conforming to the RFC (and actually
it would be), but it could do all these stupid an bad things.

> The shorter answer is that GPG will take an expiration, a revocation key
> ("designated revoker"), or key flags from an 0x1F.
Thanks.

Thanks,
Peter

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 02 Feb 2009 15:54:37 +0100

> multiple places to store a key.
I've tried this with gpg, but at least it seems that you can only set one keyserver.
Would it parse and query more keyservers if they'd be set in the subpackets?

Bye

---

From: David Shaw <[email-masked]>
Date: Mon, 2 Feb 2009 10:15:47 -0500

> Would it parse and query more keyservers if they'd be set in the  

Nope.  There are places where multiple subpackets are reasonable.   
That doesn't mean that a given implementation will actually act on them.

If you want a better example, look at designated revoker subpackets.   
GPG will only generate a single designated revoker subpacket per  
signature.  If, however, there are multiple designated revoker  
subpackets in a given 0x1F, GPG will act on all of them.  This implies  
properly handling the "sensitive" flag in the designated revoker as  
well, and dealing with the potential conflict when one revoker is  
sensitive and one is not, but they are located on the same subpacket  
so they cannot be separated.

David

---

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

On Feb 1, 2009, at 4:04 PM, Peter Thomas wrote:

>> out of

Why isn't the solution then what the RFC says -- that the last one  
takes precedence?

If you find this unsatisfying, then why not start an I-D to clarify?

> completely up to the implementation.

I apologize for not having the time to be an RFC lawyer, but if the  
RFC says that the last one takes precedence, I think we're done.

	Jon

---

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

On Feb 1, 2009, at 6:44 PM, Christoph Anton Mitterer wrote:

> * PGP Signed by an unverified key: 02/01/2009 at 06:44:23 PM
>

What's the difference?

Key expiration is expressed as a part of the self-signature. Yes, you  
could time-limit the self signature and thus when the self-signature  
expires you have a UID with no self-signature. But that strikes me as  
an eccentric way to do the same thing. The question was not about  
signature expirations, it was about key expiry.

> same signature must be used? Or was this just a "should"?

I believe that it is guidance not a mandate.

	Jon