Hi Sean,
Thanks for the comments. Please see responses inline.
On 10-04-30 03:16 PM, Sean Turner wrote:
The IESG wrote:
The IESG has received a request from the Cga & Send maIntenance WG (csi)
to consider the following document:
- 'Certificate profile and certificate management for SEND '
<draft-ietf-csi-send-cert-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.
1) I would like to see an ASN.1 module added to the document. That way
we can import the EKUs. Here's what I'm looking for (something similar
was done in draft-ietf-sip-eku):
-----
SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-send-cert-extns(TBD) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- OID Arc
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
-- Extended Key Usage Values
id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp TBA1 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp TBA2 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp TBA3 }
END
-----
Sounds good. Will do.
2) You also need to register the OIDs for the EKUs and the ASN.1 module.
I assume you're going to try to get them out of the PKIX arc?
Yes. We will use 23,34, & 25 as the values for TBA1, TBA2 and TBA3 as
allocated by Russ and Steve.
3) Technically your IANA considerations is wrong because you need to get
OIDs. Might I suggest something like:
This document makes use of object identifiers to identify a Extended
Key Usages (EKUs) and the ASN.1 module found in Appendix *TBD*. The
EKUs and ASN.1 module OID are registered in an arc delegated by IANA
to the PKIX Working Group. No further action by IANA is necessary for
this document or any anticipated updates.
Given 2) is it OK to leave this section as it is?
4) In the last paragraph of Section 7 you describe what the
certificate-using application might require.
4.a) It says that including the EKU extension is a MAY, but the first
paragraph says it MUST be present in EE certificates for SEND.
Assuming the 1st paragraph is correct the 1st MAY needs to be a MUST in
the last paragraph.
4.b) Assuming the 1st paragraph in is correct and EKU MUST be present
then shouldn't value also be required? That is, make the second MAY a
MUST in the last paragraph.
Ack on both .a and .b. Will make this change.
4.c) Was there discussion about support for the anyExtendedKeyUsage OID
from 4.2.1.12 of RFC 5280?
No. I am not sure it would be useful as the SEND implementations really
need to know the EKU to work properly. The packet processing is based on
the value of the EKU.
4.d) You should look at draft-ietf-sip-eku for what they say about
processing their EKU. Those rules are helpful to implementers.
OK.
5) draft-ietf-sidr-res-certs-17 is expired.
We need to normatively reference this draft. So I guess we will get
stuck in the RFC-Ed Queue waiting for this.
Thanks
Suresh
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf