Subject: Basic constraints, key usage, and LDAP schema

From: Tim Polk <[email-masked]>
Date: Tue, 01 May 2001 16:03:11 -0400

Folks,

I have been reading the email messages on the list about the relationships 
between basic constraints, key usage, and the schema.  After mulling over 
the problem.  I would like to propose a solution - the only solution, as 
far as I can tell...

The solution is to simplify and separate the semantics of the basic 
constraints and key usage extension.  This has positive implications for 
the PKIX LDAP schema as well.

Basic Constraints

As stated in the current text for Basic Constraints (in 2459):  "The basic 
constraints extension identifies whether the subject of the certificate is 
a CA and how deep a certification path may exist through that CA."

I believe this is the right semantics, and that basic constraints should be 
included and cA should be asserted in *any* certificate issued to a CA, 
regardless of the type or role associated with the public key in the 
certificate.

Key Usage

The issuer should use the Key Usage extension to disambiguate the subject's 
key pairs:
(a) The issuer indicates this public key may be used to verify the 
signature on a public key certificate by asserting keyCertSign.  (b) The 
issuer indicates this public key may be used to verify the signature on 
CRLs by asserting cRLSign.  (c) The issuer indicates that this public key 
may be used to establish symmetric keys with the subject by asserting 
either keyEncipherment or keyAgreement.  (d) The issuer indicates that this 
public key may be used to verify signatures on objects other than public 
key certificates and CRLs by asserting nonRerpuidation or digitalSignature.

Of course, if a key pair is used for multiple purposes, multiple key usages 
may be asserted.

In each of these cases, the basic constraints extension also appears in the 
certificate and asserts that the subject is a CA.

LDAP Schema

All certificates issued to CAs would be considered CA certificates since 
the basic constraints extension is present and asserts that the subject is 
a CA.  As a result, each of these could appear in the cACertificate 
attribute or crossCertificatePair attribute.  They would *not* appear in 
the userCertificate attribute.  (That would include all types (a) through 
(d) above).

------------------

The implications of this strategy are as follows: (1) when a client is 
searching for a CA certificate, they will not have to check the 
userCertificate attribute; (2) the issuer can indicate that the subject is 
a CA regardless of the key usage; and (3) minimal changes to the text (my 
favorite!).

What do you think?

Thanks,

Tim Polk

---

From: [email-masked] (Terry Hayes)
Date: Tue, 01 May 2001 13:41:36 -0700

Tim,

I agree with your proposed solution.  As you have said, it separates the 
semantics of the two extensions, and simplifies the rules for the LDAP 
schema.

There is one remaining point to address, and I believe it may be the 
main point of discussion in the current thread.

When a CA uses the CRLDP extension to designate another entity to be the 
source for revocation information about some of its certificates, should 
that entity  have a "CA" certificate (with appropriate basicConstraints 
extension)?  I'm *not* suggesting that a basicConstraints extension is 
necessary for the entity to be authorized to sign the CRL.  Instead, the 
problem is that clients that are trying to locate the certificate will 
not know whether they should look in the cACertificate attribute or the 
userCertificate attribute to find the appropriate certificate.

To solve this, we can suggest that cACertificate be searched first, 
followed by userCertificate, or we can require that designated entities 
must always be a "CA", and the client can safely skip the 
userCertificate attribute.  This is a question of searching the 
directory only, and does not suggest changing your assertion that any 
set of bits may be set in the keyUsage extension of "CA" certificates.

Terry

Tim Polk wrote:

> Folks,
>
> I have been reading the email messages on the list about the 
> relationships between basic constraints, key usage, and the schema.  
> After mulling over the problem.  I would like to propose a solution - 
> the only solution, as far as I can tell...
>
> constraints and key usage extension.  This has positive implications 
> for the PKIX LDAP schema as well.
>
> Basic Constraints
>
> As stated in the current text for Basic Constraints (in 2459):  "The 
> basic constraints extension identifies whether the subject of the 
> certificate is a CA and how deep a certification path may exist 
> through that CA."
>
> I believe this is the right semantics, and that basic constraints 
> should be included and cA should be asserted in *any* certificate 
> issued to a CA, regardless of the type or role associated with the 
> public key in the certificate.
>
> Key Usage
>
> The issuer should use the Key Usage extension to disambiguate the 
> subject's key pairs:
> signature on a public key certificate by asserting keyCertSign.  (b) 
> The issuer indicates this public key may be used to verify the 
> signature on CRLs by asserting cRLSign.  (c) The issuer indicates that 
> this public key may be used to establish symmetric keys with the 
> subject by asserting either keyEncipherment or keyAgreement.  (d) The 
> issuer indicates that this public key may be used to verify signatures 
> on objects other than public key certificates and CRLs by asserting 
> nonRerpuidation or digitalSignature.
>
> Of course, if a key pair is used for multiple purposes, multiple key 
> usages may be asserted.
>
> In each of these cases, the basic constraints extension also appears 
> in the certificate and asserts that the subject is a CA.
>
> LDAP Schema
>
> All certificates issued to CAs would be considered CA certificates 
> since the basic constraints extension is present and asserts that the 
> subject is a CA.  As a result, each of these could appear in the 
> cACertificate attribute or crossCertificatePair attribute.  They would 
> *not* appear in the userCertificate attribute.  (That would include 
> all types (a) through (d) above).
>
> ------------------
>
> userCertificate attribute; (2) the issuer can indicate that the 
> subject is a CA regardless of the key usage; and (3) minimal changes 
> to the text (my favorite!).
>
> What do you think?
>
> Thanks,
>
> Tim Polk
>
>
>

---

From: [email-masked] (Regunathan Rajaiah)
Date: Tue, 01 May 2001 17:00:40 -0400

Terry
    I like the idea of
  " or we can require that designated entities must always be a "CA","

I am wondering if the entity [source of revocation info] is not required to
be CA , are the clinets expected to trust that entity too?

We should require the designated entities must always be a CA

---

From: Tim Polk <[email-masked]>
Date: Tue, 01 May 2001 17:05:17 -0400

Terry,

I think it would be best if the client did not need to check the 
userCertificate attribute to validate CRLs.  This adds complexity without 
any real benefit (in my opinion.)  I have included some proposed text for 
the first paragraph of section 4.2.1.10 (basic constraints) that would 
clarify the issue.

----------------proposed text for first paragraph of 4.2.1.10----------------

The basic constraints extension identifies whether the subject of the 
certificate is a CA and the maximum depth of valid certification paths that 
include this certificate.  A subject is considered a CA if it issues public 
key certificates or CRLs that describe the revocation status of public key 
certificates.

----------------------end proposed text

What do you think?

Thanks,

Tim Polk

At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:
>semantics of the two extensions, and simplifies the rules for the LDAP schema.
>
>There is one remaining point to address, and I believe it may be the main 
>point of discussion in the current thread.
>
>problem is that clients that are trying to locate the certificate will not 
>know whether they should look in the cACertificate attribute or the 
>must always be a "CA", and the client can safely skip the userCertificate 
>attribute.  This is a question of searching the directory only, and does 
>not suggest changing your assertion that any set of bits may be set in the 
>keyUsage extension of "CA" certificates.
>
>Terry
>
>Tim Polk wrote:
>
>>Folks,
>>
>>After mulling over the problem.  I would like to propose a solution - the 
>>only solution, as far as I can tell...
>>
>>certificate is a CA and how deep a certification path may exist through 
>>that CA."
>>
>>I believe this is the right semantics, and that basic constraints should 
>>be included and cA should be asserted in *any* certificate issued to a 
>>CA, regardless of the type or role associated with the public key in the 
>>certificate.
>>
>>Key Usage
>>
>>either keyEncipherment or keyAgreement.  (d) The issuer indicates that 
>>this public key may be used to verify signatures on objects other than 
>>public key certificates and CRLs by asserting nonRerpuidation or 
>>digitalSignature.
>>
>>In each of these cases, the basic constraints extension also appears in 
>>the certificate and asserts that the subject is a CA.
>>
>>LDAP Schema
>>
>>the basic constraints extension is present and asserts that the subject 
>>is a CA.  As a result, each of these could appear in the cACertificate 
>>userCertificate attribute; (2) the issuer can indicate that the subject 
>>is a CA regardless of the key usage; and (3) minimal changes to the text 
>>(my favorite!).
>>
>>What do you think?
>>
>>Thanks,
>>
>>Tim Polk
>>
>>
>
>

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 01 May 2001 17:27:03 -0400

Regunathan,

Bear in mind that if an entity other than the certificate issuer issues CRLs that provide revocation information for a certificate, the CRLs should only be accepted if the certificate issuer specifically designates the CRL issuer as the source of revocation information. Whether we call the CRL issuer a CA or not should not affect the degree to which clients trust that entity. Similarly, whether the cA bit is set or not should not affect whether clients trust that entity.

If a CA issues a certificate, specifies entityX as the source of revocation information (using a distribution point), and then issues a certificate to entityX with the cRLSign KeyUsage bit set, then clients that are willing to accept the certificate should trust the CRLs issued by entityX to provide accurate revocation information for the certificate. It doesn't make sense to say that the information in the CRL should be trusted if the certificate issued to entityX has the cA bit set, but should not be trusted if the cRLSign bit is set but the cA bit is not set.

I do like the idea, however, of putting any certificate with cRLSign set in the cACertificate or crossCertificatePair attribute. We should try to have a single place for clients to look to find the certificate they need. Since most certificates with cRLSign set will also have KeyCertSign set as well, the cACertificate or crossCertificatePair attributes seem the best choice.

 From my point of view, the real value that basicConstraints adds is the ability to impose path length constraints. Using the cA bit to confer some degree of "trustworthiness" on the subject seems to be overloading the bit. We already have KeyUsage to indicate whether the subject public key can be used to verify signatures on certificates, CRLs, etc.

Dave

At 05:00 PM 5/1/01 -0400, Regunathan Rajaiah wrote:
>I am wondering if the entity [source of revocation info] is not required to be CA , are the clinets expected to trust that entity too? 
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 02 May 2001 15:14:04 +0200

Tim,

I stayed silent on that topic and it is quite hard to catch all the e-mails
related to it. I certainly missed or skipped missed some of them.
 
> ----------------------end proposed text

RFC 2459 only said:

   through that CA.

However, according to the new text a "CRL Issuer" is now also a "CA": " A
subject is considered a CA if it issues public key certificates or CRLs that
describe the revocation status of public key certificates."

The current text of new-part1-06 also goes in the same direction.

   The cA bit indicates if the certified public key may be used to
   verify signatures on other certificates.  If the cA bit is asserted,
   then either the keyCertSign bit or the cRLSign bit in the key usage
   extension (see 4.2.1.3) MUST also be asserted. If the cA bit is not
   asserted, then both the keyCertSign bit and the cRLSign in the key
   usage extension MUST NOT be asserted.

This seems quite strange. A CRL issuer is just one way to make available
revocation status information. OCSP is another way. RFC 2560 says:

   OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

If a "CRL issuer" is a "CA", why should an OCSP responder designated by a CA
not also be a "CA" ?

As far as I remember, originally the cA boolean in the basic constraints
extension only allowed to make the difference between leaf certificates and
CA certificates. This boolean now seems to be be used with a different
meaning (and, maybe, we should change its meaning - not the syntax). 

Could someone say again, why that change was requested and what are the real
benefits of that change ?

In other words, could someone say again what the problem was ? :-)

Thanks,

Denis

---

From: Tim Polk <[email-masked]>
Date: Wed, 02 May 2001 10:42:30 -0400

Denis,

These messages have been flying fast and furious under several topic 
lines.  I don't believe I caught them all either!  As they are all related, 
it is difficult to resolve the issues one-by-one.  The separate solutions 
may combine to present new problems.  That was the rationale for the single 
comprehensive posting.

The real problems, in my opinion, are as follows:

(1) Consider a PKIX client, searching for a certificate to validate a 
particular CRL.  Under 2459, the client cannot guess whether the basic 
constraints extension will be present with the CA bit asserted.

If the key used to validate the CRL is also used to validate certificates, 
it will have basic constraints and assert cA is TRUE.  In this case, the 
certificate should be in the ca certificate attribute (or perhaps the cross 
certificate pairs).

If the key is not used to validate certificates, basic constraints will be 
omitted and the certificate will be stored in the user certificate attribute.

(2) If a PKIX client wishes to communicate with a CA for certificate 
management purposes (e.g., to request a new certificate, request 
revocation, or perhaps centralized key generation for key escrow scenarios) 
the client will need to validate the CA's signature and perhaps make use of 
the CA's key management key.  If the keys used for these transactions are 
also used to sign PKCs, the certs will be in the CA certificate 
attribute.  If the keys used for these purposes are not used to sign PKCs, 
there will be no indication that this entity is a CA and the certs will be 
stored in the user certificate attribute.

As above, the PKIX client does not know where to look for these 
certificates.  Where they are not used to sign PKCs, there will be no 
indication in the certificate that this entity is a CA at all.

(3) The attribute certificate profile is very clear regarding AC issuers 
versus PKC issuers. Section 4.5 states "the AC issuer's PKC MUST NOT have a 
basicConstraints extension with the cA BOOLEAN set to TRUE."

However, the combination of RFC 2459 and the attribute certificate profile 
does not permit an issuer to specify whether a subject can issue CRLs 
for  PKCs, ACs, or both.  This would provide us with an analogous solution: 
if the CA bit is not asserted, but the cRLSign bit is set in key usage, the 
subject is only permitted to issue CRLs for ACs.

To be honest, (3) is the least compelling problem.  The CA must explicitly 
name an indirect CRL issuer in PKCs it issues *anyway*, so the CA bit isn't 
a big security issue.  Still, I think it is nice to supply clients with 
this information.

Anyway, I hope this clarifies things a bit.  My goal was to resolve all 
three problems simultaneously and consistently.

Thanks,

Tim Polk

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 02 May 2001 11:39:41 -0400

Terry:

In my view, certificates that contain public keys used to verify signatures 
on public key certificates or CRLs that contain revocation status 
information about public key certificates are CA certificates.  As such, 
the basic constraints extension should assert the cA bit, and they should 
be fetched from the cACertificate directory attribute.

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 03 May 2001 14:37:54 -0400

Tim,

Does this mean that if a user wanted to send an S/MIME request
for information to a CA, the user agent should look for the CA's
email certificate in the cACertificate or crossCertficatePair
attribute?  Similarly for a CMC certificate signing request
encrypted for the CA?  And for the TLS server certificate for
the CA's web site?  And for the signature certificate used to
validate the CA's published CPS?

I believe that the original intent of the cA flag in basicConstraints
was that it be an indicator that the certificate can be used in
path validation, not that it should be set in in every certificate
belonging to a CA.  With this interpretation, the cA flag is synonymous
with, and MUST always have the same value as, the keyCertSign bit whenever
both basic constraints and key usage are present in a certificate.

Mandating cA=keyCertSign is a much cleaner solution than expecting
clients to reject a path containing a CA's web server certificate
which has cA=true and key usage not present.  Are you proposing that
PKIX-conforming CAs MUST populate a critical key usage extension in all
certificates used to sign certificates AND all end-entity certificates
belonging to a CA?  And that all PKIX-conforming applications MUST reject
a path unless a critical key usage extension is present with keyCertSign
asserted in every certificate but the last?

I'd heartily agree with that generation requirement, but I don't think
the application requirement is practical. And without the application
requirement, it would be dangerous to assert the cA flag in CA
certificates not intended for use in validating signatures on
certificates.

Regards,
Dave

---

From: Tim Polk <[email-masked]>
Date: Thu, 03 May 2001 17:24:51 -0400

Dave,

My comments are in-line.

At 02:37 PM 5/3/01 -0400, David P. Kemp wrote:

Tim,

Yes, that is what it would mean.  (Actually, I don't think the TLS
server certificate would necessarily have the same name; in that case, it
wouldn't be a CA certificate.  I would consider that an RA.
I'm splitting hairs, though.)

When a client needs a CA's public key, it would be advantageous if the
client could guess which attribute the certificate might be found
in.  However, a client has no way to guess the full range of uses
for the key used to sign a CRL, or used to sign the published CPS.
If the same private key is used to sign certs, the certificate will
appear in either the caCertificate attribute, crossCertificatePair
attribute, or both.  [Note we are already checking two
locations!]  On the other hand, if this private key is not used to
sign certificates the corresponding certificate would have to be stored
in the userCertificate attribute.  [That is three locations]

The client doesn't want a user's public key.  It wants a public key
associated with a CA for some purpose other than validating a
certificate.  Why shouldn't it look for a cA certificate?

I believe that the original intent of the cA
flag in basicConstraints

belonging to a CA.  With this interpretation, the cA flag is
synonymous

with, and MUST always have the same value as, the keyCertSign bit
whenever

both basic constraints and key usage are present in a
certificate.

That may in fact have been the intent.  X.509 states

The cA component indicates if the certified
public key may be used to verify certificate signatures.
I wasn't around in those meetings, so I am not sure if this was the
*original* intent.

However, I think that PKI clients need to be able to confirm that the CPS
was signed by a CA, not just some random certificate subject.  They
need to be able to determine that the entity generating their key
management key pair is in fact the CA, not some random certificate
subject.

I don't know how we convey this information if we don't use the basic
constraints extension.  Since we have key usage to refine the
meaning of basic constraints we should be able to say "the subject
is a CA and the public key may be used to [one or more of the following:
validate signatures on certificates; validate signatures on CRLs; key
encipherment; etc. etc.]"

Mandating cA=keyCertSign is a much cleaner
solution than expecting

which has cA=true and key usage not present.  Are you proposing
that

PKIX-conforming CAs MUST populate a critical key usage extension in
all

certificates used to sign certificates AND all end-entity
certificates

belonging to a CA?  And that all PKIX-conforming applications MUST
reject

a path unless a critical key usage extension is present with
keyCertSign

That's pretty much what I'm proposing, although the criticality is a
requirement imposed on generation, not processing.  PKIX conforming
implementations require that basic constraints assert cA=TRUE *OR** the
client must have out-of-band information that the subject is a CA for
each intermediate certificate (6.1.4.step (k)).  If key usage
appears, it must assert keyCertSign.  The path validation algorithm
does not check the criticality of these extensions.

I'd heartily agree with that generation
requirement, but I don't think

the application requirement is practical. And without the
application

certificates.

You are correct, it would be dangerous to assert cA=TRUE without
specifying a critical key usage extension.  I guess the question is,
what would a client do if it encountered an intermediate certificate
where basic constraints indicated it was a CA certificate and the key
usage extension appeared but keyCertSign was not asserted?

On the other hand, the subject is trusted to issue certificates or CRLs
anyway.  If the subject wants to perform mischief, it can do so with
the appropriate key pair. Right?

Regards,

Dave

Tim Polk wrote:

> I have been reading the email messages on the list about the
relationships

> I believe this is the right semantics, and that basic constraints
should be

> The issuer should use the Key Usage extension to disambiguate the
subject's

> Of course, if a key pair is used for multiple purposes, multiple key
usages

> In each of these cases, the basic constraints extension also appears
in the

> All certificates issued to CAs would be considered CA certificates
since

> userCertificate attribute; (2) the issuer can indicate that the
subject is

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 04 May 2001 10:27:55 -0400

Tim Polk wrote:
> 
> However, I think that PKI clients need to be able to confirm that the CPS was
> signed by a CA, not just some random certificate subject.  They need to be
> able to determine that the entity generating their key management key pair is
> in fact the CA, not some random certificate subject.
> 
> constraints extension.  Since we have key usage to refine the meaning of basic
> constraints we should be able to say "the subject is a CA and the public key
> may be used to [one or more of the following: validate signatures on
> certificates; validate signatures on CRLs; key encipherment; etc. etc.]"

The counter-argument is that you need to know that the entity
generating the key management keypair is in fact the CA that will
be signing your certificate, not some random CA.  So checking the
name and the signature chaining of the transaction certificate is
necessary and sufficient, whereas checking the cA flag is neither
necessary nor sufficient.  The X.509 term "self-issued" covers the
case of a CA issuing transaction, web server, and CRL-signing
certificates to itself; the criterion for determining
self-issued-ness is subject/issuer name equality, not key usage
or basic constraints.

> You are correct, it would be dangerous to assert cA=TRUE without specifying a
> critical key usage extension.  I guess the question is, what would a client do
> if it encountered an intermediate certificate where basic constraints
> indicated it was a CA certificate and the key usage extension appeared but
> keyCertSign was not asserted?
> 
> anyway.  If the subject wants to perform mischief, it can do so with the
> appropriate key pair. Right?

I'm more concerned about an adversary's mischief than the CA's.
Certificate signing keys are the most powerful and should be
the best protected.  Web server and CRL signing private keys are
more exposed, but compromising them causes less damage than
compromise of a cert signing key.  If an adversary has a
compromised private key and a corresponding valid certificate
with cA=true, then any application which would accept that
certificate as part of a path would allow the adversary to
escalate his privileges from impersonating a web server to
creating bogus certificates.

Setting the cA flag on non-certificate-signing certificates
is not necessary. And it is potentially dangerous because even
if we make a critical key usage extension a MUST in the profile,
we can't guarantee that every CA in the world will be
PKIX-compliant.

I oppose re-defining the cA flag in this manner.  I believe we
should continue to treat the cA flag as having semantics
identical to the keyCertSign bit.

Dave