Subject: Re: [Gen-art] Gen-art review of draft-ietf-csi-send-name-type-registry-03

From: Elwyn Davies <[email-masked]>
Date: Mon, 17 May 2010 11:58:10 +0100

Hi, Roque.

Thanks for the quick response.

[I am afraid my email from the IETF is a bit mixed up at the moment. It may be best to 
send any further responses direct as well.] 

(deleting the agreed bits)
> On Fri, May 14, 2010 at 6:46 PM, Elwyn Davies <elwynd at dial.pipex.com> wrote:
> >
> > Major issues:
> > s3/s3.1: There seems to be some confusion here.  Section 4.2.1.2 of RFC 5280 does not 
> > specify a unique method for encoding the Subject Key Identifier extension and there 
> > doesn't appear to be any method of finding out what method was (allegedly) used to 
> > generate the Subject Key Identifier.  S3 specifies that the SEND TA option has to carry 
> > the Key identifier in a specific one of those forms (#1 in RFC 5280). S3.1 specifies 
> > that the TA option carries the value from the SKI extension (without knowing whether 
> > that field is the SHA-1 form or some other). It appears that this document is placing 
> > a restriction on the algorithm used to generate the SKI extension value, but without 
> > saying this explicitly.  This all seems a bit of a mess.. or am I missing something?
> > Presumably the reason for the DER-encoding cruft is to facilitate simple comparison.
> >
>
> (Roque) We were only considering SHA-1 as it is the only hash
> described in the certificate profile document
> (draft-ietf-sidr-res-certs). However, the SECDIR already requested us
> to add other hashes values to the registry. We are proposing adding
> the following values 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                                           |
>      +---------+----------------------------------------------------+
>
>
OK
>
> > Minor issues:
> > s3/s3.1: Is the 'Key Identifier' described here sent as the value of the 'Name' field 
> > in the TA option?  If so, say so.  Otherwise explain what is in the Name field in this 
> case and where the Key Identifier fits in.
> >
>
> (Roque) The answer is yes, but that is said in Section 6.4.3 of RFC
> 3971. The only thing that we are doing is creating a registry for the
> different 'Name type' fields and registering some new possibilities
> based on the SKI.
True, but I think you need to actually say what goes in the Name field explicitly.  Its not a big 
deal and RFC 3971 says for each case what goes in the Name field. 

Presumably the intention is that what is in the Name field is directly compared with the 
SKI information in the certificate.  This may be obvious but I can't actually find anywhere 
in the various documents that this actually said!  This might be added here but there maybe 
better places. 

Elwyn

---

From: Roque Gagliano <[email-masked]>
Date: Mon, 17 May 2010 13:30:24 +0200

Hi Elwyn,

Thanks for your email.

Actually Sean Turner pointed the same issue in his review and I
proposed a revised text for the section 3 that I am including next.

What do you think?

Regards,
Roque

-----------------------------

3.  SEND SKI trust anchor option Name Type fields

3.1.  Updates to 6.4.3 of RFC 3971

   Add the following under Name Type:

           Name Type      Description
            3              SHA-1 Subject Key Identifier (SKI).
            4              SHA-224 Subject Key Identifier (SKI).
            5              SHA-256 Subject Key Identifier (SKI).
            6              SHA-384 Subject Key Identifier (SKI).
            7              SHA-512 Subject Key Identifier (SKI).

   Add the following under Name:

   When the Name Type field is set to 3, the Name field contains a 160-
   bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of
   the subject public key, as described in Section 3.9.2 of
   [I-D.ietf-sidr-res-certs].

   When the Name Type field is set to 4,5,6 or 7, the hash function will
   respectively be: SHA-224, SHA-256, SHA-284 or SHA-512.

3.2.  Processing Rules for Routers

   As specified in RFC 3971, a TA is identified by the SEND TA option.
   If the TA option is represented as a SKI, then the SKI MUST be equal
   to the SKI extension in the trust anchor's certificate.  The router
   SHOULD include the TA option(s) in the advertisement for which the
   certification path was found.  Also, following [RFC3971]
   specification, if the router is unable to find a path to the
   requested anchor, it SHOULD send an advertisement without any
   certificate.  In this case, the router SHOULD include the TA options
   that were solicited.

-----------------------------

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 17 May 2010 13:01:35 +0100

Hi.
This seems sensible, except that presumably it should be mentioned that
the hash lengths are also different.

Is the use of these SHA-2 hashes for the SKI extension explicitly
standardized somewhere?  Presumably the comments in RFC 3971 about what
exactly you hash (The keyIdentifier is composed of the 160-bit SHA-1
hash of the value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits) apply to using any of the SHA-2
algorithms in place of SHA-1.  Either something explicit or a reference
is needed.

Regards,
Elwyn

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 18 May 2010 00:10:55 +0200

Hi Elwyn,

Thank you for your email, please find my answer inline.

Roque.

> algorithms in place of SHA-1.  Either something explicit or a reference

AFAIK the use of SHA-2 hashes for the SKI is not standardized more of
what is said in section 4.2.1.2 of RFC 5280 where it is said that
"Other methods of generating unique numbers are also acceptable."

Adding the registration for other hashes was a request from the SED AD
and the SECDIR review process in order to avoid to have to write
another I-D in the future. I do not believe this document should
establish how to compute the SKIs for SHA-2 hashes.

Regard,

Roque.