Opened 8 years ago

Last modified 7 years ago

#15 new task

Client behaviour specification needed

Reported by: beldmit@… Owned by:
Priority: major Milestone:
Component: client-behavior Version:
Severity: - Keywords:
Cc:

Description

In case the TLS client gets more than one SCTs, it seems to be reasonable to ignore the ones that couldn't be validated by this client (for example, because the log server's algorithm is not supported by the client).

Change History (7)

comment:1 Changed 7 years ago by eranm@…

My understanding is you suggest the spec would explicitly state that clients are allowed to ignore SCTs that couldn't be validated by this client (unknown log or signature algorithm). Is that correct?

A TLS client enjoy's CT's benefits if it sees at least one valid SCT with the certificate. It can't do anything with SCTs from unknown logs.
As for SCTs from known logs which don't validate, do you see anything useful that can be done with them? Seems safe to allow ignoring those too, as that essentially means the log did not sign them.

comment:2 Changed 7 years ago by benl@…

Comment 1 is correct.

comment:3 Changed 7 years ago by benl@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to benl@…
  • Status changed from new to assigned

comment:4 Changed 7 years ago by beldmit@…

Here are my suggestions:

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.
  1. The client MUST ignore all the SCTs provided by unknown logs.
  1. TLS clients MUST reject SCTs whose timestamp is in the future.
  1. If no SCTs has left after steps 2-3, the client SHOULD reject the connection.
  1. 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.

comment:5 Changed 7 years ago by eranm@…

Note: This should be a part of the client behaviour document (but the list of situations here is useful for specifying in rfc6962-bis, just without the client behaviour details).

comment:6 Changed 7 years ago by eranm@…

  • Owner benl@… deleted
  • Status changed from assigned to new

comment:7 Changed 7 years ago by melinda.shore@…

  • Component changed from rfc6962-bis to client-behavior
Note: See TracTickets for help on using tickets.