[secdir] Secdir review of draft-turner-additional-cms-ri-choices-03.txt

[Charlie Kaufman <[e-mail]>]

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document proposes a syntax for including OCSP (Online Certificate Status Protocol) and SCVP (Server-Based Certificate Validation Protocol) response within a RevocationInfoChoices data structure defined in CMS. Previously, while that data structure was designed to be extensible, the only defined syntax was for the inclusion of CRLs (Certificate Revocation Lists).

The document proposes the most natural way to embed the new information and I found no problems with the spec.

My only concern is with regard to the last line of Security Considerations: "It is a matter of local policy whether these encapsulated SCVP responses are considered valid by another entity." Even though the SCVP responses are signed by the SCVP server, there is no way for the verifying entity to determine whether the nonces inside the response are fresh, therefore it's not obvious under what circumstances it would be safe for the verifying entity to trust that response. If there were a timestamp inside the response, that would help. I don't know whether there is or whether there is a similar issue with OCSP.

I am surprised that IANA is not expected to track and post the object identifiers defined in this RFC below an arc that IANA delegated to the PKIX working group, but the IANA considerations section seems to imply this.

Some typos (both in section 4):

posses -> possess
"client can retain" -> "client to retain"