On Tue, 2015-05-05 at 22:04 +0200, 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.
Well that's one of the points I've mentioned in my original wishlist:
While I don't think we should overly aggressive define trust models,
some of the questions you answer are not well defined, so one can
basically only hope that the implementation makes a sane choice.
But such ambiguities always leave up some space for meta-level attacks,
social engineering and so on.
- Key expired two weeks ago. Status of a signature from three weeks ago?
IMHO not well defined.
One may e.g. choose to consider the signature still valid, but not the
key... and e.g. an implementation may then say "valid signature from a
trusted but expired key".
In addition it may e.g. make some "guess"... like when they expiration
is 5 days ago it may just print the warning... but if it was 10 years
ago it would start to flash the screen like mad and play alert sirens at
all sound devices.
One clearly sees... nothing well defined... quite ambiguous.
- Key revoked two weeks ago, because it was compromised. Status of a
signature from three weeks ago?
Not sure whether it's formally standardised, but it's clear that the
signature needs to be considered invalid in any case, as the attacker
can of course forge any date.
- Key revoked two weeks ago, because no reason given. Status of a
signature from three weeks ago?
Again... not defined.
I (personally) would probably say that in case of "no reason given" one
must assume the worst case (key compromise - the revocation certs may
have been created for that purpose at the key creation, but without a
reason, since it wasn't known yet).
So same as directly above.
- Key revoked two weeks ago, because it was superseded. Status of a
signature from three weeks ago?
As above.... not well defined.
I'd probably choose something like the first paragraph above.
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.
I have no strong opinion whether such definitions should be part of the
"core RFC", but they should be definitely standard and mandatory
defined.
The reason is simply that people may actually depend their security on
such things being used/interpreted as they should (whatever that is).
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp