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

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

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

The point that I think is a bit different is the use of the CA bit in basic constraints. This is one of many 'business controls' that a CA can put into a certificate that it issues to another CA to restrict the set of paths (including that certificate) that can be successfully validated. In my mind this extension exists so that a relying party can know whether the certificate they are processing is one that certifies a key that can be used to verify the signature of the next cert in the path. Full stop. It isn't an 'authorization' of any entity to issue certificates but a signal to the relying party that the certified key can be used for verifying the next signature. The pathLengthConstraint component of that extension, along with all the other business control extensions (policy stuff, name constraints etc) further retrict a relying party with respect to the certification paths (and contained certificates) that can be successfully validated using the certificate that contains the extensions. Each issuer has the ability to place such restrictions and the complete validation of the path depends, in part on those constraints.  

 

When we look at the two basic trust models (hierarchical and distributed), then this does get muddled somewhat, because in a hierarchy there is sort of a sense of 'authorization' of subordinate CAs. The same is not true in a distributed trust model. A CA is any entity that issues public-key certificates regardless of whether some other CA happens to have issued it a certificate containing the basic constraints extension with the CA bit set to true. The extension really only matters when one tries to validate a certification path and needs to be sure that the issuer of a particular certificate 'trusts' certificates signed with the key corresponding to that certified in the current certificate.

 

Consider the above 2 paragraphs my personal opinion on basicConstraints.

 

As for attribute certificates and attribute authorities, in some environments there is absolutely no need to tie the PMI to the PKI. The verifiers may import one or more trust anchors for SOAs, similar to how they do today for PKI trust anchors. However, in other environments, there was a requirement to have a single trust anchor and be able to validate both public key and attribute certificates. For this reason, X.509 added the sOAIdentifier extension. Its syntax is NULL. Its only purpose in life is to support this requirement of binding a PMI to a PKI.  As for the attribute certificate 'equivalent' of a certification path, this is a delegation path. There are completely different extensions defined to ensure that a delegationPath is valid (although you will recognize similarities). basicAttConstraints inidicates whether or not the assigned privilege can be further delegated by the subject of the containing certificate. 'Business controls' extensions include delegatedNameConstraints, acceptableCertPolicies, authorityAttributeIdentifier (to ensure that the delegating authority actually holds sufficicient privilege to delegate it) etc). Don't try to shoehorn the PKI extensions into the PMI model. The only real overlap is that we reused the basic CRL structure.

 

Hope that helps and doesn't confuse the issues further :-)

 

Sharon

 

 -----Original Message-----
From: Jim Schaad [mailto:jimsch5@xxxxxxxx]
Sent: Friday, April 20, 2001 2:08 PM
To: 'Sharon Boeyen'; ietf-pkix@xxxxxxx
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)

Sharon,

 

Much of this question arose from how to deal with AC "authorities".  I don't have access at the moment to the X. version of the AC draft (yes I know I can now get it), but do you believe that AC issuers and "revokers" need to be authorities in that the CA bit should be set for them?

 

jim

-----Original Message-----
From: Sharon Boeyen [mailto:sharon.boeyen@xxxxxxxxxxx]
Sent: Friday, April 20, 2001 9:57 AM
To: 'David A. Cooper'; ietf-pkix@xxxxxxx
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)

Just to be clear, lets not confuse what I may happen to want as
an individual contributor to PKIX or any other list, with what
I state as 509 editor (they're not necessarily always the same :-)

My comments were purely from the editor's perspective and yes,
the current 509 text is quite clear that the CA that issues a
certificate is responsible for stating whether or not that certificate
can be revoked, and if so, what mechanism is used to inform
relying parties. If that mechanism is CRLs, these are issued by
the certificate issuer or by another authority delegated that
task by the certificate issuer (that doesn't necessarily mean that
509 requires a cert to be issued to that authority, nor that the cert
contain the basic constraints extension though, that is the job of
profile groups to determine and incidentally I don't believe they'll
all adopt the same solution so I would want 509 to remain flexible).

My own personal view is that industry has moved to a point where there
probably isn't any real requirement for a CRL issuer to also be a cert
issuer as long as that CRL issuer is delegated that responsibility
by the cert issuer and there is a cryptographic way to ensure that
binding for relying parties. To achieve that, I believe some changes
are required in 509.

On the separate keys for cert and CRL signing (by the same authority), my
personal opinion is that anything you read into 509 text on that specific
topic would be accidental as I don't recall any specific discussion on it.
However, since that is a real world requirement, I would want to be sure
that 509 did not prohibit it.

Hope that clarifies where my comments are coming from :-)
   

> -----Original Message-----
> From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
> Sent: Friday, April 20, 2001 11:44 AM
> To: ietf-pkix@xxxxxxx
> Subject: RE: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-n ew-part1-06.txt comments)
>
>
> Sharon,
>
> Are you suggesting that in order for an entity to issue CRLs
> on behalf of a certificate issuer, that CRL issuer would need
> to issue certificates as well (so that it can qualify as an
> authority)?  I don't think there should be such a
> requirement, but even if there were it wouldn't settle the issue.
>
> Even if only authorities can issue CRLs, there is nothing to
> prevent that authority from using different keys to sign
> certificates and CRLs.  X.509 states that "[t]he cA component
> indicates if the certified public key may be used to verify
> certificate signatures."  So, the proper value of the cA bit
> is determined by the allowable uses of the subject public
> key, not by the type of entity the subject is.  So, even if
> the certificate subject is a CA, and issues certificates
> under some key, the cA bit should not be set unless the
> particular subject public key in the certificate can be used
> to verify certificate signatures. If an authority is the
> subject of a certificate and the particular public key of
> that authority that is being certified is only to be used to
> verify signatures on CRLs, then the cA bit should not be set.
>
> Dave
>
> At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:
>
> >David, sorry but I disagree with your assertions about X.509's
> >position on this issue. Either by design or by accident,
> X.509 requires that if CRLs are being issued, they are issued
> by an 'authority'. Remember that the definition of
> "authority" is "An entity responsible
> >
> >for the issuance of certificates". Much of the text in X.509
> predates OCSP or the concept of a validation authority, but I
> do know that the quotes below are new text added within the
> past couple of years with the intent of clarifying the role
> of CAs with respect to CRLs.
> >
> >Clause 7.3 says: 
> >
> >"An authority that issues certificates is required to state,
> possibly through a published statement of their practices,
> through the certificates themselves, or through some other
> identified means, whether:
> >
> >-       The certificates cannot be revoked; or
> >-       The certificates may be revoked by the same
> certificate-issuing authority directly; or
> >-       The certificate-issuing authority authorizes a
> different authority to perform revocation."
> >
> >further down in the same clause is the text:
> >
> >"
> >An authority that issues and subsequently revokes certificates:
> >a)      may be required to maintain an audit record of its
> revocation events for all certificate types issued by that
> authority (e.g. public-key certificates, attribute
> certificates issued to end-entities as well as other authorities);
> >
> >b)      shall provide revocation status information to
> relying parties using CRLs, on-line certificate status
> protocol or some other mechanism for the publication of
> revocation status information;
> >
> >c)      if using CRLs, shall maintain and publish CRLs even
> if the lists of revoked certificates are empty."
> >
> >The quotes that you included in your message tie in with
> this base text, since the authority that issued the
> certificates has these responsibilities around revocation,
> there was no need for X.509 to state anything specific to CRL
> issuance. In the indirect CRL case, this was envisioned to be
> another CA or AA, that combined revocation notices from
> several CAs/AAs.
> >
> >Having said that (with my X.509 editor's hat on), if there
> is a requirement to have entities that are not CAs or AAs be
> authorized to issue CRLs on behalf of the certificate issuer
> (because remember that a CRL is an indication that a
> certificate is no longer considered valid "by its
> issuer")changes to X.509 would be needed. I'm not necessarily
> opposed to such changes, I'm just clarifying, in this
> message, that they would be needed in order for such
> implementations to be conformant. This, as usual could be
> done through the enhancements work or could be proposed
> through the defect process. One way to enable that kind of
> change might be to redefine authority and to talk about 3
> types rather than two. However, it would take some careful
> review to ensure that the set of changes was thorough and complete.
> >
> >Sharon
> >
> > > -----Original Message-----
> > > From: David A. Cooper
> [<mailto:david.cooper@xxxxxxxx>mailto:david.cooper@xxxxxxxx]
> > > Sent: Thursday, April 19, 2001 5:08 PM
> > > To: ietf-pkix@xxxxxxx
> > > Subject: cA flag and CRL issuers (was Re: Last Call:
> > > draft-ietf-pkix-new-part1-06.txt comments)
> > >
> > >
> > > At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
> > > >Dave Cooper,
> > > >
> > > >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
> > > >>I see no basis in X.509 for setting the cA flag in
> > > basicConstraints for certificate subjects that can issue CRLs
> > > but not certificates. The current discussion about how to
> > > deal with CRLs for attribute certificates vs. public key
> > > certificates just further goes to show that it was a mistake
> > > to suddenly change the rules at the last IETF meeting.
> > > >
> > > >We disagree on this point. Nowhere in X.509 or in previous
> > > PKIX documents has there ever been text to suggest that other
> > > than a CA can sign a CRL for a public key certificate. So,
> > > the rules were not changed at the last meeting, they were
> > > reasserted and clarified.
> > >
> > > Steve,
> > >
> > > You may say that X.509 and PKIX do not suggest that entities
> > > other than CAs can sign CRLs. However, I think we all agree
> > > that both X.509 and PKIX allow for a CRL to be signed with a
> > > different key than the key used to sign the certificates that
> > > are covered by that CRL. This may be a result of the CA that
> > > issued the certificates signing the corresponding CRLs with a
> > > different key or the CA that issued the certificates
> > > delegating the CRL issuing to another entity (via the
> > > distribution points extension). There is no requirement that
> > > the key used to sign the CRL also be used to sign
> > > certificates. So, I think we agree that there will be times
> > > where we will be issuing certificates to entities (whether
> > > those entities are CAs or not) where the intent is to specify
> > > that the public keys in the certificates may be used to
> > > verify signatures on CRLs but not on certificates.
> > >
> > > The only place we seem to disagree is on the contents of the
> > > certificates issued in such circumstances. In particular,
> > > should the certificates contain a basicConstraints extension
> > > with the cA bit set? On this point, both X.509 and the
> > > previous PKIX documents are quite clear that the cA bit
> > > should not be set. Why? Because a CA is defined as an entity
> > > that issues public-key certificates and both documents
> > > similarly state that the cA bit is used to specify whether
> > > the certificate subject can issue certificates. There is no
> > > similar connection made between being a CA and issuing CRLs.
> > >
> > >
> > > The following are some quotes from X.509 and pkix-new-part1-05:
> > >
> > > In X.509 a CA is defined as "[a]n authority trusted by one or
> > > more users to create and assign public-key certificates."
> > >
> > > Section 7 of X.509 states that "[a] CA-certificate is a
> > > certificate issued by a CA to a subject that is itself a CA
> > > and therefore is capable of issuing public-key certificates."
> > >
> > >
> > > 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."
> > >
> > >
> > > The description of the key usage bits are consistent with
> > > this as well.
> > >
> > > X.509:
> > > "The bit keyCertSign is for use in CA-certificates only. If
> > > KeyUsage is set to keyCertSign and the basic constraints
> > > extension is present in the same certificate, the value of
> > > the cA component of that extension shall be set to TRUE."
> > >
> > > pkix-new-part1-05:
> > > "The keyCertSign bit is asserted when the subject public key
> > > is used for verifying a signature on certificates.  This bit
> > > may only be asserted in CA certificates.  If the keyCertSign
> > > bit is asserted, then the cA bit in the basic constraints
> > > extension (see 4.2.1.10) MUST also be asserted. If the
> > > keyCertSign bit is not asserted, then the cA bit in the basic
> > > constraints extension MUST NOT be asserted.
> > >
> > > The cRLSign bit is asserted when the subject public key is
> > > used for verifying a signature on revocation information
> > > (e.g., a CRL)."
> > >
> > >
> > >
> > > So, both X.509 and pkix-new-part1-05 go to great lengths to
> > > clearly state that only CAs can issue certificates and that
> > > basicConstraints with the cA bit set to true must be present
> > > in the certificates where the public key is to be used to
> > > verify signatures on certificates. There are no similar
> > > statements about CRLs. In fact, both documents are quite
> > > clear that the cA bit must not be set when the subject public
> > > key can not be used to verify certificates. So, if the
> > > subject public key can be used to verify CRLs, but not
> > > certificates, the cA bit must not be set.
> > >
> > > X.509 is also careful not to preclude the public keys of
> > > non-CAs from being used to verify signatures on CRLs. For
> > > instance, an end entity is defined as "[a] certificate
> > > subject that uses its private key for purposes other than
> > > signing certificates or an entity that is a relying party."
> > > This leaves room for an end entity to use its private key to
> > > sign CRLs.
> > >
> > >
> > > So, if PKIX wants to require that the cA bit be set whenever
> > > the subject public key can be used to verify CRLs and also
> > > wants to maintain consistency with X.509, PKIX would have to
> > > require that any certificate authorizing the use of a public
> > > key for verifying CRL signatures also authorize the use of
> > > that public key for verifying certificate signatures. Since
> > > we are in agreement that we do not want to impose such a
> > > restriction and that we do want to maintain consistency with
> > > X.509, we can not require that the cA bit be set when the
> > > subject public key can only be used to verify CRL signatures.
> > >
> > > Dave
> > >
> > >
>
>