Subject: Series of minor questions about OpenPGP 6

From: Peter Thomas <[email-masked]>
Date: Fri, 30 Jan 2009 23:14:31 +0100

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

---

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

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

> are invalided because they're expired, right?

Yes.

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

> something like don't import the signature itself and neither the

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.

> E.g. Two policy URIs in on 0x13, or two preferred key servers. And

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.

> (look closely as there are minor differences between the stuff  

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

---

From: David Shaw <[email-masked]>
Date: Fri, 30 Jan 2009 23:04:04 -0500

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

(skipping the ones Jon answered)

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

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