Hi Tom,
Quite honestly I think the text for the schema was written when we all envisioned
CAs issuing CRLs for the certificates they issued. Anything else (like indirect or
non CA issuers) wasn't at the forefront of our minds when we labored over that text.
That was such a long long long debate that when we reached words that nobody objected
strongly to, I think we were all just happy to have it done. We focused so much on the
which certs go where between self issued and non self-issued that CRL signing was
not a key contributor to at least my thought process :-( I suspect that needs revisting.
Sharon
> -----Original Message-----
> From: Tom Gindin [mailto:tgindin@xxxxxxxxxx]
> Sent: Thursday, April 26, 2001 10:01 AM
> To: Sharon Boeyen
> Cc: 'Tony Bartoletti'; David A. Cooper; ietf-pkix@xxxxxxx
> Subject: RE: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments)
>
>
>
> Thanks for clearing that up. On a related subject, do
> self-issued
> (i.e. having the same issuer and subject name, but not self-signed)
> CRL-signing certificates get published in the directory's
> caCertificate
> attribute or the userCertificate one? How about other
> certificates issued
> with the same subject DN as the CA certificate?
>
> Tom Gindin
>
>
> Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx> on 04/25/2001 03:34:33 PM
>
> To: "'Tony Bartoletti'" <azb@xxxxxxxx>, "David A. Cooper"
> <david.cooper@xxxxxxxx>, ietf-pkix@xxxxxxx
> cc:
> Subject: RE: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix
> -new-part1-06.txt comments)
>
>
> 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:azb@xxxxxxxx]
> > Sent: Wednesday, April 25, 2001 2:54 PM
> > To: David A. Cooper; ietf-pkix@xxxxxxx
> > 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 <azb@xxxxxxxx>
> > Information Operations, Warfare and Assurance Center
> > Lawrence Livermore National Laboratory
> > Livermore, CA 94551-9900
> >
> >
> >
> >
>
>
>