Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03

"Patrick Cain" <pcain@coopercain.com> Mon, 17 May 2010 21:28 UTC

Return-Path: <pcain@coopercain.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 432B73A6A15; Mon, 17 May 2010 14:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 oxJOAFd3Zm+N; Mon, 17 May 2010 14:28:20 -0700 (PDT)
Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id B23603A6AEE; Mon, 17 May 2010 14:28:01 -0700 (PDT)
Received: from familyroom (familyroom8.bc.edu [136.167.27.76]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id o4HLRf1w022812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 May 2010 16:27:47 -0500
Received: from familyroom by familyroom (PGP Universal service); Mon, 17 May 2010 17:27:47 -0500
X-PGP-Universal: processed; by familyroom on Mon, 17 May 2010 17:27:47 -0500
From: Patrick Cain <pcain@coopercain.com>
To: 'Sean Turner' <turners@ieca.com>, 'Roque Gagliano' <roque.lacnic@gmail.com>
References: <020001caeebe$ffdcd560$ff968020$@com> <AANLkTikBkBWm8hY9Jyj7PxciFc8FRrnbII_OajwD7Gt2@mail.gmail.com> <p06240804c8109ae33406@192.168.1.5> <AANLkTin41WmwxOsbvHD4IwzQ4za9D8dmZLGwHJhWO5bE@mail.gmail.com> <4BF1580C.70407@ieca.com>
In-Reply-To: <4BF1580C.70407@ieca.com>
Date: Mon, 17 May 2010 17:27:40 -0400
Message-ID: <02d901caf607$cb1d9d00$6158d700$@com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acr10IGckDeyKMytR1ud5qf7t2OMUQANo2Aw
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
Cc: iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03
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: Mon, 17 May 2010 21:28:21 -0000

Sean,
I'm not so sure that I was *asking* for it, as much as *pointing it out*.

Roque,
The additional numbers look just fine to me, but I am far from an expert in
their use.

Pat

-----Original Message-----
From: Sean Turner [mailto:turners@ieca.com] 
Sent: Monday, May 17, 2010 10:52 AM
To: Roque Gagliano
Cc: Stephen Kent; Patrick Cain; secdir@ietf.org; iesg@ietf.org;
draft-ietf-csi-send-name-type-registry.all@tools.ietf.org
Subject: Re: [secdir] secdir review of
draft-ietf-csi-send-name-type-registry-03

That is what, I believe, Pat was asking for.

spt

Roque Gagliano wrote:
> Stephen/ Patrick/Sean,
> 
> Thank you for your comments. What about adding the following extra
> numbers to the registry?:
> 
>   +---------+----------------------------------------------------+
>      | Value   | Description                                        |
>      +---------+----------------------------------------------------+
>      | 0       | Reserved                                           |
>      |         |                                                    |
>      | 1       | DER Encoded X.501 Name (RFC 3971)                  |
>      |         |                                                    |
>      | 2       | FQDN (RFC 3971)                                    |
>      |         |                                                    |
>      | 3       | SHA-1 Subject Key Identifier (SKI) ( Section 3 )   |
>      |         |                                                    |
>      | 4       | SHA-224 Subject Key Identifier (SKI) ( Section 3 ) |
>      |         |                                                    |
>      | 5       | SHA-256 Subject Key Identifier (SKI) ( Section 3 ) |
>      |         |                                                    |
>      | 6       | SHA-384 Subject Key Identifier (SKI) ( Section 3 ) |
>      |         |                                                    |
>      | 7       | SHA-512 Subject Key Identifier (SKI) ( Section 3 ) |
>      |         |                                                    |
>      | 253-254 | Experimental use                                   |
>      |         |                                                    |
>      | 255     | Reserved                                           |
>      +---------+----------------------------------------------------+
> 
> This way we stay ready if SIDR certs uses some of these hashes
> functions in the future.
> 
> regards,
> 
> Roque
> 
> 
> On Wed, May 12, 2010 at 8:00 PM, Stephen Kent <kent@bbn.com> wrote:
>> At 6:38 PM +0200 5/8/10, Roque Gagliano wrote:
>>
>> Patrick,
>>
>> Thank you for your review.
>>
>> You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and
>> required in draft-ietf-sidr-res-cert
>>
>> Regards,
>>
>> Roque
>>
>> Roque,
>> 5280 defines how to use SHA-1, but it does not require use of this
specific
>> hash function. 4.2.1.2 says:
>>    For CA certificates, subject key identifiers SHOULD be derived from
the
>> public key or a method that generates unique values.  Two common methods
for
>> generating key identifiers from the public key are:
>> ...
>> Other methods of generating unique numbers are also acceptable.
>> So, use of another one-way hash function, e.g., SHA-256 meets the
criteria
>> defined above (associated with the "SHOULD") and is consistent with the
>> final comment.
>> CAs need to know which function to use, but RPs just perform comparisons.
We
>> could modify the RPKI cert profile (if Geoff and the SIDR WG don't mind)
to
>> specify use of SHA-256 for generation of SKI/AKI values. I guess the real
>> issue is whether commonly used software (e.g., OpenSSL) will support
this.
>> Steve
>