Subject: Re: Basic constraints, key usage, and LDAP schema

From: "Tom Gindin" <[email-masked]>
Date: Tue, 1 May 2001 17:46:04 -0400

Tim's idea looks good to me too.  I have no strong opinions as to
whether an entity delegated to sign PK CRL's which does not have the same
DN as any signer of PK Certificates should have basicConstraints indicating
that it is a CA and be published in caCertificate, or whether it should be
published in userCertificate with no basicConstraints extension in the
certificate.  However, an entity which signs AC CRL's but not PK CRL's is
not a CA (it may be an AA, but not a CA).  First, do we need an Key Purpose
ID to designate such certificates?  I would think that we do.  Second, what
attribute does the CRL signing certificate go into?  It can't go into the
aACertificate attribute which contains AC's rather than PKC's.

          Tom Gindin

[email-masked] (Terry Hayes) on 05/01/2001 04:41:36 PM

To:   Tim Polk <[email-masked]>
cc:   [email-masked]
Subject:  Re: Basic constraints, key usage, and LDAP schema

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...
>
> 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: Sharon Boeyen <[email-masked]>
Date: Wed, 2 May 2001 16:05:54 -0400

Hi Tim,

I just want to clarify the directory attributes. All certs that are not self
issued must go in the cross certificates attribute. All self issued certs
must go in the caCertificates attribute. A subset of the certificates in the
cross certificate pairs attributes may also be present in the caCertificates
attribute (those issued within the same realm, a term left undefined). Lets
not go back down that rathole :-) The two attributes are not
interchangeable. Given that the certs you are talking about are not self
issued then they must go in the cross certificate pairs attribute and may
also be placed in the caCertificate attribute if issued within the same
realm.

Sharon

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 10:43 AM
> To: Denis Pinkas
> Cc: [email-masked]
> 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
> 
> At 03:14 PM 5/2/01 +0200, Denis Pinkas wrote:
> >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.
> >
> > > 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?
> >
> >RFC 2459 only said:
> >
> >    The basic constraints extension identifies whether the 
> subject of the
> >    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
> >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > > At 01:41 PM 5/1/01 -0700, Terry Hayes wrote:
> > > >Tim,
> > > >
> > > >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...
> > > >>
> > > >>constraints and key usage extension.  This has positive 
> implications for
> > > >>the PKIX LDAP schema as well.
> > > >>
> > > >>Basic Constraints
> > > >>
> > > >>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
> > > >>
> > > >>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.
> > > >>
> > > >>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: "Tom Gindin" <[email-masked]>
Date: Wed, 2 May 2001 17:43:04 -0400

In the current draft of X.509v4, "self-issued" means something
different than "self-signed".  "self-issued" appears to be the condition
"the certificate's subject name can be matched to its own issuer name,
which is that of a CA", while "self-signed" is that with the added
condition "the certificate signature is verifiable with the public key
contained in the message".  Most of these CRL signing certificates are
"self-issued" in this sense, although not "self-signed".
     One other reason why such CRL signing certificates would legitimately
not go into the CC Pair attribute would be that there is no other directory
entry where the CA certificate to verify the signature on this certificate
could be found, unlike any other certificates in CC Pair.
     Lastly, if a CRL signing certificate were issued by a CA certificate
with the same DN, it would certainly belong in the same realm, if that
concept has any meaning at all.

          Tom Gindin

Sharon Boeyen <[email-masked]> on 05/02/2001 04:05:54 PM

To:   "'Tim Polk'" <[email-masked]>, Denis Pinkas
      <[email-masked]>
cc:   [email-masked]
Subject:  RE: Basic constraints, key usage, and LDAP schema

Hi Tim,

I just want to clarify the directory attributes. All certs that are not
self issued must go in the cross certificates attribute. All self issued
certs must go in the caCertificates attribute. A subset of the certificates
in the cross certificate pairs attributes may also be present in the
caCertificates attribute (those issued within the same realm, a term left
undefined). Lets not go back down that rathole :-) The two attributes are
not interchangeable. Given that the certs you are talking about are not
self issued then they must go in the cross certificate pairs attribute and
may also be placed in the caCertificate attribute if issued within the same
realm.

Sharon

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 3 May 2001 10:34:42 -0400

I see your point - I was missing the point that they are self-issued and was

thinking of the case where you are delegating authority to an indirect 
issuer. In the indirect case the cert would need to be in the cross-cert
pairs
attribute and may also appear in the caCerts attribute.

On the self issued ones, why are they needed at all? Why would a CA issue 
a cert to itself indicating that it can sign CRLs? Why do we need that?

Sharon

> From: Tom Gindin [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 5:43 PM
> To: Sharon Boeyen
> Cc: 'Tim Polk'; Denis Pinkas; [email-masked]

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 3 May 2001 12:32:29 -0400

Sharon:
 
One reason a CA may issue itself a CRL signing certificate is the scenario
as follows:
 
1.  The CA is a trust anchor for some relying parties, and
 
2.  The CA wants to use different key for CRL signing for operational
security, and
 
3.  The CA wants to only provide one trust anchor (i.e., the certificate
signature verification public key).
 
In that scenario, the CA will issue itself a certificate for the CRL
signature verification public key.
 
-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 10:35 AM
To: 'Tom Gindin'; Sharon Boeyen
Cc: 'Tim Polk'; Denis Pinkas; [email-masked]
Subject: RE: Basic constraints, key usage, and LDAP schema

Sharon 

> From: Tom Gindin [ mailto:[email-masked] <mailto:[email-masked]> ]

> > From: Tim Polk [ mailto:[email-masked] <mailto:[email-masked]> ]

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 3 May 2001 12:52:30 -0400

Thanks, I understand now.

-----Original Message-----
From: Santosh Chokhani 
Sent: Thursday, May 03, 2001 12:32 PM
To: Sharon Boeyen; 'Tom Gindin'
Cc: 'Tim Polk'; Denis Pinkas; [email-masked]
Subject: RE: Basic constraints, key usage, and LDAP schema

Sharon:

 

 
-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 10:35 AM
To: 'Tom Gindin'; Sharon Boeyen
Cc: 'Tim Polk'; Denis Pinkas; [email-masked]
Subject: RE: Basic constraints, key usage, and LDAP schema

Sharon

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 4 May 2001 10:11:40 -0400

Just BTW, my reasoning is similar to Santosh's.  I would like to
mention that the reasons for issuing a distinct CMP certificate for a CA
are even stronger than those for a distinct CRL certificate.  However, it
is not obvious whether this should be classed as a CA certificate since a
certificate to be used with CMP looks more like a standard server
certificate.

          Tom Gindin

Sharon Boeyen <[email-masked]> on 05/03/2001 12:52:30 PM

To:   Santosh Chokhani <[email-masked]>, Tom Gindin/Watson/IBM@IBMUS
cc:   "'Tim Polk'" <[email-masked]>, "'Denis Pinkas'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject:  RE: Basic constraints, key usage, and LDAP schema

 -----Original Message-----
 From: Santosh Chokhani
 Sent: Thursday, May 03, 2001 12:32 PM
 To: Sharon Boeyen; 'Tom Gindin'
 Cc: 'Tim Polk'; Denis Pinkas; [email-masked]
 Subject: RE: Basic constraints, key usage, and LDAP schema

 Sharon:

 -----Original Message-----
 From: Sharon Boeyen [mailto:[email-masked]]
 Sent: Thursday, May 03, 2001 10:35 AM
 To: 'Tom Gindin'; Sharon Boeyen
 Cc: 'Tim Polk'; Denis Pinkas; [email-masked]
 Subject: RE: Basic constraints, key usage, and LDAP schema

 I see your point - I was missing the point that they are self-issued and
 was
 thinking of the case where you are delegating authority to an indirect
 issuer. In the indirect case the cert would need to be in the cross-cert
 pairs
 attribute and may also appear in the caCerts attribute.

 Sharon

 > concept has any meaning at all.
 (snip)