Subject: Re: Part1 last call comments

From: Russ Housley <[email-masked]>
Date: Thu, 01 Mar 2001 17:51:05 -0500

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 2 Mar 2001 10:46:15 -0800

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, March 01, 2001 2:51 PM
> To: [email-masked]
> Subject: Re: Part1 last call comments
>
>

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

> ...

Deleting the middle statement is acceptable to me.
> Russ

Jim