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

From: Hal Lockhart <[email-masked]>
Date: Mon, 21 May 2001 12:52:16 -0400

David P. Kemp wrote:
> I certainly agree that the intent of X.509, from v1 to the 
> present, was
> that a CA entity is the ultimate and sole authority for revoking the
> certificates that it issues.

I think that at least part of this debate stems from different views of
exactly what constitutes an "entity". I believe the following are implied in
messages from different people:

1. a key
2. a DN
3. a legally constituted organization

Hal

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 21 May 2001 18:25:42 -0400

Hal,

I believe the debate really stems from different ways of determining the meaning of the cA field in basicConstraints. I believe the meaning of the field should be taken from section of the document that describes the basicConstraints extension (section 8.4.2.1 in X.509 4th edition). This section states:

         The cA component indicates if the certified public key may be used to verify certificate signatures

This text clearly supports the position of David Kemp and I (and others).

I do not know the basis for argument that the cA field should be set to TRUE if the subject public key may only be used to sign CRLs, but my best guess is that the argument is as follows:

         1) The introductory (and other) material in the document states that only CAs can issue CRLs

         3) Since there is a requirement that only CAs can issue CRLs, there must be some way for
             relying parties to verify that the signer of a CRL is a CA.

         2) In the basicConstraints extension, there is a field of type boolean named cA. Based on the
             name of this field, this bit must be an indicator of whether the subject of the certificate is
             is CA. (As I stated above, this is only my guess at the reasoning. Given that in order to
             conclude that this is the proper interpretation of the bit one must ignore the text that explicitly
             describes the meaning of the bit, it is possible that I am misinterpreting the argument.)

         4) Since the cA field indicates whether the subject is a CA and the signer of a CRL must be a
             CA, the cA field must be set to TRUE if the subject public key is to be used to sign CRLs.

I think we are all willing to accept the notion that only CAs can issue CRLs. However, that simply means that

         1) A certificate may only contain a keyUsage extension with the cRLSign bit set, if the subject of
             the certificate is a CA.

         2) If a certificate contains a cRLDistributionPoints extension and the cRLIssuer field is present,
             the entity named in the cRLIssuer field must be a CA.

However, the cA field in basicConstraints should only be set if the subject public key may be used to verify signatures on certificates. The text in the standard clearly states that this is a meaning of the bit. Perhaps naming the field "cA" has led to some confusion, with some people assigning semantics to the field based on the name. But the semantics of the cA field in basic constraints must be based on the stated description of the field ("The cA component indicates if the certified public key may be used to verify certificate signatures"), not on the field's name.

Dave

---

From: "Al Arsenault" <[email-masked]>
Date: Mon, 21 May 2001 21:52:18 -0400

Okay, I think that we've reached consensus that the text in the current
documents (X.509 and offspring-of-2459) is wrong.  It's inconsistent, as
cited by Dave Cooper below.

Now, what's the best way to fix it?

Do we:

    (a) decide that only CA's can sign CRLs; that CA's are determined by the
value of the basicConstraints extension; that CA's who sign CRLs but not
certificates need not have the keyCertSign bit set in KU, and that that
section 8.4.2.1 in X.509 and corresponding text in offspring-of-2459 needs
to be fixed?

    (b) decide that non-CA's of some stripe can sign CRLs, and fix all of
the text in X.509 and offspring-of-2459 that needs to be fixed?

    (c) something else?

Clearly, leaving the text in the documents as it stands now is unacceptable;
I think we all agree that it's wrong.

So, what will it be?

Personally, if we were voting, I'd vote for (a) above, but that's just my
preference and there's probably some hanging chads around here...

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

----- Original Message -----
From: "David A. Cooper" <[email-masked]>
To: "Hal Lockhart" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 21, 2001 6:25 PM
Subject: RE: cA flag and CRL issuers (was Re: Last Call:
draft-ietf-pkix-new-part1-06.txt comments)

> Hal,
>
> I believe the debate really stems from different ways of determining the
meaning of the cA field in basicConstraints. I believe the meaning of the
field should be taken from section of the document that describes the
basicConstraints extension (section 8.4.2.1 in X.509 4th edition). This
section states:
> I do not know the basis for argument that the cA field should be set to
TRUE if the subject public key may only be used to sign CRLs, but my best
guess is that the argument is as follows:
> However, the cA field in basicConstraints should only be set if the
subject public key may be used to verify signatures on certificates. The
text in the standard clearly states that this is a meaning of the bit.
Perhaps naming the field "cA" has led to some confusion, with some people
assigning semantics to the field based on the name. But the semantics of the
cA field in basic constraints must be based on the stated description of the
field ("The cA component indicates if the certified public key may be used
to verify certificate signatures"), not on the field's name.

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 22 May 2001 09:35:13 -0400

Al,

The problem with (a) is that *not* only CAs can sign CRLs.  The discussion
has lasted so long because of a proposal to expand the description of
the keyUsage extension from one sentence to six.
Tim proposed a rule whereby cRLSign could be used to verify CRLs containing
PK certificates ONLY if cA is true, and cRLSign could be used to verify
CRLs containing Attribute Certificates ONLY if cA is false.

There are two problems with this - 1) it is unnecessarily complex: keyUsage
and issuer name or CRLDP are sufficient to link the issuer of a certificate
with the CRL which can revoke it, and 2) it needlessly prohibits a CA from
issuing attribute certificates.  (The AC profile currently does prohibit
CAs from being AAs, but if we want that prohibition, it should be an
explicit statement in the AC profile, not a side effect of processing
rules for the keyUsage and basicConstraints extensions.)

The answer is (c):  Only the issuer of a certificate (CA or AA) is responsible
for signing the CRLs that apply to that certificate.  That responsibility
can be exercised directly by using the same public key to sign the cert
and CRL, or indirectly by issuing a cRLSign certificate for the public
key used to sign the CRL.

The cA bit tells you nothing about who is entitled to revoke a
certificate: VeriSign can't revoke Cybertrust certificates
even though it is a CA.  Using the cA bit in the rules for
CRL processing adds no value, it adds only needless confusion.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 22 May 2001 13:01:53 -0400

I really don't think the issue of whether a non-CA can issue a CRL is important. We all agree that it is permissible for an entity that does not issue certificates to issue CRLs . I personally don't care if such an entity is called a certification authority, a revocation authority, or a french fry.

However, if we do decide that only CAs can issue CRLs, then the definition of CA should be changed, since X.509 currently defines a CA as an entity that issues public key certificates. (X.509 similarly defines an authority as an entity that issues either public key or attribute certificates). If we decide that non-CAs can issue certificates, then it appears that some of the text needs to be cleaned up to make that clear.

What I consider to be far more important than the name we assign to a CRL issuing entity are the certificate generation and processing rules. Here I believe the standard is quite clear. X.509 states that:

         The cA component [of basicConstraints] indicates if the certified public key may be
         used to verify certificate signatures.

There is nothing in the description of the cA component that even suggests that this field indicates whether the certificate subject is a CA. Certainly, the subject must be a CA if cA is set to TRUE, since by definition an entity that signs public key certificates is a CA. However, it is possible for a CA to be the subject of a certificate in which the subject public key is not intended to be used to verify signatures on certificates. It could be that the subject public key is only to be used to verify signatures on S/MIME messages or CRLs. In such a case, the subject of the certificate would be a CA, but cA would be set to FALSE.

It may be useful to agree on a term for entities that issue CRLs but not certificates, if this would help to make the overview material in the standards more clear. However, there is no reason that the outcome of such a decision should have any effect on either the certificate generation or certificate processing rules. The value of the cA bit in basicConstraints is determined by keyUsage, not by the type of entity that the certificate subject is. As has already been stated several times, there are no security issues here. It is simply a matter of ensuring that the certificate generation and processing rules are clear and consistent.

Dave

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 22 May 2001 13:44:24 -0400

Dave,

----- Original Message -----
From: "David P. Kemp" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 22, 2001 9:35 AM
Subject: Re: cA flag and CRL issuers (was Re: Last Call:

> CRLs containing Attribute Certificates ONLY if cA is false.

AWA:  Let's accept your premise - that not only CA's can sign CRLs.  I can
actually live with this, if it reflects the wishes of this group.  However,
if that's the consensus, then offspring-of-2459 is going to require heavy
editing.  I took a quick 10-minute scan through
<draft-ietf-pkix-new-part1-06.txt>, and identified the following areas which
must be changed, at a minimum:

    - Section 3.3 - revocation - which says CA's issue CRLs.  It will have
to describe other entities that can sign CRLs.

       Section 4.2.1.3, p. 30:  Obviously, the section on the keyUsage
extension will have to be cleaned up.

       Basically, all of Section 5 will have to be rewritten.  It currently
imposes requirements only on CA's who issue CRLs.  There are no requirements
imposed on other, non-CA entities who sign CRLs.  For example, the intro to
Section 5; the second paragraph of Section 5.1.1.3., etc.

My personal bottom line is this:  the document says explicitly in numerous
places that only CA's issue CRLs.  Now, if we're going to change that, we're
going to change the entire document so that it consistently covers those
entities that can sign CRLs.  I really do not want to be a party to some
semantic game (it took me 10 tries to find a phrase as inoffensive as
"semantic game" to use here :-) where we leave all the ancillary text the
way it is, and then say but no, really, non-CAs can sign CRLs, too.

And I would object also to a game where we declared a "CA" to be anybody who
had a cert with keyUsage = cRLSign, regardless of the value of
basicConstraints. (i.e., just because it doesn't have the CA bit set doesn't
mean it's not a CA.) That just strikes me as a lazy way of getting around a
problem, not a fix to the problem.

> key used to sign the CRL.

AWA:  And how exactly do you identify that separate certificate which is
authorized to sign CRLs?

> even though it is a CA.

AWA:  True, but irrelevant.

>Using the cA bit in the rules for

AWA:  Leaving the document the way it is does not solve the problem, it only
causes needless confusion!!!!

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

---

From: "Carlin Covey" <[email-masked]>
Date: Tue, 22 May 2001 12:12:59 -0700

I've been following this thread with some interest, and I thought
I'd interject a few observations:

1)  If only a CA can issue CRLs, and an Attribute Authority is not
a CA, then who is going to revoke an AA's Attribute Certificates?

2)  Perhaps there is no great significance to the fact that X.509
does not mention the CA bit in connection with verifying signatures
over CRLs.  It may simply reflect the earlier historical reality.
Once upon a time only the certificate issuer's certificate could
be used to verify the signature over the corresponding CRL.

3)  Why don't we just ask the good folks in the X.509 working group
what the current text in X.509 section 8.4.2.1 "Basic constraints extension"
is intended to mean with respect to CA bit and CRL signing?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 22 May 2001 17:26:53 -0400

> must be changed, at a minimum:  ...

Al,

Like David Cooper, I don't particularly care what you call entities that
can sign CRLs - it could be "CA or AA", "Authority", or "Revocation
Authority".  Cleaning up the text is a good idea, but it's not what
I'm focused on.

The MUST requirements for generating and receiving applications are what
I care about.  Those requirements should be as minimal as possible
without adversely affecting security.  In particular, a new requirement
that links the cA flag in basic constraints with the type of certificate
contained in the CRL is simultaneously baroque and incomplete.

> problem, not a fix to the problem.

Fine.  Your problem is getting the document to define "what do we call
the entities that sign CRLs", and I agree that there is a painful way
and a lazy way to fix it. I agree that the lazy way won't work, because
an AA must be able to revoke ACs without being called a "CA".  I don't
particularly object to leaving the ancilliary text the way it is, and then
say once "The authority to revoke any certificate rests with the issuer
of that certificate. CRLs can be signed by CAs, AAs, or their authorized
agents."

My problem is an application has a certificate X.  X could be anything;
it could belong to an EE, a CA, or an AA, and it could be a public key
certificate or an attribute certificate.  The application also has a CRL
signed by public key Y, and a certificate for public key Y with cRLSign
asserted. The application needs to decide if the CRL is valid and applies
to certificate X.

My position is that the application does not need to even look at the basic
constraints extension in the certificate for Y to determine whether the
CRL applies to certificate X.   

> AWA:  True, but irrelevant.

It is relevant because it demonstrates that the cA flag in basic
constraints is not sufficient to determine whether a CRL Z applies to
certificate X.

I don't need to specify the exact algorithm for identifying the CRL Z
(signed by Y) which applies to certificate X, or for identifying the
certificate for public key Y.  All I need to do is demonstrate that
the cA flag in the certificate for public key Y is irrelevant to that
algorithm.  The entity that signed the certificate for public key Y
has set the cRLSign bit.  There is no reason to either require or
prohibit it from also setting the cA flag in that certificate, and
there is no reason for an application to look at the cA flag in that
certificate when applying the CRL.

> AWA:  Leaving the document the way it is does not solve the problem, 
> it only causes needless confusion!!!!

These two statements are both true, but they refer to different
problems.  They are somewhat synergistic in that if you don't try
to differentiate and name all the kinds of entities that can sign
CRLs, then you don't need to assign meanings to those names.

IMO, "Revocation Authority", defined as the subject of a certificate
which has cRLSign asserted, is the only name we need to clean up the
document.

Dave

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 24 May 2001 16:03:50 -0400

>a CA, then who is going to revoke an AA's Attribute Certificates?

CAs issue public key certificates and they may issue CRLs associated with 
those public key certificates.

AAs issue attribute certificates and they may issue CRLs associated with 
those attribute certificates.

>be used to verify the signature over the corresponding CRL.

With X.509v3 certificates, we get increased flexibility and complexity.  I 
hope this thread is about the level of flexibility and complexity that we 
want to embrace in the Internet profile of X.509v3.  In many cases, we have 
reduced flexibility in order to achieve greater interoperability and 
simplicity.

>is intended to mean with respect to CA bit and CRL signing?

I think that Sharon has done a fine job in patiently representing the views 
as the editor of X.509.  Editors often represent and write the view of the 
overall group, even when they personally disagree with a particular 
detail.  I applaud her efforts.

Russ

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 24 May 2001 18:12:42 -0700

Thanks for answering my questions, Russ.  Socrates must have been better at
the method than I am.  ;>)  Let me try a more straightforward approach.

Some postings in this thread have stated that only CA's can issue CRL's.
'Tain't true.  As Russ says, Attribute Authorities can also issue CRL's.

Some postings in this thread have attached significance to the fact that
X.509 does not discuss whether the CA bit should be set when cRLSign is true
but keyCertSign is false.  I agree with you, Russ, that the discussion
should center on the level of flexibility and complexity that the PKIX
community want to embrace in its certificate and CRL profile, rather than
the nuances of text omissions in X.509.

I also agree that Sharon does a fine job in representing X.509's view.  I
understand that she is on vacation at the moment.

All that said, let me now second Santosh's proposal: "I vote for not
requiring the cA flag for CRL check and making appropriate changes to X.509
and to PKIX to make it clear and consistent."  - Santosh Chokhani, 24 May
2001

My rationale is this:  Attribute Authorities can issue CRL's.  Attribute
Authority certificates will not have the CA bit set.  So if we don't adopt
Santosh's proposal, the validation algorithm for CRL's will check for the CA
bit in the CRL issuer's certificate if the CRL issuer is a CA, but will not
check for the CA bit if the issuer is an Attribute Authority.  This doesn't
appear to add anything to the security, since having the CA bit set doesn't
mean that the CA is authoritative for status of the certificates on the CRL.
In both the CRL-issuer-is-CA case and the CRL-issuer-is-AA case the
validation algorithm must ensure that the CRL issuer is either the issuer of
the certificates on the CRL, or is a delegate of the issuer of the
certificates on the CRL.  So why bother checking the CA bit?

To streamline the algorithm a little further, I suggest that we ask X.509 to
allow the keyCertSign bit to be asserted in Attribute Authority
certificates, as well as CA certificates.  As far as I can see, that would
make the CRL validation algorithm identical for AA-issued and CA-issued
CRL's.

       "The bit keyCertSign is for use in CA-certificates only."
        - X.509 Ed. 4 v8, section 8.2.2.3 "Key usage extension"

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Housley, Russ
Sent: Thursday, May 24, 2001 1:04 PM
To: Carlin Covey
Cc: [email-masked]
Subject: RE: cA flag and CRL issuers

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 25 May 2001 09:09:15 -0400

> the nuances of text omissions in X.509.

Yes.

> understand that she is on vacation at the moment.

Yes!  It is exceedingly rare to find in one person her level of technical
understanding, fairness, and equanimity.  Thank you, Sharon. 

> and to PKIX to make it clear and consistent."  - Santosh Chokhani, 24 May

Yes.  However, for consistency you need a generation non-requirement
in addition to Santosh's recipient non-requirement:  I vote for not
requiring the cA flag for CRL generation or checking and for making
appropriate changes to X.509 and to PKIX to make them clear and consistent.

> make the CRL validation algorithm identical for AA-issued and CA-issued

No.  I support reserving the keyCertSign bit exclusively for use in
certificates of issuers of (public-) key certificates.

Regards,

Dave