Subject: Re: [sidr] Operations Directorate Review of draft-ietf-sidr-keyroll-06

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Jun 2011 13:53:49 -0400

Elwyn,

>Nits/editorial comments:
>s4, s4.1 and s4.2:
>The  term 're-issue' is used in this section regarding the new
>certificates that the CA creates, e.g. in s4.1:
>>When a CA, as part of the key rollover process, re-issues a CA
>>    certificate,
>The term 're-issues' might be slightly confusing. Its a new certificate
>but with lots of fields the same.  I would be inclined to go with
>'issues new' but its a quibble.

There is not uniform terminology for describing this sort of process 
in the PKI world, but the term "reissue" (or re-issue) is reasonable. 
(It is distinct from cert "renewal," which implies a new cert with 
the same key and all attributes remaining constant except for the 
validity interval and serial number. Cert "re-key" refers to issuing 
a new cert with a new key, new serial number, maybe a new validity 
interval, but the same Subject name and other attributes remaining 
constant.)  Also, we use the same terminology in several other SIDR 
docs, e.g., draft-ietf-sidr-repos-struct-07.txt, 
draft-ietf-sidr-ta-07,  draft-ietf-sidr-res-certs-18, and in an 
analogous context in draft-ietf-sidr-rpki-manifests-11.txt.

Steve

---------------------

Bert,

Responses to your comments below:

>...
>
>RFC5706 suggests but does not require a separate
>"operational considerations section".
>
>The draft-ietf-sidr-keyroll-06 discusses the operational considerations
>in the "Security Considerations" section. I can live with that and leave it
>to the OPS ADs if they rather see that split out in a separate section
>or not.

Thanks.

>
>Substantive comments/questions:
>
>- last para on page 4
>
>    During the transition of the "current" and "new" CA instances it is
>    necessary for the "new" CA instance to re-issue all subordinate
>    products of the "current" CA.  The procedure described here requires
>
>    I wonder if the "requires" should be a "REQUIRES" (yep, I know that
>    rfc2119 does not have that exact capitalized form of require, but I
>    think that a MUST or REQUIRED is intended here, no?)?

How about:

     During the transition of the "current" and "new" CA instances the "new"
     CA instance MUST re-issue all subordinate products of the "current" CA. 

>- page 6
>       4.  The NEW CA enters a Staging Period.  This duration of the
>           Staging Period is determined by the CA, but it SHOULD be no
>           less than 24 hours.
>    Does/would it make sense to also suggest/recommend a max period?
>    Would 48 hours make sense?

A recommended max period is probably a good idea, since relying parties are
burdened by having to deal with two sets of signed objects. If my 
co-author does not object, I would revise the text as follows:

4.        The NEW CA enters a Staging Period.  This duration of the
           Staging Period is determined by the CA, but it SHOULD be no
           less than 24 hours.  (It is RECOMMENDED that the staging period
	  be no longer than 48 hours.) ...

>
>- given the first para in sect 1, I wonder if ID.ietf-sidr-arch should be
>    a normative instead of a informative reference.

OK, that's an easy change.

>Editorial/nits:
>
>- sect 1. 1st sentence
>    This document describes an algorithm to by employed by a
>
>    s/by/be/  (the first occurrence of "by")

OK.

>- page 4, at top:
>   CURRENT:
>       The CURRENT CA is the active CA instance used to accept and
>       process certificate issuance and revocation requests The starting
>
>   s/requests/requests./

OK.

>- page 5
>    expand acronym CPS on its first use in this document.

      used in the CURRENT CA certificate.  The Certificate Practice
      Statement  (CPS) for the issuer of the NEW CA certificate will
      indicate the time frame within which a certificate request is
      expected to be processed.

>- same for AIA acronym on page 6.

       -  Generate a new key pair, and generate an associated EE
          certificate request with an Authority Information Access (AIA)
          value of the NEW CA's repository publication point. 

>- page 6:
>   4.  The NEW CA enters a Staging Period.  This duration of the
>
>   s/This duration of the/The duration of this/

OK

>- page 8
>    expand acronym CMS on its first use in this document.

      (If the signing time or binary signing time values in the Cryptograpic
      Message Syntax (CMS) wrapper are non-null, they MAY be updated to
      reflect the current time.)

Steve

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 01 Jun 2011 22:02:28 +0100

Hi.

Stephen Kent wrote:
> (It is distinct from cert "renewal," which implies a new cert with the 
> same key and all attributes remaining constant except for the validity 
> interval and serial number. Cert "re-key" refers to issuing a new cert 
> with a new key, new serial number, maybe a new validity interval, but 
> the same Subject name and other attributes remaining constant.)  Also, 
> we use the same terminology in several other SIDR docs, e.g., 
> draft-ietf-sidr-repos-struct-07.txt, draft-ietf-sidr-ta-07,  
> draft-ietf-sidr-res-certs-18, and in an analogous context in 
> draft-ietf-sidr-rpki-manifests-11.txt.
>
> Steve
>

OK.

Stick with what you've used.. consistency is wise.

Regards,
Elwyn

---

From: Geoff Huston <[email-masked]>
Date: Thu, 2 Jun 2011 08:04:26 +1000

On 02/06/2011, at 7:02 AM, Elwyn Davies wrote:

>> There is not uniform terminology for describing this sort of process in the PKI world, but the term "reissue" (or re-issue) is reasonable.  (It is distinct from cert "renewal," which implies a new cert with the same key and all attributes remaining constant except for the validity interval and serial number. Cert "re-key" refers to issuing a new cert with a new key, new serial number, maybe a new validity interval, but the same Subject name and other attributes remaining constant.)  Also, we use the same terminology in several other SIDR docs, e.g., draft-ietf-sidr-repos-struct-07.txt, draft-ietf-sidr-ta-07,  draft-ietf-sidr-res-certs-18, and in an analogous context in draft-ietf-sidr-rpki-manifests-11.txt.
>> 
>> Steve
>> 
> 
> OK.
> 

ok - thanks

  Geoff

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 2 Jun 2011 00:21:28 +0200

Re: Operations Directorate Review of draft-ietf-sidr-keyroThanks, and your suggested changes do address al my comments/concerns/questions,

bert
  ----- Original Message ----- 
  From: Stephen Kent 
  To: Bert (IETF) Wijnen ; [email-masked] ; [email-masked] 
  Cc: Geoff Huston ; [email-masked] ; [email-masked] ; Romascanu, Dan (Dan) ; Ron Bonica ; [email-masked] 
  Sent: Wednesday, June 01, 2011 7:53 PM
  Subject: Re: Operations Directorate Review of draft-ietf-sidr-keyroll-06

  Elwyn,

    Nits/editorial comments:
    s4, s4.1 and s4.2:

  Steve

  ---------------------

  Bert,

    ...

  Thanks.

    - last para on page 4

  How about:

    - page 6

  A recommended max period is probably a good idea, since relying parties are
  burdened by having to deal with two sets of signed objects. If my co-author does not object, I would revise the text as follows:

    Editorial/nits:

    - sect 1. 1st sentence

  OK.

    - page 4, at top:
      CURRENT:

      s/requests/requests./

  OK.

    - page 5

    - page 6:

  OK

    - page 8

  Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 2 Jun 2011 14:49:26 +1000

Given that during the staging period the only things that are published are the CA, the CRL and the Manifest for the new CA (sobordinate products are only published on the expiration of the staging period when the actual cutover happens), then relying parties are not burdened by having to deal with two sets of signed products. In many ways the staging period is a "pre-loaded new key in waiting" and in theory could be held in this state indefinitely. 

So I wonder:

 a) why a max period is necessary to stipulate, and 

 b) if it is necessarily a good idea, then is this a substantive change that means that the document should head back to the WG for a review?

My personal opinion is that this is harmless and it is not necessary to alter the document to specify a max period.

    Geoff

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 2 Jun 2011 11:59:39 +0200

Ok Geoff, thanks for the explanation.
I am not as intimately familiar with the technical details here as you guys are,
so I hope Stephen and you can come to agreement on that.

If nothing else, maybe add that explanation that you gave below in one form or
another. It shows that you've thought about it and explains why you do list
a minimum time but not a max.

Bert
----- Original Message ----- 
From: "Geoff Huston" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "George Michaelson" 
<[email-masked]>; <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>; 
"Ron Bonica" <[email-masked]>; <[email-masked]>; "Bert Wijnen (IETF)" 
<[email-masked]>
Sent: Thursday, June 02, 2011 6:49 AM
Subject: Re: Operations Directorate Review of draft-ietf-sidr-keyroll-06

I will make all the noted changes to -07 of this document - except the 
following, which I would like to discuss:

> burdened by having to deal with two sets of signed objects. If my co-author 
> does not object, I would revise the text as follows:

Given that during the staging period the only things that are published are the 
CA, the CRL and the Manifest for the new CA (sobordinate products are only 
published on the expiration of the staging period when the actual cutover 
happens), then relying parties are not burdened by having to deal with two sets 
of signed products. In many ways the staging period is a "pre-loaded new key in 
waiting" and in theory could be held in this state indefinitely.

So I wonder:

 b) if it is necessarily a good idea, then is this a substantive change that 
means that the document should head back to the WG for a review?

My personal opinion is that this is harmless and it is not necessary to alter 
the document to specify a max period.

    Geoff

---

From: Stephen Kent <[email-masked]>
Date: Thu, 2 Jun 2011 09:48:34 -0400

>Given that during the staging period the only things that are 
>published are the CA, the CRL and the Manifest for the new CA 
>(sobordinate products are only published on the expiration of the 
>staging period when the actual cutover happens), then relying 
>parties are not burdened by having to deal with two sets of signed 
>products. In many ways the staging period is a "pre-loaded new key 
>in waiting" and in theory could be held in this state indefinitely.
>
>So I wonder:
>
>  b) if it is necessarily a good idea, then is this a substantive 
>change that means that the document should head back to the WG for a 
>review?
>
>My personal opinion is that this is harmless and it is not necessary 
>to alter the document to specify a max period.
>
>     Geoff

Upon further reflection, I agree with Geoff's observation that the burden on
RPs is pretty minimal, since we're talking about only 3 objects (CA 
cert, a null CRL, and a trivial manifest).  So, I am less inclined to 
stipulate a max period,
although I don't think it would be bad to suggest (as implementation guidance)
that a few days (as Terry suggested) is probably sufficient.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Fri, 3 Jun 2011 10:05:20 +1000

Thanks Bdert,

I'll add the text:

"As the Staging Period imposes no additional burden on Relying Parties, there is no stipulated or recommended maximum Staging Period."

Geoff

On 02/06/2011, at 7:59 PM, Bert Wijnen (IETF) wrote:

> ----- Original Message ----- From: "Geoff Huston" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; "George Michaelson" <[email-masked]>; <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>; "Ron Bonica" <[email-masked]>; <[email-masked]>; "Bert Wijnen (IETF)" <[email-masked]>

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 3 Jun 2011 10:35:41 +0200

Great and thanks.

Bert
----- Original Message ----- 
From: "Geoff Huston" <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "George Michaelson" <[email-masked]>; <[email-masked]>;
"Romascanu, Dan (Dan)" <[email-masked]>; "Ron Bonica" <[email-masked]>;
<[email-masked]>
Sent: Friday, June 03, 2011 2:05 AM
Subject: Re: Operations Directorate Review of draft-ietf-sidr-keyroll-06

Thanks Bdert,

I'll add the text:

"As the Staging Period imposes no additional burden on Relying Parties, there is
no stipulated or recommended maximum Staging Period."

Geoff

On 02/06/2011, at 7:59 PM, Bert Wijnen (IETF) wrote:

> Given that during the staging period the only things that are published are
> the CA, the CRL and the Manifest for the new CA (sobordinate products are only
> happens), then relying parties are not burdened by having to deal with two
> sets of signed products. In many ways the staging period is a "pre-loaded new
> key in waiting" and in theory could be held in this state indefinitely.
>
> So I wonder:
>

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]