Last Call Review of draft-turner-additional-cms-ri-choices-
review-turner-additional-cms-ri-choices-secdir-lc-kaufman-2010-04-27-00

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"