Subject: Re: Open Issue in Part1: path length constraints

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Mar 2001 16:48:40 -0500

David,

>Let's make this a fair fight and make it three on three.  This David 
>agrees with
>Steve and John.
>
>In Tim's original message:
>
>"CA "A" issues a CA certificate to CA "B".  "A" trusts end entity
>certificates issued by "B", but does not trust "B" to issue certificates to
>other CAs.  "A" includes basic constraints in the certificate it issues to
>"B" with cA = TRUE and pathLen = 0."
>
>""B" does not issue its own CRLs, but delegates this to CA "C".  "B" also
>trusts "C" to issue end entity certificates. So, "B" includes basic
>constraints in the certificate it issues to "B" with cA = TRUE."
>
>Let me begin by stating that I really dislike this scenario. 
>Theoretically this
>is possible, but why would anyone architect such a design?  If I really had to
>address this scenario, a design that fits within the current 
>semantics would be
>one that creates a distinct "personality" for issuing the CRLs which could be
>issued an end entity certificate with the cRLSign bit set.
>
>Stay with the current semantics and stop trying to break things that really
>aren't broken.

I am too bothered by the emergence of the notion that entities other 
than  CAs issues CRLs. I reread 2459 and it does not seem to make a 
case for this, although I did note that the CRLSign bit in key usage 
did not limit its use to CAs, even though the KeyCertSign bit is so 
restricted. But 5.2.5 (the CRL distribution point extension) does 
say: "The CRL is signed using the CA's private key" and that 
certainly argues for what I would consider the usual interpretation, 
i.e., only CAs sign CRLs.

OCSP clearly introduced the notion of a non CA entity vouching for 
certificate status. But we're talking about CRLs here and I still 
think they should be issued only by CAs. I view the CRLSign bit to be 
a means by which a CA can have different keys and certs for cert 
signing vs. CRL signing, and appropriate split  that can enhance 
security in many instances.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 02 Mar 2001 17:57:06 -0500

Steve,

 From a policy point of view, it may make sense to say that only CAs should be issuing CRLs, but what does this mean from a certificate path processing point of view?

X.509 states "[t]he cA component indicates if the certified public key may be used to verify certificate signatures". It says nothing about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA certificates but does do so with cRLSign. Are you arguing that we should change the standards to require basicConstraints with cA=TRUE in certificates that only authorize the use of the subject's public key to verify signatures on CRLs? Or are you suggesting that a certificate should be treated as a CA certificate if cRLSign is set in keyUsage even if basicConstraints is absent?

To be more specific, if we accept the idea that pathLenConstraint should be computed differently depending on what type of certificate the last one in the path is, should CA1's relying parties accept CRLs issued by CA3 in the certification path below?

CA1 ----------------------------> CA2 ----------------------------------> CA3
         basicConstraints:                               keyUsage:
                 cA=TRUE                                 cRLSign
                 pathLenConstraint=0 

                 keyUsage:                               CRLDistributionPoints:
                         keyCertSign, cRLSign            cRLIssuer: CA3

At 04:48 PM 3/2/01 -0500, Stephen Kent wrote:
>I am too bothered by the emergence of the notion that entities other than  CAs issues CRLs. I reread 2459 and it does not seem to make a case for this, although I did note that the CRLSign bit in key usage did not limit its use to CAs, even though the KeyCertSign bit is so restricted. But 5.2.5 (the CRL distribution point extension) does say: "The CRL is signed using the CA's private key" and that certainly argues for what I would consider the usual interpretation, i.e., only CAs sign CRLs.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Mar 2001 18:29:15 -0500

David,

>Steve,
>
>From a policy point of view, it may make sense to say that only CAs 
>should be issuing CRLs, but what does this mean from a certificate 
>path processing point of view?

I have to admit that I have not thought as much about the path 
processing aspect of the issue.

>
>X.509 states "[t]he cA component indicates if the certified public 
>key may be used to verify certificate signatures". It says nothing 
>about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA 
>certificates but does do so with cRLSign. Are you arguing that we 
>should change the standards to require basicConstraints with cA=TRUE 
>in certificates that only authorize the use of the subject's public 
>key to verify signatures on CRLs? Or are you suggesting that a 
>certificate should be treated as a CA certificate if cRLSign is set 
>in keyUsage even if basicConstraints is absent?

I have always expected to see the CA flag set to true on a cert used 
to sign CRLs, but, as I noted in my message, a closer look at 2459 
fails to require that. Still, throughout most of the document we see 
references to CAs, not to EEs, with regard to CRL signing. If there 
was an intent to allow non-CAs to sign CRLs, we certainly did not 
make it clear.

Until we had the KeyUsage extension and the the certSign bit in v3 
certs, there was no doubt that only a CA could sign a CRL. It was not 
clear to me that X.509, or 2459, made a point of advertising that a 
feature of this extension, and of indirect CRLs, was to promote the 
signing of CRLs by other than a CA. Rereading the 259 text, I still 
have to say that is not a message that comes through.

>To be more specific, if we accept the idea that pathLenConstraint 
>should be computed differently depending on what type of certificate 
>the last one in the path is, should CA1's relying parties accept 
>CRLs issued by CA3 in the certification path below?
>

I would say no, if I understand your diagram. First, the cert from 
CA2 to CA3 does not say that CA3 is a CA! Also, if the distribution 
point extension is in the cert issued by CA2 to CA3, it is a 
statement about where to find the CA3 cert if it is ever revoked. If 
the distribution point were in certs issued by CA2 to EEs, then it 
would be saying that CA3 would be the issuer of these CRLs. But, look 
at the text below, from 2459

5.2.5  Issuing Distribution Point

    The issuing distribution point is a critical CRL extension 
identifies the CRL distribution point for a particular CRL, and it 
indicates whether the CRL covers revocation for end entity
certificates only, CA  certificates only, or a limitied set of reason 
codes.  Although the extension is critical, conforming 
implementations are not required to support this extension.

    The CRL is signed using the CA's private key.  CRL Distribution
    Points do not have their own key pairs.  If the CRL is stored in 
the X.500 Directory, it is stored in the Directory entry 
corresponding to the CRL distribution point, which may be different 
than the Directory entry of the CA.

This explicitly refers to the CRL being signed with a CA private key, 
not an EE private key.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 2 Mar 2001 16:43:20 -0800

All,

I've submitted a new OCSPv2 draft (-02) based on the WG's efforts in San
Diego.  This version incorporates the technical content of the OCSP-based
DPD and DPV I-Ds; those I-Ds will be allowed to expire in favor of this
unified specification.  Many thanks to all for your support in refining
those concepts.  A draft document defining the OCSP state machine was also
submitted.  If you wish to receive a copy of either prior to their eventual
appearance on the official IETF web site, please contact me offlist at
[email-masked].

Otherwise, here's a precis:

Pulled in core of the OCSP-based DPV and DPD I-Ds and moved around some
elements of the -01 text to more accurately reflect the
framework+service_type approach the prior three I-Ds and RFC2560 had already
defined.  I made what I hope are useful editorial (i.e. non-normative)
corrections along the way.  I also worked in the minor editorial corrections
we've made to RFC 2560 as it progresses along the standards track.

Accordingly, the Protocol Overview section is totally rewritten.  The only
potential surprise in this section is the abstract definition of Online
Revocation Status (ORS) service as a peer service to DPV and DPD.  ORS
service is simply what's currently in RFC 2560.  So basically we have ORS,
DPV and DPD as standardized OCSP services and a handful of potentially
useful but ancillary extensions (e.g. Archive Cutoff).

The technical definition of the DPV and DPD services were substantially
augmented to conform to the Dec 29 draft requirements definition as well as
the input received from the ad-hoc OCSPv2 working sessions conducted in San
Diego.  I wasn't able to work in all perspectives (some were mutually
exclusive of others) but at present the following is proposed in response to
those inputs:

DPVOptions  :: = SEQUENCE{
    pathParams              PathParameters             OPTIONAL,
    validAt           [2]   GeneralizedTime            OPTIONAL,
    revInfo           [3]   SEQUENCE OF RevocationInfo OPTIONAL,
    dPVFLags          [4]   DPVFlags                   OPTIONAL }

PathParameters ::= SEQUENCE {
    initialPolicySet  [0]   PolicyList                 OPTIONAL,
    trustPoints       [1]   SEQUENCE OF ReqCert        OPTIONAL }

DPVFlags ::= BIT STRING {
    returnpath        (0),
    returnrevinfo     (1),
    returntsp         (2),
    returnpolicy      (3) }

RevocationInfo ::= CHOICE {
    cRL               CertificateList,
    oCSP              OCSPResponse }

DPDOptions  :: = SEQUENCE{
    retryReference          OCTET STRING,
    initialPolicySet  [0]   EXPLICIT PolicyList OPTIONAL,
    trustPoints       [1]   SEQUENCE OF ReqCert OPTIONAL,
    validAt           [2]   GeneralizedTime     OPTIONAL,
    dDPFlags          [3]   DPDFlags            OPTIONAL}

DPDFlags ::=  BIT STRING {
    returnTSP          (0),
    returnpolicy       (1),
    crlonly            (2),
    ocsponly           (3),
    either             (4) }

SUBSTANTIAL context and additional technical content omitted for the sake of
brevity.  See the I-D for full details.  Specification subject to change.
Fasten seatbelts prior to takeoff.

Mike

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 05 Mar 2001 11:06:02 -0500

Steve,

You are right that RFC 2459 seems to be somewhat careless in its use of the term CA. However, X.509 seems to be more clear:

(1) Certification Authority is defined as "An authority trusted by one or more users to create and assign public-key certificates."

(2) For the basicConstraints extension, it states: "The cA component indicates if the certified public key may be used to verify certificate signatures."

(3) For the cRLDistributionPoints extension, it states: "The cRLIssuer component identifies the authority that issues and signs the CRL."

So X.509, when defining CAs, doesn't seem to say anything about CRLs and also uses the term authority instead of certification authority to describe the entity that signs a CRL.

At 06:29 PM 3/2/01 -0500, Stephen Kent wrote:
>I have always expected to see the CA flag set to true on a cert used to sign CRLs, but, as I noted in my message, a closer look at 2459 fails to require that. Still, throughout most of the document we see references to CAs, not to EEs, with regard to CRL signing. If there was an intent to allow non-CAs to sign CRLs, we certainly did not make it clear.
>
>Until we had the KeyUsage extension and the the certSign bit in v3 certs, there was no doubt that only a CA could sign a CRL. It was not clear to me that X.509, or 2459, made a point of advertising that a feature of this extension, and of indirect CRLs, was to promote the signing of CRLs by other than a CA. Rereading the 259 text, I still have to say that is not a message that comes through.
>
>I would say no, if I understand your diagram. First, the cert from CA2 to CA3 does not say that CA3 is a CA! Also, if the distribution point extension is in the cert issued by CA2 to CA3, it is a statement about where to find the CA3 cert if it is ever revoked. If the distribution point were in certs issued by CA2 to EEs, then it would be saying that CA3 would be the issuer of these CRLs. But, look at the text below, from 2459

Yes, I should have CA issuing two certificates: one to an EE with the CRLDistributionPoints extension and the other issued to CA3 with the keyUsage extension.

>    The issuing distribution point is a critical CRL extension  identifies the CRL distribution point for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA  certificates only, or a limitied set of reason codes.  Although the extension is critical, conforming implementations are not required to support this extension.
>
>    The CRL is signed using the CA's private key.  CRL Distribution Points do not have their own key pairs.  If the CRL is stored in the X.500 Directory, it is stored in the Directory entry corresponding to the CRL distribution point, which may be different than the Directory entry of the CA.
>
>This explicitly refers to the CRL being signed with a CA private key, not an EE private key.

The quote from 2459 above seems to have been copied from the following statement from X.509. Notice that in X.509, however, it uses the term "CRL issuer" instead of CA.

                 The CRL is signed by the CRL issuer’s key  CRL distribution points do not have
                 their own key pairs. However, for a CRL distributed via the Directory, the CRL
                 is stored in the entry of the CRL distribution point, which may not be the directory
                 entry of the CRL issuer.

So, I would argue that any suggestion in 2459 that only CAs can sign CRLs was as a result of the authors not being sufficiently cautious in their use of terms. I see no reason to reject a CRL simply because the certificate issued to CRL's issuer does not contain basicConstraints with cA=TRUE.

Dave