Subject: Re: Last Call: draft-ietf-csi-send-name-type-registry (SEND Name Type field Registry) to Proposed Standard

From: Sean Turner <[email-masked]>
Date: Sat, 08 May 2010 12:17:16 -0400

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
> [email-masked] mailing lists by 2010-05-14. Exceptionally, 
> comments may be sent to [email-masked] 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.

#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).

#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.

#4) Sec 2: Add the following to the final paragraph:

Consequently, this document updates section 6.4.3 and 6.4.5 of [RFC3971].

#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].

#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]

#7) Sec 3.1 (or wherever it ends up): r/then the SKI must be 
equal/then the SKI MUST be equal

spt

P.S. As with draft-ietf-csi-send-cert, [I-D.ietf-sidr-res-certs] is 
expired.

---

From: Roque Gagliano <[email-masked]>
Date: Sun, 16 May 2010 22:41:24 +0200

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 <[email-masked]> wrote:
>> [email-masked] mailing lists by 2010-05-14. Exceptionally, comments may be
>> sent to [email-masked] instead. In either case, please retain the beginning
>> of the Subject line to allow automated sorting.
>>
> 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.

> 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):
>

(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.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 May 2010 14:45:56 +0300

AFAICT, there is a registry for this already, just that its not easy to 
find. SEND options are also ICMP options, so the registry is on the ICMP 
options page: http://www.iana.org/assignments/icmpv6-parameters (Search 
for 3971 or for Name Type.)

Jari

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 19 May 2010 17:30:26 +0200

Hi Jari,

On Wed, May 19, 2010 at 1:45 PM, Jari Arkko <[email-masked]> wrote:
> options page: http://www.iana.org/assignments/icmpv6-parameters (Search for
> 3971 or for Name Type.)

Thanks for the review.

That was a good catch and you can bat that is difficult to find. The
initial idea was to simple add the SKI registry. We will work on
updating the document reflecting the comments in your DISCUSS.

Regards,
Roque.

> Jari
>
> _______________________________________________
> CGA-EXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cga-ext
>