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
#78: algorithm agility discussion is inadequate
Comment (by [email protected]):
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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
