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

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Dec 2015 10:39:51 -0500

> #78: algorithm agility discussion is inadequate
>
>
> Comment (by [email-masked]):
>
>   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.