[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)
Steve,
Santosh has stated that setting both the cA flag and the cRLSign
bit provides no security advantage over setting the cRLSign bit only.
Tom Gindin has said:
> Just BTW, my reasoning is similar to Santosh's. I would like to
> mention that the reasons for issuing a distinct CMP certificate for a CA
> are even stronger than those for a distinct CRL certificate. However, it
> is not obvious whether this should be classed as a CA certificate since a
> certificate to be used with CMP looks more like a standard server
> certificate.
Russ Housley has said:
> Dave:
>
> Your first two arguments seem to be compelling.
>
> Russ
>
> At 11:42 AM 4/30/2001 -0400, you [David Kemp] wrote:
> >
> >1) Previously, conforming clients could validate a CRL if the cRLSign
> > bit is asserted and the cA flag is not asserted. This change
> > would declare such clients to be non-conforming.
> >
> >2) [snip]
> > My position is that no additional flag is needed in either the CA or
> > the AA case. If the CRL signer has a valid certificate with the
> > cRLSign bit set, then it is an authority because the certificate
> > signer (or it's parent) has said so. Requiring two flags in the
> > same certificate is no more secure than requiring one.
Denis Pinkas has said:
> As far as I remember, originally the cA boolean in the basic constraints
> extension only allowed to make the difference between leaf certificates and
> CA certificates. This boolean now seems to be be used with a different
> meaning (and, maybe, we should change its meaning - not the syntax).
>
> Could someone say again, why that change was requested and
> what are the real benefits of that change ?
You have ignored David Cooper's point that the CA signs the certificate
containing the cRLSign bit, and therefore relying parties know
conclusively that a certificate with cRLSign asserted (and cA not
necessarily asserted) contains the public key that the CA uses to
sign CRLs. This is the semantic context that matters - as you say,
the CA is responsible for signing CRLs. The CA can unambiguously
designate the key RPs use to validate its CRLs by setting only the
cRLSign bit in a self-issued certificate.
I believe it is time for you to call for a straw poll on whether
to make extensive changes to the texts of PKIX and X.509 to
require the cA flag to be set in certificates used to validate CRLs
By my count, at least 5 people believe there is no need for such
a change:
Santosh Chokhani
David Cooper
Denis Pinkas
Russ Housley
Dave Kemp
I have not heard from Tim Polk since Russ' conversion :-), and I can't
determine a position from postings by Tom Ginden and Sharon Boeyen.
Dave
----------------- Begin Included Message ---------------------------
> Date: Tue, 15 May 2001 18:45:26 -0400
> To: "David A. Cooper" <david.cooper@xxxxxxxx>
> From: Stephen Kent <kent@xxxxxxx>
> Subject: Re: cA flag and CRL issuers (was Re: Last Call:
draft-ietf-pkix-new-part1-06.txt comments)
> Cc: ietf-pkix@xxxxxxx
>
> Dave,
>
> I provided an analysis of the evolution of CRL signing from V1 + V2
> certs, to the changes you cite re V3 certs. You have chosen to
> ignore large parts of this analysis, and focus on text in the current
> version of X.509 that emphasizes syntactic details but not the larger
> semantic context. You have not adressed the fact that both X.509 and
> RFC 2459 make repeated references to "authorities" or CAs re CRL
> issuance. You have received feedback from Sharon, and I think several
> of the 2459 authors have weighed in on this topic during the
> multi-week debate.
>
> I see no point in continuing the discussion.
>
> Steve