Subject: new -- Clarification Note proposal on cert revocation -

From: Ed Gerck <[email-masked]>
Date: Tue, 20 Apr 2004 13:24:43 -0700

All,

I'm sending this new version for additional list's comments, in its 
short and long forms. Please refer to the long form if you have
questions reading the short form. PKIX list traffic also has ~30 
messages recently, Re "cert revocation", showing some of the context
and need for this clarification.

MOTIVATION (not intended as part of the proposed text)

The proposal is to add a Clarification Note to current PKIX documents
that deal with revocation and validation of certs. This would help 
the weary reader, who must otherwise wade through the PKIX documents
and list's archives in order to find limitations that are often not so
clear to most folks. I also used the opportunity to point out the 
conditions on those limitations in the long form of the Note, with a 
view to reducing their effect.

The purpose of the Clarification Note is not to reinvent or change 
X.509 or related PKIX RFCs. The purpose is to clarify and unify PKIX 
references (including WG context interpretation) in regard to 
certificate revocation. There should be many paragraphs in X.509 and 
related PKIX RFCs that are, with analysis, equivalent to the 
Clarification Note and vice versa. This is how it should be. The 
informative aspect of the Clarification Note is in terms of ambiguity 
resolution in the documentation and context interpretation.

As reported by Steve Kent, since there is a suggestion before the WG to 
issue an update to 3280, the WG can decide whether the Clarification Note
text should be part of the next update, if the WG proceeds on that work
item.

CLARIFICATION NOTE ON CERTIFICATE REVOCATION (short form)

In X.509/PKIX there is only one issuer CA for a given certificate. Only 
the issuer CA of a certificate is authoritative for revocation conditions
of the certificate. 

If a certificate is listed as revoked by means of one of those mechanisms 
identified by the issuer CA in a conforming certificate extension (e.g.,
a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP 
status, an HTTP CRL list), OR if any other revocation condition defined by 
the issuer CA applies (e.g., expired or revoked issuer CA certificate), the
certificate is revoked. Otherwise, the certificate is not revoked.

However, from a particular RP's point of view, there are several limitations
on verifying the current revocation status of a certificate.

For example, if an RP does not support any of the mechanisms defined by the 
issuer CA to verify the revocation status, or times out during such 
verification, or cannot find a path to verify the status, then the revocation 
status is undefined for that RP. 

Also, since there may be more than one path used to verify the revocation 
status of the same certificate, the occurrence of race conditions, 
differently available paths, and revoked parent certificates can lead to 
ambiguous results for different RPs. Therefore, different RPs may arrive at a 
different view of the revocation status of a EE, CA or cross certificate at a 
particular time.

An RP software relying on the revocation status of a certificate specified by 
any mechanism, authorized or not by the issuer CA of the certificate, is also
subject to conditions defined by the issuer CA. Those conditions may change 
from time to time. Some mechanisms may not include direct evidence of the 
issuer CA's assertion of a certificate's revocation status or conditions, at 
a particular time.

Further, from a particular RP's point of view, the revocation status of a 
certificate is not enough to define the validity of that certificate. 
Certificate validity is a function of a number of additional parameters, 
including the certificate path that the RP trusts to validate the 
certificate, the access to revocation status information available to the RP, 
the local policy used by the RP, and the application (the RP software) that 
the RP will employ. The validity of a certificate refers to conditions that 
are authoritatively defined locally. 

Note that the distinction between "revocation" and "validation" has been 
somewhat blurred in the documentation and informal discussions. That 
distinction is, however, necessary to preserve both the control needs for 
PKI, requiring centralized conditions of revocation that are authoritatively 
defined by the issuer CA, and those business and user needs, requiring local 
authoritative definition of validation.

Now we ask the critical question: When is a certificate revoked? The answer
is: when the corresponding revocation status is published by means of one of
those mechanisms identified by the issuer CA in a conforming certificate 
extension, or when any other revocation condition defined by the issuer CA
applies. It does not matter when a particular RP is able to verify that 
status, or what mechanisms an RP can use for such purpose. The revocation 
status of a certificate issued by a conforming CA does not depend on an
RP and is always well-defined from an RP's point of view -- i.e., it is 
unambiguous (revoked or not revoked) and ultimately verifiable.

Therefore, from a particular RP's point of view, the limitations on 
verifying the current revocation status of a certificate have nothing to do
with the eventual result of that verification, which is always well-defined.
The limitations have to do with the efforts for that verification, which may 
require an unspecified amount of time and work. Human intervention may also
be necessary.  The same considerations apply to certificateHold and 
removefromCRL status.

CLARIFICATION NOTE ON CERTIFICATE REVOCATION (long form)

In X.509/PKIX there is only one issuer CA for a given certificate. Only 
the issuer CA of a certificate is authoritative for revocation conditions
of the certificate. One of those conditions is that the certificate must 
be signed by a CA certificate, issued by the issuer CA, that has not expired 
and is not revoked. Another condition is that the issuer CA may delegate the 
authority for a particular certificate's revocation notices and/or status to 
another entity called the CRL issuer, identified by the CA in the CRL 
Distribution Point (CDP) extension of the certificate. Another condition is 
that the issuer CA may send the revocation notice for a particular 
certificate as a status service to a server identified by the CA in the 
Authority Information Access (AIA) extension of the certificate with an OCSP 
access descriptor or an HTTP CRL access descriptor.

If a certificate is listed as revoked by means of one of those mechanisms 
identified by the issuer CA in a conforming certificate extension (e.g.,
a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP 
status, an HTTP CRL list), OR if any other revocation condition defined by 
the issuer CA applies (e.g., expired or revoked issuer CA certificate), the
certificate is revoked. Otherwise, the certificate is not revoked.

In short, because the revocation status of a certificate refers to conditions
that a conforming issuer CA authoritatively and unambiguously defines, a 
certificate is either revoked or not from the issuer CA viewpoint.

However, from a particular RP's point of view, there are several limitations
on verifying the current revocation status of a certificate.

For example, if an RP does not support any of the mechanisms defined by the 
issuer CA to verify the revocation status, or times out during such 
verification, or cannot find a path to verify the status, then the revocation 
status is undefined for that RP. According to RFC 3280, this can happen even 
for a conforming CA and a conforming application (RP software). Conforming 
CAs are not required to issue CRLs if other revocation or certificate status 
mechanisms are provided. Conforming applications are NOT REQUIRED to support 
processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all 
certificates issued by one CA. 

Also, since there may be more than one path used to verify the revocation 
status of the same certificate, the occurrence of race conditions, 
differently available paths, and revoked parent certificates can lead to 
ambiguous results for different RPs. If a CA sends status data to an OCSP 
Responder including a revocation notice before creating a CRL, the 
certificate in question is revoked for an RP receiving the OCSP Responder's 
status but not for an RP accessing only the current CRL. Even along a single 
path, different RPs may have access to different revocation status for a CA 
or cross certificate. Further, as demanded by chain processing rules, a 
revoked parent certificate may or may not cause an RP to deduce that a child 
certificate status is revoked, independently of the current authoritative 
revocation status. Therefore, different RPs may arrive at a different view of 
the revocation status of a EE, CA or cross certificate at a particular time.

Resolution of revocation status may be difficult for the RP's software. For 
example, the software may need to wait for a fresher CRL, the software may 
need more time than what is available for the desired action, the software 
may need additional communication channels that are not available to the 
software at the time of checking, the software might need human intervention, 
and so on. Using any single mechanism to specify revocation information can 
be seen as introducing a single point of failure from the RP's software point 
of view. 

An RP software relying on the revocation status of a certificate specified by 
any mechanism, authorized or not by the issuer CA of the certificate, is also
subject to conditions defined by the issuer CA. Those conditions may change 
from time to time. Some mechanisms may not include direct evidence of the 
issuer CA's assertion of a certificate's revocation status or conditions, at 
a particular time.

With a view to reducing the effect of those limitations, an RP can determine 
bounds on the extent of those limitations, or at least ways in which those 
limitations can be bounded. Some of those limitations can also be prevented 
or reduced by using a strategy of redundancy and diversity.

For example:

- There are various unspecified and unpublished delays between the time a CA, 
CRL issuer or OCSP Responder receives notice to revoke, suspend, or reinstate 
a certificate and the time the information status is made available through 
the CA's CRL, an indirect CRL, a delta CRL, an OCSP Responder, a DPV Server, 
or a client. Nonetheless, some of these bounds can be actually known or 
modeled by an RP.

- To prevent single access faults and race conditions, a certificate can use 
multiple mechanisms to specify revocation information, some of which can be 
redundant mechanisms, where an RP should be able to interoperate with any of 
those mechanisms which it trusts. Multiple mechanisms available to an issuer 
CA include a CDP extension with a URI DistributionPointName, an AIA extension 
with an OCSP access descriptor, and an AIA extension with an HTTP CRL access 
descriptor. An RP receiving both an OCSP Responder's status and the CA's CRL 
for a certificate is less susceptible to race conditions caused by CA's 
delays when sending status data to the OCSP Responder with a revocation 
notice and publishing a CRL for the certificate in question.

Further, from a particular RP's point of view, the revocation status of a 
certificate is not enough to define the validity of that certificate. 
Certificate validity is a function of a number of additional parameters, 
including the certificate path that the RP trusts to validate the 
certificate, the access to revocation status information available to the RP, 
the local policy used by the RP, and the application (the RP software) that 
the RP will employ. The validity of a certificate refers to conditions that 
are authoritatively defined locally.

Note that the distinction between "revocation" and "validation" has been 
somewhat blurred in the documentation and informal discussions. It is further
corroded by the usual practice of talking about the determination of the 
revocation status by an RP, whereas all that the RP can do is verify the 
revocation status, for which conditions the issuer CA is authoritative. 

That distinction is, however, necessary to preserve both the control needs 
for PKI, requiring centralized conditions of revocation that are 
authoritatively defined by the issuer CA, and those business and user needs,
requiring local authoritative definition of validation. There are also those
cases in which domains may choose to adopt one or other model based on an 
operational rationale. The flexibility of having both a centralized 
revocation mechanism and a localized validation mechanism is an important
feature of X.509/PKIX.

For example, a certificate can also be authoritatively revoked when the 
issuer CA or the CRL issuer makes the revocation status available to an RP in 
a reasonable way. For example, by signed XML messages in a wireless network, 
by SQL over HTTPS, or in a signed SOAP response for database lookup over web 
services. What matters to the RP is the revocation status, in a repository or
as a status message, and whether it has been published by some means 
acceptable by the RP.

As another example, a CRL Issuer or an OCSP responder may perform additional 
processing, beyond aggregating and republishing revocation notices as 
revocation status services. If the operator of the service knows an RP's 
validation criteria, they may apply those criteria when creating a validation 
service for that RP. In this case, the "validation service" is a policy- 
enhanced validation service tuned to the acceptance processes of the RP, 
rather than only to the revocation processes of CAs and their delegates.

Can a validation service indicate a certificate to be valid, when the 
revocation status is revoked? Yes -- e.g., for the purpose of an RP reading a 
timely message, the security policy of a validation service may consider a 
certificate to be valid when no revocation status can be contacted. 
Generalizing this behavior is an implementation flaw, however. For example, 
the widely used TLS/SSL security application in Internet browsers does not 
currently verify the revocation status of EE and CA certificates and always 
considers the resulting undefined revocation status as valid. 

Now we ask the critical question: When is a certificate revoked? The answer
is: when the corresponding revocation status is published by means of one of
those mechanisms identified by the issuer CA in a conforming certificate 
extension, or when any other revocation condition defined by the issuer CA
applies. It does not matter when a particular RP is able to verify that 
status, or what mechanisms an RP can use for such purpose. The revocation 
status of a certificate issued by a conforming CA does not depend on an
RP and is always well-defined from an RP's point of view -- i.e., it is 
unambiguous (revoked or not revoked) and ultimately verifiable.

Therefore, from a particular RP's point of view, the limitations on 
verifying the current revocation status of a certificate have nothing to do
with the eventual result of that verification, which is always well-defined.
The limitations have to do with the efforts for that verification, which may 
require an unspecified amount of time and work. Human intervention may also
be necessary.  The same considerations apply to certificateHold and 
removefromCRL status.

ACKNOWLEDGMENTS

The names cited do not mean endorsement of this work, which is the sole 
responsibility of the author. I would like to thank very useful comments by 
Santoshi Chokhani, Tom Gidin, Paul Hoffman, David Kemp, Steve Kent, Stefan 
Santesson, Peter Williams, Julien Stern and the PKIX list.

Ed Gerck
[email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 20 Apr 2004 22:46:02 -0400

Ed:

I do not think 3280 needs any clarification in this area.

There are several errors in the statements.

Also, some of the topics are CA and RP policy issues and not certificate and
CRL formats issue.

Since PKIX is not operating a CA or recommending any operations policy, none
of this is needed for any other document either.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Gerck
Sent: Tuesday, April 20, 2004 4:25 PM
To: PKIX
Subject: new -- Clarification Note proposal on cert revocation -

All,

I'm sending this new version for additional list's comments, in its 
short and long forms. Please refer to the long form if you have questions
reading the short form. PKIX list traffic also has ~30 
messages recently, Re "cert revocation", showing some of the context and
need for this clarification.

The proposal is to add a Clarification Note to current PKIX documents that
deal with revocation and validation of certs. This would help 
the weary reader, who must otherwise wade through the PKIX documents and
list's archives in order to find limitations that are often not so clear to
most folks. I also used the opportunity to point out the 
conditions on those limitations in the long form of the Note, with a 
view to reducing their effect.

In X.509/PKIX there is only one issuer CA for a given certificate. Only 
the issuer CA of a certificate is authoritative for revocation conditions of
the certificate. 

If a certificate is listed as revoked by means of one of those mechanisms 
identified by the issuer CA in a conforming certificate extension (e.g., a
CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP 
status, an HTTP CRL list), OR if any other revocation condition defined by 
the issuer CA applies (e.g., expired or revoked issuer CA certificate), the
certificate is revoked. Otherwise, the certificate is not revoked.

For example, if an RP does not support any of the mechanisms defined by the 
issuer CA to verify the revocation status, or times out during such 
verification, or cannot find a path to verify the status, then the
revocation 
status is undefined for that RP. 

Also, since there may be more than one path used to verify the revocation 
status of the same certificate, the occurrence of race conditions, 
differently available paths, and revoked parent certificates can lead to 
ambiguous results for different RPs. Therefore, different RPs may arrive at
a 
different view of the revocation status of a EE, CA or cross certificate at
a 
particular time.

An RP software relying on the revocation status of a certificate specified
by 
any mechanism, authorized or not by the issuer CA of the certificate, is
also subject to conditions defined by the issuer CA. Those conditions may
change 
from time to time. Some mechanisms may not include direct evidence of the 
issuer CA's assertion of a certificate's revocation status or conditions, at

a particular time.

certificate, the access to revocation status information available to the
RP, 

Now we ask the critical question: When is a certificate revoked? The answer
is: when the corresponding revocation status is published by means of one of
those mechanisms identified by the issuer CA in a conforming certificate 
extension, or when any other revocation condition defined by the issuer CA
applies. It does not matter when a particular RP is able to verify that 
status, or what mechanisms an RP can use for such purpose. The revocation 
status of a certificate issued by a conforming CA does not depend on an RP
and is always well-defined from an RP's point of view -- i.e., it is 
unambiguous (revoked or not revoked) and ultimately verifiable.

In X.509/PKIX there is only one issuer CA for a given certificate. Only 
the issuer CA of a certificate is authoritative for revocation conditions of
the certificate. One of those conditions is that the certificate must 
be signed by a CA certificate, issued by the issuer CA, that has not expired

If a certificate is listed as revoked by means of one of those mechanisms 
identified by the issuer CA in a conforming certificate extension (e.g., a
CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP 
status, an HTTP CRL list), OR if any other revocation condition defined by 
the issuer CA applies (e.g., expired or revoked issuer CA certificate), the
certificate is revoked. Otherwise, the certificate is not revoked.

In short, because the revocation status of a certificate refers to
conditions that a conforming issuer CA authoritatively and unambiguously
defines, a 
certificate is either revoked or not from the issuer CA viewpoint.

For example, if an RP does not support any of the mechanisms defined by the 
issuer CA to verify the revocation status, or times out during such 
verification, or cannot find a path to verify the status, then the
revocation 
status is undefined for that RP. According to RFC 3280, this can happen even

certificate status is revoked, independently of the current authoritative 
revocation status. Therefore, different RPs may arrive at a different view
of 
the revocation status of a EE, CA or cross certificate at a particular time.

Resolution of revocation status may be difficult for the RP's software. For 
example, the software may need to wait for a fresher CRL, the software may 
need more time than what is available for the desired action, the software 
may need additional communication channels that are not available to the 
software at the time of checking, the software might need human
intervention, 
and so on. Using any single mechanism to specify revocation information can 
be seen as introducing a single point of failure from the RP's software
point 
of view. 

An RP software relying on the revocation status of a certificate specified
by 
any mechanism, authorized or not by the issuer CA of the certificate, is
also subject to conditions defined by the issuer CA. Those conditions may
change 
from time to time. Some mechanisms may not include direct evidence of the 
issuer CA's assertion of a certificate's revocation status or conditions, at

a particular time.

For example:

- There are various unspecified and unpublished delays between the time a
CA, 
CRL issuer or OCSP Responder receives notice to revoke, suspend, or
reinstate 
a certificate and the time the information status is made available through 
the CA's CRL, an indirect CRL, a delta CRL, an OCSP Responder, a DPV Server,

CA include a CDP extension with a URI DistributionPointName, an AIA
extension 
with an OCSP access descriptor, and an AIA extension with an HTTP CRL access

certificate, the access to revocation status information available to the
RP, 

Note that the distinction between "revocation" and "validation" has been 
somewhat blurred in the documentation and informal discussions. It is
further corroded by the usual practice of talking about the determination of
the 
revocation status by an RP, whereas all that the RP can do is verify the 
revocation status, for which conditions the issuer CA is authoritative. 

For example, a certificate can also be authoritatively revoked when the 
issuer CA or the CRL issuer makes the revocation status available to an RP
in 
a reasonable way. For example, by signed XML messages in a wireless network,

services. What matters to the RP is the revocation status, in a repository
or as a status message, and whether it has been published by some means 
acceptable by the RP.

validation criteria, they may apply those criteria when creating a
validation 

revocation status is revoked? Yes -- e.g., for the purpose of an RP reading
a 

Now we ask the critical question: When is a certificate revoked? The answer
is: when the corresponding revocation status is published by means of one of
those mechanisms identified by the issuer CA in a conforming certificate 
extension, or when any other revocation condition defined by the issuer CA
applies. It does not matter when a particular RP is able to verify that 
status, or what mechanisms an RP can use for such purpose. The revocation 
status of a certificate issued by a conforming CA does not depend on an RP
and is always well-defined from an RP's point of view -- i.e., it is 
unambiguous (revoked or not revoked) and ultimately verifiable.

ACKNOWLEDGMENTS

Ed Gerck
[email-masked]

---

From: Ed Gerck <[email-masked]>
Date: Wed, 21 Apr 2004 09:00:15 -0700

> I do not think 3280 needs any clarification in this area.

With all due respect, I think this reply shows otherwise.
 
> There are several errors in the statements.

Thank you. If you could please name them as you see them, this will
also help the clarification.

> Also, some of the topics are CA and RP policy issues and not certificate and

CA and RP policy issues are not described but, again, if you could please name 
them as you see them, this will also help the clarification.

> of this is needed for any other document either.

On Wed, Apr 07, you wrote: 
"There is no mechanism to limit the time of delegation."

However, as you see in the Clarification Note, this is not true: The issuer 
CA can authoritatively revoke delegation to the CRL issuer. Delegation is not 
for the life of the cert. A issuer CA could revoke the signing cert and re-
issue all certs with a different delegation specification or no delegation. 
This also provides an incentive for the CRL issuer to conform to the issuer 
CA's policy.

On the same day, you also wrote:
"...and if the Indirect CRL is checked by the relying party, there is no
requirement to check any CRL issued by the issuing CA."

Yes, but that check was not done absolutely, as explained in the Note. 
It depends on whether the issuer CA signing cert is revoked or not,
OR whether any other conforming revocation condition defined by the 
issuer CA applies. Also, as explained in the Note,

 An RP software relying on the revocation status of a certificate specified
 by any mechanism, authorized or not by the issuer CA of the certificate, 
 is also subject to conditions defined by the issuer CA. Those conditions 
 may change from time to time. Some mechanisms may not include direct evidence
 of the issuer CA's assertion of a certificate's revocation status or 
 conditions, at a particular time.

Cheers,
Ed Gerck

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 21 Apr 2004 13:21:42 -0400

Ed:

There is no particular reason to debate this.  We have gone down this path
and at your request, I have had several private exchanges with you regarding
this.

If you still do not get it, I do not have time to help any further.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Gerck
Sent: Wednesday, April 21, 2004 12:00 PM
To: Santosh Chokhani
Cc: 'PKIX'
Subject: Re: new -- Clarification Note proposal on cert revocation -

 
> There are several errors in the statements.

Thank you. If you could please name them as you see them, this will also
help the clarification.

> Also, some of the topics are CA and RP policy issues and not 
> certificate and CRL formats issue.

CA and RP policy issues are not described but, again, if you could please
name 
them as you see them, this will also help the clarification.

> Since PKIX is not operating a CA or recommending any operations 
> policy, none of this is needed for any other document either.

CA can authoritatively revoke delegation to the CRL issuer. Delegation is
not 

Yes, but that check was not done absolutely, as explained in the Note. 
It depends on whether the issuer CA signing cert is revoked or not, OR
whether any other conforming revocation condition defined by the 
issuer CA applies. Also, as explained in the Note,

 An RP software relying on the revocation status of a certificate specified
by any mechanism, authorized or not by the issuer CA of the certificate, 
 is also subject to conditions defined by the issuer CA. Those conditions 
 may change from time to time. Some mechanisms may not include direct
evidence  of the issuer CA's assertion of a certificate's revocation status
or 
 conditions, at a particular time.

Cheers,
Ed Gerck

---

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

Santosh,

You do not believe that CAs are authoritative for revocation 
conditions. You also think that there is no mechanism to limit 
the time of delegation; no way for revoking the delegation. Yet, 
an issuer CA can revoke the signing cert, hence revoking the 
revocation delegation for all certs signed by that cert.

By ignoring the authoritative role of CAs in revocation conditions, 
you will not improve the authoritative role of CRL issuers, however. 
You will not make the role of OCSP responders clearer, either. You 
will just create more confusion on revocation delegation, making the 
position of an issuer CA even stronger (why should you get revocation 
from a delegate if you can get the real thing without pesky questions?).

The bottom line of what I'm saying is that revocation in PKIX is not 
as bad as "flip a coin to know if this cert is revoked" (as it may 
seem) but can be understood and verified by a relying party, to the
extent the RP desires. As I showed, the only limitation is how much 
time and work the RP is willing to spend, not the result. The result 
is ultimately unambiguous and verifiable.

X.509 is not perfect. But we shall not demand perfection. Pointing 
out that PKIX cert revocation is ultimately unambiguous for an RP
is, IMO a great clarification -- if this lit's archives and my private 
mailbox can be proof. Yes, it does renovate some notions. However, to 
renovate is not to destroy. It is to respect the foundations, and so 
restore works for the general good.

Thanks again. 

Cheers,
Ed Gerck

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 22 Apr 2004 08:46:08 -0400

A relying party is obviously authoritative for the sources of
information that that relying party trusts.  This cannot be
disputed - proof by construction.

If an RP says a CA is the only authoritative source of revocation
information for that CA's certs, then it is (for that RP).  If
a different RP trusts some other source, then the CA is not
authoritative.

PKIX can only seek to put in place standards capable of
faithfully and securely mechanizing RP trust policies without
introducing unrecognized or difficult to foresee violations
of those policies (i.e., vulnerabilities).

PKIX does not attempt to tell you, or Santosh, what to believe.

Ed Gerck wrote:

> conditions.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 22 Apr 2004 12:44:27 -0400

Dave:

I agree with you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Thursday, April 22, 2004 8:46 AM
To: PKIX
Subject: Re: new -- Clarification Note proposal on cert revocation -

A relying party is obviously authoritative for the sources of information
that that relying party trusts.  This cannot be disputed - proof by
construction.

If an RP says a CA is the only authoritative source of revocation
information for that CA's certs, then it is (for that RP).  If a different
RP trusts some other source, then the CA is not authoritative.

PKIX can only seek to put in place standards capable of faithfully and
securely mechanizing RP trust policies without introducing unrecognized or
difficult to foresee violations of those policies (i.e., vulnerabilities).

---

From: Ed Gerck <[email-masked]>
Date: Thu, 22 Apr 2004 15:37:42 -0700

Dave,

Clearly, an RP can rely on (trust) any source for revocation 
information of a cert issued by a CA. 

Still, this does not mean that the revocation status of a cert 
is defined by that RP or by conditions authoritatively defined by 
that RP. That revocation status is defined by conditions set forth
authoritatively by the issuer CA, whether that RP agrees with them 
or not, whether that RP reads them or not. Here, a tree falls even 
though no one may watch it fall.

Moreover, when an RP decides to rely on any source for revocation
information and something goes wrong (e.g., that cert turns out to 
have been listed as revoked by a CRL issuer identified in the 
certificate, or by the issuer CA), will the RP be able to claim 
to anyone that it relied on the cert based on anything else but 
the RP's own risk in such a case? No. The RP has 100% of the risk
if the RP has not followed the conditions defined by the issuer
CA to learn the revocation status of a cert issued by that CA.

Further, what good or harm has X.509 done in such a case? Nothing,
either way. There is no violation of X.509 -- if an RP decides to 
be on its own and blindly ignores the conditions for reliance defined
in X.509 in terms of revocation conditions and where to find them, 
that RP was and is on its own -- proof by construction.

The matter is different in terms of validation vs. revocation.
An RP is always authoritative for validation of a certificate.
And also has 100% of the risk. The RP cannot rely on the issuer
CA to define the validation status of a cert, which is a matter
of local policy.

Finally, in the context of an organization, will the organization
allow each employee to decide what source to rely on for revocation 
information of a cert issued by a CA? Probably not, for the reasons
noted above. The organization will want to enforce the restrictions
on cert reliance placed by the issuer CA (including when a cert is 
revoked or not) in addition to their own restrictions on validation
of that cert (e.g., the path used to verify the revocation information).

Cheers,
Ed Gerck