Re: Behavior of implementations regarding certain key material

["L. Sassaman" <rabbi@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31 May 2000, Lutz Donnerhacke wrote:

> * Werner Koch wrote:
> >On Tue, 30 May 2000, Lutz Donnerhacke wrote:
> >> But certificates of expired keys are still valid.
> >
> >However, this depends on the reason of certification.
> 
> No.
> 
> >For example, a revocation may have been issued to express that the
> >key has been compromised long time in the past and therefore the
> >signature has never been valid.
> 
> Every certificate of an revoked key is invalid. In law all certificates with
> has a timestamp before the key revokation timestamp are valid. German law
> contains a protocol error to not require the timestamp at receiver's end.

You say that every certificate of a revoked key is invalid. The current
draft claims otherwise. From 2440bis2:5.2.3.23:


   If a key has been revoked because of a compromise, all signatures
   created by that key are suspect. However, if it was merely
   superceded or retired, old signatures are still valid. If the
   revoked signature is the self-signature for certifying a user id, a
   revocation denotes that that user name is no longer in use. Such a
   revocation SHOULD inclide [sic] an 0x20 subpacket.

Note that this brings up several issues. Current implementations of PGP do
not use the Reason for Revocation tag, so all signatures made with PGP
currently must be treated as invalid if the signing key is revoked.

In the future, if this tag is used, keys revoked with reasons 0x01 and
0x03 should be considered "safe" in that certifications are still
valid. All other reasons for revocation, including 0x00, should render
certifications invalid.

I have ignored 0x20 on this issue, since it does not apply to revoked
keys.

I think that we should have another revocation reason, 0x04 - Preemptive
revocation certificate. I do not think that generating revocation
certificates at the time of key gen, and saving them for future use is the
best way to handle lost keys, but some people do this, and GnuPG actually
advises the user to make such revocations at the time of key
generation. Currently, they would fall into the category of 0x00, but due
to the lack of a valid timestamp on them, I would prefer to see them with
a more specific reason. Keys revoked with this reason should also render
their certifications invalid.


> >It is not easy to check this because it may be a pre-generated revocation
> >or a malicious revocation.
> 
> Definititly. That's why the law requires a timestamp on revokation and
> ultimate publication.

Again, a good reason to have a new reason for revocation in the case of
pre-generated revocations.

Another interesting problem that appears when certain revocations do not
render certifications invalid is that now we must still provide the user
with the means of re-revoking his key with a different reason for
revocation. If the reason is 0x01 or 0x03, it seems to me that we would
want to allow the user to change it to 0x02 if indeed it had been
compromised.


Or we simply say that all certifications by revoked keys are invalid, and
change the wording in the draft. 




__

L. Sassaman

System Administrator                |  "It's a nice day 
Technology Consultant               |   to start again."
icq.. 10735603                      |    
pgp.. finger://ns.quickie.net/rabbi |        --Billy Idol







-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE5NXBPPYrxsgmsCmoRAlf+AJ9tueOebqUju8Mqpw8P6FxTJFTZlQCdG+Mt
avRioD4mjQlivh29zsaYoa0=
=Z7W9
-----END PGP SIGNATURE-----