ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Key Validity Scenarios

2015-05-07 07:21:19
You're talking about the status of signatures for the purpose of human signing, not keys nor digsigs.

Such things as human signing digsigs can only be assumed / used within some form of context. Such a context could be a CPS or a contractual agreement (eg rules of keysigning party) or a cooperative (eg CAcert) or a law (eg Estonia & EU Directive). Without such an approach, the notion of human signing lacks foundation. With such an approach, it is up to the approach to decide what the status of signatures for human signing is.

In other words, it is out of scope of OpenPGP as it is currently constructed.

iang



On 5/05/2015 21:04 pm, Vincent Breitmoser wrote:

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.



So, yes, b).  BUt old chinese proverb:  be careful what you wish for!



iang

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>