RFC 6460

Suite B Profile for Transport Layer Security (TLS)

📅 published January 2012, from ietf

Suite B Profile for Transport Layer Security (TLS) 🎀

okay bestie, let's start with the vibes ✨ This is RFC 6460, Suite B Profile for Transport Layer Security (TLS), from the IETF, dated January 2012 🌸

  • Authors: M. Salter (National Security Agency) and R. Housley (Vigil Security) 👑
  • Category: Informational, so it's published for info, not as a Standards Track spec 🫶
  • Obsoletes: RFC 5430 🦋
  • ISSN: 2070-1721 💜

Abstract 🌸

so the United States government put out guidelines called "NSA Suite B Cryptography," and they set the cryptographic algorithm policy for national security applications 🇺🇸 this doc defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B 💅

Status of This Memo 📋

this one is not an Internet Standards Track spec, it's published for informational purposes 🧚

it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🙌 not every IESG-approved doc is a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🍓

for info on the current status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6460 🔥

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please actually read those, they spell out your rights and restrictions 🙈 any Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💖

also, this doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. so unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either, except to format it for publication as an RFC or to translate it into languages other than English 🫶

Table of Contents 🗺️

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Suite B Requirements ............................................3
   3.1. Minimum Levels of Security (minLOS) for Suite B TLS ........4
   3.2. Suite B TLS Authentication .................................5
4. Suite B Compliance and Interoperability Requirements ............5
   4.1. Acceptable Curves ..........................................6
   4.2. Certificates ...............................................7
   4.3. signature_algorithms Extension .............................7
   4.4. CertificateRequest Message .................................8
   4.5. CertificateVerify Message ..................................8
   4.6. ServerKeyExchange Message Signature ........................8
5. Security Considerations .........................................8
6. Acknowledgments .................................................9
7. References ......................................................9
   7.1. Normative References .......................................9
   7.2. Informative References ....................................10
Annex A. A Transitional Suite B Profile for TLS 1.1 and 1.0 .......11
Annex B. Changes since RFC 5430 ...................................13

1. Introduction ✨

okay so this doc specifies the conventions for using National Security Agency (NSA) Suite B Cryptography [SuiteB] with Transport Layer Security (TLS), and with Datagram Transport Layer Security (DTLS) too 🦋

it does not define any new cipher suites 🙅‍♀️ instead, it defines a Suite B compliant profile for use with TLS version 1.2 [RFC5246], DTLS version 1.2 [RFC6347], and the cipher suites defined in [RFC5289]. this profile uses only Suite B algorithms 💅

RFC 5430 defined an extra transitional profile for TLS versions 1.0 [RFC2246] and 1.1 [RFC4346], or for DTLS version 1.0 [RFC4347] and the cipher suites defined in [RFC4492] 🍓 if either the client or the server doesn't support TLS version 1.2 and DTLS version 1.2, the transitional profile can get you interoperability that isn't Suite B compliant. the description for it lives in Annex A of this doc 🌸

2. Conventions Used in This Document 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119] 💜

we'll use the notation "ECDSA-256" for the Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256 curve and the SHA-256 hash function ✨ and "ECDSA-384" means ECDSA with the P-384 curve and the SHA-384 hash function 🔥

3. Suite B Requirements 🎀

the Fact Sheet on Suite B Cryptography asks for key establishment and authentication algorithms based on Elliptic Curve Cryptography, and for encryption using AES [AES] 🧚 Suite B algorithms are defined to support two minimum levels of security: 128 and 192 bits 💖

here's what Suite B includes 👑

Encryption:         Advanced Encryption Standard (AES) [AES] --
                    FIPS 197 (with key sizes of 128 and 256 bits)

Digital Signature:  Elliptic Curve Digital Signature Algorithm
                    (ECDSA) [DSS] - FIPS 186-3 (using the curves
                    with 256- and 384-bit prime moduli)

Key Exchange:       Elliptic Curve Diffie-Hellman (ECDH) - NIST
                    Special Publication 800-56A [PWKE] (using the
                    curves with 256- and 384-bit prime moduli)

the two elliptic curves in Suite B each show up in the literature under two different names 🦋 for clarity, here are both names 🌈

Curve    NIST name   [SECG] name
--------------------------------
P-256    nistp256    secp256r1
P-384    nistp384    secp384r1

the purpose of this doc is to specify the requirements for a Suite B compliant implementation of TLS (from here on called "Suite B TLS") 💅

3.1. Minimum Levels of Security (minLOS) for Suite B TLS 🔐

Suite B gives you two levels of cryptographic security: a 128-bit minimum level of security (minLOS_128) and a 192-bit minimum level of security (minLOS_192) 🌸 each level sets a minimum strength that every cryptographic algorithm has to reach 💪

these are the combinations of algorithms and key sizes used in Suite B TLS ✨

Suite B Combination 1              Suite B Combination 2
--------------------------------   --------------------------------
AES with 128-bit key in GCM mode   AES with 256-bit key in GCM mode
ECDH using the 256-bit prime       ECDH using the 384-bit prime
   modulus curve P-256 [DSS]          modulus curve P-384 [DSS]
TLS PRF with SHA-256 [SHS]         TLS PRF with SHA-384 [SHS]

okay this part is important 🚨 Suite B TLS configured at a minimum level of security of 128 bits MUST use a TLS cipher suite that satisfies either SuiteB_Combination_1 in its entirety or SuiteB_Combination_2 in its entirety 🫶

Suite B TLS configured at a minimum level of security of 192 bits MUST use a TLS cipher suite that satisfies SuiteB_Combination_2 in its entirety 💖

the specific Suite B compliant cipher suites for each combination are listed in Section 4 🧚

for Suite B TLS, ECDH uses the Ephemeral Unified Model Scheme with cofactor set to 1 (see Section 6.1.2.2 in [PWKE]) 🦋

for backward compatibility, a Suite B TLS client or server MAY be configured to accept a cipher suite that isn't part of Suite B 🌈 but whenever a Suite B TLS client and a Suite B TLS server establish a TLS version 1.2 session, Suite B algorithms MUST be used 💅

3.2 Suite B TLS Authentication 🔑

okay the big rule: Suite B TLS MUST use ECDSA for digital signatures, and authentication methods other than ECDSA-256 and ECDSA-384 MUST NOT be used for TLS authentication 🚫 if a relying party gets a signature based on any other authentication method, it MUST return a TLS error and stop the TLS handshake 💀

a system that's compliant with Suite B TLS and configured at a minimum level of security of 128 bits MUST use either ECDSA-256 or ECDSA-384 for client or server authentication 🌸 one party can authenticate with ECDSA-256 while the other authenticates with ECDSA-384 ✨ that flexibility lets a client and a server with ECDSA authentication keys of different sizes still interoperate 🫶

clients and servers in a system configured at a minimum level of security of 128 bits MUST be able to verify ECDSA-256 signatures, and they SHOULD be able to verify ECDSA-384 signatures too, unless it's absolutely certain the implementation will never need to verify certificates from an authority that uses an ECDSA-384 signing key 🔥

a system that's compliant with Suite B TLS and configured at a minimum level of security of 192 bits MUST use ECDSA-384 for client and server authentication 👑

clients and servers in a system configured at a minimum level of security of 192 bits MUST be able to verify ECDSA-384 signatures 🧚

in all cases, the client MUST authenticate the server 💜 the server MAY authenticate the client, as needed by the specific application 🎀

more of this spec is coming in part 2, bestie 💖🦋

4. Suite B Compliance and Interoperability Requirements ✨

okay so bestie, let's talk about the good stuff 💅 TLS 1.1 and earlier can't do Galois/Counter Mode (GCM) cipher suites [RFC5289] 😭 but TLS 1.2 [RFC5246] and later totally can 🙌 so for Suite B TLS, GCM cipher suites MUST be used, which means a Suite B TLS client MUST implement TLS version 1.2 or later. no cap, that's the whole vibe 🎀

A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite is the preferred one 🦋 so if it's offered, it MUST appear before the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite.

If it's configured at a minimum level of security of 192 bits, the client MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite and MUST NOT offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite 🔥 very strict, very iconic.

One of these two cipher suites MUST be the first (most preferred) cipher suite in the ClientHello message 👑 A Suite B TLS client that wants to interoperate with servers that are not Suite B compliant MAY offer additional cipher suites, but any additional cipher suites MUST appear after the two Suite B compliant cipher suites in the ClientHello message 🫶

A Suite B TLS server MUST implement TLS version 1.2 or later 💖

A Suite B TLS server configured at a minimum level of security of 128 bits MUST accept either the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite or the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite if it is offered in the ClientHello message, with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite being preferred 🌸

A Suite B TLS server configured at a minimum level of security of 192 bits MUST accept the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite if it is offered in the ClientHello message 🧚

If the server isn't offered either of the Suite B cipher suites, and it wants to interoperate with clients that are not Suite B compliant, then the Suite B TLS server MAY accept another offered cipher suite that the server administrator considers acceptable 💜

4.1. Acceptable Curves 🌈

RFC 4492 defines a whole bunch of elliptic curves 🙈 but Suite B TLS connections MUST use secp256r1(23) or secp384r1(24). These are the same curves that show up in FIPS 186-3 [DSS] as P-256 and P-384, respectively ✨

secp256r1 MUST be used for the key exchange in all cipher suites in this specification using AES-128, and secp384r1 MUST be used for the key exchange in all cipher suites in this specification using AES-256 💅 RFC 4492 requires that the uncompressed(0) form be supported. The ansiX962_compressed_prime(1) point format MAY also be supported 🦋

Clients who only want to negotiate a Suite B TLS connection MUST generate a "Supported Elliptic Curves Extension" containing only the allowed curves 🎀 Clients operating at a minimum level of security of 128 bits MUST include secp256r1 and SHOULD include secp384r1 in the extension. Clients operating at a minimum level of security of 192 bits MUST include secp384r1 in the extension. To be able to verify ECDSA signatures, a client and server in a system configured at a minimum level of security of 128 bits MUST support secp256r1 and SHOULD support secp384r1, unless it is absolutely certain that the client and server will never need to use or verify certificates from an authority that uses an ECDSA-384 signing key 😭 A client and server in a system configured at a minimum level of 192 bits MUST support secp384r1.

TLS connections that offer options that are both compliant and non-compliant with Suite B MAY omit the extension, or they MAY send the extension but offer other curves as well as the appropriate Suite B ones 🌸

Servers who want to negotiate a Suite B TLS connection SHOULD check for the presence of the extension, but they MUST NOT select a curve that is not Suite B, even if the client offers it 🔥 this lets a client that's willing to do either Suite B or non-Suite B TLS connections still interoperate with a server that will only do Suite B TLS 🫶 If the client doesn't advertise an acceptable curve, the server MUST generate a fatal "handshake_failure" alert and terminate the connection 💀 Clients MUST check the chosen curve to make sure it is one of the Suite B curves 👑

4.2. Certificates 🦋

Server and client certificates used to establish a Suite B TLS connection MUST be signed with ECDSA and MUST be compliant with the "Suite B Certificate and Certificate Revocation List (CRL) Profile", [RFC5759] 🎀

4.3. signature_algorithms Extension 💖

The signature_algorithms extension is defined in Section 7.4.1.4.1 of TLS version 1.2 [RFC5246]. A Suite B TLS version 1.2 or later client MUST include the signature_algorithms extension. A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer SHA-256 with ECDSA, and SHOULD offer ECDSA with SHA-384 in the signature_algorithms extension, unless it is absolutely certain that a client will never need to use or verify certificates from an authority that uses an ECDSA-384 signing key 🌈 A Suite B TLS client configured at a minimum level of 192 bits MUST offer ECDSA with SHA-384 in the signature_algorithms extension 🧚

Following the guidance in [RFC5759], Suite B TLS connections MUST only accept signature algorithms ECDSA with either SHA-256 or SHA-384 for certification path validation. (Note that this is a change from [RFC5430].) Other offerings MAY be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with Suite B, and to indicate the signature algorithms that are acceptable for certification path validation in non-compliant Suite B TLS connections 💜

4.4. CertificateRequest Message ⭐

A Suite B TLS server configured at a minimum level of security of 128 bits MUST include ECDSA with SHA-256, and SHOULD include ECDSA with SHA-384, in the supported_signature_algorithms field of the CertificateRequest message, unless it is absolutely certain that a server will never need to verify certificates from an authority that uses an ECDSA-384 signing key 🙈 A Suite B TLS server configured at a minimum level of security of 192 bits MUST include ECDSA with SHA-384 in the supported_signature_algorithms field 🎀

4.5. CertificateVerify Message 🍓

Using the definitions found in Section 3.2, a Suite B TLS client MUST use ECDSA-256 or ECDSA-384 for the signature in the CertificateVerify message. A Suite B TLS client configured at a minimum security level of 128 bits MUST use ECDSA-256 or ECDSA-384. A Suite B TLS client configured at a minimum security level of 192 bits MUST use ECDSA-384 ✨

4.6. ServerKeyExchange Message Signature 🦋

In the TLS_ECDHE_ECDSA-collection of cipher suites, the server sends its ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. These parameters MUST be signed with ECDSA using the server's private key, which corresponds to the public key in the server's certificate 💅

A Suite B TLS server MUST sign the ServerKeyExchange message using either ECDSA-256 or ECDSA-384. A system configured at a minimum level of security of 128 bits MUST use either ECDSA-256 or ECDSA-384. A system configured at a minimum level of security of 192 bits MUST use ECDSA-384 🌸

5. Security Considerations 💀

okay this part is SERIOUS bestie 😭🚨 Most of the security considerations for this document are described in "The Transport Layer Security (TLS) Protocol Version 1.2" [RFC5246], "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)" [RFC4492], "AES Galois Counter Mode (GCM) Cipher Suites for TLS" [RFC5288], and "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)" [RFC5289]. Readers should go read those docs 📚🫶

In order to meet the goal of a consistent security level for the entire cipher suite, Suite B TLS implementations MUST ONLY use the curves defined in Section 4.1. Otherwise, it's possible to have a set of symmetric algorithms with much weaker or stronger security properties than the asymmetric (ECC) algorithms 🚨 no mixing and matching, periodt 💅

6. Acknowledgments 🌷

The authors would like to thank Eric Rescorla for his work on the original RFC 5430 💖

This work was supported by the US Department of Defense 🇺🇸

7. References 📚

7.1. Normative References 🔥

  • [AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
  • [DSS] National Institute of Standards and Technology, "Digital Signature Standard", FIPS 186-3, June 2009.
  • [PWKE] National Institute of Standards and Technology, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 800-56A, March 2007.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
  • [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008.
  • [RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
  • [SHS] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008.
  • [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.

7.2. Informative References 📖

Annex A. A Transitional Suite B Profile for TLS 1.1 and 1.0 🦋

okay so this annex is the bridge for older TLS 1.0, TLS 1.1, and DTLS 1.0 setups 🌉 it uses Suite B crypto as much as it can and keeps backward compatibility too. ngl it's not fully Suite B compliant, but it's a transitional path toward the real compliant profile 💖 here's the lineup:

Transitional Suite B Combination 1 Transitional Suite B Combination 2
---------------------------------- ----------------------------------
AES with 128-bit key in CBC mode   AES with 256-bit key in CBC mode
ECDH using the 256-bit prime       ECDH using the 384-bit prime
   modulus curve P-256 [DSS]          modulus curve P-384 [DSS]
Standard TLS PRF                   Standard TLS PRF
   (with SHA-1 and MD5)               (with SHA-1 and MD5)
HMAC with SHA-1 for message        HMAC with SHA-1 for message
   authentication                     authentication

Now the rules, bestie 🎀

A Transitional Suite B TLS system configured at a minimum level of security of 128 bits MUST use a TLS cipher suite that satisfies either Transitional Suite B Combination 1 in its entirety or Transitional Suite B Combination 2 in its entirety. 🔥

A Transitional Suite B TLS system configured at a minimum level of security of 192 bits MUST use a TLS cipher suite that satisfies Transitional Suite B Combination 2 in its entirety. 👑

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA satisfy Transitional Suite B Combination 1 and Transitional Suite B Combination 2, respectively. ✨

A Transitional Suite B TLS client MUST implement TLS version 1.1 or earlier. 💅

A Transitional Suite B TLS system configured at a minimum level of security of 128 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite and/or the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite in the ClientHello message. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA is the preferred one 🌸 and if it's offered, it MUST appear before TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (if that one is present too).

A Transitional Suite B TLS system configured at a minimum level of security of 192 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite in the ClientHello message. 🧚

One of these Transitional Suite B cipher suites MUST be the first (most preferred) one in the ClientHello message. 💜

A Transitional Suite B client that wants to interoperate with servers that are not Suite B transitional MAY offer additional cipher suites. If any additional cipher suites are offered, they MUST appear after the Transitional Suite B cipher suites in the ClientHello message. 🍓

A Transitional Suite B TLS server MUST implement TLS version 1.1 or earlier. 🦋

A Transitional Suite B TLS server configured at a minimum level of security of 128 bits MUST accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite (preferred) or the TLS_ECHDE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it's offered in the ClientHello message. 🌈

A Transitional Suite B TLS server configured at a minimum level of security of 192 bits MUST accept the TLS_ECHDE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it's offered in the ClientHello message. ⭐

If a Transitional Suite B TLS server isn't offered the Transitional Suite B cipher suites, and it still wants to interoperate with non-Transitional Suite B clients, then the server MAY accept another offered cipher suite that the server administrator considers acceptable. 🫶

A Transitional Suite B TLS server MUST sign the ServerKeyExchange message using ECDSA with SHA-1. The Transitional Suite B profile doesn't impose any extra restrictions on the server certificate signature or on the signature schemes used elsewhere in the certification path. Likewise, the Transitional Suite B profile doesn't impose restrictions on the signature schemes used in the certification path for the client's certificate when mutual authentication is used. 🔐

Annex B. Changes since RFC 5430 📝

the changes from [RFC5430] are as follows, and honestly this list is the glow-up 🌟

  • The transitional profile for use with TLS version 1.0, TLS version 1.1, and DTLS version 1.0 was moved into an annex. 🎀
  • The requirement in Section 4 of RFC 5430 that a Suite B TLS 1.2 Client offer TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 or TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 cipher suites was removed. 🙈
  • A Suite B TLS system configured at a minimum level of security of 128 bits MUST use either TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, with the first one being preferred. 🔥
  • A Suite B TLS system configured at a minimum level of security of 128 bits MUST use either ECDSA on the secp256r1 curve with SHA-256 or ECDSA on the secp384r1 curve with SHA-384. One party can authenticate with ECDSA on the secp256r1 curve and SHA-256 when the other party authenticates with ECDSA on the secp384r1 curve and SHA-384. 💖
  • A system that wants to negotiate a Suite B TLS connection at a minimum level of security of 128 bits MUST generate a "Supported Elliptic Curves Extension", MUST include secp256r1 in the extension, and SHOULD include secp384r1 in the extension. 🦋
  • A client and a server, in order to verify digital signatures in a Suite B TLS system configured at a minimum level of security of 128 bits, MUST support secp256r1 and SHOULD support secp384r1. 🧚
  • A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer SHA-256 with ECDSA and SHOULD offer SHA-384 with ECDSA in the signature_algorithms extension. 🌸
  • Certification path validation MUST only include certificates containing an ECDSA public key on the secp256r1 curve or on the secp384r1 curve. The ECDSA public keys used in the certification path MUST be in non-descending order of size, from the end entity public key to the root public key. 👑
  • A Suite B TLS server configured at a minimum level of security of 128 bits MUST include ECDSA with SHA-256 and SHOULD include ECDSA with SHA-384 in the supported_signature_algorithms field of the CertificateRequest message. 🍓
  • A Suite B TLS client configured at a minimum level of security of 128 bits MUST use ECDSA on the secp256r1 curve and SHA-256, or ECDSA on the secp384r1 curve and SHA-384. 💅
  • A Suite B TLS server configured at a minimum level of security of 128 bits MUST use either ECDSA on the secp256r1 curve and SHA-256, or ECDSA on the secp384r1 curve and SHA-384, when signing the ServerKeyExchange message. 🌈

Authors' Addresses 🖋️

Margaret Salter
National Security Agency
9800 Savage Rd.
Fort Meade  20755-6709
USA
EMail: misalte@nsa.gov

Russ Housley
Vigil Security
918 Spring Knoll Drive
Herndon  21070
USA
EMail: housley@vigilsec.com
📦 where this page comes from