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

From: "Patrick Cain" <[email-masked]>
Date: Sat, 8 May 2010 10:58:55 -0400

Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

About this document:

SEcure Neighbor Discovery (SEND) defines the Name Type field in the
   Trust Anchor option.  This document request to IANA the creation and
   management of a registry for this field.  This document also
   specifies a new Name Type field based on a certificate Subject Key
   Identifier (SKI).

My comments:

The document has no major technical shortcomings that I could find.

I do note that the new registry value defined in this document relies on
SHA-1 (160).
This may be a good time to save a few RFC numbers and define a value for the
impending other SHA values, like SHA-2, although I'm not so sure they exist
in x.509
certificates yet.

Pat

---

From: Roque Gagliano <[email-masked]>
Date: Sat, 8 May 2010 18:38:24 +0200

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

---

From: Sean Turner <[email-masked]>
Date: Tue, 11 May 2010 12:09:49 -0400

Roque,

I think what Pat is suggesting that at some point in the future SHA-1 
might not be required and then we'd need to do another update to the 
registry.  We could do a little future proofing by including registry 
entries for SHA-224, SHA-256, SHA-384, and SHA-512 in this I-D.

spt

Roque Gagliano wrote:
> On Sat, May 8, 2010 at 4:58 PM, Patrick Cain <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 May 2010 14:00:00 -0400

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

---

From: Sean Turner <[email-masked]>
Date: Mon, 17 May 2010 10:51:18 -0400

Stephen Kent wrote:
> 5280 defines how to use SHA-1, but it does not_ require_ use of this 
> specific
>    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:
> 
> ...
> 
> criteria defined above (associated with the "SHOULD") and is consistent 
> with the final comment.
> 
> 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

---

From: Sean Turner <[email-masked]>
Date: Mon, 17 May 2010 10:51:56 -0400

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 <[email-masked]> wrote:
>>    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:
>> ...
>> 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
>

---

From: Roque Gagliano <[email-masked]>
Date: Sun, 16 May 2010 19:37:00 +0200

Stephen/ Patrick/Sean,

regards,

Roque

---

From: "Patrick Cain" <[email-masked]>
Date: Mon, 17 May 2010 17:27:40 -0400

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:[email-masked]] 
Sent: Monday, May 17, 2010 10:52 AM
To: Roque Gagliano
Cc: Stephen Kent; Patrick Cain; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [secdir] secdir review of
draft-ietf-csi-send-name-type-registry-03

spt

> numbers to the registry?:
the
>> So, use of another one-way hash function, e.g., SHA-256 meets the
criteria