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

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

Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 5AFA13A69D2; Sun, 25 Apr 2010 22:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
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 ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id CVImOMT+CGlC; Sun, 25 Apr 2010 22:48:46 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com []) by core3.amsl.com (Postfix) with ESMTP id C47243A6880; Sun, 25 Apr 2010 22:44:06 -0700 (PDT)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com ( by TK5-EXGWY-E801.partners.extranet.microsoft.com ( with Microsoft SMTP Server (TLS) id; Sun, 25 Apr 2010 22:43:55 -0700
Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([]) with mapi; Sun, 25 Apr 2010 22:43:54 -0700
From: Charlie Kaufman <charliek@microsoft.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-turner-additional-cms-ri-choices.all@tools.ietf.org" <draft-turner-additional-cms-ri-choices.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-turner-additional-cms-ri-choices-03.txt
Thread-Index: AcrlA3NMIZNH4zjOTC66YANKWweFog==
Date: Mon, 26 Apr 2010 05:43:51 +0000
Message-ID: <D80EDFF2AD83E648BD1164257B9B0912120B4289@TK5EX14MBXC117.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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 05:48:47 -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"