Re: CA Rekey and CRL Validation

["David A. Cooper" <david.cooper@xxxxxxxx>]

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?

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.

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,
  

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.