Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)

[Stephen Kent <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans