Hi Sean, Thank you for your comments, please see my response inline. Regards, Roque On Sat, May 8, 2010 at 6:17 PM, Sean Turner <turners@xxxxxxxx> wrote: > The IESG wrote: >> >> The IESG has received a request from the Cga & Send maIntenance WG (csi) >> to consider the following document: >> >> - 'SEND Name Type field Registry ' >> <draft-ietf-csi-send-name-type-registry-03.txt> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@xxxxxxxx mailing lists by 2010-05-14. Exceptionally, comments may be >> sent to iesg@xxxxxxxx instead. In either case, please retain the beginning >> of the Subject line to allow automated sorting. >> >> The file can be obtained via >> >> http://www.ietf.org/internet-drafts/draft-ietf-csi-send-name-type-registry-03.txt > > Just a couple of comments: > > #1) The introductions says: > > In [I-D.ietf-csi-send-cert] the certificate profile described > in [I-D.ietf-sidr-res-certs] is adopted for SEND. In these > documents, the Subject field in the certificates are declared > to be meaningless and the subjectAltName field is not allowed. > On the other hand, the Subject Key Identifier (SKI) extension > for the X.509 certificates is defined as mandatory and > non-critical. > > Where does it says that the subjectAltName is not allowed in the profiles? > I see in [I-D.ietf-sidr-res-certs] that the extension is not allowed in a > certificate request, but that doesn't necessarily mean that the CA won't > include it. RFC 3971 also seems to indicate that subjectAltName is > supported (see Sec 6.4.5). It's possible I just missed it. (Roque) I must say that the reference is a little bit tricky. Section 3.5 of the [I-D.ietf-sidr-res-certs] document refers to section 2.2 of the document:draft-ietf-sidr-arch-09. As the arch document is informational, the clearest normative reference is in the CP document (draft-ietf-sidr-cp-08), where in section 3.1.1 it is stated that: "The distinguished name for every CA and end entity consists of a single Common Name (CN) attribute with a value generated by the issuer of the certificate. Optionally, the serialNumber attribute may be included along with the common name (to form a terminal relative distinguished name set), to distinguish among successive instances of certificates associated with the same entity." > > #2) Abstract: r/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)./This document > requests that IANA create and maintain a registry for this field. This > document also specifies a new Name Type field based on a certificate Subject > Key Identifier (SKI). > (Roque) ok. thanks. > #3) Sec 2: r/This document request to IANA the creation and management of a > registry for this field./This document requests that IANA create and > maintain a registry for this field. > (Roque) ok. thanks. > #4) Sec 2: Add the following to the final paragraph: > > Consequently, this document updates section 6.4.3 and 6.4.5 of [RFC3971]. > (Roque) ok. thanks. > #5) Sec 3: I was kind of expecting to see something like the following (so > it looks a lot like RFC 3971 and you don't have to repeat what's in RFC > 3971): > > 3. SEND SKI trust anchor option Name Type field > > 3.1 Updates to 6.4.3 of RFC 3971 > > Add the following under Name Type: > > 3 SHA-1 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 > 4.2.1.2 of [RFC5280]. > > 3.2 Updates to 6.4.5 of RFC 3971 > > Add the following to the penultimate paragraph as the penultimate > sentence: > > If the TA option is represented as a SHA-1 SKI, then the SKI must > be equal to the SKI extension in the trust anchor's certificate > calculated as described in [draft-ietf-sidr-res-certs-17]. > (Roque) I like what you are proposing, I received the request to add other hashes to the registry, so I will take your text as a base. > #6) Sec 3: You point to both RFC 5280 and sidr-res-certs for how to compute > the SKI. Shouldn't you just be point to one (i.e., sid-res-certs)? That is > r/Section 4.2.1.2 of [RFC5280]/[draft-ietf-sidr-res-certs-17] > (Roque) ok. > #7) Sec 3.1 (or wherever it ends up): r/then the SKI must be equal/then the > SKI MUST be equal > (Roque) ok. > spt > > P.S. As with draft-ietf-csi-send-cert, [I-D.ietf-sidr-res-certs] is expired. > (Roque) true, hope that it will be updated shortly. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf