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

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 01 Mar 2001 10:26:47 -0700

I would agree with David, that using the same key or certificate
for both correspondence and certificate issuance would be
extremely improbable.

However, it is not nearly so clear that a CA might choose to use the 
same key for certificate signing and for signing its CPS, for
example, so it would appear that his scenario is worth considering.

Bob

>>> David Kemp <[email-masked]> 03/01/01 09:58AM >>>

> Date: Wed, 28 Feb 2001 13:28:46 -0500
> From: Steve Hanna <[email-masked]>
> X-Accept-Language: en
> To: "David P. Kemp" <[email-masked]>
> CC: [email-masked] 
> Subject: Re: Open Issue in Part1: path length constraints
> 
> "David P. Kemp" wrote:
> > > From: Steve Hanna <[email-masked]>
> > > I find it odd to say that a certificate with cA=TRUE is a CA certificate
> > > *unless* it is the last certificate in a path. I suppose this is only a
> > > wording problem, but I find this wording *less* clear than the old
> > > wording.
> > 
> > The oddness arises because you are applying the label "CA certificate"
> > to the certificate based on its contents instead of its usage.
> > 
> > If a certificate contains cA=TRUE and
> > keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
> > than one purpose.  It is a CA certificate when validating the signature
> > of a certificate, and it is an EE certificate when validating the
> > signature of a CRL or a message.  (A CA should not use a cert-signing
> > private key to sign correspondence, but X.509 doesn't prohibit unhygenic
> > practices.)
> 
> So you're saying that a certificate with cA=TRUE is an end-entity
> certificate when it appears at the end of a certificate chain and a CA
> certificate otherwise? The same certificate is both a CA certificate and
> an end-entity certificate? This seems to be contrary to the way these
> terms have been used in the past and the way they are used in X.509, RFC
> 2459, new-part1, and throughout the industry.

Steve,

Yes, that's what I'm saying.  If "you" are a CA, and you use the same
private key to sign certificates and to sign email, and you are the
subject of a certificate which has both keyCertSign and digitalSignature
key usage bits, then what kind of certificate is it?

My answer is that it is both.  What is your answer?

Using the same cert for correspondence signatures and certificate
signatures is probably so risky that such certs are not routinely used.
But this discussion is about using the same cert for signing certificates
and for signing CRLs, which is probably standard industry practice.
When validating the signature on a CRL, is the CA's certificate a
CA certificate or an End-Entity certificate?

My answer is that it is the certificate of an entity which has signed
a CRL.  What is your answer?

> I suggest the following:
> 
>    In this case, it gives the maximum number of intermediate CA
>    certificates that may follow this certificate in a certification
>    path. (Note: One final certificate will follow the final intermediate
>    CA certificate in the path. This certificate may be either a CA
>    certificate or an end-entity certificate.) A pathLenConstraint of
>    zero indicates that no intermediate CA certificates may follow in the
>    path. Where it appears, the pathLenConstraint field MUST be greater
>    than or equal to zero. Where pathLenConstraint does not appear, there
>    is no limit to the allowed length of the certification path.

This doesn't answer the question of what to call the final certificate
in the path when that certificate has cA=TRUE and the signature being
verified is that of a CRL or a message.  Which is OK, since it doesn't
make a bit o' difference what you call it as long as it isn't counted in
pathLenConstraint.

The suggestion is OK with me, but it is no less plausible to
call (2) an "end-entity certificate" than it is to call (1) an
"intermediate CA certificate".  (1) is the last CA certificate
in the path, but if you want to call it an intermediate CA, fine.

     [anchor]  --> [CA-a]  --> [CA-b]  --> [Joe User] --> [message]
                                 (1)

     [anchor]  --> [CA-a]  --> [CA-b]  --> [message]
                                 (2)
                                 
Dave

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 01 Mar 2001 09:53:15 -0800

> for both correspondence and certificate issuance would be

How about a CA key signing OCSP responses?  Or CRLs, for that matter.  Either
are non-certificate "messages".

		Marc