Ben,
I agree that some aspects of CT operation are procedural matters that fall
outside the scope of what the IETF usually specifies when defining a
protocol.
But, readers cannot evaluate the effectiveness of a proposed system (CT is
a system, not just a protocol) without a clear picture of what the system
designers envision wrt to operational issues. You might want to look at
the suite
of RFCs published by the SIDR WG, defining the RPKI, as an example of
how to address
the full range of issues associated with a big, complex system. Most of
the RFCs are
standards track, but a few are informational; together they provide a
fairly clear
picture of what is expected of each element of the system, and how the
elements
are intended to work together. Topics such as key rollover were party of
the initial
set of RFCs, as well as discussion of the expected frequency with which
relying
parties would query repositories, etc.
I don't agree that specifying behavior for browsers is out of scope for this
WG. (Pardon me if I misunderstood part of your response.) To define the
CT system
one needs to specify behavior for TLS servers, TLS clients, Web PKI
CAs, log operators,
monitors, and Auditors. The current doc does some of this, but there are
a number of gaps.
If browser vendors are to play a major role in managing config info in
support info
for CT, e.g, providing pointers to log and public key for logs, then
this should be
stated explicitly.
I've just completed a detailed analysis of the CT I-D and will begin
posting my comments,
questions, and suggested edits on Monday. No need to dump this on the
list on a Friday :-).
The analysis is about 18 pages, so I'll break it into separate messages,
each dealing with
a section of the I-D, plus a message offering overall comments.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
