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