Hello Melinda,
On Tue, May 13, 2014 at 9:26 AM, Melinda Shore <[email protected]>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
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
