Index: doc/rfc6962-bis.xml
diff --git a/doc/rfc6962-bis.xml b/doc/rfc6962-bis.xml
index eb890a73f7815f2119c7bd6f6b868b1fcd28354a..a9cd7b9388849655992e30f17f08b4f8ec3cb136 100644
--- a/doc/rfc6962-bis.xml
+++ b/doc/rfc6962-bis.xml
@@ -846,7 +846,7 @@ messages.
The version of the SignedCertificateTimestamp structure, in decimal. A compliant v1 implementation MUST NOT expect this to be 0 (i.e., v1).
- The log ID, base64 encoded. Since log clients who request an SCT for inclusion in TLS handshakes are not required to verify it, we do not assume they know the ID of the log.
+ The log ID, base64 encoded.
The SCT timestamp, in decimal.
@@ -860,7 +860,7 @@ messages.
- If the sct_version is not v1, then a v1 client may be unable to verify the signature. It MUST NOT construe this as an error. (Note: Log clients don't need to be able to verify this structure; only TLS clients do. If we were to serve the structure as a binary blob, then we could completely change it without requiring an upgrade to v1 clients.)
+ If the sct_version is not v1, then a v1 client may be unable to verify the signature. It MUST NOT construe this as an error. This is to avoid forcing an upgrade of compliant v1 clients that do not use the returned SCTs.
@@ -1126,10 +1126,10 @@ but it is expected there will be a variety.
- Submitters submit certificates or Precertificates to the log as described above. They may go on to use the returned SCT to construct a certificate or use it directly in a TLS handshake.
+ Submitters submit certificates or Precertificates to the log as described above. When a Submitter intends to use the returned SCT directly in a TLS handshake or to construct a certificate, they SHOULD validate the SCT as described in if they understand its format.
-
+
TLS clients receive SCTs alongside or in server certificates. In
addition to normal validation of the certificate and its chain, TLS clients