Re: [keyassure] Opening issue #21: "Need to specify which crypto

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 04 March 2011 14:57 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8513A694C for <keyassure@core3.amsl.com>; Fri, 4 Mar 2011 06:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.829
X-Spam-Level:
X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 stHobJ9QiOIu for <keyassure@core3.amsl.com>; Fri, 4 Mar 2011 06:57:31 -0800 (PST)
Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 64F903A69D7 for <keyassure@ietf.org>; Fri, 4 Mar 2011 06:57:27 -0800 (PST)
Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p24EwWtc030679 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <keyassure@ietf.org>; Fri, 4 Mar 2011 07:58:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D70FE18.2040703@vpnc.org>
Date: Fri, 04 Mar 2011 06:58:32 -0800
From: Paul Hoffman <paul.hoffman@vpnc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8
MIME-Version: 1.0
To: keyassure@ietf.org
References: <E1PvVl0-0005Oy-PT@login01.fos.auckland.ac.nz>
In-Reply-To: <E1PvVl0-0005Oy-PT@login01.fos.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2011 14:57:32 -0000

On 3/4/11 6:13 AM, Peter Gutmann wrote:
> Phillip Hallam-Baker<hallam@gmail.com>  writes:
>
>> OK, how about this
>>
>> Define code points for
>>
>> SHA2-256
>> SHA2-512
>> SHA3-256 (reserved)
>> SHA3-512 (reserved)
>>
>> If SHA3 is ready in time (i.e. we are still not ready in 2012) we could
>> consider making SHA3-256 the required algorithm. If not make SHA2-256 and
>> SHA2-512 the required algorithms.
>
> Sounds good, although I'd make 256 a MUST and 512 a MAY, both to keep the
> every-bit-is-sacred crowd happy and because in practice there's going to be a
> de facto universal default that everyone uses, and my guess is it'll be -256,
> in the same way that currently the universal default that everyone uses is
> SHA1, no matter what other algorithms the spec allows.

While I prefer Warren's original proposal (two mandatory algorithms 
now), I can see a reason to have just one now followed by strong wording 
that we are likely to change this in the foreseeable future to a 
specific code point so implementers need to plan for that now. We don't 
have to be specific about what will go in that code point because we 
won't know until NIST is finished, but we can say that we expect that to 
become mandatory as well.

--Paul Hoffman