Re: Open Issue in Part1: path length constraints

[Stephen Kent <kent@xxxxxxx>]

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

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