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

Sean Turner <turners@ieca.com> Mon, 26 April 2010 13:41 UTC

Return-Path: <turners@ieca.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 9F32528C110 for <secdir@core3.amsl.com>; Mon, 26 Apr 2010 06:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.817
X-Spam-Level:
X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001]
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 PejXSvLJHQUq for <secdir@core3.amsl.com>; Mon, 26 Apr 2010 06:41:08 -0700 (PDT)
Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 6D2D83A6B27 for <secdir@ietf.org>; Mon, 26 Apr 2010 06:41:08 -0700 (PDT)
Received: (qmail 50443 invoked from network); 26 Apr 2010 13:40:56 -0000
Received: from thunderfish.local (turners@71.191.2.51 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 26 Apr 2010 06:40:56 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: W0o440oVM1krpBGmzR1Ch16geaibHvwQo1mMt2FHkLBGojI8Ki39e3HUFEnPMlLoLZoq0G0yMIsEb3AIJvSqG8KSaM7gmnos1oz52cGE10VDFsXzIErwENkxepiLzdTLOjz6J3DSgwxMxSRAE.XmUq7G318AMCGYbSgDv_gICJz3vilgydngc3GcJckN6aEfqScffhXD1N4gqrUCcuANUr7QhGurJ0ChyQmYBVQoEqLIGK1ZK9yvqJFthOIvmKd6S1r2c3sOxZlVyOzKiwBlBUpg8KaRw1IbGgj4FxCJj0KZpNO8GhTSs0WVZMPJwnSO_MkTJlFMp56M5HZSbUbS57v.QJlwD8tMNxI04HdVnDWbZvTg35BwSkYEjaFoYYN3QPExmQneoXtKNXgttMJ__BC45uwzzInBL6YcqT0KRbVe
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4BD597DA.7000002@ieca.com>
Date: Mon, 26 Apr 2010 09:40:42 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Charlie Kaufman <charliek@microsoft.com>
References: <D80EDFF2AD83E648BD1164257B9B0912120B4289@TK5EX14MBXC117.redmond.corp.microsoft.com>
In-Reply-To: <D80EDFF2AD83E648BD1164257B9B0912120B4289@TK5EX14MBXC117.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 13:41:09 -0000

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.