[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Part1 last call comments
Russ Housley said:
> The same compiler would like "EXPLICIT" or "IMPLICIT" to be
> inserted before
> uses of ORAddress, Name, DirectoryString, and
> RelativeDistinguishedName.
Having been bitten by this in the past, I would recommend that PKIX at least
insert a comment into the ASN.1 source with the appropriate tag type.
Frank
> -----Original Message-----
> From: Russ Housley [mailto:housley@xxxxxxxxxx]
> Sent: Thursday, March 01, 2001 5: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.
>
> 2. The implicit module (section A.2) contains the following:
>
> DistributionPoint ::= SEQUENCE {
> distributionPoint [0]
> DistributionPointName OPTIONAL,
> reasons [1] ReasonFlags OPTIONAL,
> cRLIssuer [2] GeneralNames OPTIONAL }
>
> IssuingDistributionPoint ::= SEQUENCE {
> distributionPoint [0] DistributionPointName OPTIONAL,
> onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
> onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
> onlySomeReasons [3] ReasonFlags OPTIONAL,
> indirectCRL [4] BOOLEAN DEFAULT FALSE }
>
> DistributionPointName ::= CHOICE {
> fullName [0] GeneralNames,
> nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
>
> This matches the definitions from X.509 (4th Edition), but it
> is still a
> very strange use of CHOICE. It relies on a little-known ASN.1 rule:
>
> The tagging construct specifies explicit tagging if
> the "Tag Type"
> alternative is used and the value of "TagDefault"
> for the module is
> "IMPLICIT TAGS", but the type defined by "Type" is a
> choice type
> or an any type.
>
> The same compiler as discussed above, does not internally
> implement this
> rule. The programmer must insert the "EXPLICIT." Again, my
> reaction is
> that anyone who uses a tool with such shortcomings must edit
> the module to
> overcome them. I think we should make sure that the example
> certificate
> includes these cases to help implementors catch mistakes early in the
> development process.
>
> I think that implementors would be well served if the specification
> included the binary certificates were made available. I do
> not think that
> we should make the document any bigger. Perhaps we can
> develop a companion
> document that contains several sample certification paths
> with CRLs to aid
> developers. Of course, we need to carefully consider the
> validity periods
> for the sample certificates to be useful to future
> developers, but that is
> a topic for another thread.
>
> Now to Jim Schaad's message.
>
> >3. Section 4.2.2.2 - Recommend moving the defintion of
> id-ad-caRepository
> >to implicit ASN.1 module since that is where accessLocation
> is located.
>
> Good idea. I do not think that moving the OID definition will impact
> anyone that already did an implementation.
>
> >5. ASN Module A.1: Do not have a new module OID for this.
>
> A new OID for the modules was assigned quite some time ago.
> It should have
> been included in this draft.
>
> id-mod-pkix1-explicit OBJECT IDENTIFIER ::= {
> id-mod 18 }
>
> >6. A.1:
> > X520SerialNumber PrintableString (SIZE
> > (1..ub-serial-number))
> > replace with
> > X520SerialNumber ::=
> PrintableString (SIZE
> > (1..ub-serial-number))
>
> Agree; the assignment operator (::=) is missing.
>
> >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").
>
> >8. ASN Module A.2: Do not have a new module OID for this.
>
> A new OID for the modules was assigned quite some time ago.
> It should have
> been included in this draft.
>
> id-mod-pkix1-implicit OBJECT IDENTIFIER ::= {
> id-mod 19 }
>
> >9. Section A.2
> > anyPolicy OBJECT IDENTIFIER ::=
> > {id-ce-certificate-policies 0}
> > replace with
> > anyPolicy OBJECT IDENTIFIER ::=
> {id-ce-certificatePolicies 0}
> > (or fix the previous line)
>
> Agree. X.509 (the 4th Edition) uses
> id-ce-certificatePolicies, and we
> should too.
>
> >---------------- Algorithm Draft
> >
> >ASN Module:
> >Fix:
> > PKIX1Algorithms88 { tbd }
>
> I assigned id-mod-pkix1-algorithms a long time ago. It
> should have been
> put into this draft.
>
> id-mod-pkix1-algorithms OBJECT IDENTIFIER ::= {
> id-mod 17 }
>
> >Replace
> > cofactor INTEGER OPTIONAL, -- The
> integer h = #E(Fq)/n
> >With
> > cofactor INTEGER OPTIONAL -- The
> integer h = #E(Fq)/n
>
> My preference would be to replace the comma with "}" and
> delete the next
> line. This is just taste. The comma needs to go.
>
> >------------------ Random
> >
> >part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88
> does not have an
> >OID assigned to it
> >
> > --- single name would be nice but not necessary. In the
> case of pkcs-9
> >however there should be a harmonization plan.
> >
> >rfc2630.asn(254) : warning XXXXX: Arc naming collision
> between x9algorithm
> >and x9cm
> > Conflicts with what's in Algorithms draft
> >rfc2630.asn(262) : warning XXXXX: Oid value assigned to
> multiple symbols:
> >'dh-public-number' and 'dhpublicnumber'
> > Conflicts with what's in Algorithms draft
> >rfc2634.asn(204) : warning XXXXX: Arc naming collision
> between pkcs-9 and
> >pkcs9
> > Conflicts with what's in Part1 A.1
>
> I do not see a problem with adopting the names from RFC 2630
> and RFC 2634.
>
> Russ
>
>