[smime] draft-turner-additional-cms-ri-choices-00

[Alfred Hönes <[e-mail]>]

Hello,
following Sean's kind invitation, I have taken a closer look at
    draft-turner-additional-cms-ri-choices-00.

It has been observed that CRLs in many deployments are increasing
in size to an extent making their use unmanageable in various
messaging scenarios.  The IETF has standardized two protocols
providing certificate verification information.
To make responses obtained via these protocols available for
inclusion in CMS messages in an interoperable manner, standardized
conventions are needed, and this draft aims at providing these.

As such, this is a useful addition to the CMS framework.
I support adopting this straightforward document, which should not
need much discussion, and it should b possible to ship it quickly
 to the IESG for publication as a Standards Track RFC.


Editorials:


(1)  Section 4 -- a typo, and an enhancement request

(1a)
Typo in the 1st line:    s/unprotect/unprotected/

(1b)
Because of the commonality and the related flaw later on in the draft,
I suggest to add to the text in Section 4 a clause like:

|  SCVP responses use the type CVResponse, identified by the OID
|  id-ct-scvp-certValResponse, which both are defined in [SCVP].

After this addition, some subsequent text might be shortened.
(This is a MAY !)


(2)  Section 4.2 and Appendix A.1 -- inconsistency

Apparently, there has been a shift in the design; now the idea is
to assign new OIDs all under the id-ri branch, and not to 'recycle'
id-ct-scvp-certValResponse immediately for Unprotected SCVP Responses.

However, this shift has not been completed consistently in the draft
text; the next detail most likely is a result of this incomplete
change.

In Section 4.2, the first paragraph and the subsequent definition
do not match and this inconsistency leads to an inappropriate
citation:

   To carry an unprotected SCVP response, the otherRevInfoFormat is set
|  to id-ct-scvp-certValResponse, which has the following ASN.1
         ^^^^^^^^^^^^^^^^^^^^^^^
|  definition [SCVP]:
             ^^^^^^^
!  id-ri-unprotected-scvp-response OBJECT IDENTIFIER ::= { id-ri TBD }
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Following the naming style in 4.1.*, this should perhaps read:

   To carry an unprotected SCVP response, the otherRevInfoFormat is set
|  to id-ri-unprotected-scvp-response, which has the following ASN.1
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  definition:

   id-ri-unprotected-scvp-response OBJECT IDENTIFIER ::= { id-ri TBD }

Note:
  It would indeed have made some sense to keep
  id-ct-scvp-certValResponse for this purpose,
  but the uniform use of id-ri would be lost this way.

Even worse, the last OID definition in A.1 does not match
Section 4.2 either, introducing yet another name, which does
not appear anywhere else in the draft:

|  id-ri-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ri TBD }
   ^^^^^^^^^^^^^^^^^^^^^^^^^^

I strongly propose to use  id-ri-unprotected-scvp-response   as well.

Note:
 A.2 indeed uses, consistent with the definition in 4.2 (but not
 the prose, as shown above):

|  id-ri-unprotected-scvp-response OBJECT IDENTIFIER ::= { id-ri TBD }
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Please ensure consistency of the OID names.


(3)  Appendix A -- comment

The draft says:

   Appendix A.1 provides the normative ASN.1 definitions for the
   structures described in this specification using ASN.1 as defined in
   [X.680] for compilers that support the 1988 ASN.1.

   Appendix A.2 provides informative ASN.1 definitions for the
   structures described in this specification using ASN.1 as defined in
   [X.680], [X.681], [X.682], and [X.683] for compilers that support the
   2002 ASN.1. This appendix contains the same information as Appendix
   A.1 in a more recent (and precise) ASN.1 notation, however Appendix
   A.1 takes precedence in case of conflict.

That's a really nice description.
Should the WG adopt this text as boilerplate for future documents --
as long as we still hesitate to fully shift to the 'new' ASN.1 ?


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+