Subject: [sidr] WG Last Call request for draft-ietf-sidr-rescerts-provisioning-09

From: Geoff Huston <[email-masked]>
Date: Thu, 11 Nov 2010 14:22:18 +1100

Hi,

I've revised this draft as per the feedback from the WG in today's SIDR meeting regarding text in the Security Considerations that notes that the protocol itself does not describe how a client and a server can "reset" the CMS signing time attribute value

Given that this addresses the WG comments from today's session. I'd like to request the chairs to conduct a WG Last Call for this draft.

thanks

   Geoff & Byron

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: 11 November 2010 2:16:44 PM AEDT
> To: [email-masked]
> Cc: [email-masked],[email-masked],[email-masked]
> Subject: New Version Notification for draft-ietf-sidr-rescerts-provisioning-09 
> 
> 
> A new version of I-D, draft-ietf-sidr-rescerts-provisioning-09.txt has been successfully submitted by Geoff Huston and posted to the IETF repository.
> 
> Filename:	 draft-ietf-sidr-rescerts-provisioning
> Revision:	 09
> Title:		 A Protocol for Provisioning Resource Certificates
> Creation_date:	 2010-11-11
> WG ID:		 sidr
> Number_of_pages: 31
> 
> Abstract:
> This document defines a framework for certificate management
> interactions between a resource issuer ("Issuer") and a resource
> recipient ("Subject") through the specification of a protocol for
> interaction between the two parties.  The protocol supports the
> transmission of requests from the Subject, and corresponding
> responses from the Issuer encompassing the actions of certificate
> issuance, certificate revocation and certificate status information
> reports.  This protocol is intended to be limited to the application
> of resource certificate management and is not intended to be used as
> part of a more general certificate management framework.
> 
> 
> 
> The IETF Secretariat.
> 
> 

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: George Michaelson <[email-masked]>
Date: Thu, 11 Nov 2010 11:24:26 +0800

> Given that this addresses the WG comments from today's session. I'd like to request the chairs to conduct a WG Last Call for this draft.

I support this WGLC.

-george

---

From: Andrei Robachevsky <[email-masked]>
Date: Thu, 11 Nov 2010 06:08:21 +0100

I support the WG LC.

Andrei

Geoff Huston wrote on 11/11/10 4:22 AM:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 16 Nov 2010 15:39:29 +0100

Hi Geoff,

As I listened to the recorded version of the session in Beijing, looks like there some level of consensus that it may be a good idea to add an additional "error_response" code value for "algorithm suite not supported". I believe that will help the algorithm migration process as we can write the exact process in the draft.

You could always use the code 1203, but that is a generic response to a malformed message.

Regards,

Roque

---

From: Geoff Huston <[email-masked]>
Date: Wed, 17 Nov 2010 02:21:50 +1100

On 17/11/2010, at 1:39 AM, Roque Gagliano wrote:

> As I listened to the recorded version of the session in Beijing, looks like there some level of consensus that it may be a good idea to add an additional "error_response" code value for "algorithm suite not supported".

I did not hear that as a clear consensus, and in my discussions with others who are familiar with this protocol, I tended to the opinion that there was adequate information already in the provisioning protocol to support multiple algorithms via classes.

> I believe that will help the algorithm migration process as we can write the exact process in the draft.

I am of the opinion that the protocol already has sufficient knobs to support an environment of algorithm transition without further augmentation.

The existing protocol supports:
- multiple algorithms are implemented as multiple classes
- algorithms for each class are identified in the certificate provided by the server in the response to a LIST command
- the server performs a proof of possession text using the algorithm associated with the class that was nominated in the certificate request.

  Geoff

---

From: Randy Bush <[email-masked]>
Date: Tue, 16 Nov 2010 16:53:18 +0100

> I am of the opinion that the protocol already has sufficient knobs to
> support an environment of algorithm transition without further
> augmentation.
> 
> - algorithms for each class are identified in the certificate provided
>   by the server in the response to a LIST command 
> - the server performs a proof of possession text using the algorithm
>   associated with the class that was nominated in the certificate
>   request. 

<aol>

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 18 Nov 2010 14:49:55 +0100

Hi Geoff,

Thank you for your email, please see comments inline.

> - multiple algorithms are implemented as multiple classes
(Roque) agree.
> - algorithms for each class are identified in the certificate provided by the server in the response to a LIST command
(Roque) agree. I believe you meant that as we implement top-down you could use the issuer's certificate, correct?
> - the server performs a proof of possession text using the algorithm associated with the class that was nominated in the certificate request.
(Roque) agree. And if we do not create any additional error code and if a client sends a "issue" request using a non-supported algorithm for a given class, the server will respond MUST an error code 1203: badly formed payload. correct?

I will add text describing this mechanism in the next version of the agility draft.

Regards,
Roque.

---

From: Geoff Huston <[email-masked]>
Date: Fri, 19 Nov 2010 01:28:46 +1100

> (Roque) agree. I believe you meant that as we implement top-down you could use the issuer's certificate, correct?

geoff: yes.

> (Roque) agree. And if we do not create any additional error code and if a client sends a "issue" request using a non-supported algorithm for a given class, the server will respond MUST an error cod…

Geoff: Correct. In an algorithm transition context, the client MUST use the same algorithm as used in the server (issuer's) certificate within a resource class  (as provided by the Issuer in the LIST command response), and the server will response with a 1203 error code otherwise. You can write that up in the algorithm document. 

> I will add text describing this mechanism in the next version of the agility draft.

thank you

 Geoff