[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Part1 last call comments




> -----Original Message-----
> From: Russ Housley [mailto:housley@xxxxxxxxxx]
> Sent: Thursday, March 01, 2001 2:51 PM
> To: ietf-pkix@xxxxxxx
> Subject: Re: Part1 last call comments
>
>
> All of these comments deal with the ASN.1 modules in
> draft-ietf-pkix-new-part1-04.txt and
> draft-ietf-pkix-ipki-pkalgs-01.txt.  Jim Schaad posted some comments
> earlier, but I do not completely agree with his resolutions.  I will
> address those second.  First, I want to raise a two things
> that were not
> raised in Jim's message.
>
>   1.  AuthorityKeyIdentifier is defined as:
>
>     AuthorityKeyIdentifier ::= SEQUENCE {
>        keyIdentifier             [0] KeyIdentifier           OPTIONAL,
>        authorityCertIssuer       [1] GeneralNames            OPTIONAL,
>        authorityCertSerialNumber [2] CertificateSerialNumber
> OPTIONAL  }
>
>     KeyIdentifier ::= OCTET STRING
>
> There is nothing wrong with this ASN.1; however, at least one
> compiler
> wants either "EXPLICIT" or "IMPLICIT" to be inserted before
> CertificateSerialNumber.  Obviously, only one of these is
> correct.  The
> problem in the compiler seems to come from the fact that
> CertificateSerialNumber is imported from the explicit module.
>
> The same compiler would like "EXPLICIT" or "IMPLICIT" to be
> inserted before
> uses of ORAddress, Name, DirectoryString, and
> RelativeDistinguishedName.
>
> A programmer must know a fair amount about ASN.1 to know the
> correct type
> of tagging in each case.  To avoid implementation errors from
> anyone that
> might use that tool, should we make the insertion?  My
> initial reaction is
> that anyone who uses a tool with such shortcomings must edit
> the module to
> overcome them.  I think that preserving alignment with X.509 is
> important.  However, I think we should make sure that the example
> certificate includes these cases to help implementors catch
> mistakes early
> in the development process.

I agree with Russ that the ASN.1 is correct and we should not "fix" it for a
broken tool.

> ...
> >7. Section A.1
> >                    id-domainComponent      AttributeType ::=
> > id-domainComponent
> >      replace with
> >                    id-domainComponent      AttributeType ::=
> > id-domainComponent }
>
> I do not think that this is the correct change.  The document says:
>
>          id-domainComponent     OBJECT IDENTIFIER  ::=
>                                              { 0 9 2342
> 19200300 100 1 25 }
>
>          id-domainComponent      AttributeType ::= id-domainComponent
>          domainComponent ::=     IA5String
>
> I think the middle statement should be deleted altogether.
> Also, the last
> line must begin with a capital letter ("domainComponent" becomes
> "DomainComponent").

Deleting the middle statement is acceptable to me.
> Russ
>
>

Jim