From 5a2d7a8f572f4d9dcd97451964558f3991f77129 Mon Sep 17 00:00:00 2001 From: Rich Salz Date: Mon, 8 Mar 2021 11:09:58 -0500 Subject: [PATCH 1/7] Clarify server status options --- draft-ietf-trans-rfc6962-bis.md | 47 +++++++++++++++++---------------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md index 3f68e079..744523f9 100644 --- a/draft-ietf-trans-rfc6962-bis.md +++ b/draft-ietf-trans-rfc6962-bis.md @@ -1573,33 +1573,34 @@ Outputs: # TLS Servers {#tls_servers} -CT-using TLS servers MUST use at least one of the three mechanisms listed below +CT-using TLS servers MUST use at least one of the mechanisms described below to present one or more SCTs from one or more logs to each TLS client during full TLS handshakes, where each SCT corresponds to the server certificate. They SHOULD also present corresponding inclusion proofs and STHs. -Three mechanisms are provided because they have different tradeoffs. - -* A TLS extension (Section 4.2 of [RFC8446]) with type `transparency_info` - (see {{tls_transinfo_extension}}). This mechanism allows TLS servers to - participate in CT without the cooperation of CAs, unlike the other two - mechanisms. It also allows SCTs and inclusion proofs to be updated on the fly. - -* An Online Certificate Status Protocol (OCSP) [RFC6960] response extension (see - {{ocsp_transinfo_extension}}), where the OCSP response is provided in the - `CertificateStatus` message, provided that the TLS client included the - `status_request` extension in the (extended) `ClientHello` (Section 8 of - [RFC6066]). This mechanism, popularly known as OCSP stapling, is already - widely (but not universally) implemented. It also allows SCTs and inclusion - proofs to be updated on the fly. - -* An X509v3 certificate extension (see {{cert_transinfo_extension}}). This - mechanism allows the use of unmodified TLS servers, but the SCTs and inclusion - proofs cannot be updated on the fly. Since the logs from which the SCTs and - inclusion proofs originated won't necessarily be accepted by TLS clients for - the full lifetime of the certificate, there is a risk that TLS clients will - subsequently consider the certificate to be non-compliant and in need of - re-issuance. +The preferred mechanism is to use +a TLS 1.3 extension (Section 4.2 of [RFC8446]) with type `transparency_info` +(see {{tls_transinfo_extension}}). This mechanism allows TLS servers to +participate in CT without the cooperation of CAs, unlike the other two +mechanisms. It also allows SCTs and inclusion proofs to be updated on the fly. + +If the server supports TLS version 1.2 or earlier, it may use +an Online Certificate Status Protocol (OCSP) [RFC6960] response extension (see +{{ocsp_transinfo_extension}}), where the OCSP response is provided in the +`CertificateStatus` message, provided that the TLS client included the +`status_request` extension in the (extended) `ClientHello` (Section 8 of +[RFC6066]). This mechanism is popularly known as OCSP stapling. +It also allows SCTs and inclusion +proofs to be updated on the fly. + +For off-line use, +an X509v3 certificate extension (see {{cert_transinfo_extension}}). This +mechanism allows the use of unmodified TLS servers, but the SCTs and inclusion +proofs cannot be updated on the fly. Since the logs from which the SCTs and +inclusion proofs originated won't necessarily be accepted by TLS clients for +the full lifetime of the certificate, there is a risk that TLS clients will +subsequently consider the certificate to be non-compliant and in need of +re-issuance. ## Multiple SCTs {#multiple-scts} From bd576099a8d292eb77702e7724ee21db60c41fb3 Mon Sep 17 00:00:00 2001 From: Rich Salz Date: Mon, 8 Mar 2021 12:24:53 -0500 Subject: [PATCH 2/7] Update server status-sending options Address feedback from Rob and Ryan. --- draft-ietf-trans-rfc6962-bis.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md index 744523f9..e6b984ea 100644 --- a/draft-ietf-trans-rfc6962-bis.md +++ b/draft-ietf-trans-rfc6962-bis.md @@ -1578,20 +1578,21 @@ to present one or more SCTs from one or more logs to each TLS client during full TLS handshakes, where each SCT corresponds to the server certificate. They SHOULD also present corresponding inclusion proofs and STHs. -The preferred mechanism is to use +A server can provide SCT's using a TLS 1.3 extension (Section 4.2 of [RFC8446]) with type `transparency_info` (see {{tls_transinfo_extension}}). This mechanism allows TLS servers to participate in CT without the cooperation of CAs, unlike the other two mechanisms. It also allows SCTs and inclusion proofs to be updated on the fly. -If the server supports TLS version 1.2 or earlier, it may use -an Online Certificate Status Protocol (OCSP) [RFC6960] response extension (see -{{ocsp_transinfo_extension}}), where the OCSP response is provided in the -`CertificateStatus` message, provided that the TLS client included the -`status_request` extension in the (extended) `ClientHello` (Section 8 of -[RFC6066]). This mechanism is popularly known as OCSP stapling. -It also allows SCTs and inclusion -proofs to be updated on the fly. +The server may also use an Online Certificate Status Protocol (OCSP) +[RFC6960] response extension (see {{ocsp_transinfo_extension}}), +popularly known as "OCSP stapling." +For TLS +1.3, the information is encoded as an extension in the `status_request` +extension data; see Section 4.4.2.1 of [RFC8446] For TLS 1.2, the information +is encoded as an extension in the `CertificateStatus` message; see Section 8 +of [RFC6066]). This mechanism also +allows SCTs and inclusion proofs to be updated on the fly. For off-line use, an X509v3 certificate extension (see {{cert_transinfo_extension}}). This From 523d32ca40b94a53e3affc1dc9c2075da603287d Mon Sep 17 00:00:00 2001 From: Rich Salz Date: Mon, 8 Mar 2021 13:12:18 -0500 Subject: [PATCH 3/7] Remove 'for off-line use' per @agwa --- draft-ietf-trans-rfc6962-bis.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md index e6b984ea..b9ebafe5 100644 --- a/draft-ietf-trans-rfc6962-bis.md +++ b/draft-ietf-trans-rfc6962-bis.md @@ -1594,8 +1594,8 @@ is encoded as an extension in the `CertificateStatus` message; see Section 8 of [RFC6066]). This mechanism also allows SCTs and inclusion proofs to be updated on the fly. -For off-line use, -an X509v3 certificate extension (see {{cert_transinfo_extension}}). This +CT information can also be encoded as an extension in the X.509v3 certificate +(see {{cert_transinfo_extension}}). This mechanism allows the use of unmodified TLS servers, but the SCTs and inclusion proofs cannot be updated on the fly. Since the logs from which the SCTs and inclusion proofs originated won't necessarily be accepted by TLS clients for From 96f895d3c33867e82df574bae946a364fb767361 Mon Sep 17 00:00:00 2001 From: Rich Salz Date: Wed, 10 Mar 2021 13:36:06 -0500 Subject: [PATCH 4/7] Fix some typo's --- draft-ietf-trans-rfc6962-bis.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md index b9ebafe5..aaea78b9 100644 --- a/draft-ietf-trans-rfc6962-bis.md +++ b/draft-ietf-trans-rfc6962-bis.md @@ -1578,7 +1578,7 @@ to present one or more SCTs from one or more logs to each TLS client during full TLS handshakes, where each SCT corresponds to the server certificate. They SHOULD also present corresponding inclusion proofs and STHs. -A server can provide SCT's using +A server can provide SCTs using a TLS 1.3 extension (Section 4.2 of [RFC8446]) with type `transparency_info` (see {{tls_transinfo_extension}}). This mechanism allows TLS servers to participate in CT without the cooperation of CAs, unlike the other two @@ -1589,9 +1589,9 @@ The server may also use an Online Certificate Status Protocol (OCSP) popularly known as "OCSP stapling." For TLS 1.3, the information is encoded as an extension in the `status_request` -extension data; see Section 4.4.2.1 of [RFC8446] For TLS 1.2, the information +extension data; see Section 4.4.2.1 of [RFC8446]. For TLS 1.2, the information is encoded as an extension in the `CertificateStatus` message; see Section 8 -of [RFC6066]). This mechanism also +of [RFC6066]. This mechanism also allows SCTs and inclusion proofs to be updated on the fly. CT information can also be encoded as an extension in the X.509v3 certificate From d37c52526a2149f7cd2ac49710e125901f94c672 Mon Sep 17 00:00:00 2001 From: Rich Salz Date: Thu, 11 Mar 2021 07:57:58 -0500 Subject: [PATCH 5/7] Update draft-ietf-trans-rfc6962-bis.md Take Ryan's rewording improvement. Co-authored-by: sleevi --- draft-ietf-trans-rfc6962-bis.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md index aaea78b9..2535dee4 100644 --- a/draft-ietf-trans-rfc6962-bis.md +++ b/draft-ietf-trans-rfc6962-bis.md @@ -1586,7 +1586,8 @@ mechanisms. It also allows SCTs and inclusion proofs to be updated on the fly. The server may also use an Online Certificate Status Protocol (OCSP) [RFC6960] response extension (see {{ocsp_transinfo_extension}}), -popularly known as "OCSP stapling." +providing the OCSP response as part of the TLS handshake. Providing +a response during a TLS handshake is popularly known as "OCSP stapling." For TLS 1.3, the information is encoded as an extension in the `status_request` extension data; see Section 4.4.2.1 of [RFC8446]. For TLS 1.2, the information From 0e8e4c2d2902067250abd524f4b4cde4f16d7b69 Mon Sep 17 00:00:00 2001 From: Rich Salz Date: Thu, 11 Mar 2021 07:58:33 -0500 Subject: [PATCH 6/7] Update draft-ietf-trans-rfc6962-bis.md Ryan's clarity improvements. Co-authored-by: sleevi --- draft-ietf-trans-rfc6962-bis.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md index 2535dee4..08922d6f 100644 --- a/draft-ietf-trans-rfc6962-bis.md +++ b/draft-ietf-trans-rfc6962-bis.md @@ -1600,9 +1600,10 @@ CT information can also be encoded as an extension in the X.509v3 certificate mechanism allows the use of unmodified TLS servers, but the SCTs and inclusion proofs cannot be updated on the fly. Since the logs from which the SCTs and inclusion proofs originated won't necessarily be accepted by TLS clients for -the full lifetime of the certificate, there is a risk that TLS clients will +the full lifetime of the certificate, there is a risk that TLS clients may subsequently consider the certificate to be non-compliant and in need of -re-issuance. +re-issuance or the use of one of the other two methods for delivering CT +information. ## Multiple SCTs {#multiple-scts} From b5aab66ebaebae258d49ea234442307af11f14c7 Mon Sep 17 00:00:00 2001 From: Rich Salz Date: Thu, 11 Mar 2021 08:00:18 -0500 Subject: [PATCH 7/7] Slight further clarification of d37c5252 --- draft-ietf-trans-rfc6962-bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md index 08922d6f..bf0fdf34 100644 --- a/draft-ietf-trans-rfc6962-bis.md +++ b/draft-ietf-trans-rfc6962-bis.md @@ -1592,7 +1592,7 @@ For TLS 1.3, the information is encoded as an extension in the `status_request` extension data; see Section 4.4.2.1 of [RFC8446]. For TLS 1.2, the information is encoded as an extension in the `CertificateStatus` message; see Section 8 -of [RFC6066]. This mechanism also +of [RFC6066]. Using stapling also allows SCTs and inclusion proofs to be updated on the fly. CT information can also be encoded as an extension in the X.509v3 certificate