Re: Series of minor questions about OpenPGP 6


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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 "security(_at_)pgp(_dot_)com" 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