Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments

[Russ Housley <rhousley@xxxxxxxxxxxxxxx>]

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