ietf-openpgp
[Top] [All Lists]

Re: Behavior of implementations regarding certain key material

2000-05-29 18:00:38
In <tgwvkg74z2(_dot_)fsf(_at_)mercury(_dot_)rus(_dot_)uni-stuttgart(_dot_)de>, 
on 05/27/00 
   at 10:49 AM, Florian Weimer 
<Florian(_dot_)Weimer(_at_)RUS(_dot_)Uni-Stuttgart(_dot_)DE> said:

Jon Callas <jon(_at_)callas(_dot_)org> writes:

At 10:46 AM +0200 5/26/00, Florian Weimer wrote:
From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for
Revocation":

| A revoked certification no longer is a part of validity
| calculations.

We were a bit surprised when we discovered this change to RFC 2440
because RFC 2440 primarily specifies the OpenPGP message format,
and not the behavior of implementations when they encounter certain
OpenPGP messages, much to our discomfort.


Umm, so what is the problem? Is there a reason that a revoked certification
*should* be part of validity calculations?

No, of course not.  Our point is: There is no reason why an expired
certification should be part of validity calculations, either (at least
by default).  Ditto for expired keys.  But 2440bis does not state what to
do in these cases, and in fact, implementations already show different
behavior.  This is quite annoying if you want to limit in time the
validity of your certificates.  In the past, the only way to do that was
to revoke the certifying keys (yuk!); with 2440bis, you have to revoke
the certificates.  Both options lead to a quickly growing CRL, which is
very suboptimal.

Why can't you set an expiration time for the signature? This would seem
the optimal way to do this.

Just to make one thing clear: We do not want to standardize the validity
calculations themselves, nor the way the web of trust is built.  But we
do want to have a set of conditions under which a certificate or a key
won't be considered by validity calculations at all.

Well either you need to have some standardization or you are going to have
everyone doing their own thing. While I don't think a rigid RFC would be
needed I do think a separate informational RFC would be advised. 

From the point of view of interoperability it will be important for
developers to know how the WoT is being handled by the various vendors.
The major issue is keyring sharing. Take the situation of 5 OpenPGP
vendors developing both standalone and application integration products.
Either the vendors must require the end user to make use of separate
keyrings or there must be some documentation in this area so the various
vendor products can share keyrings.

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------