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.
#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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf