Bringing up a topic related to expirations, one thing that has bothered
me for a while is that the validity periods of keys, in terms of
expiration and revocation, are very ambiguous.
Consider these scenarios:
- Key expired two weeks ago. Status of a signature from three weeks ago?
- Key revoked two weeks ago, because it was compromised. Status of a
signature from three weeks ago?
- Key revoked two weeks ago, because no reason given. Status of a
signature from three weeks ago?
- Key revoked two weeks ago, because it was superseded. Status of a
signature from three weeks ago?
It's possible to argue for all extremes in all of these scenarios, and
the conservative choice would always be to reject the signature, however
this is not necessarily applicable for all implementation circumstances.
So the possibilities here are:
a) try to cover the key validity for most scenarios in the standard.
this seems tricky because I don't think all needs can be covered.
b) leave the main standard purely focused on data format, but add an
informational one with this sort of definitions.
c) add an explicit definition about treatment of retrograde signatures
to the expiration and revocation signatures themselves, i.e. delegate to
the implementation which creates the key.
d) none of the above, i.e. leave it to the implementation which uses the
key.
I'd like b), but that one implies a bunch of extra work.
- V
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp