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

[Sean Turner <[e-mail]>]

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
> [e-mail] mailing lists by 2010-05-14. Exceptionally, 
> comments may be sent to [e-mail] 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