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

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

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