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

From: Charlie Kaufman <[email-masked]>
Date: Mon, 26 Apr 2010 05:43:51 +0000

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"

---

From: Sean Turner <[email-masked]>
Date: Mon, 26 Apr 2010 09:40:42 -0400

Charlie,

Thanks for your review. Responses inline.

spt

> 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 t…

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…

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.

> "client can retain" -> "client to retain"

Both fixed.

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 26 Apr 2010 16:38:54 +0000

I guess what I was looking for was some guidance as to under what circumstances it would be reasonable for a verifier to trust such an SCVP response, since it could have been trivially forged by the sender. I guess it could be taken as an assertion by the sender that the sender verified the status of the certificates before sending on the message, and so if the sender were judged sufficiently trustworthy the certificates might be believed on that basis. But the intricacies of who is trusting who for what are sufficiently subtle that it might deserve explicit mention. I don't remember SCVP or OCSP well enough to know whether there is an asserted timestamp associated with any of these signatures; if so, that might also be relevant to a trust decision.

I don't feel strongly about this, and don't want to make trouble. When I'm reviewing a spec that is "just fine", I try to find the most significant area for possible elaboration by way of saying I don't believe there are any issues more significant than this "nit".

	--Charlie

-----Original Message-----
From: Sean Turner [mailto:[email-masked]] 
Sent: Monday, April 26, 2010 6:41 AM
To: Charlie Kaufman
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir review of draft-turner-additional-cms-ri-choices-03.txt

Charlie,

spt

> 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 t…

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:

NEW:

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

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.

Both fixed.