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

Stefan Santesson <stefan@aaa-sec.com> Thu, 07 January 2010 11:19 UTC

Return-Path: <stefan@aaa-sec.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 29D8E3A6816 for <secdir@core3.amsl.com>; Thu, 7 Jan 2010 03:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 t+TA-opAxDkO for <secdir@core3.amsl.com>; Thu, 7 Jan 2010 03:19:38 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 1F5CC3A67B2 for <secdir@ietf.org>; Thu, 7 Jan 2010 03:19:37 -0800 (PST)
Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E017F2E80AD for <secdir@ietf.org>; Thu, 7 Jan 2010 12:19:37 +0100 (CET)
Received: (qmail 86476 invoked from network); 7 Jan 2010 11:19:33 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO MacBookPro-6.local) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s57.loopia.se (qmail-ldap-1.03) with SMTP for <pcain2@mail2.coopercain.com>; 7 Jan 2010 11:19:33 -0000
Received: from [127.0.0.1] by MacBookPro-6.local (PGP Universal service); Thu, 07 Jan 2010 12:19:34 +0100
X-PGP-Universal: processed; by MacBookPro-6.local on Thu, 07 Jan 2010 12:19:34 +0100
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 07 Jan 2010 12:19:31 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: pat cain <pcain2@mail2.coopercain.com>, <draft-ietf-pkix-rfc3161-update@tools.ietf.org>, "Pope, Nick" <Nick.Pope@thales-esecurity.com>
Message-ID: <C76B81D3.794B%stefan@aaa-sec.com>
Thread-Topic: [secdir] Security Review of draft-ietf-pkix-rfc3161-update-09.txt
Thread-Index: Acp5zbtpe0AaM7i2RWyyVwO4obpXfwVvYzrV
In-Reply-To: <02f601ca79cd$c433b4e0$4c9b1ea0$@coopercain.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: pkix-chairs@tools.ietf.org, secdir@ietf.org
Subject: Re: [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: Thu, 07 Jan 2010 11:19:39 -0000

Pat,

I think you may have misunderstood the issue this draft is addressing.
Including ESSCertIDv2 does not mean adding another signature with different
strength.

ESSCertID and ESSCertIDv2 are just different certificate identifiers for the
same certificate used to validate the same signature. The only difference is
that the identifier in ESSCertIDv2 is done with a stronger hash (and
includes a hash alg identifier) than the one in ESSCertID.

I don't see any problem with including both. How to deal with that is
defined by, and an issue for, S/MIME rather than this specification.

/Stefan

On 09-12-10 8:19 PM, "pat cain" <pcain2@mail2.coopercain.com> 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.
> 
> 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].
> 
> Comment:
> 
> 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
> signing 
> 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
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir