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

Chris Palmer <chris@eff.org> Tue, 08 March 2011 01:40 UTC

Return-Path: <chris@eff.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 2644628C0FB for <keyassure@core3.amsl.com>; Mon, 7 Mar 2011 17:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.229
X-Spam-Level:
X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, 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 hTPEKmw0A7NG for <keyassure@core3.amsl.com>; Mon, 7 Mar 2011 17:40:09 -0800 (PST)
Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id 6B3833A69E9 for <keyassure@ietf.org>; Mon, 7 Mar 2011 17:40:09 -0800 (PST)
Received: from [192.168.0.28] (208-90-214-239.PUBLIC.monkeybrains.net [208.90.214.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: chris) by mail1.eff.org (Postfix) with ESMTPSA id AD372BDC1F; Mon, 7 Mar 2011 17:41:22 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Chris Palmer <chris@eff.org>
In-Reply-To: <4D758064.9090608@vpnc.org>
Date: Mon, 07 Mar 2011 17:41:20 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D880A4A-9044-4027-9A40-E46E5586E8D8@eff.org>
References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> <9C30235F-FF8C-44E7-B7BC-5D284586D11B@eff.org> <4D752197.5090403@vpnc.org> <8FB60B62-483F-48B5-8A36-390872C18BD5@kumari.net> <4B7097F3-26FD-412F-B96E-8AB46D1E967C@eff.org> <4D758064.9090608@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1082)
Cc: keyassure@ietf.org
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: Tue, 08 Mar 2011 01:40:10 -0000

On Mar 7, 2011, at 5:03 PM, Paul Hoffman wrote:

> One specific thing that this author would like to see is what you and others specifically mean by "a slot for SHA-3" and "a plan for SHA-3". To me, those are quite different. We already have slots for SHA-3, SHA-42, and so on; they are not named as such, but they are there.

Change this:

"""
4.3.  TLSA Hash Types

   This document creates a new registry, "Hash Types for TLSA Resource
   Records".  The registry policy is "Specification Required".  The
   initial entries in the registry are:

   Value        Short description       Ref.
   -----------------------------------------------------
   0            No hash used            [This]
   1            SHA-1                   NIST FIPS 180-2
   2            SHA-256                 NIST FIPS 180-2
   3            SHA-384                 NIST FIPS 180-2
   4-254        Unassigned

   Applications to the registry can request specific values that have
   yet to be assigned.
"""

To something like this:

4.3.  TLSA Hash Types

   This document creates a new registry, "Hash Types for TLSA Resource
   Records".  The registry policy is "Specification Required".  The
   initial entries in the registry are:

   Value        Short description       Ref.
   -----------------------------------------------------
   0            No hash used            [This]
   1            SHA-1                   NIST FIPS 180-2
   2            SHA-256                 NIST FIPS 180-2
   3            SHA-384                 NIST FIPS 180-2
   4            Reserved
   5            Reserved
   6-254        Unassigned

   Applications to the registry can request specific values that have
   yet to be assigned. Note that that types 4 and 5 are reserved to
   indicate the SHA-3 algorithm, when it is defined. Future revisions
   to this document SHALL require implementations to support SHA-3, and
   implementors SHOULD prepare for this with a flexible implementation
   strategy.

I don't really speak RFC-ese, but hopefully this makes enough sense. :)


-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation