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

Sean Turner <turners@ieca.com> Mon, 17 May 2010 14:52 UTC

Return-Path: <turners@ieca.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 6CEA43A6A46 for <secdir@core3.amsl.com>; Mon, 17 May 2010 07:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.964
X-Spam-Level:
X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 8ezqaXKh7DUW for <secdir@core3.amsl.com>; Mon, 17 May 2010 07:52:08 -0700 (PDT)
Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 395003A6A7C for <secdir@ietf.org>; Mon, 17 May 2010 07:51:31 -0700 (PDT)
Received: (qmail 81977 invoked from network); 17 May 2010 14:51:21 -0000
Received: from thunderfish.local (turners@71.191.0.118 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 17 May 2010 07:51:19 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: fJ0W3D8VM1kuaspxz6wrwA9b65yOIHCQfhinL2ZRsPaRDrPO4kwG.Ge7PKwO7kmfTImRvmc7nIPb1EvBo_KGjqYxpJNyMgQbSNej02Bz4PwM.ifNC50liz_GB1CVlLYI22QgByIQ9x2nvvmnE6LUfbyqjtAVdomEUExkD7bZ.ldPuW2fgcYqQKWI9.kUhbg2dkLkvJj9l4MVptHRM_RZh353bO_6h1JYUzEh8VeuHoR7SlcUHvPMUu1TTvB_npR2HPFsdQezoTVuTS41Wi531lq8xk_xBGGXaSnohy6hs97IKJAmlS76zkY-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4BF157E6.2050808@ieca.com>
Date: Mon, 17 May 2010 10:51:18 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <020001caeebe$ffdcd560$ff968020$@com> <AANLkTikBkBWm8hY9Jyj7PxciFc8FRrnbII_OajwD7Gt2@mail.gmail.com> <p06240804c8109ae33406@[192.168.1.5]>
In-Reply-To: <p06240804c8109ae33406@[192.168.1.5]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, draft-ietf-csi-send-name-type-registry.all@tools.ietf.org, Roque Gagliano <roque.lacnic@gmail.com>, 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 14:52:08 -0000

Stephen Kent 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.

I'm sure somebody will correct me if I'm wrong.

At first, I was encouraged because OpenSSL allows you pick between 
"the guidelines in RFC3280 or a hex string giving the extension value 
to include".  If you want to follow the standard, then you use the 
following: subjectKeyIdentifier=hash.  But, then I went to the 
str_lib.c files, part of OpenSSL:

SHA_DIGEST_LENGTH,  /* ISSUERKEYID:  SHA1 digest, 160 bits */
SHA_DIGEST_LENGTH,  /* SUBJECTKEYID: SHA1 digest, 160 bits */

So it looks like it's hard coded to use SHA-1.

spt