Subject: Re: Current status of CRL validation ?

From: Ed Gerck <[email-masked]>
Date: Fri, 02 Apr 2004 14:26:53 -0800

Stephen Kent wrote:
> 
> Ed,
> 
> I really should have asked the context in which you were referring to
> an RP's reliance on revocation status info. 

I welcome this clarification. Saying that the RP "relies" is not enough.
The context of an RP's reliance is what provides the RP's justification 
for reliance. 

It's easy to say that an RP's justification of reliance is a matter of 
need. But this is not quantitative. If we are to make some progress in 
this, we need to define those needs as degrees or levels -- i.e., in terms 
that we can identify their differences and their required revocation models.

For starters, I'd suggest the following reliance levels (from weaker to stronger):

(0) What the RP relies upon without any consideration of "why" and without 
any recourse (open reliance).

(1) What the RP relies upon without any consideration of "why" (actual reliance).

(2) What the RP relies upon because it is presented by a party accepted by the 
truster for that purpose (authorization reliance).

(3) What the RP as a reasonable man might do, with all prudence that might be
reasonable to use (reasonable reliance). In other words, "what would be reasonable
for a prudent man to do under the circumstances".

(4) What can be justified by the RP after an examination of the facts presented
(justified reliance).

As usually defined by a CA's CPS, revocation information provided by a CA is 
level (0). The RP has no contract relationship with the CA and is denied any 
warranties and rights to recourse. The revocation information is provided by 
the CA to an RP "as is". 

Therefore, it does not help much to talk about CRL issue dates and RP reliance
if the RP is stuck in level (0). No matter how frequent we make those CRL
updates (and how much excess traffic we impose on the RP), that's why I
said that the RP is unable to measure with any desired confidence (i.e., 
desired by the RP) whether a cert is revoked or not.

The RP can hope to move to levels (1) and (2) when using a Trusted Responder 
during certificate reliance (i.e., whether the cert has been revoked or not) 
under CRLs or OCSPs. However, as I said before, one cannot rely upon them for 
other than their value as a representation of the issuer CA revocation 
management as expressed in the issuer CA own terms and rules -- which are
in level (0).

Thus, even though a X.509/PKIX cert is either revoked or not (and, yes, 
this is strictly enforceable in X.509/PKIX),  X.509/PKIX is unable to
allow a RP to measure with any desired confidence whether the cert is
in fact revoked or not.

The real problem is to make the cert unusable when revoked.

> If the RP is validating a
> signature for NR purposes, then the RP is nominally protected if he
> waits until the "next" CRL is issued before he acts on the signed
> object. 

The "next" CRL is usually one or two weeks away. Hardly worth waiting
for in an e-commerce transaction -- may as well fly there. And if the 
cycle is shorter, traffic shoots up.

> The CRL issuer is the only game in town re authoritative info
> on the revocation status of a cert. AN RP is, by definition, a
> "relying" party and he relies on the cert and CRL issuer(s) to
> provide this status data when they have said it becomes available. 

A relying party to whom? If in level (0), to himself.

> if
> the RP cannot tolerate the wait, tough luck. 

The wait would be one to two weeks today. And for an information without
any reliance except as an open statement. Tough luck indeed ;-)

> If the RP is using a signature in an access control context, then the
> problem is often different. For access control purposes, one usually
> will not have the luxury of waiting for the next CRL to determine
> revocation status, and even use of OCSP may not help, as many OCSP
> servers are driven by CRLs. But, this is not an X.509 problem per se.
> If the operator of an access control systems wants to ensure that a
> user's privileges are revoked quickly, then the best way to do that
> is to change the ACLs associated with the resources being protected,
> or to push a hot list to each resource access manager. When certs are
> used to verify identity in support of access control, these general
> rules apply, and they are not fundamentally different than if one had
> chosen to use passwords for user authentication.

If X.509 revocation information could be trusted in this context,
access control would not have that security gap.

> >We have struggled with this passage before. Thanks for helping me
> >clarify it now. In short, I mean that revocation by reference (i.e., a
> >X.509 reference that X is revoked) does not revoke anything. Actual
> >revocation, OTOH, would make it impossible to use the cert -- even if
> >a reference about its revocation is not available.
> 
> One cannot, in general, make "it impossible to use the cert" but one
> can make a cert unusable in a given context. But that is not
> surprising. In many systems with capability-like properties,
> revocation effected by seizing an access token is often infeasible.

Seizing the token is not the only way to make the token unusable.

> If I have a keyed padlock on a locker, I can change the lock to
> effect revocation of access privileges for the holders of keys, and
> reissue new keys for the new lock to the folks I want to authorize.
> Do I know that the keys that are out there will not be able to open
> any other padlocks? Not really/ There may have been another padlock
> that would accept the same keys and I don't now, nor can I prevent
> the use of the keys in that padlock.

Even though I usually dislike physical metaphors for crypto locks/keys,
I think that you surely can prevent the keys that are out there to open 
any other padlocks.  It's called key management and is the same with
crypto locks/keys.

> So, I'm afraid I don't find your clarification helpful. Maybe we're
> still just missing a concisely stated context for the comment.

Revoking by reference (the current method with CRLs and OCSPs) has some 
unsolved and unsolvable problems, and does not solve the real problem. 
The real problem is to make the cert unusable when revoked. For that, 
one should also not need to trust user intervention (even to update 
software, as some certs have been revoked).

Cheers,
Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Fri, 02 Apr 2004 14:31:52 -0800

(2) What the RP relies upon because it is presented by a party accepted by the 
RP for that purpose (authorization reliance).

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 14:08:05 -0400

Ed,

I'd like to respond to each of your points, but experience has shown 
that we never manage to get closure in these exchanges.

Since you are convinced that X.509 and PKIX standards do not address 
the real problems that a certification system should address, and 
since this list is devoted to PKIX standards development, let's just 
stop now and save everyone's time.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Mon, 05 Apr 2004 11:55:00 -0700

> stop now and save everyone's time.

Steve,

Let me clarify. Nothing that I wrote is a critique of X.509 or
PKIX. I use X.509/PKIX everyday. I'm simply stating that there is 
a problem with certificate validation in X.509/PKIX. The problem
is very basic, as I outlined. I think it's incumbent upon the PKIX
WG, sooner or later, to address the need for a better revocation
mechanism.

BTW, there is no closure possible ;-) I'd like keep this old
grudge until it's solved.

Cheers,
Ed Gerck

PS: Private mail is also fine if you want to exchange tentative ideas
on this.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 17:14:07 -0400

Ed,

PKIX is winding down now; we are not taking on any new work items. I 
suspect that anything as basic as what you allude to would be a 
significant departure from what we have done, and thus is not 
appropriate for PKIX to pursue.

Stev

---

From: Ed Gerck <[email-masked]>
Date: Mon, 05 Apr 2004 15:31:10 -0700

Steve,

How about a clarification to be added to the current PKIX documents
that deal with revocation and validation of certs? This would help 
the weary reader, who must otherwise wade through this list's archives
in order to find the limitations we have been discussing. For example 
(using some of your previous text):

NOTE:
 In X.509/PKIX only the issuer of a certificate can revoke it and there 
 is only one issuer for a given certificate. Therefore, a certificate 
 is either revoked or not. However, the ability of a RP to establish
 the validity of a certificate is a function of the certificate path 
 that the RP uses to validate the certificate, and of the access to 
 revocation status information available to the RP. Since there may be 
 more than one path used to validate the same certificate, it is possible 
 to obtain different answers to the question whether a certificate is 
 valid, depending on which path the RP uses. Also, two RPs may have 
 access to different revocation status data for the EE certificate or for
 a CA certificate along a path, so that each RP may arrive at a different
 view of the validity of the EE certificate at any given time.

 Moreover, in X.509/PKIX reliance terms, one may trust the confirmation 
 procedures of the issuer CA, the issuer CA Designated Responder or any 
 Trusted Responder during certificate reliance (i.e., whether the 
 certificate has been revoked or not) under CRLs or OCSPs, but one cannot
 rely upon them for other than their value as a representation of the 
 issuer CA revocation management as expressed in the issuer CA own terms 
 and rules, usually contained in the CA CPS.

Comments?

Cheers,
Ed Gerck

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 5 Apr 2004 19:30:10 -0500

>(using some of your previous text):

New work items are decided by the WG, not just one co-chair. You are 
asking the WG whether or not we should take up a clarification 
document based on just two paragraphs of text. As Steve said, we're 
trying to wind down, so such a generic request is really hard to 
support.

If you are serious about this work item (and I'm not suggesting that 
you are), please put together an abstract and a reasonably complete 
outline so the WG can see if we want to do it. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Ed Gerck <[email-masked]>
Date: Mon, 05 Apr 2004 20:34:28 -0700

Paul Hoffman / IMC wrote:
> document based on just two paragraphs of text. 

No, I'm based on the recent list traffic Re this subject line.

> As Steve said, we're

What is generic about it? It's two paragraphs of text that address
head on the question whether a cert is revoked or not, both from the
issuer CA point of view as well as from the RP's.

> outline so the WG can see if we want to do it. Thanks!

My abstract is my previous posting; the reasonably complete outline
is this list's archive with all ~20 messages re "Current status of CRL
validation ?" 

If you are serious about your comment (and I see no reason to suggest
you are not), please note that the WG already has in the recent list
archive all ~20 messages it needs in order to consider my proposal, 
including my very succinct suggestion for the clarification.

I think that the WG can reasonably expand or rework what I have
already presented as my input. I am of course available for a 
second, third or n-pass.

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Apr 2004 09:31:12 -0400

>  and rules, usually contained in the CA CPS.

We have a suggestion before the WG to issue an update to 3280, so the 
WG can decide if text of the sort noted above should be part of the 
update, if we proceed on that work item.

With regard to the text above, I like the first paragraph :-), but 
the second one becomes murky very quickly. The paragraph doesn't 
convey any meaning to me.
It probably doesn't help that the paragraph is one, 6 line sentence, 
or that it introduces terms such as "CA Designated Responder," 
"Trusted Responder," ...

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 6 Apr 2004 13:56:34 -0400

Steve:

I do not have objection to parts of the first paragraph.  But, the first two
sentences of the paragraph are not accurate by most interpretations.  I
quote:

"In X.509/PKIX only the issuer of a certificate can revoke it and there is
only one issuer for a given certificate. Therefore, a certificate is either
revoked or not."

Through indirect CRL issuer mechanism (as defined in X.509 and in 3280), an
indirect CRL issuer can revoke a certificate with or without the knowledge
of the certificate issuing CA.  Since neither standard provide operations
related guidance (lack of this guidance is appropriate in the case of both
the standards), a subscriber can directly contact indirect CRL issuer and
have their certificate placed on the CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, April 06, 2004 9:31 AM
To: Ed Gerck
Cc: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation
?

At 3:31 PM -0700 4/5/04, Ed Gerck wrote:
>that deal with revocation and validation of certs? This would help the 
>weary reader, who must otherwise wade through this list's archives in 
>order to find the limitations we have been discussing. For example 
>  Moreover, in X.509/PKIX reliance terms, one may trust the 
> confirmation  procedures of the issuer CA, the issuer CA Designated 
> Responder or any  Trusted Responder during certificate reliance (i.e., 
> whether the  certificate has been revoked or not) under CRLs or OCSPs, 
> but one cannot  rely upon them for other than their value as a 
> representation of the  issuer CA revocation management as expressed in 
> the issuer CA own terms  and rules, usually contained in the CA CPS.
>
>Comments?
>
>Cheers,
>Ed Gerck

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 06 Apr 2004 10:36:59 -0700

> update, if we proceed on that work item.

Sounds like good timing. 

> With regard to the text above, I like the first paragraph :-), 

;-) I improved it a bit.

> but

Agree. I reworded it as:

 To decide whether a certificate has been revoked or not, a RP may 
 trust the confirmation procedures of the issuer CA, or a proxy 
 designated by the CA, or any third party that the RP so chooses. 
 However, the RP cannot rely upon them for other than their value 
 as a representation of the issuer CA revocation management policy.

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Apr 2004 14:24:30 -0400

Ed,

>  as a representation of the issuer CA revocation management policy.

Getting better. But the last sentence, as best I can make out, just 
says that the CA or its designees can only tell an RP about the 
revocation status of a cert as seen by the CA. This seems almost a 
tautology, and does not shed light on whatever subtle issue is 
lurking behind the words.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Apr 2004 15:08:32 -0400

>have their certificate placed on the CRL.

Good point. I overlooked that "feature" of the newer CRLs. Of course, 
I always thought it was a very questionable feature, so maybe I was 
pre-disposed to overlook it ;-)

The problem is not so much that a subscriber could ask someone other 
than the issuer of his cert to list it on an indirect CRL, but rather 
that we have no way for an RP to know whether certs listed in this 
way are appropriately revoked, in the general case. An indirect CRL 
is not authoritative for the entries that refer to certs issued by 
other CAs. In that sense I would still argue that only the issuer can 
revoke the certs that it issues. The use of indirect CRLs is much 
like using OCSP, in that an RP that is configured to accept 
revocation status data from a CA issuing an indirect CRL implicitly 
assumes that the CA is authorized to revoke whatever certs it chooses 
to list in this fashion. i don't think we would say that any OCSP 
server can revoke any cert, even though any server can issue a 
respnse that asserts that any cert is revoked. It's an issue of 
whether a RP is configured to accept status info from an OCSP server, 
or in the case of an indirect CRL, to accept indirect 
(non-authoritative) CRL entries.

Steve

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 06 Apr 2004 17:49:29 -0400

Ed,

While the first paragraph is factually correct, it nonetheless may
lead the careless reader to an incorrect conclusion, namely that
it is possible for an RP to obtain two *conflicting* answers, rather
than merely two different answers.

If you ask whether an IP packet can reach its destination through
a mesh of routers, the answer may well be that some paths are valid
while others are not due to link failures.  But as long as at least
one path is valid, the destination is reachable.  There is no
conflict between paths that are up and those that are down.

There would be less chance of misinterpretation if your Note were
to say:
  "Since there may be more than one path used to validate the
  same certificate, it is possible that some paths to that
  certificate are valid while others are not."

As you say, there is an unambiguous validity status for each
certificate in every potential path.  Validation engines used
by RP software can always return an unambiguous answer:
 * valid if at least one valid path exists,
 * invalid if no path is valid and all CRLs are available, or
 * unknown if no path is known valid and at least one CRL for
    a potentially valid path is unavailable.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 6 Apr 2004 17:48:35 -0400

Steve:

Both X.509 and 3280 are very clear in this area.  The CA need not issue CRL
(ref: introduction in 3280 and paragraph 3 in introduction of Section 5 in
3280 just as a start and there is more).

The relying party software can use the indirect CRL issuer information and
thus from software viewpoint, certificate issuer may not be involved.

From operations, viewpoint, I gave a simple model where the certificate
issuer is not involved.

Thus, adding those sentences creates conflict in the standard.

Now, to the security issue, I agree that indirect CRL mechanism is not a
good idea.  It should be a matter of relying party policy.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, April 06, 2004 3:09 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: clarification proposal -- Re: Current status of CRL validation
?

At 1:56 PM -0400 4/6/04, Santosh Chokhani wrote:
>Steve:
>
>I do not have objection to parts of the first paragraph.  But, the 
>first two sentences of the paragraph are not accurate by most 
>interpretations.  I
>quote:
>
>"In X.509/PKIX only the issuer of a certificate can revoke it and there 
>is only one issuer for a given certificate. Therefore, a certificate is 
>either revoked or not."
>
>Through indirect CRL issuer mechanism (as defined in X.509 and in 
>3280), an indirect CRL issuer can revoke a certificate with or without 
>the knowledge of the certificate issuing CA.  Since neither standard 
>provide operations related guidance (lack of this guidance is 
>appropriate in the case of both the standards), a subscriber can 
>directly contact indirect CRL issuer and have their certificate placed 
>on the CRL.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Apr 2004 18:08:10 -0400

>3280 just as a start and there is more).

yes, but I thought that was an accommodation for OCSP, in the case of 3280.

>thus from software viewpoint, certificate issuer may not be involved.

yes, but doing so is dangerous unless there are appropriate controls 
on the set of CAs for which the indicates CA can issue indirect CRLs. 
I bet such controls are rarely if ever available on clients.

>good idea.  It should be a matter of relying party policy.

well, at least we agree on that, which is the underlying issue here.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 6 Apr 2004 18:17:06 -0400

Steve:

Here is the quote from 3280, paragraph 3, Section 5.

"CRL issuers issue CRLs.  In general, the CRL issuer is the CA.  CAs
   publish CRLs to provide status information about the certificates
   they issued.  However, a CA may delegate this responsibility to
   another trusted authority.  Whenever the CRL issuer is not the CA
   that issued the certificates, the CRL is referred to as an indirect
   CRL."

This may have been done to accommodate OCSP, but as the RFC is written, it
should be interpreted to accommodate various situations, not just OCSP.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, April 06, 2004 6:08 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: clarification proposal -- Re: Current status of CRL validation
?

>The relying party software can use the indirect CRL issuer information 
>and thus from software viewpoint, certificate issuer may not be 
>involved.

>  >From operations, viewpoint, I gave a simple model where the 
>certificate issuer is not involved.
>
>Now, to the security issue, I agree that indirect CRL mechanism is not 
>a good idea.  It should be a matter of relying party policy.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 06 Apr 2004 15:56:35 -0700

> have their certificate placed on the CRL.

Santosh,

Yes, semantically, an indirect CRL issuer can "revoke" a cert as
requested by the cert's subscriber. However, does this mean that 
the revocation signature is chained to the issuer CA of that cert? 
Not necessarily. Thus, a RP may have no way of knowing whether 
such "revocation" is bogus or not. The issuer CA is the only 
authoritative source, by virtue of crypto math, that can revoke 
a cert (or delegate such revocation by chaining). Anything else is 
not much more than hearsay.

That's exactly why I added the second paragraph to the proposed 
clarification note. It says that, when deciding whether a certificate 
has been revoked or not, a RP cannot rely upon the confirmation 
procedures of any party that the RP chooses (e.g., a delegated CRL
issuer, or an indirect CRL issuer) for anything other than their 
value as a representation of the issuer CA revocation management 
policy. 

Cheers,
Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Tue, 06 Apr 2004 16:21:29 -0700

Steve,

I think your reply to Santoshi exemplifies why the second paragraph
is needed in the proposed clarification. It is not about the "revocation 
status of a cert as seen by the CA". It is about who has authoritative 
management of that status in what context.

The second paragraph is needed to assert that the issuer CA is and 
remains authoritative for the policy governing revocation management of 
certs issued by that CA in *all* contexts. Even when such revocation is 
delegated by the CA, or is designated to another entity by the cert 
subscriber or by the RP. This goes beyond the crypto math assurances 
underlying and linking the issuer CA signature of the cert and its 
possible CRL.

BTW, as an alternative to that second paragraph, I suggest: 

When deciding whether a certificate has been revoked or not, a RP 
cannot rely upon the confirmation procedures of any party that the 
RP chooses (e.g., a delegated CRL issuer, or an indirect CRL issuer)
for anything other than their value as a representation of the 
issuer CA revocation management policy. The issuer CA is authoritative 
for the revocation management of certificates issued by that CA.

Cheers,
Ed Gerck

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 6 Apr 2004 21:10:16 -0400

Any chnage of this nature is inconsistent with how X.509 and 3280 are.

On Tue, 06 Apr 2004 16:21:29 -0700, Ed Gerck wrote
> is needed in the proposed clarification. It is not about the 
> "revocation status of a cert as seen by the CA". It is about who has 
> authoritative management of that status in what context.
> 
> remains authoritative for the policy governing revocation management 
> of certs issued by that CA in *all* contexts. Even when such 
> revocation is delegated by the CA, or is designated to another 
> entity by the cert subscriber or by the RP. This goes beyond the 
> crypto math assurances underlying and linking the issuer CA 
> signature of the cert and its possible CRL.
> 
> issuer CA revocation management policy. The issuer CA is 
> authoritative for the revocation management of certificates issued 
> by that CA.
> 
> Cheers,
> Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Tue, 06 Apr 2004 23:43:53 -0700

Dave,

I agree:

However:

(1) the valid paths may present the same answer but at least one
of the answers is stale and should have been different at that time
(e.g., due to delays before and after publication),

(2) the valid paths may present conflicting answers (e.g., due to 
race conditions), 

(3) even though in principle the answers are always resolvable to 
one conclusion (since an X.509/PKIX cert is either revoked or not), 
resolution may be impossible in practical terms by a RP software. 
For example, it may need more time than what's available, and/or 
need additional channels not included/reachable by that RP software, 
and/or need human intervention.

An ambiguous answer may exist by conditions (1), (2), (3) or their
combinations. In other words, it is possible for a RP to obtain 
two *conflicting* answers for the same cert. It is also possible for 
different RPs to obtain *conflicting* answers for the same cert. 
These possibilities, and you are correct, can be concluded from that 
first paragraph. Nonetheless, from the issuer CA viewpoint, the 
cert is either revoked or not. Unambiguously.

Is this a flaw? The rather surprising answer is that it isn't. An 
ambiguous answer is more informative than an unknown answer -- 
which is also possible. In other words, a RP would rather have an 
ambiguous answer than an unknown answer. For example, the issuer 
CA informs that the cert is not in the current CRL while an indirect 
CRL issuer informs that the cert is "revoked". This is informative 
and might be used by the RP software.

Moreover, even when a validation engine used by RP software does 
return answers that are all valid and look unambiguous there is always 
some degree of unreliability because the occurrence of (1), (2), (3) 
or their combinations cannot be ruled out.

When such things are considered, is revocation information useful? 
Surely, as it allows the RP software to have more information on the 
cert revocation status than without it. However, there are caveats and
even experts may disagree on their description. Presenting those caveats
in a clear and unified way, with some degree of consensus, was the 
purpose behind the proposed two paragraphs in the clarification Note 
(with their edits/improvements as further discussed in this thread).

Comments?

Cheers,
Ed Gerck

PS: In information theory terms, a RP software should need to use more
than one reporting channel in order to validate cert revocation status
with some degree of reliability. The improved results should compensate
the additional efforts. This may validate the use of indirect CRL issuers
and responders trusted by the RP, in addition to the issuer CA. As a 
counter example, if the RP has only one channel (e.g., the issuer CA CRL) 
presenting the information that the cert is not revoked, that information
is accurate (there is only one value) but is not reliable (the issuer 
CA CRL may be outdated). Conversely, if we have three or more channels (e.g.,
the issuer CA CRL, an indirect CRL issuer, a responder trusted by the RP) 
presenting the information that the cert is not revoked, that information
can be accurate (even if 2 out of 3 agree) and reliable. The use of two 
channels, even though it would lead to an ambiguity in case of a single 
failure, would still be an improvement over the single channel case
(that has a  single point of failure) of the issuer CA alone providing
the revocation information.

---

From: Ed Gerck <[email-masked]>
Date: Wed, 07 Apr 2004 01:30:09 -0700

> Any chnage of this nature is inconsistent with how X.509 and 3280 are.

Can you please point to the inconsistency in each case? I don't see it.

When X.509 says that a CA may delegate the responsibility of issuing CRLs 
to another trusted authority, X.509 does not bar the issuer CA from using 
its revocation management policy to govern all representations made to RPs,
whether they are delegated or not.  In fact, I understand that the issuer 
CA is authoritative to decide all aspects of such delegation.

What happens, for example, if the delegated CRL issuer oversteps the limits
of the issuer CA delegation when issuing a CRL (e.g., by issuing the CRL
after the delegation expires)?  As I understand it, X.509 says that the 
CRL is not valid in this case. The responsibility of issuing the CRL was 
not, in fact, delegated by the issuer CA when the CRL was issued.

Thus, with delegation or not, a RP cannot rely upon the confirmation 
procedures of any party that the RP chooses (e.g., a delegated CRL issuer,
or an indirect CRL issuer) for anything other than their value as a 
representation of the issuer CA revocation management policy. 

Comments?

Cheers,
Ed Gerck

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Apr 2004 08:49:46 -0400

-----Original Message-----
From: Ed Gerck [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 4:30 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation?

Ed:

Please read X.509 and 3280 carefully.  There is no mechanism to limit the
time of delegation.  See the syntax and semantics of CRL DP extension.

Also, there is no requirement for the certificate issuing CA to issue a CRL
and if the Indirect CRL is checked by the relying party, there is no
requirement to check any CRL issued by the issuing CA.

Actually, if the CRL DP extension is marked critical and it points to an
indirect CRL issuer, you MUST check that CRL.

Comments?

Cheers,
Ed Gerck

---

From: "Julien Stern" <[email-masked]>
Date: Wed, 7 Apr 2004 16:44:50 +0200

On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote:
> 
> Julien,
> 
> The confusion stems from somewhat sloppy use of terminology in these 
> discussions.
> 
> Only the issuer of a cert can revoke it and in X.509 (unlike PGP) 
> there is only one issuer for a given cert. So, the revocation 
> question as you stated it was not well formed.

Stephen,

I do not believe that only the issuer of a cert can revoke it,
notably when indirect CRL are used.

> A cert is either revoked or not.

Well, I'm sincerely starting to believe this is not true :)
and not because of lack of available information.
Please point me to the flaw in the following setting:

       +-----+        +-----+    I have a certificate (Cert). Two
       | CA1 |        |     |    Different CAs (CA4 and CA5) have
       | DN1 |        | DN1 |    matching issuer DN and keys for it.
       | PK1 |        |     |
       +-----+        +-----+    These two CAs have two super CAs
        /   \            |       signed by the same root.
  +-----+   +-----+   +-----+
  | CA2 |   | CA3 |   |     |    I also have a CRL which refers to
  | DN2 |   | DN3 |   | DN3 |    the certificate but whose only
  | PK2 |   | PK3 |   |     |    chain up to DN1 is going through
  +-----+   +-----+   +-----+    DN4 and DN3 (but NOT DN2).
     |         |         |
  +-----+   +-----+   +-----+    Now assume that the left path
  | CA4 |   | CA5 |   |     |    (CA1 -> CA2 -> CA4 -> Cert)
  | DN4 |   | DN4 |   | DN4 |    is valid for SOME policies, and
  | PK4 |   | PK4 |   |     |    the right path is valid for some
  +-----+   +-----+   +-----+    OTHER policies.
       \     /           |
       +-----+        +-----+
       |Cert |        | CRL |
       +-----+        +-----+
 
If I try to validate the certificate with the "left" policy mappings,
only the "left" chain will be valid. Then, I will check the chain
for the CRL, which will be valid and will match the DN matching rule,
so I will conclude that the certificate is revoked.

If I try to validate the certificate with the "right" policy mappings,
onle the "right" chain will be valid. Then, I will check the chain
for the CRL, which will not match the DN matching rule, so I will not
be able to verify the validity of the CRL, and hence conclude that
the certificate is valid.

Sincerely,

--
Julien

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 2004 09:54:12 -0400

>should be interpreted to accommodate various situations, not just OCSP.

Agreed that the wording is not OVCS-specific. maybe we can add that 
to the list of fixes for 3280 as we go forward.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 2004 10:02:09 -0400

Ed,

We agree that there are some edge cases re revocation, as Santosh 
noted. My objection to your text is that it fails to clarify.

If you meant to say that
	- only the issuer of a cert is authoritative for revocation, and
	- relying on revocation status mechanisms such as OCSP and 
indirect CRLs  may not provide direct evidence of the issuer's 
assertion of a cert's revocation status

then say that. phrases like "...anything other than their value as a 
representation of the issuer CA revocation management policy" are 
just not helpful to most folks.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Apr 2004 12:07:34 -0400

Julien:

I am not sure that two distinct CAs with the same key (putting aside the
same DN) should be the basis for analysis.  That situation will always lead
to problems.  We are relying on randomness of large numbers to help us that
this will not happen.

Consider providing an example where different CAs do not have the same key.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Wednesday, April 07, 2004 10:45 AM
To: [email-masked]
Subject: Re: Current status of CRL validation ?

Stephen,

I do not believe that only the issuer of a cert can revoke it, notably when
indirect CRL are used.

 
If I try to validate the certificate with the "left" policy mappings, only
the "left" chain will be valid. Then, I will check the chain for the CRL,
which will be valid and will match the DN matching rule, so I will conclude
that the certificate is revoked.

If I try to validate the certificate with the "right" policy mappings, onle
the "right" chain will be valid. Then, I will check the chain for the CRL,
which will not match the DN matching rule, so I will not be able to verify
the validity of the CRL, and hence conclude that the certificate is valid.

Sincerely,

--
Julien

---

From: "Julien Stern" <[email-masked]>
Date: Wed, 7 Apr 2004 18:35:12 +0200

> Consider providing an example where different CAs do not have the same key.

You should view my "two" CAs as the same CA with two different keys.
I might not have been totally clear about that, sorry.
This can be "either due to multiple concurrent key pairs or
due to changeover" (to quote RFC3280 :)).

--
Julien

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 2004 11:47:28 -0400

Julien,

I think you must be a bit behind on reading PKIX mail, since Santosh 
and I have been discussing the indirect CRL issue for two days now.

In your example, the first flaw I see is that the cert in question is 
supposedly signed by two CAs (CA4 and CA5), which have the same DN 
and public keys. if they have the same DN and the same public key, 
then they are the same CA, so the example is broken at that point, 
period.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Wed, 07 Apr 2004 10:17:11 -0700

Santosh Chokhani wrote:
> time of delegation.

I find this interpretation interesting. I wonder how many people
would agree with that. We now have eternal certs, that don't
expire and cannot be revoked. This would certainly solve the
revocation problem ;-)

As an alternative reading to eternal delegation, X.509 should be 
interpreted in its entirety. Since there is nothing that mandates 
eternal delegation, the CA is  free to use its CPS to control
delegation as the CA so chooses --including expiration dates and 
revocation mechanisms-- both off-line and on-line.

>  See the syntax and semantics of CRL DP extension.

I see the semantics of the CPS. There is nothing stated there that
would bar a CA from limiting the time and scope of delegation.

> Also, there is no requirement for the certificate issuing CA to issue a CRL

My point exactly -- the CA can control all aspects of its revocation 
management policy.

> requirement to check any CRL issued by the issuing CA.

Yes, but that check was not done absolutely. It was done in reference
to what the issuer CA defines in its CPS, including its revocation 
management policy. For example, look for words such as "...MAKES NO 
REPRESENTATION ..." and "...MAKES NO ASSURANCES ...". The issuer CA 
can also change its CPS at any time, possibly excluding any delegation
from some time on.

> indirect CRL issuer, you MUST check that CRL.

My point exactly -- the issuer CA can control all aspects of its revocation 
management policy. Let's ask, who signed that critical CRL DP extension? 
Who controls whether the RP MUST check that CRL at that indirect CRL issuer
or not? Further, who can revoke such critical CRL DP extension?

Cheers,
Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Wed, 07 Apr 2004 11:21:11 -0700

Steve,

We agree. The purpose, after all is to clarify ;-) 

There are three meanings re that pesky phrase "...anything other than
their value as a representation of the issuer CA revocation management 
policy." The first two you list in your reply inlined below. The third
meaning has to do with limitations on the edge cases mentioned by 
Santoshi:
	- relying on revocation status mechanisms such as OCSP and 
indirect CRLs is subject to conditions defined the issuer CA.

Based on the input so far, I now restate the clarification NOTE.

NOTE:

 In X.509/PKIX only the issuer of a certificate is authoritative for 
 revocation and there is only one issuer for a given certificate. 
 Therefore, a certificate is either revoked or not from the issuer CA 
 point of view.

 From the RP point of view, the ability of a RP to establish the validity 
 of a certificate is a function of the certificate path that the RP uses 
 to validate the certificate, and of the access to revocation status 
 information available to the RP. Since there may be more than one path 
 used to validate the same certificate, it is possible that some paths to
 that certificate are valid while others are not. It is also possible to
 obtain different answers to the question whether a certificate is valid 
 or not. Also, two RPs may have access to different revocation status 
 data for the EE certificate or for a CA certificate along a path, so 
 that each RP may arrive at a different view of the validity of the EE 
 certificate at any given time.

 When a RP relies on revocation status mechanisms such as OCSP and 
 indirect CRLs, the data is subject to conditions defined by the issuer
 of the certificate. Such conditions may change from time to time. Also,
 the RP may not have direct evidence of the issuer CA's assertion of 
 a certificate's revocation status at that time.

 In terms of a RP software, resolution may be difficult in practical 
 terms. For example, it may need more time than what's available, 
 and/or need additional channels not included/reachable by that RP 
 software, and/or need human intervention.

 However, because a RP is always subject to conditions defined the 
 issuer CA, revocation status is ultimately definable by a RP.

Comments?

Cheers,
Ed Gerck

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Apr 2004 15:36:40 -0400

Ed:

I see no benefit of having this dialog.  Our understanding of security, PKI,
X.509, 3280, and ASN.1 are so far apart, I better go and back to
kindergarten and learn some stuff.

Rest of the PKIXers:

My lack of response to Ed on this thread from now on should not be viewed as
concurrence.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Gerck
Sent: Wednesday, April 07, 2004 1:17 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation?

Santosh Chokhani wrote:
> Please read X.509 and 3280 carefully.  There is no mechanism to limit 
> the time of delegation.

I find this interpretation interesting. I wonder how many people would agree
with that. We now have eternal certs, that don't expire and cannot be
revoked. This would certainly solve the revocation problem ;-)

As an alternative reading to eternal delegation, X.509 should be 
interpreted in its entirety. Since there is nothing that mandates 
eternal delegation, the CA is  free to use its CPS to control delegation as
the CA so chooses --including expiration dates and 
revocation mechanisms-- both off-line and on-line.

>  See the syntax and semantics of CRL DP extension.

I see the semantics of the CPS. There is nothing stated there that would bar
a CA from limiting the time and scope of delegation.

> requirement to check any CRL issued by the issuing CA.

Yes, but that check was not done absolutely. It was done in reference to
what the issuer CA defines in its CPS, including its revocation 
management policy. For example, look for words such as "...MAKES NO 
REPRESENTATION ..." and "...MAKES NO ASSURANCES ...". The issuer CA 
can also change its CPS at any time, possibly excluding any delegation from
some time on.

> Actually, if the CRL DP extension is marked critical and it points to 
> an indirect CRL issuer, you MUST check that CRL.

Cheers,
Ed Gerck

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Apr 2004 16:02:41 -0400

Julien:

There is still poor terminology being used.  Neither multiple concurrent key
pairs nor rekey will lead to the same CA to have the same key. Actually, it
is the other way around.  The DN will be the same and the keys will be
different.

Nonetheless, I will try to deal with your example assuming that it is the
same CA.

First of all, if you can not find a CRL that does not mean you conclude the
certificate to be valid.

Second, if the certification path you have for the CRL does not match, you
do not give up, you try other paths.

One of the basic tricks is: try to verify the signature on the CRL using the
same CA public key as you used to verify the signature on the certificate
whose status you want to check.

If that does not succeed, you can create variation of that path one link at
a time to account for re-key.

Your example has errors and lack of specificity to answer the question.

The simply answer is that you do not need a separate path for CRL since PK4
is used to sign both the certificate and CRL.

It is also not clear what your thesis or agenda is.

May be you are still trying understand it.  If you are challenging the rules
we have proposed for CRL path, let me know.

May be you are saying that certificate issuing CA may not be the only
authoritative source for revocation information.  If that is the case, I
agree with you, but your example does not illustrate that.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Wednesday, April 07, 2004 12:35 PM
To: [email-masked]
Subject: Re: Current status of CRL validation ?

On Wed, Apr 07, 2004 at 12:07:34PM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> I am not sure that two distinct CAs with the same key (putting aside 
> the same DN) should be the basis for analysis.  That situation will 
> always lead to problems.  We are relying on randomness of large 
> numbers to help us that this will not happen.
> 

You should view my "two" CAs as the same CA with two different keys. I might
not have been totally clear about that, sorry. This can be "either due to
multiple concurrent key pairs or due to changeover" (to quote RFC3280 :)).

--
Julien

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julien Stern
> I do not believe that only the issuer of a cert can revoke it, notably 
> when indirect CRL are used.
> 
> Well, I'm sincerely starting to believe this is not true :) and not 
> because of lack of available information. Please point me to the flaw 
> in the following setting:
> 
> only the "left" chain will be valid. Then, I will check the chain for 
> the CRL, which will be valid and will match the DN matching rule, so I 
> will conclude that the certificate is revoked.
> 
> onle the "right" chain will be valid. Then, I will check the chain for 
> the CRL, which will not match the DN matching rule, so I will not be 
> able to verify the validity of the CRL, and hence conclude that the 
> certificate is valid.
> 
> Sincerely,
> 
> --
> Julien
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 2004 16:34:49 -0400

>due to changeover" (to quote RFC3280 :)).

Well, that would make this a very different example. it also means 
that the two CAs, with different keys, would not both point to the 
same cert, since that would yield different cert signatures.

So, let me suggest you recreate a valid example before we expend any 
more ffort on this.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Wed, 07 Apr 2004 13:32:53 -0700

> kindergarten and learn some stuff.

;-) we have not discussed ASN.1 yet, so how could you have guessed?

> My lack of response to Ed on this thread from now on should not be viewed as

That's SOP. Anyway, I have benefited greatly by your responses
and I am always happy to see your comments as you usually bring 
a different POV.

Cheers,
Ed Gerck

---

From: "Julien Stern" <[email-masked]>
Date: Thu, 8 Apr 2004 12:05:21 +0200

On Wed, Apr 07, 2004 at 04:02:41PM -0400, Santosh Chokhani wrote:
> (snip)
> May be you are still trying understand it.  If you are challenging the
> rules we have proposed for CRL path, let me know.

I am quite honestly still trying to understand.

We have a validation algorithm with policy mappings and CRL/Indirect
CRL/OCSP support. The simple case (one cert -> one chain) is trivial.
We are interested in cases where one can potentially reconstructs many
chains for the certificate and for the CRL/OCSP response.

When I can actually build at least one chain to a TA to
verify the certificate, the revocation status of the certificate can be:
- UNREVOKED
- REVOKED (with reason)
- UNTERMINED

When there is only one revocation source, obviously, different
implementations cannot give UNREVOKED on one hand and REVOKED on the
other, but they could possibly give, say, either REVOKED or UNTERMINED
depending on how they implement verifications. That seems OK: a "smart"
verification algorithm will get the answer, a "simpler" one will just
indicate it did not find it. 

Now, my understanding of RFC3280 is that several entities could
potentially indicate that a given certificate is revoked,
using, say, Indirect CRLs. In this case, am I supposed to assume they
are all in sync ? That the first one checked is authoritative ?
That I have to check them all ?

My MAJOR problem in this case, is that our current algorithm
can give either REVOKED or UNREVOKED depending on:
- Initial Trust Anchors
- Policy mappings
- Even implementations details like path building order or Extension
  processing order

To be specific, I though one could want to have many "Local CAs" issuing
their own CRLs, plus a CRLDP to the CRL of a common "Revocation Center"
which is authorized to process revocations for all the Local CAs. So
maybe this case is just stupid, or even forbidden, but if not, I have a
serious soundness problem in my current verification algorithm ;)

Sincerely,

--
Julien