Re: Series of minor questions about OpenPGP 6

[Jon Callas <jon@xxxxxxxxxx>]

-----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@xxxxxxx" 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
>


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFJg5VtsTedWZOD3gYRAjEWAKCzTgK60jwnkNc6gV6NT0rlBpOe3ACfQTf1
GqW0aFDRQds5vFJHEP2HWzg=
=xP4T
-----END PGP SIGNATURE-----