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.
-----------------------------
On Mon, May 17, 2010 at 12:58 PM, Elwyn Davies <[email protected]> wrote:
> 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
>>
>>
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
