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

[Sean Turner <[e-mail]>]

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.