[secdir] Security Review of draft-ietf-pkix-rfc3161-update-09.txt

"pat cain" <pcain2@mail2.coopercain.com> Fri, 11 December 2009 16:03 UTC

Return-Path: <pcain2@mail2.coopercain.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 80AD73A68D9 for <secdir@core3.amsl.com>; Fri, 11 Dec 2009 08:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id iwxN7xC5TEEi for <secdir@core3.amsl.com>; Fri, 11 Dec 2009 08:03:13 -0800 (PST)
Received: from server1.acmehacking.com (server1.acmehacking.com []) by core3.amsl.com (Postfix) with ESMTP id A7C5A3A68C4 for <secdir@ietf.org>; Fri, 11 Dec 2009 08:03:13 -0800 (PST)
Received: from familyroom (familyroom8.bc.edu []) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id nBAJJt1v024141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Dec 2009 13:20:25 -0600
Received: from familyroom by familyroom (PGP Universal service); Thu, 10 Dec 2009 14:20:27 -0500
X-PGP-Universal: processed; by familyroom on Thu, 10 Dec 2009 14:20:27 -0500
From: "pat cain" <pcain2@mail2.coopercain.com>
To: <draft-ietf-pkix-rfc3161-update@tools.ietf.org>
Date: Thu, 10 Dec 2009 14:19:55 -0500
Message-ID: <02f601ca79cd$c433b4e0$4c9b1ea0$@coopercain.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acp5zbtpe0AaM7i2RWyyVwO4obpXfw==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
Cc: pkix-chairs@tools.ietf.org, secdir@ietf.org
Subject: [secdir] Security Review of draft-ietf-pkix-rfc3161-update-09.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: Fri, 11 Dec 2009 16:03:14 -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.

Document Abstract:

   This document updates RFC 3161 [RFC3161]. It allows the use of
   ESSCertIDv2 defined in RFC 5035 [ESSV2] to specify the hash of a
   signer certificate when the hash is calculated with a function other
   than SHA-1 [SHA1].


The purpose of this document is laudable.
My only comment/concern is about the 'note' at the end of Section 2.2.1.

"Note: For backwards compatibility, in line with RFC 5035, both
            ESSCertID and ESSCertIDv2 MAY be present. Systems MAY ignore
            ESSCertIDv2 if RFC 5035 has not been implemented."

When RFC3161 was undergoing development, there was a robust discussion about
A TST multiple times. I seem to recall the output was not to do it. Since
the requestor has to verify the TST when the TSA sends it back, I'm unclear
on how a requestor that "has not implemented RFC5035" is going to do this
verification if both ESSCertID and ESSCertIDV2 are included.
I expect more guidance is needed here since the different signature
algorithms will have differing characteristics and strengths.

It seems to make more sense that a TSA return a TST with *either* an
ESSCertID or ESSCertIDV2, but not both. Is there a specific use case that
was intended here or are we just trying to be polite.

Pat Cain