Ben,
On Fri, 13 Nov 2015 at 17:13 Stephen Kent <[email protected]> wrote:
Ben,
Section 10 of 6962-bis-10 says:
Ifnecessary, the new log can contain existing entries from the
frozen
log, which monitors can verify are an exact match.
To me, this suggests a connection between and old log a a new one, so
they don't seem to be completely independent, as you suggest. But,
I see
you point that a new log will have new metadata and the fact that
it has
any ties to the old log is largely irrelevant (other than the somewhat
mysterious comment above).
I think it was more an observation that if you make the claim "log Y
contains all of log X" someone should probably check. :-)
Standardising that kind of claim seems a little pointless because
there are an infinite number of related claims (e.g. "log Y contains
all of log X up to entry N" or "log Y contains all of log X except
certificates of type T") and reasons for making them.
So the text in question should me omitted since there is no way for a
log to make
the claim in a standard fashion? I'm OK with that change.
There is a need to make available the metadata
for each new log to all log clients. The issue of alg agility for
log metadata
is addressed via that mechanism (which seems to be unspecified).
So, I agree that this issue can be closed, if Section 10 is
revised to explain
what I noted above.
OK. You might want to update the ticket so we don't lose this!
Here is suggested text for Section 10 to address this issue:
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
