Subject: RE: New ID: draft-gerck-pkix-revocation-00.txt

From: "Dave Engberg" <[email-masked]>
Date: Fri, 28 May 2004 16:12:25 -0400

Ed -

Thanks for putting together this revocation memo.  This provides a very
useful philosophical analysis for PKI architectures.

To paraphrase one of the central arguments (section 3.1.2):  the
objective revocation of a certificate is (basically) defined as the
first instant of publication of a corresponding CRL (or Delta CRL, OCSP
response, etc.) by the cert's issuer.  You separate this definition of
revocation from the more ambiguous processes of checking revocation
through all of our non-transactional PKI protocols.

I'm interested to hear why you chose to define "objectively revoked" in
terms of the completion of publication rather than the moment of
notification to the CA.

Consider:  I'm familiar with a large PKI that used to require a few
hours to produce a CRL.  If the CA was notified of a revocation at 9am,
the first external communication about this revocation would only be
available in the afternoon.

If you asked the administrators of this PKI, they would have intuitively
felt that the cert was "really" revoked at 9am, and that the latency
between this time and the first publication was just a propogation delay
for the objective reality.

Obviously, this is an extreme example, but there will always be some
latency between a CA's notification of revocation and when that
information propogates to Relying Parties.  I'm curious why you put part
of this latency (production of the CRL) before the "objective
revocation" and parts of it (distribution to LDAP directories, OCSP
responders, transmission to RPs) after the objective moment of
revocation.

Thanks,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ed Gerck
Sent: Thursday, May 27, 2004 8:56 PM
To: PKIX
Subject: New ID: draft-gerck-pkix-revocation-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is an individual submission in reference to the Public-Key
Infrastructure
(X.509) Working Group of the IETF.

	Title		: Certificate Revocation Revisited
	Author(s)	: E. Gerck
	Filename	: draft-gerck-pkix-revocation-00.txt

...

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 28 May 2004 17:16:19 -0700

>terms of the completion of publication rather than the moment of

Dare I speak for Ed on this matter ... :)

I may feel I have notified my CA of (compromise, revocation desire, etc) at 
time T.

The CA is free to take this into consideration, according to their own 
processes.  Those processes are (and perhaps should be) quite opaque to 
outsiders.  The world of RPs who may rely upon that certificate must, of 
necessity, depend upon a notification made by the CA.  From a strictly 
formal standpoint, the certificate is not revoked when the CA "feels" is it 
revoked, but only when the CA SAYS it is revoked.  They are the only 
authority in this matter.

It might be "nice" if such notifications included "reason", indicating 
(perhaps) "report of compromise at time T".  But really, what CA would want 
to open itself to such (potential) liability?  Of what other value (except 
to put the CA into hot water) would one desire to learn that a certificate, 
revoked this moment but relied upon 1 hour ago, was reported compromised 2 
hours earlier?

 From the RP standpoint, it was reasonable and "right" to rely upon it 1 
hour ago, in any case.

Should the RP desire certifications that limit the "window of opportunity" 
to 5 minutes, they must reject certifications made by CA's that do not 
support sufficient timeliness.  "Let the RP beware".

Cheers!   ____tony____

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Ed Gerck <[email-masked]>
Date: Fri, 28 May 2004 18:35:56 -0700

> useful philosophical analysis for PKI architectures.

I hope it's more practical than philosophical ;-)

The  philosophical aspect might be that because similar issues can be recognized
in other areas, the memo benefits from their solutions. For example, when
verifying the revocation status of a cert for a given time T, what does it mean
to require that two different RPs shall come to the same result for the same time
T? It means that the revocation status shall be an objective reference. Which
introduces some requirements, one of which is observability.

> terms of the completion of publication rather than the moment of

First, we need to distinguish between "notice" and "status" (perhaps a new
item to be discussed in the ID). The moment of notification to the CA is a
notice. For example, a request for revocation sent by the subscriber. A
revocation notice is NOT the revocation status, and is also NOT that status
available as an observable entity. The certificate's status changes NOT when
the notice is received but when the CRL is published. Moreover, in  order
to be objective, the revocation status needs to be observable -- for example,
the published status must be readable by an RP.

> available in the afternoon.

As defined in the freshestCRL field, for example.

> for the objective reality.

This is exactly what the ID clarifies: the cert was not revoked at 9am. The
event that can be observed by any RP is the first external communication
about this revocation, which would only be available in the afternoon
according to your example.

> information propogates to Relying Parties.  

Yes, this is discussed in section 4.6, "Increasing Reliability",
which also discusses how the latency can be reduced or, at least,
bounded.

> I'm curious why you put part

Because the latency that corresponds to the "notice" process (including
production of the CRL and the delay for its publication in the next update)
cannot be reduced by any efforts of the RP. The RP is entirely at the
mercy of the CRL issuer for this part. OTOH, after the objective moment
of revocation (i.e., the revocation status "revoked" is observable by
any RP), additional efforts by an RP should increase the ability of the
RP to make a reliance determination of a certificate's revocation status
in less time.

Cheers,
Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Fri, 28 May 2004 18:47:23 -0700

Tony Bartoletti wrote:
> Should the RP desire certifications that limit the "window of 
> opportunity" to 5 minutes, they must reject certifications made by CA's 
> that do not support sufficient timeliness. 

Yes. This can be easily automated by the RP by using the freshestCRL field,
for example. If the CRL was issued more than 5 minutes ago, wait for the
next CRL and decide within 5 minutes of its publication.

 > "Let the RP beware".

Yes, "Let the RP beware" because RP reliance is that which can break the RP's
security policy (Section 2 of the ID). The revocation status of a cert depends
both on processes that the RP CAN verify and processes that the RP CANNOT
verify. The latter defines the limitations of RP reliance. The lesser the
limitations of RP reliance, the lesser the risk faced by the RP that RP
reliance might be broken by factors outside RP control.

Cheers,
Ed Gerck