Hi SIDR WG,
I just submitted the first version of the algorithm agility document.
I submit it as an individual contribution, but it is my understanding that the
group has already decided to take this as a working item. I kindly request the
WG chairs to indicate if there is still a need to request WG adoption or I can
go ahead and submit it as a WG item.
Going to the content, the document documents what has been presented in
Maastricht and discussed in the mailing list. There are some sections that
still need to be completed, particularly on how to sync. the different CAs
during the transition for both the CAs and the RPs.
I do have two requests for the provisioning protocol draft, that is a
consequence of the decision to adopt the "lazier faire" mode taken in
Maastricht:
- As any subordinate CA can start the transition at any given time without
waiting to its parent CA to be able to issue certificates using the new
algorithm suite, we need a way in the provisioning protocol for the subordinate
CA to indicate which signing algorithm the parent CA should use to process a
particular request. This could be implemented this way:
- in the "issue" message, add an optional attribute:
"signing_algorithm=OID"
<request
class_name="class name"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set"
cert_signing_algorithm="OID">
[Certificate request]
</request>
Behavior from issuing CA: if the cert_signing_algorithm is specified and
supported, use that OID. If the cert_signing_algorithm not specify, use
"current" algorithm. If the cert_signing_algorithm not supported, reply with a
"Request-Not-Performed" message with error code:
1401 request - request - signing algorithm not supported.
- In order for the transition process to happen without any "off-line"
communication between CAs on when are they going to be able to handle requests
using the "new" algorithm sets, it may be a good idea to include in the
provisioning protocol the possibility to ask the server about its capabilities.
Another option is just to try to issue a certificate with the new suite and see
if you receive an error "core 1401".
I look forward for your comments,
Roque
Begin forwarded message:
> From: IETF I-D Submission Tool <[email protected]>
> Date: October 18, 2010 2:31:30 AM GMT+02:00
> To: [email protected]
> Cc: [email protected], [email protected]
> Subject: New Version Notification for
> draft-rgaglian-sidr-algorithm-agility-00
>
>
> A new version of I-D, draft-rgaglian-sidr-algorithm-agility-00.txt has been
> successfully submitted by Roque Gagliano and posted to the IETF repository.
>
> Filename: draft-rgaglian-sidr-algorithm-agility
> Revision: 00
> Title: Algorithm Agility Procedure for RPKI.
> Creation_date: 2010-10-18
> WG ID: Independent Submission
> Number_of_pages: 22
>
> Abstract:
> This document specifies the process that Certificate Authorities
> (CAs) and Relying Parties (RP) participating in the Resource Public
> Key Infrastructure (RPKI) will need to follow to transition to a new
> (and probably cryptographically stronger) algorithm set. The process
> is expected to be completed in a time scale of months or years.
> Consequently, no emergency transition is specified.
>
>
>
> The IETF Secretariat.
>
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
