From f5be0a19f384cb19fb95635d9e8377600cc2a594 Mon Sep 17 00:00:00 2001 From: Eran Messeri Date: Fri, 16 Jun 2017 12:02:27 +0100 Subject: [PATCH] Issue #164: Clarify roles of TLS clients. (#258) * Issue #164: Clarify roles of TLS clients. Remove repeated text about TLS clients having to validate inclusion proofs. Make it clear they SHOULD do it, though. * Implementing Rob's suggestion of splitting the section about inclusion proofs. --- draft-ietf-trans-rfc6962-bis.md | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md index 01caa27..4f440ec 100644 --- a/draft-ietf-trans-rfc6962-bis.md +++ b/draft-ietf-trans-rfc6962-bis.md @@ -1647,7 +1647,7 @@ variety. ## TLS Client {#tls_clients} -### Receiving SCTs +### Receiving SCTs and inclusion proofs TLS clients receive SCTs alongside or in certificates. TLS clients MUST implement all of the three mechanisms by which TLS servers may present SCTs (see @@ -1690,23 +1690,20 @@ one of the log's parameters. TLS clients MUST NOT consider valid any SCT whose timestamp is in the future. +### Fetching inclusion proofs {#fetching_inclusion_proofs} + +When a TLS client has validated a received SCT but does not yet possess +a corresponding inclusion proof, the TLS client MAY request the inclusion +proof directly from a log using `get-proof-by-hash` ({{get-proof-by-hash}}) or +`get-all-by-hash` ({{get-all-by-hash}}). Note that this will disclose to the +log which TLS server the client has been communicating with. + ### Validating inclusion proofs {#validating_inclusion_proofs} -After validating a received SCT, a TLS client MAY request a corresponding -inclusion proof (if one is not already available) and then verify it. An -inclusion proof can be requested directly from a log using `get-proof-by-hash` -({{get-proof-by-hash}}) or `get-all-by-hash` ({{get-all-by-hash}}), but note -that this will disclose to the log which TLS server the client has been -communicating with. - -Alternatively, if the TLS client has received an inclusion proof (and an STH) -alongside the SCT, it can proceed to verifying the inclusion proof to the -provided STH. The client then has to verify consistency between the provided STH -and an STH it knows about, which is less sensitive from a privacy perspective. - -TLS clients SHOULD also verify each received inclusion proof (see -{{verify_inclusion}}) for which they have the corresponding log's parameters, to -audit the log and gain confidence that the certificate is logged. +When a TLS client has received, or fetched, an inclusion proof (and an STH), +it SHOULD proceed to verifying the inclusion proof to the provided STH. +The TLS client SHOULD also verify consistency between the provided STH +and an STH it knows about. If the TLS client holds an STH that predates the SCT, it MAY, in the process of auditing, request a new STH from the log ({{get-sth}}), then verify it by