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

[Sean Turner <[e-mail]>]

Charlie,

Thanks for your review. Responses inline.

spt

Charlie Kaufman wrote:
> 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.

The "these encapsulated SCVP responses" refers to the locally stored
unprotected and unauthenticated responses from the first line of that
paragraph:

To locally store unprotected or authenticated SCVP responses, an
entity can encapsulate the unprotected or authenticated SCVP response
in a SignedData.

It's legal for SCVP to return unsigned and authenticated responses (the
server might do this because they use TLS between the client and the
server) and then for the client to apply a SignedData and store it for
it's own use.  So, we're just pointing out that though the client might
accept these as valid chances are nobody else is going to accept them as
valid.  If I change the paragraph as follows is it clearer?

OLD:

  To locally store unprotected or authenticated SCVP responses, an
  entity can encapsulate the unprotected or authenticated SCVP response
  in a SignedData.  It is a matter of local policy whether these
  encapsulated SCVP responses are considered valid by another entity.

NEW:

  To locally store unprotected or authenticated SCVP responses, a
  client can encapsulate the unprotected or authenticated SCVP response
  in a SignedData.  It is a matter of local policy whether these
  SCVP responses that are encapsulated and signed by the client are
  considered valid by another entity.

> 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.

I used to put "none" because the OIDs were already registered, but then
somebody said that I needed to explain where I got the OIDs and what
IANA had to do now and in the future.  I decided to follow the lead of
RFC 5280.  Note that similar text was also used in RFC 5753, 5755, and
drafts that have recently been put through to the IESG.

> Some typos (both in section 4):
> 
> posses -> possess
> "client can retain" -> "client to retain"

Both fixed.