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

Stephen Kent <> Thu, 13 May 2010 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 452213A6C5C; Thu, 13 May 2010 10:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.535
X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZSuxXsE69bfA; Thu, 13 May 2010 10:12:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 10D7E3A6C50; Thu, 13 May 2010 10:12:44 -0700 (PDT)
Received: from ([]:58433 helo=[]) by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1OCbxZ-000Dzr-EE; Thu, 13 May 2010 13:12:33 -0400
Mime-Version: 1.0
Message-Id: <p06240804c8109ae33406@[]>
In-Reply-To: <>
References: <020001caeebe$ffdcd560$ff968020$@com> <>
Date: Wed, 12 May 2010 14:00:00 -0400
To: Roque Gagliano <>
From: Stephen Kent <>
Content-Type: multipart/alternative; boundary="============_-938351741==_ma============"
Subject: Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 May 2010 17:12:57 -0000

At 6:38 PM +0200 5/8/10, Roque Gagliano wrote:
>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


5280 defines how to use SHA-1, but it does not require use of this specific
hash function. 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.