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

["Jim Schaad" <jimsch5@xxxxxxxx>]

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