[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
I thought it was clearer first time! But its still ok.
Stephen.
Russ Housley wrote:
>
> Tim Polk and I just got off the phone. After a lengthy discussion, we
> propose a revision to the cRLSign discussion:
>
> The cRLSign bit is asserted when the subject public key is used
> for verifying a signature on revocation information (e.g., a CRL).
> This bit MUST be asserted in CA certificates that are used to
> verify signatures on CRLs. If the cRLSign bit is asserted in a CA
> certificate, then the cA bit in the basic constraints extension
> (see 4.2.1.10) MUST also be asserted. If the cRLSign bit is
> asserted in a non-CA certificate, then the cA bit in the basic
> constraints extension MUST NOT be asserted. Such non-CA
> certificates MUST NOT be used to verify signatures on CRLs
> containing revocation information for public key certificates;
> however, these non-CA certificates MAY be used to verify
> signatures on CRLs containing revocation information concerning
> other types of certificates (e.g., attribute certificates). If
> neither the cRLSign bit nor the keyCertSign bit are asserted, then
> the cA bit in the basic constraints extension MUST NOT be
> asserted.
>
> Hey, this section was only one sentence in RFC 2459...
>
> Please let us know if anyone has any remaining concerns.
>
> Russ
>
> At 09:25 AM 4/18/2001 -0400, Russ Housley wrote:
> >Based on this discussion, I think that the working group wants the
> >keyCertSign and cRLSign key usage text to read as follows:
> >
> > The keyCertSign bit is asserted when the subject public key is
> > used for verifying a signature on public key certificates. This
> > bit MUST 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 neither the
> > cRLSign bit nor the keyCertSign bit are 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 certificate revocation lists (CRLs).
> > This bit MUST only be asserted in CA certificates and Attribute
> > Authority (AA) certificates. If the cRLSign bit is asserted in a
> > CA certificate, then the cA bit in the basic constraints extension
> > (see 4.2.1.10) MUST also be asserted. If the cRLSign bit is
> > asserted in an AA certificate, then the cA bit in the basic
> > constraints extension MUST NOT be asserted. If neither the
> > cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> > in the basic constraints extension MUST NOT be asserted.
> >
> >Let me know if you disagree.
> >
> >Russ
> >
> >At 02:31 PM 4/17/2001 +0100, Stephen Farrell wrote:
> >
> >>I'd also go along with Jim here - that an AA be allowed to
> >>have cRLSign set without having cA set in basicConstraints,
> >>i.e. that AA's be an exception to the general rule for EE's
> >>and that this be explicitly called out in son-of-2459. I'm
> >>assuming that keyCertSign is therefore not set for AA's too
> >>(and the text for keyCertSign shouldn't say "certificates",
> >>but "public key certificates").
> >>
> >>Stephen.
> >>
> >>Jim Schaad wrote:
> >> >
> >> > Russ,
> >> >
> >> > > -----Original Message-----
> >> > > From: Russ Housley [mailto:rhousley@xxxxxxxxxxxxxxx]
> >> > > Sent: Monday, April 16, 2001 10:33 AM
> >> > > To: jimsch@xxxxxxxxxx
> >> > > Cc: ietf-pkix@xxxxxxx
> >> > > Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> >> > >
> >> > >
> >> > > Jim:
> >> > >
> >> > > >1. As currently written in section 4.2.1.3, it is not
> >> > > possible for a non-CA
> >> > > >CRL issuer to be created for attribute certificates. Was
> >> > > this the final
> >> > > >resolution of this issue? This seems to me to be
> >> > > problematic as it means as
> >> > > >an end-user one can issue an attribute certificate, but one
> >> > > must always use
> >> > > >a different agent, which is a CA, to issue the CRLs. This
> >> > > means that all
> >> > > >attribute CRL issuers are indirect.
> >> > >
> >> > > I do not recall a consensus on this point. Should an AA that
> >> > > supports CRLs
> >> > > have the cRLSign bit set in its public key certificate? If
> >> > > so, this text
> >> > > must change.
> >> >
> >> > I don't recall anything except private discussions on this issue. It is
> >> > here for the mailing list to comment on.
> >> >
> >> > It is my option that an AA that supports CRLs SHOULD have the cRLSign bit
> >> > set. Either that or we ask X509 to create AACertSign and AACrlSign
> >> bits and
> >> > keep this current text as is.
> >> >
> >> > >
> >> > > >2. Section 4.2.1.3, paragraph last: Current Text: "set in
> >> > > An instantiation"
> >> > > >modify to "set in an instantiation".
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >4. Section 6.2 paragraph 2: The text "For example, an
> >> > > implementation may
> >> > > >specify name constraints that apply to a specific trust
> >> > > anchor." is diffcult
> >> > > >for me given that the validation algorithm explicitly states
> >> > > that name
> >> > > >constraints are not applied to self signed certificates. Suggest "For
> >> > > >example, an implemenation may modify the algorithm to apply
> >> > > name constaints
> >> > > >during the initialization phase."
> >> > >
> >> > > Self-signed certificates are a common mechanism for
> >> > > distributing public
> >> > > keys for trust anchors, but they are not a mandated
> >> > > mechanism. That said,
> >> > > I think that your text it an improvement. How about a hybrid:
> >> > >
> >> > > For example, an implementation MAY modify the algorithm
> >> > > to apply name constraints to a specific trust anchor
> >> > > during the initialization phase.
> >> >
> >> > I have no problems with this new text.
> >> >
> >> > >
> >> > > >5. ASN module:
> >> > > >part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
> >> > > >referenced
> >> > >
> >> > > Agree. I removed it.
> >> > >
> >> > > Russ
> >> > >
> >> > >
> >> >
> >> > jim
> >>
> >>--
> >>____________________________________________________________
> >>Stephen Farrell
> >>Baltimore Technologies, tel: (direct line) +353 1 881 6716
> >>39 Parkgate Street, fax: +353 1 881 7000
> >>Dublin 8. mailto:stephen.farrell@xxxxxxxxxxxx
> >>Ireland http://www.baltimore.com
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:stephen.farrell@xxxxxxxxxxxx
Ireland http://www.baltimore.com