[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
Al,
I've only been skimming the arguments on this topic, but I believe there is significant merit in allowing local control over CRLs, e.g., by the relying party's organization, who may be in a better position to know whether or not to TRUST a certificate, for all that implies, than the CA that originally issued it. This local control option should not necessarily force the CRL issuer to be a CA, and even if they were one, they would not necessarily have issued the certificate in question.
Obviously, allowing some organization other than the issuing CA to publish CRLs could raise some havoc if the trust relationships were not properly managed. But I believe that that can be accomplished by proper management of the trusted root of that CRL issuer within the relying party software.
The same philosophy, of allowing local control of trust on behalf of the relying party's organization, would also apply to OCSP, of course.
So I would vote for option B.
Bob
Robert R. Jueneman
Security Architect
Novell, Inc -- the leading provider of Net services software
>>> "Al Arsenault" <awa1@xxxxxxxx> 05/21/01 07:52PM >>>
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" <david.cooper@xxxxxxxx>
To: "Hal Lockhart" <hal.lockhart@xxxxxxxxxxxxx>
Cc: <ietf-pkix@xxxxxxx>
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:
>
> 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
>
> At 12:52 PM 5/21/01 -0400, Hal Lockhart wrote:
> >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
>
>
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Bob Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell Inc. -- the leading provider of Net services software;DS eBusiness Solutions
TEL;PREF;FAX:01-801/861-2522
EMAIL;WORK;PREF;NGW:BJUENEMAN@xxxxxxxxxx
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;;Novell, Inc.\n1800 South Novell Place\n;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah 84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah 84606
END:VCARD
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell, Inc.;DS eBusiness Solutions
TEL;PREF;FAX:01-801/861-2522
EMAIL;WORK;PREF;NGW:BJUENEMAN@xxxxxxxxxx
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah 84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah 84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
END:VCARD