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(_at_)ieca(_dot_)com> 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(_at_)ietf(_dot_)org mailing lists by 2010-05-14. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf