RE: Comments on draft-ietf-pkix-ocspv2-01

[Michael Myers <MMyers@xxxxxxxxxxxx>]

Phil,

Many thanks for your detailed analysis.  We'll fold this into the -02 (and
with hope, final) draft for WG consideration.

Mike

> -----Original Message-----
> From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com]
> Sent: Tuesday, December 12, 2000 8:57 AM
> To: pkix list
> Subject: Comments on draft-ietf-pkix-ocspv2-01
> 
> 
> 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
> ------------------------------------------------------------
>