Subject: RE: CA Rekey and CRL Validation

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 17 Sep 2004 11:16:34 +0100

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.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 17 Sep 2004 08:07:07 -0400

Stefan:

It is the IDP definition you need to look at since IDP in CRL is the one
that limits the CRL scope and not the CRL DP in the certificate.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, September 17, 2004 6:17 AM
To: Denis Pinkas; Santosh Chokhani
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis,

of

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.

Stefan Santesson

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 17 Sep 2004 15:43:53 -0400

Not only do other sections suggest that the CA can be a CRL issuer, the
text regarding "CRL issuer" on page 6 is *not* a definition of that 
term, it is
an item in the list of components in the PKIX architectural model.  That
model is shown in the accompanying diagram.

Any reasonable reading of the phrase "CRL issuer" in an English language
sentence would hold that it means the issuer of a CRL.  There are two
components that issue CRLs in the PKIX architecture; one of these
components also issues certificates.

---

From: Ed Gerck <[email-masked]>
Date: Fri, 17 Sep 2004 15:05:10 -0700

David,

You are correct, but there are two hats and that's why the text
should be modified to:

    If the distributionPoint field is absent, the CRL MUST contain
    entries for all revoked unexpired certificates *issued* by the
    issuer CA, if any, within the scope of the CRL

Using the CRL issuer hat, there is no issued cert.

Cheers,
Ed Gerck

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 20 Sep 2004 15:41:01 -0400

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:

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.]

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]

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:

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,

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

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 21 Sep 2004 16:30:50 +0200

David A. Cooper wrote:

> Here are a few quotes from X.509:
>
>   1.
>
>       Section 7: "NOTE 1 – Although the _CAs are unambiguously defined
>       by a distinguished name_
>
[...]

> 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. [...]

I think it's not really a question that they have to be considered valid CA.

The point is in an internet environement, you take an active decision 
when you start accepting a new root, but then you are vulnerable to 
whatever that root does (you can decide to remove it, but it will happen 
only *after* you know it did something inadequate).

And in an open environement, just telling to a root to never emit a CA 
certificate whose distinguished name is not unambiguous with other 
independant CA is not an absolute garantee it will never happen. Even 
unintentionally.

So it may be OK for X.509, but pkix can not say "all CA will emit 
unambiguous distinguished name", and then go on opening security 
breaches if it ever occurs.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 23 Sep 2004 10:02:52 +0200

To the list,

It is time to work on a correction to correct the defective text of RFC 3280.

I took the opportunity to have a meeting where I met Stefan to work with him 
on a fix. Hereafter is the result.

Current wording in RFC 3280 (page 59):

    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
    the CRL includes certificates issued by authorities other than the
    CRL issuer.

Proposed replacement:

    When the CRL issuer is a CA and the scope of the CRL includes
    certificates issued by other CAs, the indirectCRL boolean MUST asserted.

    When the CRL issuer is not a CA, the indirectCRL boolean MUST asserted.

Denis