ietf
[Top] [All Lists]

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

2010-05-17 09:55:12
Dear Elwyn,

Thank you for your review. Please see my comments inline.

Regards,

Roque


On Fri, May 14, 2010 at 6:46 PM, Elwyn Davies 
<elwynd(_at_)dial(_dot_)pipex(_dot_)com> wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document:draft-ietf-csi-send-name-type-registry-03.txt
Reviewer: Elwyn Davies
Review Date: 14 May 2010
IETF LC End Date: 14 May 2010
IESG Telechat date: (if known) -

Summary:
Probably not ready. There seems to be a conflict or confusion between the 
prescriptive specification of a single algorithm for how the Subject Key 
Identifier has to be created in this document and the permissive 
specification in RFC 5280 that allows any suitable algorithm.  Either this 
specification will only deal with certificates that use the chosen SHA-1 hash 
or this specification is unnecessarily restrictive.  There are also a a few 
(related) minor issues and nits.

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                                           |
     +---------+----------------------------------------------------+




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.

s3: Needs a reference to specify how to do DER-encoding of ASN.1 (and DER 
needs expanding).


(Roque) ok, will include.

Nits/editorial comments:
Abstract: s/This document request to IANA/This document is a request to IANA 
for the/


(Roque) ok.

s2, para 1: s/to certify a router authority/to certify a router's authority/.
s/for NDP/for the NDP/,
s/This document request to IANA/This document is a request to IANA for the/


(Roque)  ok.

s2, para 2: s/the certificates are declared/the certificates ia declared/


(Roque) ok.

s3: It would be clearer if the line starting '3 SHA-1' was indented a bit and 
the description separated so that it doesn't sit under the 'Name Type' header.
Something like:
  Name Type    Description

      3        SHA-1 Subject Key Identifier (SKI)


(Roque) ok.

s4, last para: s/is through/require/; there should be a reference to RFC 5226.

(Roque) ok.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>