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

[Dmitry Belyavsky <[e-mail]>]

Hello Melinda,




On Tue, May 13, 2014 at 9:26 AM, Melinda Shore <[e-mail]>wrote:

> On 5/12/14 9:12 PM, Nico Williams wrote:
> > Incidentally, rfc6962bis could use an operational considerations
> > section covering issues such as what CAs are expected to be logged.
>
> We've talked about the possibility of breaking out client behavior
> into a separate document, and while that discussion focused on
> the protocol between a client and a log server it seems that
> this sort of thing may belong there, as well.
>
> Nobody has stepped forward to draft a document but at this point
> it would be very helpful indeed if someone could step forward and
> contribute some text.
>
>
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