Subject: [sidr] Proposed amendement to draft-ietf-sidr-keyroll

From: Geoff Huston <[email-masked]>
Date: Thu, 30 Sep 2010 07:13:13 +1000

I received a comment back in July from Tim Bruijnzeels that step 3 of the keyroll document 
that the document lacked details in step 3 of the described procedure and in particular that 
the procedure should note that step 3 includes the publication of the empty CRL and the 
initial manifest for the NEW CA.

In response to this comment I'd like to propose altering the document such that step 3 of 
the procedure as follows:

Current:

      3.   Request the entity's Issuer to generate and publish a NEW CA
           certificate, with an issuer-selected Subject Name that is
           distinct from the Subject Name used in the CURRENT CA
           certificate for this entity.

Proposed:

      3.   Request the entity's Issuer to generate and publish a NEW CA
           certificate, with an issuer-selected Subject Name that is
           distinct from the Subject Name used in the CURRENT CA
           certificate for this entity.

              A more detailed view of this step is to:

              -  Wait for the superior CA to publish the NEW CA
                 certificate, and store the URL of the NEW CA's
                 publication point as the NEW CA's repository
                 publication point.

              -  Use the key pair associated with the NEW CA to generate
                 an initial empty CRL, and publish this CRL in the NEW
                 CA's repository publication point.

              -  Generate a new key pair, and form an associated EE
                 certificate request, with an AIA value of the NEW CA's
                 repository publication point, pass this EE certificate
                 request to the NEW CA, and mark the returned EE
                 certificate as the manifest EE certificate.

              -  Generate a manifest containing the published CRL as the
                 only entry, and sign it with the private key associated
                 with the manifest EE certificate, generate the CMS
                 signing object for the manifest which includes the EE
                 certificate and publish the manifest at the NEW CA's
                 repository publication point.

              -  If the NEW CA has opted to use a single-use EE
                 certificate for the manifest, discard the key pair
                 associated with the manifest EE certificate.

I'm unsure as to the appropriate level of detail of the description of this procedure,
so I'm asking others for comments as to whether this proposed additional level is
getting too far into the specific implementation details, or whether this additional
information is helpful in the context of the document's overall purpose.

thanks,

   Geoff

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Sep 2010 17:45:35 -0400

Geoff,

I don't recall if I sent this proposed, revised version to you, or 
not. Anyway, here it is. I apologize that I "accepted" all of my 
changes, so you'll need to do a diff to see the edits that I made.

My proposed changes reduce the number of discrete steps, both by 
combining some steps, and by changing the order of some operations

Steve

---

From: Geoff Huston <[email-masked]>
Date: Fri, 1 Oct 2010 07:07:53 +1000

Steve,

Thank you for these revisions to the draft - I've made the changes to the draft and I'll shortly be submitting a -01 version of the draft with this and the proposed change I noted on the mailing list yesterday.

regards,

   Geoff

On 30/09/2010, at 7:45 AM, Stephen Kent wrote:

> Geoff,
> 
> I don't recall if I sent this proposed, revised version to you, or not. Anyway, here it is. I apologize that I "accepted" all of my changes, so you'll need to do a diff to see the edits that I made.
> 
> My proposed changes reduce the number of discrete steps, both by combining some steps, and by changing the order of some operations
> 
> Steve<draft-huston-key-roll-rev.txt>