Comments on draft-ietf-pkix-ocspv2-01

["Phillip H. Griffin" <phil.griffin@xxxxxxxxx>]

Following are comments on minor glitches I found in 
the OCSP ASN.1 module in draft-ietf-pkix-ocspv2-01.txt.


[1] The definition of type OCSPResponseStatus is in
    error due to style. A comment "--No more data available }"
   makes the required trailing "}" missing:

   OCSPResponseStatus ::= ENUMERATED {
                  snip
      noMoreData            (7)       --No more data available }

   Suggest changing the comment to bind this text with a
   second trailing "--" to yield "--No more data available -- }"

[2] The OCSP module attempts to import type CRLReason 
    from X.509 module AuthenticationFramework. But this
    enumerated type is not defined in that module, but is
    defined in the X.509 module CertificateExtensions {
    joint-iso-itu-t ds(5) module(1) 
    certificateExtensions(26) 4 }

    Suggested change follows.

    Note that the X.509 AuthenticationFramework module 
    defines well known ASN.1 types required by the OCSP 
    module, but which are imported from elsewhere. Types 
    CertificateSerialNumber and Extensions should be
    imported from the AuthenticationFramework module.

    Suggested change follows.

    The OCSP module attempts to import types GeneralName
    and Name from a module that has an EXPLICIT tags
    default. But type Name is defined in the X.501 
    InformationFramework module, which has an IMPLICIT
    tags default. Type GeneralName is defined in the
    X.509 CertificateExtensions module which also has
    an IMPLICIT tags default, and type GeneralName is
    not defined in the PKIX1Explicit88 module that is
    referenced by OCSP.

    Suggested change follows.
    
    Note that in the OCSP IMPORTS statement, the current 
    version (4th edition) of the Directory standards are
    not referenced.

    Suggest changing the OCSP IMPORTS statement to the
    following:


   -- Directory Information Framework (X.501) --

   Name 
      FROM InformationFramework { 
         joint-iso-itu-t ds(5) module(1) informationFramework(1) 3 }

   -- Directory Authentication Framework (X.509) --

   AlgorithmIdentifier, Certificate, CertificateSerialNumber,
   Extensions
      FROM AuthenticationFramework { 
         joint-iso-itu-t ds(5) module(1) 
            authenticationFramework(7) 4 }

   -- Directory Certificate Extensions (X.509) --

   CRLReason, GeneralName
      FROM CertificateExtensions {
         joint-iso-itu-t ds(5) module(1) 
            certificateExtensions(26) 4 }

   -- PKIX (RFC 2459) --

   AuthorityInfoAccessSyntax
      FROM PKIX1Implicit93 { 
         iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0) 
               id-pkix1-implicit-93(4) }

   id-ad-ocsp, id-kp 
      FROM PKIX1Explicit93 {
         iso(1) identified-organization(3) dod(6) internet(1) 
            security(5) mechanisms(5) pkix(7) id-mod(0) 
               id-pkix1-explicit-93(3) }

   -- Cryptographic Message Syntax

   IssuerAndSerialNumber
      FROM CryptographicMessageSyntax {
         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs-9(9) smime(16) modules(0) cms(1) };

[3] Type ReqCert references type IssuerandSerialNumber (note
    lowercase "and") in both the document text and the ASN.1
    module. But the OCSP module imports IssuerAndSerialNumber.

    Suggest changing this spelling to "And" in both places.

[4] The definition of module OCSP specifies an EXPLICIT
    tags default. This means that none of the uses of the
    EXPLICIT tagging modifier are needed elsewhere in the
    module, and they tend to make the ASN.1 more difficult
    to read.

    Suggest removing the text "EXPLICIT" from all places
    in this standard except for the one occurrence needed
    in the OCSP module definition statement.

[5] The comment on the definition of type UnknownInfo
    should be removed, as it will likely lead to problems
    of interworking between applications. If it is desired
    that both NULL and ENUMERATED be allowed, I suggest
    that type UnknownInfo be defined explicitly as a 
    CHOICE type.

Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------