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

From: Sean Turner <[email-masked]>
Date: Fri, 30 Apr 2010 15:16:07 -0400

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

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?

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.

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.

4.c) Was there discussion about support for the anyExtendedKeyUsage OID 
from 4.2.1.12 of RFC 5280?

4.d) You should look at draft-ietf-sip-eku for what they say about 
processing their EKU.  Those rules are helpful to implementers.

5) draft-ietf-sidr-res-certs-17 is expired.

spt

---

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

Hi Sean,
   Thanks for the comments. Please see responses inline.

> id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp TBA3 }

Sounds good. Will do.

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

>    this document or any anticipated updates.

Given 2) is it OK to leave this section as it is?

> MUST in the last paragraph.

Ack on both .a and .b. Will make this change.

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

> 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