Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix -new-part1-06.txt comments)

From: Sharon Boeyen <[email-masked]>
Date: Wed, 25 Apr 2001 15:34:33 -0400

Tony, since PKIX profiles 509, here are answers from that standard. While
PKIX may 
use different language to describe these, they should still be aligned with
the 
basic definitions. 

Hope that helps
Sharon

> -----Original Message-----
> From: Tony Bartoletti [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2001 2:54 PM
> To: David A. Cooper; [email-masked]
> Subject: Re: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> All,
> 
> In trying to parse this issue (and Russ Housley's previous 
> proposed text) it
> appears that terminology needs a bit of shoring up, at least for me.
> 
> Can anyone answer these "simple" questions?
> 
> 1.  Is a "CA Certificate" defined to be:
> 
>      a.  A certificate whose subject is a CA
>      b.  A certificate with "cA" bit set.
>      c.  A certificate with either kCertSign or cRLSign set?
> 
>          (Are (a) and (b) equivalent "if its a CA certificate"?)

Clause 7 "A CA-certificate is a certificate issued by a CA to a subject that
is itslef a CA and therefore is capable of issuing public-key certificates."
It then goes on to define the different types of CA-certificate (Self
issued, Self signed and cross).

No a) and b) are not strictly equivalent. Clause 8.4.2.1 on basic
constraints "...with the certified public key being used to verify
certificate signatures", that's the key to use of that bit in the extension.
> 
> 2.  Is the term "public key certificate" intended to represent:
> 
>      a.  Only certificates that bind keys to "DN/Identity"
>      b.  Certificates that bind keys to anything (e.g., "attributes")
> 
>      For instance, is an "Attribute Certificate" considered to be a
>      subset of "public key certificates", or not?

No, attribute certificates are not subsets of public-key certificates. They
are 
'certificates' but do NOT contain a public-key and are therefore not a
subset.
(see 3.3.1 and 3.3.4.4)
> 
> 3.  Is an "AA" considered to be:
> 
>      a.  A "CA that certifies attributes and not DN/Identity",
>          (yet still a CA, since they author/authorize certificates.)
>      b.  Not a CA, since the term CA is "reserved" to "DN/Identity"
> 

No an AA is not a CA of any sort. CA is an authority for public-key
certificates only and AA is an authority for attribute certificates only 
(see 3.3.2 and 3.3.16. The term 'authority' used alone is defined to include
both (see 3.3.6). 

> 4.  Is an "AA Certificate" a form of "CA Certificate" or not?
>      (Answer should be derived from response to (3).

No. (as per response to 3)  
> 
> 5.  If both "CRLs and ARLs" are examples of "certificate 
> revocation lists"
>      then is an ARL:
> 
>      a.  An instance of CRL (that happens not to revoke any 
> DN/ID certs)?
>      b.  Never a CRL, since every CRL involves DN/ID certificates?

Actually 509 added specific acronyms for each type of CRL. What used 
to be called an "ARL" (Authority Revocation List) is now a "CARL" 
Certification Authority Revocation List) and is a revocation list of
public-key
certificates issued to CAs that are no longer considered valid by the 
certificate issuer (3.3.17). The equivalent of that for attribute
authorities 
would be an AARL (Attribute Authority Revocation List)as defined in 3.3.3.  

> 
> I submit that more than half of the dialogs/debates on this list can
> be traced to confusion regarding these fundamental terms.
> 
> ___tony___
> 
> 
> At 01:25 PM 4/25/01 -0400, David A. Cooper wrote:
> >Steve,
> >
> >If we are going to change PKIX to require the cA bit in 
> basicConstraints 
> >to be set even when the subject public key can only be used 
> to verify 
> >signatures on CRLs, then we need to be sure that the text 
> clearly explains 
> >to readers when the cA bit should or should not be set. Currently 
> >new-part1-06 states that "[t]he cA bit indicates if the 
> certified public 
> >key may be used to verify signatures on other certificates." 
> The clearly 
> >is not accurate, since if the cA bit is set one still does not know 
> >whether the subject public key may be used to verify signatures on 
> >certificates. One must look at the keyUsage extension to make that 
> >determination.
> >
> >I think it would be helpful to the discussion that we are 
> having if you 
> >would clearly state your interpretation of the meaning of 
> the cA bit in 
> >basicConstraints.
> >
> >  From what I have read so far, it appears that you believe 
> that the cA 
> > bit should be used to indicate if the subject of the 
> certificate is a CA. 
> > But, if this is the case, then new-part1-06 still does not 
> accurately 
> > reflect your notion of the cA bit. Currently the text 
> states that the cA 
> > bit may only be set if the keyCertSign bit or the cRLSign 
> bit in keyUsage 
> > is set. However, a CA does more than just issue 
> certificates and CRLs. A 
> > CA may have a private key dedicated to signing PKI 
> transaction messages 
> > (e.g., certification response, revocation response, 
> proof-of-possession 
> > challenge). If a certificate were issued to a CA with its 
> PKI transaction 
> > message verification key as the subject public key, neither the 
> > keyCertSign nor the cRLSign bit in KeyUsage would be set, 
> but the subject 
> > of the certificate would still be a CA.
> >
> >So, should the cA bit be used to indicate if the certificate 
> subject is a 
> >CA or to indicate that the subject public key may be used to verify 
> >signatures on certificates and/or CRLs? If the latter, then not all 
> >certificates issued to CAs will have the cA bit set.
> >
> >Dave
> >
> >At 01:31 PM 4/20/01 -0400, Stephen Kent wrote:
> > >>The description of basic constraints in X.509 further 
> supports the idea 
> > that the cA bit is used to specify certificate issuing, not 
> certificate 
> > and/or CRL issuing:
> > >>
> > >>"This field indicates if the subject may act as a CA, with the 
> > certified public key being used to verify certificate 
> signatures. ... The 
> > cA component indicates if the certified public key may be 
> used to verify 
> > certificate signatures. ... if the value of cA is not set to 
> true then the 
> > certified public key shall not be used to verify a 
> certificate signature"
> > >>
> > >>
> > >>pkix-new-part1-05 states something similar:
> > >>
> > >>"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 the 
> > keyCertSign bit in the key usage extension (see 4.2.1.3) 
> MUST also be 
> > asserted. If the cA bit is not asserted, then the 
> keyCertSign bit in the 
> > key usage extension MUST NOT be asserted."
> > >
> > >again, this supports the notion that a CA signs certs, but it says 
> > nothing about whether a CA or some other entity signs CRLs. We have 
> > uncovered a number of instances where less than perfect 
> wording has lead 
> > to confusion and our recent dialogue suggests that some of 
> the quotes you 
> > cite are examples of this.
> 
> Tony Bartoletti 925-422-3881 <[email-masked]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900
> 
> 
> 
>

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 25 Apr 2001 14:27:44 -0700

Sharon and Peter,

Thank you both for the explanations.  I now understand that an
"attribute certificate" does NOT certify a key.  Thus, an "AA"
is not an "[Attribute] Certificate Authority" (A-CA) but rather
is an "[Attribute Certificate] Authority]" (AC-A).  What is
called a "CA" is actually a "(Public) Key Certificate Authority".

Are there no instruments that attest (e.g.):

    "(anonymous) signer with this key is 21 years old"?

That is, bind a "key to attributes, sans DN/Identity"?
Could a CA do this using PMI extension attributes?

Finally, does anyone know if the PKIX "CRL/ARL" maps to
CARL/AARL?  And does this imply that no one can sign or
verify a list containing both PKC and AC revocations?

Thanks again for your previous (extensive) response!

___tony___

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 26 Apr 2001 09:24:25 -0400

Tony, on the binding of a key to attributes the 509 standard has at least
2 ways to do this. One is to include the attributes of interest 
in a public-key certificate in the subjectDirectoryAttributes extension.
If, however you want to use the more flexible approach of assigning
attributes
through attribute certificates, then there are 3 ways to identify the 
holder of the attribute certificate. One of those is to identify the user
with the baseCertificateID component that points directly to a specific 
public-key certificate for that user. If this mechanism is used, that 
means that in order for the holder to use the privileges assigned in 
the attribute cert, they must be authenticated using the indicated
public-key 
certificate (the user's DN can optionally also be present in order to help 
the verifier locate that public-key certificate). There are some other
interesting 
PMI extensions as well including one that allows the issuer of the attribute

certificate to indicate the certificate policies that are the only
acceptable 
ones for the associated public-key certificate used for authentication. So
there 
are mechanisms for relating the use of attribute certs for authorization
with the 
PKI used for authentication.

In 2459, the use of CRL (I believe) applies to two cases. In one instance it
is the 
full and complete CRL (including all revocation noticies for all certs of
all types 
issued by a CA) and in the other case it equates to what 509 defines as an
EPRL (End-
Entity Public-key Certificate Revocation List). The 2459 use of ARL equates
to 
the 509 CARL (Certification Authority Revocation List). 

509 also defines AARL and ACRL for the equivalent in the attribute cert
space.

As for the issuance of a single CRL that contains both revocation notices
for public-key 
and for attribute certs, 509 does allow this as well. In the reasonCode
extension (8.5.2.2) and in the cRLDistributionPoints extension (8.56.2.1)
you'll find that we added 2 new reasons (privilegeWithdrawn and
aaCompromise) to the existing set, so a CRL can cover any combination of
reason codes. In the crlScope (8.5.2.5) extension you'll find 
that we use the term "authority" rather than CA so that could inclode both.
In the issuingDistributionPoint extension (8.6.2.2) there are now
onlyContainsUserCerts, onlyContainsAuthorityCerts and
onlyContainsAttributeCerts, so all combinations are 
permitted. 

Cheers,
Sharon  

Hope that helps
Sharon

> Sent: Wednesday, April 25, 2001 5:28 PM
> To: [email-masked]
> Cc: Sharon Boeyen; Peter Williams
> Subject: RE: cA flag and CRL issuers (was Re: Last Call: 
> draft-ietf-pkix