#78: algorithm agility discussion is inadequate
Comment (by [email protected]):
It seems to me that the misleading text is what Steve quotes:
"If necessary, the new log can contain existing entries from the frozen
log, which monitors can verify are an exact match.".
I've changed the text in my pull request to clarify that the old and new
log are unrelated - that certificates in the old log that haven't expired
and still require valid SCTs should be re-logged in the new log and SCTs
from the new log used.
Is that adequate?
not quite. here is the text I supplied for a revised alg agility section,
in my reply to Ben on 11/16:
The term "algorithm agility" refers to mechanism and procedures that enable
use of different sets of algorithms within a protocol or system. It also
often
encompasses the transition from one set of cryptographic algorithms to
another,
in a fashion that avoids service disruption.
All of the cryptographic algorithms defined for use with CT are
represented as log metadata. None of these algorithms can be changed for
an extant log. When a new log is created the log operator MUST specify
all of the cryptographic algorithms as part of the metadata for that
log. This metadata MUST be made available to all log clients. For TLS
clients that are web browsers, CT relies on browser vendors to convey
this metadata to the clients. For all other log clients, the means of
disseminating log metadata is undefined.
The set of cryptographic algorithms initially specified for CT (in RFC
XXXX) will change
over time. New, standard algorithms will be published as (standards
track) RFCs. Log
operators and clients will be required to support these algorithms (for
new logs)
during a time frame specified by these RFCs.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
