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: Sat, 01 May 2010 06:56:54 -0400

Suresh,

Responses inline.  I deleted the ones we've agreed on.

spt

Suresh Krishnan wrote:

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

It's up to you whether you want to keep the text as is.

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

Hmmm if you're not going to support it, then you might want to 
put some text in about it not being allowed.  5280 allows 
applications to reject certificates that include this extension.

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

Yep.

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 2 May 2010 22:47:34 -0400

Hi Sean,
   I will make the changes to the IANA considerations section like you 
suggested. I think it adds clarity about the required assignment.

> applications to reject certificates that include this extension.

OK. I will add the following text at the end of Section 7

"Certificate-using applications MUST reject certificates that do not 
contain one of the three KeyPurposeIds defined above even if they 
include the anyExtendedKeyUsage OID defined in [RFC5280]."

Does this work?

Thanks
Suresh

---

From: Sean Turner <[email-masked]>
Date: Mon, 03 May 2010 08:31:37 -0400

Suresh Krishnan wrote:
>>> 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.
>>
>> Hmmm if you're not going to support it, then you might want to put 
>> some text in about it not being allowed.  5280 allows applications to 
>> reject certificates that include this extension.
> 

That would work for me.

spt

---

From: Sean Turner <[email-masked]>
Date: Sat, 08 May 2010 11:04:39 -0400

> stuck in the RFC-Ed Queue waiting for this.

I just noticed the draft-ietf-sidr-arch-09 is also expired.

spt