Subject: Behavior of implementations regarding certain key material

From: Florian Weimer <[email-masked]>
Date: 26 May 2000 10:46:46 +0200

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.

We would like to see other requirements such as "An expired
certification is no longer part of validity calculations."  If you
are running a CA, you certainly want all implementations to react
to certfication expiration, certifying key expiration, certication
revocation etc. in the same manner.

If you agree that this should be addressed, we can document additional
requirements which make sense from our point of view as a basis for
further discussion.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

---

From: Jon Callas <[email-masked]>
Date: Fri, 26 May 2000 16:47:25 -0700

>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?

You're correct that 2440 is a syntax document, not a semantics document.
However, there are times when you have to hint at semantics when you're
describing syntax.

In this particular case, OpenPGP does not specify a trust model. At one
time, there were going to be a series of documents describing various trust
models that one might use (for example, the so-called web of trust), but no
one has seen fit to write these documents.

However, even though we don't specify what validity calculations to use,
there are nonetheless syntactic things we have to say about them. Whatever
validity model you're using, it seems pretty straight forward that a
revoked certification is null and void. That's all this is saying. It's in
2440bis because consensus asked that it be there.

	Jon

---

From: Florian Weimer <[email-masked]>
Date: 27 May 2000 10:49:21 +0200

> *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.

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.

---

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 29 May 2000 19:44:35 -0500

In <[email-masked]>, on 05/27/00 

>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
---------------------------------------------------------------

---

From: Florian Weimer <[email-masked]>
Date: 30 May 2000 16:47:23 +0200

> the optimal way to do this.

AFAIK, there are implementations which use expired certificates in
validity calculations.  The certificate is used once to propagate
trust, and if the neighborhood of the web of trust doesn't change,
nothing happens if a certificate expires.

> everyone doing their own thing. 

I believe that everyone shall build his own web of trust as he sees
fit, but that's more a political statement than a technical one, of
course.  But I do want to have control over the validity of
certificates issued by myself, that's the reason why I think that some
standardization (i.e. some necessary (but not sufficient) conditions
for certificate and key validity) are very useful.

> While I don't think a rigid RFC would be

Yes, that was our internal conclusion as well.  Oliver Goebel
<[email-masked]> is preparing such a document.  In
addition, the document will contain recommendations for interactive
OpenPGP implementations in borderline situations (just as an example,
what to do if a chain of trust can be established to a key, but some
of the links are expired certificates? -- the user should be given the
choice not to use the key, use it anyway, or sign it locally to
prevent future questions).

> The major issue is keyring sharing. 

I don't think this is a problem.  Vendors can provide suitable
conversion programs.  In fact, OpenPGP implies a rather canonical key
ring exchange format (simple concatenation of keys), and I think all
OpenPGP implementation can handle this format.

On the other hand, say if a secret key is protected by a passphrase
and OpenPGP-optional symmetric cipher, there will always be
implementations which cannot do anything useful with it, simply
because the actual key material is protected by an unsupported cipher.

(Direct key ring sharing doesn't make sense anyway because the actual
key ring data structure depends heavily on the given application.
Locking is another issue.)

---

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 12:17:54 -0400 (EDT)

>>>>> "Florian" == Florian Weimer <[email-masked]> writes:

 Florian> Jon Callas <[email-masked]> 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?

 Florian> No, of course not.  Our point is: There is no reason why an
 Florian> expired certification should be part of validity
 Florian> calculations, either (at least by default).  Ditto for
 Florian> expired keys.  But 2440bis does not state what to do in
 Florian> these cases, and in fact, implementations already show
 Florian> different behavior. 

It seems to me the logical thing to do is very easy to describe:
expired or revoked certs are treated as if they were nonexistent.

	paul

---

From: [email-masked] (Lutz Donnerhacke)
Date: 30 May 2000 16:39:45 GMT

>expired or revoked certs are treated as if they were nonexistent.

But certificates of expired keys are still valid.

---

From: Werner Koch <[email-masked]>
Date: Tue, 30 May 2000 19:46:32 +0200

> But certificates of expired keys are still valid.

However, this depends on the reason of certification.  I am not sure
whether the codes we already have for this are sufficient to
automatically determine whether the cerificate is still valid.

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.  It is not easy to check this because
it may be a pre-generated revocation or a malicious revocation.

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

---

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 13:43:51 -0400 (EDT)

>>>>> "Lutz" == Lutz Donnerhacke <[email-masked]> writes:

 >> expired or revoked certs are treated as if they were nonexistent.

 Lutz> But certificates of expired keys are still valid.

For verifying old stuff, yes.  Not for new stuff.  So my simple
description was too simplistic.  I would apply it to things expired or
revoked as of the creation date of whatever I want to verify.

	paul

---

From: "L. Sassaman" <[email-masked]>
Date: Tue, 30 May 2000 11:32:11 -0700 (PDT)

> revoked as of the creation date of whatever I want to verify.

Eh? If you sign my key, and then your *key* expires, your signature is
still included in validity calculations for my key. Even after your key
expires. (However, you had to sign my key prior to the expiration of
yours).

__

L. Sassaman

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

---

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 14:37:07 -0400 (EDT)

>>>>> "L" == L Sassaman <[email-masked]> writes:

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

 Lutz> * Paul Koning wrote:
 >> >> It seems to me the logical thing to do is very easy to
 >> describe: >> expired or revoked certs are treated as if they were
 >> nonexistent.
 >> 
 >> description was too simplistic.  I would apply it to things
 >> expired or revoked as of the creation date of whatever I want to
 >> verify.

 L> Eh? If you sign my key, and then your *key* expires, your
 L> signature is still included in validity calculations for my
 L> key. Even after your key expires. (However, you had to sign my key
 L> prior to the expiration of yours).

Agreed; that's what I meant.  (Checking the signature requires a key
that was good at the time that signature was created.  It's the
signature that is being verified, and the date of that signature is
what matters.)

     paul

---

From: [email-masked] (Lutz Donnerhacke)
Date: 31 May 2000 08:36:28 GMT

* Werner Koch wrote:
>However, this depends on the reason of certification.

No.

>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.

>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.

---

From: "L. Sassaman" <[email-masked]>
Date: Wed, 31 May 2000 13:04:23 -0700 (PDT)

> 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.

> Definititly. That's why the law requires a timestamp on revokation and

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