Dimitry,
Thanks for posting the list below.
I have become very concerned that the doc we're working on describes a
mechanism,
but we seem to lack a good description of the architectural context in
which CT
is supposed to work. The intro text for the I-D is not at all adequate
for this.
Maybe the charter for this WG would have included the need to publish a
doc of
this sort if we had gone through the usual BoF process :-).
I'd like to see a doc that addresses a number of points that are now
beginning to
be raised by several folks:
- who is expected to operate logs, does every log cover all CAs, is one
log per CA (even if operated by someone else) adequate, how are users
supposed to
select logs (what the UI like?), etc.
- how are browsers expected to deal with missing SCTs, missing or
non-matching
log entries, (crypto) invalid log entries, etc. are browser actions
supposed to be
effect in real time or is this deferred activity model?
- hard fail vs. warnings for CT "exceptions?"
- how are browsers expected to deal with certs from CAs that are not
part of the Web PKI?
- what are the fallback plans if some number of the Web PKI CAs
elect to not
participate?
- same question for major browser vendors?
- what are the plans for alg aglity, for logs?
CT is a system, not just a handful of mechanisms. It needs to be
described that way.
Although not perfect, I suggest the set of RFCs that describe the RPKI
is illustrative
of the many aspects of a global system (with PKI aspects) that need to
be documented.
Steve
Here are my ideas about "strict" behaviour of the TLS client:
==============
TLS clients supporting CT are supposed to have a preconfigured set of
logs and
their public keys.
In addition to normal validation of the certificate and its chain,
they should
validate the SCTs received during the TLS connection.
The client fully conforming to the specification SHOULD perform the
following
steps before establishing the connection for every certificate in the
chain:
1. If no SCTs are provided, the client SHOULD reject the connection.
2. The client MUST ignore all the SCTs provided by unknown logs.
3. TLS clients MUST reject SCTs whose timestamp is in the future.
4. If no SCTs has left after steps 2-3, the client SHOULD reject the
connection.
5. If any of SCTs left after steps 2-3 has invalid signature, the
client SHOULD reject the connection.
Client MAY check whether the certificate is present in the log
corresponding to the passed SCT.
If the certificate is not present in the log, the connection MUST be
rejected.
=============
Can it be a starting point or you want something else?
--
SY, Dmitry Belyavsky
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
