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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
