Subject: RE: CA Rekey and CRL Validation

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 21 Sep 2004 09:48:49 +0100

David,

Thanks for the summary.

Some corrections in line:

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: den 20 september 2004 21:41
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

All,

I have been on vacation for the past couple of weeks and have just
finished reading through the messages in this thread.  So, I would now
like to comment on some of the issues that have been raised.

First, as David Kemp noted, the text on page 7 is not a definition of
CRL issuer, it is simply describing one of the components depicted in
figure 1.  Paragraph 3 of section 5 (on page 48) clearly states:

   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.

As to the main question on this thread, I believe that X.509 is very
clear that a CA is identified by name, not name+key.  Here are a few
quotes from X.509:

1.   
Section 7: "NOTE 1 - Although the CAs are unambiguously defined by a
distinguished name in the DIT, this does not imply that there is any
relationship between the  organization of the CAs and the DIT." [DC: If
same DN but different keys meant different CAs, then CAs would not be
unambiguously defined by a DN.]

2.   Section 7: "issuer identifies the entity that has signed and issued
the certificate." [DC: note that this says that the issuer field of the
certificate identifies the entity, not issuer field in combination with
key]

3.   Section 7: "Self-issued certificate - This is a certificate where
the issuer and the subject are the same CA. A CA might use self-issued
certificates, for example, during a key rollover operation to provide
trust from the old key to the new key." [DC:  If CA were defined as
name+key, then one would not say that a key rollover certificate had the
same CA as both issuer and subject.]

One is also required to ensure that two different entities are not
assigned the same name:

1.	Section 8.3.2.1 (subject alternative name extension): "For every
name form used in the GeneralName type, there shall be a name
registration system that ensures that any name used unambiguously
identifies one entity to both certificate issuer and certificate users."

I realize that some will still argue that X.509 does not explicitly
state that same name = same CA even if it does imply that it is the
case.  However, if you are going to suggest that X.509 should be
interpreted based on the assumption that different keys means different
CAs, the question I would ask is where in X.509 (or RFC 3280) is there
anything that implies this is the case?

[Stefan] I don't think anyone is suggesting this interpretation of
X.509. The issue was raised and resolved. There only remains a
suggestion that this should be more directly stated in the standards
(not only indirectly understood from the quotes above).

Some have argued that X.509 has a security vulnerability unless the
assumption is made that different keys means different CAs.  However,
these arguments always start with the assumption that one is operating
in a PKI in which there are multiple, independent CAs, all of which are
considered to be valid CAs in the infrastructure and all of which have
the same name.  However, in a valid PKI, two different CAs will not have
the same name.  So, these people are simply noting that if one operates
a PKI in a manner that is contrary to the rules of X.509 (allowing two
different CAs to share the same name), the PKI will not provide the
security assurances promised by X.509.  But, I don't see how one can
argue that this indicates a flaw in X.509.

[Stefan] This is not correct. The argument was based on the wrong
assumption that it was allowed to issue a CRL covering certificates
issued under just 1 CA key, without having IDP present in the CRL. It
was clarified however that this is not supported practice.

Santosh has proposed a restricted path validation algorithm for
validating CRL signing keys (ensuring that the certification path for
the CRL signing keys is similar to the certification path for the
certificate being validated) that mitigates that damage that would
result from a PKI in which two CAs share the same name (i.e., it
provides an extra layer of protection). His proposal mitigates the
problem as well as if one required certificates and CRLs to be signed
with the same key.  The main reason I agree with Santosh's proposal,
however, is that I don't see any good reason not to impose the
restriction he proposes, while imposing the restriction makes path
validation more efficient since there are fewer possibilities that need
to be considered.

[Stefan] I'm OK with this restrictions which also solves other security
issues discussed in ITU (Circular trust)

Dave

Stefan Santesson wrote:

Denis,

	On page 59, we have the following sentence:
	 
	    If the distributionPoint field is absent, the CRL MUST
contain
	    entries for all revoked unexpired certificates *issued* by
the CRL
	    issuer, if any, within the scope of the CRL
	 
	This sentence is either ambiguous or incorrect: a CRL issuer
does not
	*issue* certificates. On page 7, the definition of a CRL issuer
is:
	CRL issuer: an optional system to which a CA delegates the
publication of

	certificate revocation lists.

I agree that the definition is not consistent with the standard text in
general. Other sections definitely suggest that the CA can be the CRL
issuer also without delegation.
 
From 4.2.1.14  CRL Distribution Points:
 
   If the certificate issuer is not the CRL
   issuer, then the cRLIssuer field MUST be present and contain the Name
   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
   then the cRLIssuer field MUST be omitted and the distributionPoint
   field MUST be present.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 21 Sep 2004 07:08:51 -0400

Stefan:
 
The circular problem discussed in last September X.509 meeting is not
related to this.  That one relates to pitfalls of self-issued certificates.
 
But, in general, revocation status of a certificate (call is X) must not be
checked using a CRL issuing authority or OCSP Responder whose certification
path validation requires X in the path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, September 21, 2004 4:49 AM
To: David A. Cooper; [email-masked]
Subject: RE: CA Rekey and CRL Validation

David,

Thanks for the summary.

Stefan Santesson 

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: den 20 september 2004 21:41
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

All,

I have been on vacation for the past couple of weeks and have just finished
reading through the messages in this thread.  So, I would now like to
comment on some of the issues that have been raised.

First, as David Kemp noted, the text on page 7 is not a definition of CRL
issuer, it is simply describing one of the components depicted in figure 1.
Paragraph 3 of section 5 (on page 48) clearly states:

As to the main question on this thread, I believe that X.509 is very clear
that a CA is identified by name, not name+key.  Here are a few quotes from
X.509:

1.   

Section 7: "NOTE 1 - Although the CAs are unambiguously defined by a
distinguished name in the DIT, this does not imply that there is any
relationship between the  organization of the CAs and the DIT." [DC: If same
DN but different keys meant different CAs, then CAs would not be
unambiguously defined by a DN.]

2.   Section 7: "issuer identifies the entity that has signed and issued the
certificate." [DC: note that this says that the issuer field of the
certificate identifies the entity, not issuer field in combination with key]

3.   Section 7: "Self-issued certificate - This is a certificate where the
issuer and the subject are the same CA. A CA might use self-issued
certificates, for example, during a key rollover operation to provide trust
from the old key to the new key." [DC:  If CA were defined as name+key, then
one would not say that a key rollover certificate had the same CA as both
issuer and subject.]

One is also required to ensure that two different entities are not assigned
the same name:

1.	Section 8.3.2.1 (subject alternative name extension): "For every
name form used in the GeneralName type, there shall be a name registration
system that ensures that any name used unambiguously identifies one entity
to both certificate issuer and certificate users." 

I realize that some will still argue that X.509 does not explicitly state
that same name = same CA even if it does imply that it is the case.
However, if you are going to suggest that X.509 should be interpreted based
on the assumption that different keys means different CAs, the question I
would ask is where in X.509 (or RFC 3280) is there anything that implies
this is the case?

[Stefan] I don't think anyone is suggesting this interpretation of X.509.
The issue was raised and resolved. There only remains a suggestion that this
should be more directly stated in the standards (not only indirectly
understood from the quotes above).

Some have argued that X.509 has a security vulnerability unless the
assumption is made that different keys means different CAs.  However, these
arguments always start with the assumption that one is operating in a PKI in
which there are multiple, independent CAs, all of which are considered to be
valid CAs in the infrastructure and all of which have the same name.
However, in a valid PKI, two different CAs will not have the same name.  So,
these people are simply noting that if one operates a PKI in a manner that
is contrary to the rules of X.509 (allowing two different CAs to share the
same name), the PKI will not provide the security assurances promised by
X.509.  But, I don't see how one can argue that this indicates a flaw in
X.509.

[Stefan] This is not correct. The argument was based on the wrong assumption
that it was allowed to issue a CRL covering certificates issued under just 1
CA key, without having IDP present in the CRL. It was clarified however that
this is not supported practice.

Santosh has proposed a restricted path validation algorithm for validating
CRL signing keys (ensuring that the certification path for the CRL signing
keys is similar to the certification path for the certificate being
validated) that mitigates that damage that would result from a PKI in which
two CAs share the same name (i.e., it provides an extra layer of
protection). His proposal mitigates the problem as well as if one required
certificates and CRLs to be signed with the same key.  The main reason I
agree with Santosh's proposal, however, is that I don't see any good reason
not to impose the restriction he proposes, while imposing the restriction
makes path validation more efficient since there are fewer possibilities
that need to be considered.

Dave

Stefan Santesson wrote:

Denis,

    If the distributionPoint field is absent, the CRL MUST contain
    entries for all revoked unexpired certificates *issued* by the CRL
    issuer, if any, within the scope of the CRL
 
This sentence is either ambiguous or incorrect: a CRL issuer does not
*issue* certificates. On page 7, the definition of a CRL issuer is:
CRL issuer: an optional system to which a CA delegates the publication of