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

Charlie Kaufman <charliek@microsoft.com> Mon, 26 April 2010 16:39 UTC

Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9AC3A6A2D; Mon, 26 Apr 2010 09:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW+c2i0xVuKz; Mon, 26 Apr 2010 09:39:09 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 35E883A67D7; Mon, 26 Apr 2010 09:39:09 -0700 (PDT)
Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Apr 2010 09:38:57 -0700
Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.187]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi; Mon, 26 Apr 2010 09:38:56 -0700
From: Charlie Kaufman <charliek@microsoft.com>
To: Sean Turner <turners@ieca.com>
Thread-Topic: Secdir review of draft-turner-additional-cms-ri-choices-03.txt
Thread-Index: AcrlA3NMIZNH4zjOTC66YANKWweFogAfUmEAAAjrOdA=
Date: Mon, 26 Apr 2010 16:38:54 +0000
Message-ID: <D80EDFF2AD83E648BD1164257B9B0912120B44B7@TK5EX14MBXC117.redmond.corp.microsoft.com>
References: <D80EDFF2AD83E648BD1164257B9B0912120B4289@TK5EX14MBXC117.redmond.corp.microsoft.com> <4BD597DA.7000002@ieca.com>
In-Reply-To: <4BD597DA.7000002@ieca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-turner-additional-cms-ri-choices.all@tools.ietf.org" <draft-turner-additional-cms-ri-choices.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-turner-additional-cms-ri-choices-03.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 16:39:10 -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:turners@ieca.com] 
Sent: Monday, April 26, 2010 6:41 AM
To: Charlie Kaufman
Cc: secdir@ietf.org; iesg@ietf.org; draft-turner-additional-cms-ri-choices.all@tools.ietf.org
Subject: Re: Secdir review of draft-turner-additional-cms-ri-choices-03.txt

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.