IETF Logo Mail Archive

Re: [saag] SHA-1 to SHA-n transition

"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 26 February 2009 16:04 UTC

Return-Path: <pbaker@verisign.com>
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E123A6B73 for <saag@core3.amsl.com>; Thu, 26 Feb 2009 08:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level:
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 kZa0s1x5bKd3 for <saag@core3.amsl.com>; Thu, 26 Feb 2009 08:04:33 -0800 (PST)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id BE5C73A6A65 for <saag@ietf.org>; Thu, 26 Feb 2009 08:04:33 -0800 (PST)
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n1QG4tih021873; Thu, 26 Feb 2009 08:04:55 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 08:04:54 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9982B.F68D809A"
Date: Thu, 26 Feb 2009 08:04:54 -0800
Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2D4@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] SHA-1 to SHA-n transition
Thread-Index: AcmXmoPbHiUJDxxJSI6/JzhiZc+EuQAjSIzf
References: <p06240802c5c5c22d92f0@[128.89.89.88]><200902231914.n1NJEDA3011916@raisinbran.srv.cs.cmu.edu><5A6509457B6F0F71878AA5D2@atlantis.pc.cs.cmu.edu><2788466ED3E31C418E9ACC5C3166155768B2C7@mou1wnexmb09.vcorp.ad.vrsn.com><200902251951.OAA23103@Sparkle.Rodents-Montreal.ORG><2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <p0624080bc5cb79f0f8b4@[10.20.30.158]>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, saag@ietf.org
X-OriginalArrivalTime: 26 Feb 2009 16:04:54.0641 (UTC) FILETIME=[F6AE6610:01C9982B]
Subject: Re: [saag] SHA-1 to SHA-n transition
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 16:04:34 -0000

Lets not debate the semantics of what is and is not a technical issue.
 
They are the issues that are critical to deployment of a successful transition. Since we are (mostly) the people who care most about this particular transition, it is up to us to understand the problem and find a solution.
 
 
So far the only real objection is to the implementation of the suicide note. And what I am proposing is not really a suicide note in the manner proposed by Rivest and Lampson. I am merely re-using his idea of a self-authenticating statement that a key is no longer safe to use and applying it to make a similarly secure statement about an algorithm. The name seems to be distracting.
 
So lets call it a 'upgrade-available' note which is a closer description in this case.
 
How about this as a mechanism:
 
* 'Upgrade-available' Note is established on a per CA-Root basis.
* Each CA determines when they have full support deployed for OCSP back-up authentication.
* CA issues the 'Upgrade-available' note for their particular roots.
* Henceforth browsers know that if they see a SHA1 cert they should check for a SHAn OCSP token.
* This mechanism is only enabled if the user has turned on OCSP validation.
 
Binding the note to the particular root should avoid Jeff's issue. It also removes the need for the CAs to move en-masse which is probably a good thing but I will have to run some simulations to work out if that is the case.
 
 
This seems defensible to me. If I am the CA that stands behind a certificate, I can tell people when it might be appropriate to perform additional checks to make sure that a certificate is really valid.
 
If an enterprise is running its own CA it can make its own decision as to when to tell capable browsers to use SHAn.
 

________________________________

From: saag-bounces@ietf.org on behalf of Paul Hoffman
Sent: Wed 2/25/2009 5:43 PM
To: saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition



At 2:02 PM -0800 2/25/09, Hallam-Baker, Phillip wrote:
>Let us stick to the technical issues here:
>
>* Is the current transition plan viable or does it fail in the way that I predict
>* Is the proposed solution viable?
>* Is there a better solution?

None of those are technical issues.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

v2.23.0 | Report a Bug | By Email