#78: algorithm agility discussion is inadequate

Comment (by [email protected]):

 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.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email protected]           |  [email protected]
     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:3>
trans <http://tools.ietf.org/trans/>

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

Reply via email to