Subject: Re: [CGA-EXT] Last Call: draft-ietf-csi-send-cert (Certificate profile and certificate management for SEND) to Proposed Standard

From: Suresh Krishnan <[email-masked]>
Date: Fri, 30 Apr 2010 17:49:42 -0400

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