From 8e9d65096df633b8395b6e4a55352f2d8f30179c Mon Sep 17 00:00:00 2001 From: ID Bot Date: Sun, 7 Jul 2024 02:53:25 +0000 Subject: [PATCH] Script updating gh-pages from 976551d. [ci skip] --- draft-ietf-tls-rfc8446bis.html | 154 +++++++++++++++------------------ draft-ietf-tls-rfc8446bis.txt | 104 +++++++++++----------- 2 files changed, 123 insertions(+), 135 deletions(-) diff --git a/draft-ietf-tls-rfc8446bis.html b/draft-ietf-tls-rfc8446bis.html index 0f230314..6d65e7e0 100644 --- a/draft-ietf-tls-rfc8446bis.html +++ b/draft-ietf-tls-rfc8446bis.html @@ -15,23 +15,22 @@ RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. " name="description"> - + @@ -1031,11 +1030,11 @@ Internet-Draft TLS -May 2024 +July 2024 Rescorla -Expires 28 November 2024 +Expires 8 January 2025 [Page] @@ -1054,12 +1053,12 @@ 5705, 6066, 7627, 8422 (if approved)
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Author:
@@ -1099,7 +1098,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 28 November 2024.

+ This Internet-Draft will expire on 8 January 2025.

@@ -3746,7 +3745,7 @@

algorithms with known weaknesses, specifically SHA-1 which is used in this context with either (1) RSA using RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to signatures which appear in certificates (see -Section 4.4.2.2) and are not defined for use in +Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. Endpoints SHOULD NOT negotiate these algorithms @@ -3755,7 +3754,7 @@

them as the lowest priority (listed after all other algorithms in SignatureSchemeList). TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced -without it (see Section 4.4.2.2).

+without it (see Section 4.4.2.2).

@@ -4934,12 +4933,12 @@

CertificateEntry.

-
+
-
-4.4.2.2. Server Certificate Selection +
+4.4.2.2. Certificate Selection
-

The following rules apply to the certificates sent by the server:

+

The following rules apply to the certificates sent by the client or server:

  • The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated @@ -4947,99 +4946,88 @@

  • The end-entity certificate MUST allow the key to be used for signing with -a signature scheme indicated in the client's "signature_algorithms" +a signature scheme indicated in the peer's "signature_algorithms" extension (see Section 4.2.3). That is, the digitalSignature bit MUST be set if the Key Usage extension is present, and the public key (with associated restrictions) MUST be compatible with some supported signature scheme.

  • -

    The "server_name" [RFC6066] and "certificate_authorities" extensions are used to -guide certificate selection. As servers MAY require the presence of the "server_name" -extension, clients SHOULD send this extension when the server is identified by name.

    +

    If the peer sent a "certificate_authorities" extension, at least one of the +certificates in the certificate chain SHOULD be issued by one of the listed +CAs.

-

All certificates provided by the server MUST be signed by a -signature algorithm advertised by the client, if it is able to provide such +

The following rule additionally applies to certificates sent by the client:

+
    +
  • +

    If the CertificateRequest message contained a non-empty "oid_filters" +extension, the end-entity certificate MUST match the extension OIDs +that are recognized by the client, as described in Section 4.2.5.

    +
    • +
+

The following rule additionally applies to certificates sent by the server:

+
    +
  • +

    The "server_name" [RFC6066] extension is used to guide certificate +selection. As servers MAY require the presence of the "server_name" extension, +clients SHOULD send this extension when the server is identified by name.

    +
    • +
+

All certificates provided by the sender MUST be signed by a +signature algorithm advertised by the peer, if it is able to provide such a chain (see Section 4.2.3). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as -part of the chain and therefore MAY be signed with any algorithm.

-

If the server cannot produce a certificate chain that is signed only via the +part of the chain and therefore MAY be signed with any algorithm.

+

If the sender is the server, and the server +cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending -the client a certificate chain of its choice that may include algorithms -that are not known to be supported by the client. +a certificate chain of its choice that may include algorithms that are not known +to be supported by the client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash algorithm in general, but MAY do so if the client's advertisement permits it, -and MUST NOT do so otherwise.

-

If the client cannot construct an acceptable chain using the provided +and MUST NOT do so otherwise.

+

If the sender is the client, the client MAY use a fallback chain as above, or +continue the handshake anonymously.

+

If the receiver cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an appropriate certificate-related alert (by default, -"unsupported_certificate"; see Section 6.2 for more information).

-

If the server has multiple certificates, it chooses one of them based on the -above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences).

-
-
-
-
-
-4.4.2.3. Client Certificate Selection -
-

The following rules apply to certificates sent by the client:

-
    -
  • -

    The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated -otherwise (e.g., [RFC7250]).

    -
    • -
  • -

    If the "certificate_authorities" extension in the CertificateRequest -message was present, at least one of the certificates in the certificate -chain SHOULD be issued by one of the listed CAs.

    -
    • -
  • -

    The certificates MUST be signed using an acceptable signature -algorithm, as described in Section 4.3.2. Note that this -relaxes the constraints on certificate-signing algorithms found in -prior versions of TLS.

    -
    • -
  • -

    If the CertificateRequest message contained a non-empty "oid_filters" -extension, the end-entity certificate MUST match the extension OIDs -that are recognized by the client, as described in Section 4.2.5.

    -
    • -
+"unsupported_certificate"; see Section 6.2 for more information).

+

If the sender has multiple certificates, it chooses one of them based on the +above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences).

-
+
-4.4.2.4. Receiving a Certificate Message +4.4.2.3. Receiving a Certificate Message
-

In general, detailed certificate validation procedures are out of scope for -TLS (see [RFC5280]). This section provides TLS-specific requirements.

-

If the server supplies an empty Certificate message, the client MUST abort -the handshake with a "decode_error" alert.

-

If the client does not send any certificates (i.e., it sends an empty +

In general, detailed certificate validation procedures are out of scope for +TLS (see [RFC5280]). This section provides TLS-specific requirements.

+

If the server supplies an empty Certificate message, the client MUST abort +the handshake with a "decode_error" alert.

+

If the client does not send any certificates (i.e., it sends an empty Certificate message), the server MAY at its discretion either continue the handshake without client authentication, or abort the handshake with a "certificate_required" alert. Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the -handshake (considering the client unauthenticated) or abort the handshake.

-

Any endpoint receiving any certificate which it would need to validate +handshake (considering the client unauthenticated) or abort the handshake.

+

Any endpoint receiving any certificate which it would need to validate using any signature algorithm using an MD5 hash MUST abort the handshake with a "bad_certificate" alert. SHA-1 is deprecated and it is RECOMMENDED that any endpoint receiving any certificate which it would need to validate using any signature algorithm using a SHA-1 hash abort the handshake with a "bad_certificate" alert. For clarity, this means that endpoints can accept these algorithms for -certificates that are self-signed or are trust anchors.

-

All endpoints are RECOMMENDED to transition to SHA-256 or better as soon +certificates that are self-signed or are trust anchors.

+

All endpoints are RECOMMENDED to transition to SHA-256 or better as soon as possible to maintain interoperability with implementations -currently in the process of phasing out SHA-1 support.

-

Note that a certificate containing a key for one signature algorithm +currently in the process of phasing out SHA-1 support.

+

Note that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, -an RSA key signed with an ECDSA key).

+an RSA key signed with an ECDSA key).

@@ -7309,7 +7297,7 @@

[RFC8996]
-"*** BROKEN REFERENCE ***".
+Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, , <https://www.rfc-editor.org/rfc/rfc8996>.
[SHS]
@@ -7414,7 +7402,7 @@

[FETCH]
-WHATWG, "Fetch Standard", , <https://fetch.spec.whatwg.org/>.
+WHATWG, "Fetch Standard", , <https://fetch.spec.whatwg.org/>.

[FG17]
@@ -8845,7 +8833,7 @@

For maximum compatibility with previously non-standard behavior and misconfigured deployments, all implementations SHOULD support validation of certification paths based on the expectations in this document, even when handling prior TLS versions' -handshakes (see Section 4.4.2.2).

+handshakes (see Section 4.4.2.2).

TLS 1.2 and prior supported an "Extended Main Secret" [RFC7627] extension which digested large parts of the handshake transcript into the secret and derived keys. Note this extension was renamed in Appendix D. Because TLS diff --git a/draft-ietf-tls-rfc8446bis.txt b/draft-ietf-tls-rfc8446bis.txt index d368655f..268cbaa7 100644 --- a/draft-ietf-tls-rfc8446bis.txt +++ b/draft-ietf-tls-rfc8446bis.txt @@ -4,10 +4,10 @@ Transport Layer Security E. Rescorla Internet-Draft Windy Hill Systems, LLC -Obsoletes: 8446 (if approved) 27 May 2024 +Obsoletes: 8446 (if approved) 7 July 2024 Updates: 5705, 6066, 7627, 8422 (if approved) Intended status: Standards Track -Expires: 28 November 2024 +Expires: 8 January 2025 The Transport Layer Security (TLS) Protocol Version 1.3 @@ -39,7 +39,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 November 2024. + This Internet-Draft will expire on 8 January 2025. Copyright Notice @@ -2852,72 +2852,70 @@ Auth | {CertificateVerify*} in TLS 1.2 and below. In TLS 1.3, the server's SCT information is carried in an extension in the CertificateEntry. -4.4.2.2. Server Certificate Selection +4.4.2.2. Certificate Selection - The following rules apply to the certificates sent by the server: + The following rules apply to the certificates sent by the client or + server: * The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated otherwise (e.g., [RFC7250]). * The end-entity certificate MUST allow the key to be used for - signing with a signature scheme indicated in the client's + signing with a signature scheme indicated in the peer's "signature_algorithms" extension (see Section 4.2.3). That is, the digitalSignature bit MUST be set if the Key Usage extension is present, and the public key (with associated restrictions) MUST be compatible with some supported signature scheme. - * The "server_name" [RFC6066] and "certificate_authorities" - extensions are used to guide certificate selection. As servers - MAY require the presence of the "server_name" extension, clients - SHOULD send this extension when the server is identified by name. + * If the peer sent a "certificate_authorities" extension, at least + one of the certificates in the certificate chain SHOULD be issued + by one of the listed CAs. - All certificates provided by the server MUST be signed by a signature - algorithm advertised by the client, if it is able to provide such a + The following rule additionally applies to certificates sent by the + client: + + * If the CertificateRequest message contained a non-empty + "oid_filters" extension, the end-entity certificate MUST match the + extension OIDs that are recognized by the client, as described in + Section 4.2.5. + + The following rule additionally applies to certificates sent by the + server: + + * The "server_name" [RFC6066] extension is used to guide certificate + selection. As servers MAY require the presence of the + "server_name" extension, clients SHOULD send this extension when + the server is identified by name. + + All certificates provided by the sender MUST be signed by a signature + algorithm advertised by the peer, if it is able to provide such a chain (see Section 4.2.3). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. - If the server cannot produce a certificate chain that is signed only - via the indicated supported algorithms, then it SHOULD continue the - handshake by sending the client a certificate chain of its choice - that may include algorithms that are not known to be supported by the - client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash - algorithm in general, but MAY do so if the client's advertisement - permits it, and MUST NOT do so otherwise. - - If the client cannot construct an acceptable chain using the provided - certificates and decides to abort the handshake, then it MUST abort - the handshake with an appropriate certificate-related alert (by - default, "unsupported_certificate"; see Section 6.2 for more - information). - - If the server has multiple certificates, it chooses one of them based + If the sender is the server, and the server cannot produce a + certificate chain that is signed only via the indicated supported + algorithms, then it SHOULD continue the handshake by sending a + certificate chain of its choice that may include algorithms that are + not known to be supported by the client. This fallback chain SHOULD + NOT use the deprecated SHA-1 hash algorithm in general, but MAY do so + if the client's advertisement permits it, and MUST NOT do so + otherwise. + + If the sender is the client, the client MAY use a fallback chain as + above, or continue the handshake anonymously. + + If the receiver cannot construct an acceptable chain using the + provided certificates and decides to abort the handshake, then it + MUST abort the handshake with an appropriate certificate-related + alert (by default, "unsupported_certificate"; see Section 6.2 for + more information). + + If the sender has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences). -4.4.2.3. Client Certificate Selection - - The following rules apply to certificates sent by the client: - - * The certificate type MUST be X.509v3 [RFC5280], unless explicitly - negotiated otherwise (e.g., [RFC7250]). - - * If the "certificate_authorities" extension in the - CertificateRequest message was present, at least one of the - certificates in the certificate chain SHOULD be issued by one of - the listed CAs. - - * The certificates MUST be signed using an acceptable signature - algorithm, as described in Section 4.3.2. Note that this relaxes - the constraints on certificate-signing algorithms found in prior - versions of TLS. - - * If the CertificateRequest message contained a non-empty - "oid_filters" extension, the end-entity certificate MUST match the - extension OIDs that are recognized by the client, as described in - Section 4.2.5. - -4.4.2.4. Receiving a Certificate Message +4.4.2.3. Receiving a Certificate Message In general, detailed certificate validation procedures are out of scope for TLS (see [RFC5280]). This section provides TLS-specific @@ -4855,7 +4853,9 @@ Auth | {CertificateVerify*} Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, . - [RFC8996] "*** BROKEN REFERENCE ***". + [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS + 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, + . [SHS] Dang, Q., "Secure Hash Standard", National Institute of Standards and Technology, DOI 10.6028/nist.fips.180-4, @@ -4997,7 +4997,7 @@ Auth | {CertificateVerify*} DOI 10.6028/nist.sp.800-186, February 2023, . - [FETCH] WHATWG, "Fetch Standard", May 2024, + [FETCH] WHATWG, "Fetch Standard", July 2024, . [FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero