ietf-smime
[Top] [All Lists]

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

2009-10-09 10:31:10
Alfred,

Thanks again for the review.

spt

Alfred � wrote:
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/

Fixed.

(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 !)

I can see what you're driving at, but I have to admit that I like that
all the text for authenticated, unauthenticated, and unprotected are in
their own sections.  This way if somebody just jumps to that section
it's all there.

(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 }

Yes it should.  Fixed.

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.

Fixed.

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.

All aligned.

(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 ?

Technically, the WG hasn't adopted this as a WG item.  I do think that
until the new ASN.1 IDs are published that we have to have this
boilerplate.  I've copied it from other IDs in this WG and others that
have both ASN.1 versions.

_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
<Prev in Thread] Current Thread [Next in Thread>