Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 16:17:17 -0000

#78: algorithm agility discussion is inadequate

Comment (by [email-masked]):

 I am not clear what you are asking for. I cannot provide a long detailed
 plan for migrating from one log to another because the plan is as stated:
 freeze one log, start another one.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/78#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 23 Jul 2015 14:36:21 +0200

Ben,

The current, very brief description does not discuss a number of issues of
how a planned algorithm transition takes place. For example, if a log 
operator
wants to move to a new signature algorithm, it needs to create the new 
metadata
that points to the new log, including a new URL, new algorithm 
identifiers and
new keys. The means by which this metadata is distributed is not 
specified, but
it seems likely that the browser-vendor channel for distribution of this 
metadata
will take a little while. So, there is a need for guidance to a log operator
as to how to deal with the unknown delays for this metadata to become 
widely available.
There is also the question of when the old log is frozen relative to the new
log, and how this relates to the various types of log clients (CAs vs. 
browsers vs. Monitors).
For example, do CAs now need to get SCTs for certs from both the old and 
new logs
to ensure continuity for SCT consumers, and if so, for how long does 
this dual operation
persist?

I think this is a non-trivial problem and the current text does not 
address the sorts
of issues noted above.

Note that the RPKI published a detailed description of how a phased 
algorithm transition
is to be effected for that system. That system faces a much more 
difficult transition
task, but the principle of documenting how a staged transition with some 
established interval
lengths, still seems appropriate.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Jul 2015 12:49:39 +0000

Please note that responses to trac emails do not appear to end up in trac,
so if you want this response (and others) to be tracked, I guess you need
to update trac.

On Thu, 23 Jul 2015 at 13:36 Stephen Kent <[email-masked]> wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 24 Jul 2015 15:34:24 -0000

Comment (by [email-masked]):

 The current, very brief description does not discuss a number of issues of
 how a planned algorithm transition takes place. For example, if a log
 operator wants to move to a new signature algorithm, it needs to create
 the new
 metadata that points to the new log, including a new URL, new algorithm
 identifiers and new keys. The means by which this metadata is distributed
 is not
 specified, but it seems likely that the browser-vendor channel for
 distribution of this
 metadata will take a little while. So, there is a need for guidance to a
 log operator
 as to how to deal with the unknown delays for this metadata to become
 widely available. There is also the question of when the old log is frozen
 relative to the new
 log, and how this relates to the various types of log clients (CAs vs.
 browsers vs. Monitors). For example, do CAs now need to get SCTs for certs
 from both the old and
 new logs to ensure continuity for SCT consumers, and if so, for how long
 does
 this dual operation persist?

 I think this is a non-trivial problem and the current text does not
 address the sorts of issues noted above.

 Note that the RPKI published a detailed description of how a phased
 algorithm transition is to be effected for that system. That system faces
 a much more
 difficult transition task, but the principle of documenting how a staged
 transition with some
 established interval lengths, still seems appropriate.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/78#comment:3>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 24 Jul 2015 17:35:20 +0200

Ben,

Thanks for the reminder. I submitted my comments to the tracker entry 
for this topic.

Steve