Add validity period guidance?
This is a slight broadening of scope, but it's closely enough related that IMO it fits reasonably here, and is small enough that it doesn't warrant its own I-D.
The interop suite's current opinion of how sbind validity periods should be calculated appears to violate the principle of least surprise (and is incompatible with the PGP.com/GnuPG interpretation).[1] In particular, it believes that (sub)key validity begins at the date of the most recent binding signature, and not the creation date of the (sub)key packet. IMO this is fragile - it means that in order to validate historical signatures made by a subkey, all historical sbinds over that subkey must be retained indefinitely (a similar argument applies to direct sigs). Thus, if a client strips older sbinds, historical signatures made by currently valid keys become invalid. This seems perverse.
We should issue guidance as follows:
- a "binding signature" is either a) a subkey binding signature b) a direct signature over a primary key c) in the absence of a direct sig, a self-certification over the primary userID
- binding signatures SHOULD NOT contain Signature Expiration Time subpackets, only Key Expiration Time subpackets
- a binding signature is valid if its creation time is later than the creation time of the primary key that made it
- a binding signature is also valid even if the primary has been hard-revoked (so that we can still associate the primary with its signing subkeys)
- (sub)keys are valid between their creation time and the soft revocation time or expiration time in the most recent binding signature
- a (non-binding) signature made by a (sub)key is a valid signature by that (sub)key if its creation time falls within the validity period of that (sub)key
- a (non-binding) signature made by a subkey is a valid signature if there is any valid sbind over that subkey, regardless of the contents of any signature creation time or signature expiration time subpackets
The prohibition against Signature Expiration in binding signatures prevents confusion that may arise if the key is valid but the binding signature over it has expired.
We should also specify that binding signatures cannot be revoked. This is a change from RFC9580, which states that a direct key signature can be revoked by a certification revocation signature - but this runs into the same problem as revoking or expiring an sbind, since a direct key signature is effectively a self-bind.