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

Suresh Krishnan <suresh.krishnan@ericsson.com> Fri, 30 April 2010 21:50 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2415E3A6BF8; Fri, 30 Apr 2010 14:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.434
X-Spam-Level:
X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1uymrdy3oCD; Fri, 30 Apr 2010 14:50:38 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id C48FD3A6A3F; Fri, 30 Apr 2010 14:50:37 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3ULoM3U015431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Apr 2010 16:50:22 -0500
Received: from [142.133.10.113] (147.117.20.212) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.1.375.2; Fri, 30 Apr 2010 17:50:20 -0400
Message-ID: <4BDB5076.8080203@ericsson.com>
Date: Fri, 30 Apr 2010 17:49:42 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Sean Turner <turners@ieca.com>
References: <20100430135557.183CD3A6C24@core3.amsl.com> <4BDB2C77.6000206@ieca.com>
In-Reply-To: <4BDB2C77.6000206@ieca.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "cga-ext@ietf.org" <cga-ext@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [CGA-EXT] Last Call: draft-ietf-csi-send-cert (Certificate profile and certificate management for SEND) to Proposed Standard
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 21:50:41 -0000

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@ietf.org mailing lists by 2010-05-14. Exceptionally, 
>> comments may be sent to iesg@ietf.org 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