rfc9151.original   rfc9151.txt 
Network Working Group D. Cooley Independent Submission D. Cooley
Internet-Draft NSA Request for Comments: 9151 NSA
Intended status: Informational January 20, 2021 Category: Informational August 2021
Expires: July 24, 2021 ISSN: 2070-1721
Commercial National Security Algorithm (CNSA) Suite Profile for TLS and Commercial National Security Algorithm (CNSA) Suite Profile for TLS and
DTLS 1.2 and 1.3 DTLS 1.2 and 1.3
draft-cooley-cnsa-dtls-tls-profile-07
Abstract Abstract
This document defines a base profile for TLS protocol versions 1.2 This document defines a base profile for TLS protocol versions 1.2
and 1.3, as well as DTLS protocol versions 1.2 and 1.3 for use with and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with
the United States Commercial National Security Algorithm (CNSA) the US Commercial National Security Algorithm (CNSA) Suite.
Suite.
The profile applies to the capabilities, configuration, and operation The profile applies to the capabilities, configuration, and operation
of all components of US National Security Systems that use TLS or of all components of US National Security Systems that use TLS or
DTLS. It is also appropriate for all other US Government systems DTLS. It is also appropriate for all other US Government systems
that process high-value information. that process high-value information.
The profile is made publicly available here for use by developers and The profile is made publicly available here for use by developers and
operators of these and any other system deployments. operators of these and any other system deployments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on July 24, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9151.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. The Commercial National Security Algorithm Suite . . . . . . 3 2. CNSA
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology
4. CNSA Suite . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. CNSA Suites
4.1. CNSA (D)TLS Key Establishment Algorithms . . . . . . . . 5 4.1. CNSA (D)TLS Key Establishment Algorithms
4.2. CNSA TLS Authentication . . . . . . . . . . . . . . . . . 6 4.2. CNSA TLS Authentication
5. CNSA Compliance and Interoperability Requirements . . . . . . 6 5. CNSA Compliance and Interoperability Requirements
5.1. Acceptable ECC Curves . . . . . . . . . . . . . . . . . . 6 5.1. Acceptable Elliptic Curve Cryptography (ECC) Curves
5.2. Acceptable RSA Schemes, Parameters and Checks . . . . . . 6 5.2. Acceptable RSA Schemes, Parameters, and Checks
5.3. Acceptable Finite Field Groups . . . . . . . . . . . . . 7 5.3. Acceptable Finite Field Groups
5.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Certificates
6. (D)TLS 1.2 Requirements . . . . . . . . . . . . . . . . . . . 8 6. (D)TLS 1.2 Requirements
6.1. The extended_master_secret Extension . . . . . . . . . . 8 6.1. The "extended_master_secret" Extension
6.2. The signature_algorithms Extension . . . . . . . . . . . 9 6.2. The "signature_algorithms" Extension
6.3. The signature_algorithms_cert Extension . . . . . . . . . 9 6.3. The "signature_algorithms_cert" Extension
6.4. The CertificateRequest Message . . . . . . . . . . . . . 10 6.4. The CertificateRequest Message
6.5. The CertificateVerify Message . . . . . . . . . . . . . . 10 6.5. The CertificateVerify Message
6.6. The Signature in the ServerKeyExchange Message . . . . . 10 6.6. The Signature in the ServerKeyExchange Message
6.7. Certificate Status . . . . . . . . . . . . . . . . . . . 10 6.7. Certificate Status
7. (D)TLS 1.3 Requirements . . . . . . . . . . . . . . . . . . . 10 7. (D)TLS 1.3 Requirements
7.1. The "signature_algorithms" Extension . . . . . . . . . . 11 7.1. The "signature_algorithms" Extension
7.2. The "signature_algorithms_cert" Extension . . . . . . . . 11 7.2. The "signature_algorithms_cert" Extension
7.3. The "early_data" Extension . . . . . . . . . . . . . . . 12 7.3. The "early_data" Extension
7.4. Resumption . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Resumption
7.5. Certificate Status . . . . . . . . . . . . . . . . . . . 12 7.5. Certificate Status
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address
1. Introduction 1. Introduction
This document specifies a profile of TLS version 1.2 [RFC5246] and This document specifies a profile of TLS version 1.2 [RFC5246] and
TLS version 1.3 [RFC8446], as well as DTLS version 1.2 [RFC6347] and TLS version 1.3 [RFC8446] as well as DTLS version 1.2 [RFC6347] and
DTLS version 1.3 [ID.dtls13] for use by applications that support the DTLS version 1.3 [RFC9147] for use by applications that support the
National Security Agency's (NSA) Commercial National Security National Security Agency's (NSA) Commercial National Security
Algorithm (CNSA) Suite [CNSA]. The profile applies to the Algorithm (CNSA) Suite [CNSA]. The profile applies to the
capabilities, configuration, and operation of all components of US capabilities, configuration, and operation of all components of US
National Security Systems [SP80059]. It is also appropriate for all National Security Systems [SP80059]. It is also appropriate for all
other US Government systems that process high-value information. It other US Government systems that process high-value information. It
is made publicly available for use by developers and operators of is made publicly available for use by developers and operators of
these and any other system deployments. these and any other system deployments.
This document does not define any new cipher suites; instead, it This document does not define any new cipher suites; instead, it
defines a CNSA compliant profile of TLS and DTLS, and the cipher defines a CNSA-compliant profile of TLS and DTLS, and the cipher
suites defined in [RFC5288], [RFC5289], and [RFC8446]. This profile suites defined in [RFC5288], [RFC5289], and [RFC8446]. This profile
uses only algorithms in the CNSA Suite. uses only algorithms in the CNSA Suite.
The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as
well as the DTLS 1.2 and 1.3 protocol specifications: [RFC5246], well as the DTLS 1.2 and 1.3 protocol specifications: [RFC5246],
[RFC6347], [RFC8446], and [ID.dtls13]. All MUST-level requirements [RFC8446], [RFC6347], and [RFC9147], respectively. All MUST-level
from the protocol documents apply throughout this profile; they are requirements from the protocol documents apply throughout this
generally not repeated. This profile contains changes that elevate profile; they are generally not repeated. This profile contains
some SHOULD-level options to MUST-level; this profile also contains changes that elevate some SHOULD-level options to MUST-level; this
changes that elevate some MAY-level options to SHOULD-level or MUST- profile also contains changes that elevate some MAY-level options to
level. All options that are not mentioned in this profile remain at SHOULD-level or MUST-level. All options that are not mentioned in
their original requirement level. this profile remain at their original requirement level.
2. The Commercial National Security Algorithm Suite 2. CNSA
The National Security Agency (NSA) profiles commercial cryptographic The National Security Agency (NSA) profiles commercial cryptographic
algorithms and protocols as part of its mission to support secure, algorithms and protocols as part of its mission to support secure,
interoperable communications for US Government National Security interoperable communications for US National Security Systems. To
Systems. To this end, it publishes guidance both to assist with the this end, it publishes guidance both to assist with the US Government
US Government transition to new algorithms, and to provide vendors - transition to new algorithms and to provide vendors -- and the
and the Internet community in general - with information concerning Internet community in general -- with information concerning their
their proper use and configuration. proper use and configuration.
Recently, cryptographic transition plans have become overshadowed by Recently, cryptographic transition plans have become overshadowed by
the prospect of the development of a cryptographically-relevant the prospect of the development of a cryptographically relevant
quantum computer. NSA has established the CNSA Suite to provide quantum computer. The NSA has established the CNSA Suite to provide
vendors and IT users near-term flexibility in meeting their vendors and IT users near-term flexibility in meeting their
Information Assurance (IA) interoperability requirements. The Information Assurance (IA) interoperability requirements. The
purpose behind this flexibility is to avoid having vendors and purpose behind this flexibility is to avoid having vendors and
customers make two major transitions in a relatively short timeframe, customers make two major transitions in a relatively short timeframe,
as we anticipate a need to shift to quantum-resistant cryptography in as we anticipate a need to shift to quantum-resistant cryptography in
the near future. the near future.
NSA is authoring a set of RFCs, including this one, to provide The NSA is authoring a set of RFCs, including this one, to provide
updated guidance concerning the use of certain commonly available updated guidance concerning the use of certain commonly available
commercial algorithms in IETF protocols. These RFCs can be used in commercial algorithms in IETF protocols. These RFCs can be used in
conjunction with other RFCs and cryptographic guidance (e.g., NIST conjunction with other RFCs and cryptographic guidance (e.g., NIST
Special Publications) to properly protect Internet traffic and data- Special Publications) to properly protect Internet traffic and data-
at-rest for US Government National Security Systems. at-rest for US National Security Systems.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
"ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital "ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital
Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH),
respectively. ECDSA and ECDH are used with the NIST P-384 curve respectively. ECDSA and ECDH are used with the NIST P-384 curve
(which is based on a 384-bit prime modulus) and the SHA-384 hash (which is based on a 384-bit prime modulus) and the SHA-384 hash
function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman
(RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH
are used with a 3072-bit or 4096-bit modulus. When RSA is used for are used with a 3072-bit or 4096-bit modulus. When RSA is used for
digital signature, it is used with the SHA-384 hash function. digital signature, it is used with the SHA-384 hash function.
Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS
versions 1.2 and 1.3 collectively as (D)TLS. versions 1.2 and 1.3 collectively as "(D)TLS".
4. CNSA Suite 4. CNSA Suites
[CNSA] approves the use of both finite field and elliptic curve [CNSA] approves the use of both Finite Field and elliptic curve
versions of the DH key agreement algorithm, as well as RSA-based key versions of the DH key agreement algorithm as well as RSA-based key
establishment. [CNSA] also approves certain versions of the RSA and establishment. [CNSA] also approves certain versions of the RSA and
elliptic curve digital signature algorithms. The approved encryption elliptic curve digital signature algorithms. The approved encryption
techniques include the Advanced Encryption Standard (AES) used with a techniques include the Advanced Encryption Standard (AES) used with a
256-bit key in an Authenticated Encryption with Associated Data 256-bit key in an Authenticated Encryption with Associated Data
(AEAD) mode. (AEAD) mode.
In particular, CNSA includes the following: In particular, CNSA includes the following:
Encryption: Encryption:
AES [AES] (with key size 256 bits), operating in Galois/Counter
AES [AES] (with key size 256 bits), operating in Galois/Counter Mode (GCM) [GCM]
Mode (GCM) [GCM]
Digital Signature:
ECDSA [DSS] (using the NIST P-384 elliptic curve) Digital Signature:
RSA [DSS] (with a modulus of 3072 bits or 4096 bits) ECDSA [DSS] (using the NIST P-384 elliptic curve)
Key Establishment (includes key agreement and key transport): RSA [DSS] (with a modulus of 3072 bits or 4096 bits)
ECDH [PWKE-A] (using the NIST P-384 elliptic curve) Key Establishment (includes key agreement and key transport):
ECDH [PWKE-A] (using the NIST P-384 elliptic curve)
DH [PWKE-A] (with a prime modulus of 3072 or 4096 bits) DH [PWKE-A] (with a prime modulus of 3072 or 4096 bits)
RSA [PWKE-B] (with a modulus of 3072 or 4096 bits, but only in RSA [PWKE-B] (with a modulus of 3072 or 4096 bits, but only in
(D)TLS 1.2) (D)TLS 1.2)
[CNSA] also approves the use of SHA-384 [SHS] for the hash algorithm [CNSA] also approves the use of SHA-384 [SHS] as the hash algorithm
for mask generation, signature generation, Pseudo Random Function for mask generation, signature generation, Pseudorandom Function
(PRF) in TLS 1.2 and HMAC-based key derivation function (HKDF) in TLS (PRF) in TLS 1.2 and HMAC-based Key Derivation Function (HKDF) in TLS
1.3. 1.3.
4.1. CNSA (D)TLS Key Establishment Algorithms 4.1. CNSA (D)TLS Key Establishment Algorithms
The following combination of algorithms and key sizes are used in The following combination of algorithms and key sizes are used in
CNSA (D)TLS: CNSA (D)TLS:
AES with 256-bit key, operating in GCM mode AES with 256-bit key, operating in GCM mode
ECDH [PWKE-A] using the Ephemeral Unified Model Scheme with ECDH [PWKE-A] using the Ephemeral Unified Model Scheme with
skipping to change at page 5, line 50 skipping to change at line 225
Or Or
AES with 256-bit key, operating in GCM mode AES with 256-bit key, operating in GCM mode
DH using dhEphem with domain parameters specified below in DH using dhEphem with domain parameters specified below in
Section 5.3 (see Section 6.1.2.1 in [PWKE-A]) Section 5.3 (see Section 6.1.2.1 in [PWKE-A])
TLS PRF/HKDF with SHA-384 [SHS] TLS PRF/HKDF with SHA-384 [SHS]
The specific CNSA compliant cipher suites are listed in Section 5. The specific CNSA-compliant cipher suites are listed in Section 5.
4.2. CNSA TLS Authentication 4.2. CNSA TLS Authentication
For server and/or client authentication, CNSA (D)TLS MUST generate For server and/or client authentication, CNSA (D)TLS MUST generate
and verify either ECDSA signatures or RSA signatures. and verify either ECDSA signatures or RSA signatures.
In all cases, the client MUST authenticate the server. The server In all cases, the client MUST authenticate the server. The server
MAY also authenticate the client, as needed by the specific MAY also authenticate the client, as needed by the specific
application. application.
The public keys used to verify these signatures MUST be contained in The public keys used to verify these signatures MUST be contained in
a certificate, see Section 5.4 for more information. a certificate (see Section 5.4 for more information).
5. CNSA Compliance and Interoperability Requirements 5. CNSA Compliance and Interoperability Requirements
CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA-
compliant system. CNSA (D)TLS servers and clients MUST implement and compliant system. CNSA (D)TLS servers and clients MUST implement and
use either (D)TLS version 1.2 [RFC5246][RFC6347] or (D)TLS version use either (D)TLS version 1.2 [RFC5246] [RFC6347] or (D)TLS version
1.3 [RFC8446][ID.dtls13]. 1.3 [RFC8446] [RFC9147].
5.1. Acceptable ECC Curves 5.1. Acceptable Elliptic Curve Cryptography (ECC) Curves
The elliptic curves used in the CNSA Suite appear in the literature The elliptic curves used in the CNSA Suite appear in the literature
under two different names [DSS] [SECG]. For the sake of clarity, under two different names [DSS] [SECG]. For the sake of clarity,
both names are listed below: both names are listed below:
Curve NIST name SECG name +=======+===========+===========+
-------------------------------- | Curve | NIST name | SECG name |
P-384 nistp384 secp384r1 +=======+===========+===========+
| P-384 | nistp384 | secp384r1 |
+-------+-----------+-----------+
Table 1: Elliptic Curves in
CNSA Suite
[RFC8422] defines a variety of elliptic curves. CNSA (D)TLS [RFC8422] defines a variety of elliptic curves. CNSA (D)TLS
connections MUST use secp384r1 (also called nistp384) and the connections MUST use secp384r1 (also called nistp384), and the
uncompressed form MUST be used, as required by [RFC8422] and uncompressed form MUST be used, as required by [RFC8422] and
[RFC8446]. [RFC8446].
Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A]. Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A].
5.2. Acceptable RSA Schemes, Parameters and Checks 5.2. Acceptable RSA Schemes, Parameters, and Checks
[CNSA] specifies a minimum modulus size of 3072 bits; however, only [CNSA] specifies a minimum modulus size of 3072 bits; however, only
two modulus sizes (3072 bits and 4096 bits) are supported by this two modulus sizes (3072 bits and 4096 bits) are supported by this
profile. profile.
For (D)TLS 1.2: For (D)TLS 1.2:
For certificate signatures, RSASSA-PKCS1-v1_5 [RFC8017] MUST be
For certificate signature, RSASSA-PKCS1-v1.5 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be supported.
supported, and RSASSA-PSS [DSS] SHOULD be supported.
For signatures in TLS handshake messages RSASSA-PKCS1-v1.5
[RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be
supported.
For key transport, RSAES-PKCS1-v1.5 [RFC8017] MUST be
supported.
For (D)TLS 1.3: For signatures in TLS handshake messages, RSASSA-PKCS1-v1_5
[RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be
supported.
For certificate signature, RSASSA-PKCS1-v1.5 [RFC8017] MUST be For key transport, RSAES-PKCS1-v1_5 [RFC8017] MUST be supported.
supported, and RSASSA-PSS [DSS] SHOULD be supported.
For signatures in TLS handshake messages RSASSA-PSS [DSS] MUST For (D)TLS 1.3:
be supported. For certificate signatures, RSASSA-PKCS1-v1_5 [RFC8017] MUST be
supported, and RSASSA-PSS [DSS] SHOULD be supported.
For key transport, TLS 1.3 does not support RSA key transport. For signatures in TLS handshake messages, RSASSA-PSS [DSS] MUST be
supported.
For all versions of (D)TLS: For key transport, TLS 1.3 does not support RSA key transport.
RSA exponent e MUST satisfy 2^16<e<2^256 and be odd per [DSS]. For all versions of (D)TLS:
RSA exponent e MUST satisfy 2^16<e<2^256 and be odd per [DSS].
If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for
example), then the implementation MUST assert rsaEncryption as example), then the implementation MUST assert rsaEncryption as the
the public key algorithm, the hash algorithm (used for both public key algorithm, the hash algorithm (used for both mask
mask generation and signature generation) MUST be SHA-384, the generation and signature generation) MUST be SHA-384, the mask
mask generation function 1 (MGF1) from [RFC8017] MUST be used, generation function 1 (MGF1) from [RFC8017] MUST be used, and the
and the salt length MUST be 48 octets. salt length MUST be 48 octets.
5.3. Acceptable Finite Field Groups 5.3. Acceptable Finite Field Groups
[CNSA] specifies a minimum modulus size of 3072 bits; however, only [CNSA] specifies a minimum modulus size of 3072 bits; however, only
two modulus sizes (3072 bits and 4096 bits) are supported by this two modulus sizes (3072 bits and 4096 bits) are supported by this
profile. profile.
Ephemeral key pairs MUST be generated following Section 5.6.1.1.1 of Ephemeral key pairs MUST be generated following Section 5.6.1.1.1 of
[PWKE-A] using the approved safe prime groups specified in [RFC7919] [PWKE-A] using the approved safe prime groups specified in [RFC7919]
for DH ephemeral key agreement. The named groups are: for DH ephemeral key agreement. The named groups are:
ffdhe3072 (ID=257) ffdhe3072 (ID=257)
ffdhe4096 (ID=258) ffdhe4096 (ID=258)
5.4. Certificates 5.4. Certificates
Certificates used to establish a CNSA (D)TLS connection MUST be Certificates used to establish a CNSA (D)TLS connection MUST be
signed with ECDSA or RSA and MUST be compliant with the "CNSA signed with ECDSA or RSA and MUST be compliant with the CNSA Suite
Certificate and Certificate Revocation List (CRL) Profile" [RFC8603]. Certificate and Certificate Revocation List (CRL) Profile [RFC8603].
6. (D)TLS 1.2 Requirements 6. (D)TLS 1.2 Requirements
Although TLS 1.2 has technically been obsoleted by the IETF in favor Although TLS 1.2 has technically been obsoleted by the IETF in favor
of TLS 1.3, many implementations and deployments of TLS 1.2 will of TLS 1.3, many implementations and deployments of TLS 1.2 will
continue to exist. For the cases where TLS 1.2 continues to be used, continue to exist. For the cases where TLS 1.2 continues to be used,
implementations MUST use [RFC5246] and SHOULD implement the updates implementations MUST use [RFC5246] and SHOULD implement the updates
specified in [RFC8446] (outlined in Section 1.3). specified in [RFC8446] (outlined in Section 1.3 of that document).
The CNSA (D)TLS 1.2 client MUST offer at least one of these The CNSA (D)TLS 1.2 client MUST offer at least one of these cipher
ciphersuites: suites:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 [RFC5289] [RFC8422] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 [RFC5289] [RFC8422]
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 [RFC5289] [RFC8422] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 [RFC5289] [RFC8422]
TLS_RSA_WITH_AES_256_GCM_SHA384 [RFC5288] TLS_RSA_WITH_AES_256_GCM_SHA384 [RFC5288]
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 [RFC5288] [RFC7919] TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 [RFC5288] [RFC7919]
The CNSA cipher suites listed above MUST be the first (most The CNSA cipher suites listed above MUST be the first (most
preferred) cipher suites in the ClientHello message. preferred) cipher suites in the ClientHello message.
A CNSA (D)TLS client that offers interoperability with servers that A CNSA (D)TLS client that offers interoperability with servers that
are not CNSA compliant MAY offer additional cipher suites, but any are not CNSA compliant MAY offer additional cipher suites, but any
additional cipher suites MUST appear after the CNSA cipher suites in additional cipher suites MUST appear after the CNSA cipher suites in
the ClientHello message. the ClientHello message.
A CNSA (D)TLS server MUST accept one of the CNSA suites above if they A CNSA (D)TLS server MUST accept one of the CNSA Suites above if they
are offered in the ClientHello message before accepting a non-CNSA are offered in the ClientHello message before accepting a non-CNSA-
compliant suite. compliant suite.
If interoperability is not desired with non-CNSA compliant clients or If interoperability is not desired with non-CNSA-compliant clients or
servers, then the session MUST fail if no CNSA suites are offered or servers, then the session MUST fail if no CNSA Suites are offered or
accepted. accepted.
6.1. The extended_master_secret Extension 6.1. The "extended_master_secret" Extension
A CNSA (D)TLS client SHOULD include and a CNSA (D)TLS server SHOULD A CNSA (D)TLS client SHOULD include and a CNSA (D)TLS server SHOULD
accept the "extended_master_secret" extension as specified in accept the "extended_master_secret" extension as specified in
[RFC7627]. See Section 1 of [RFC7627] for security concerns when [RFC7627]. See Section 1 of [RFC7627] for security concerns when
this extension is not used. this extension is not used.
6.2. The signature_algorithms Extension 6.2. The "signature_algorithms" Extension
A CNSA (D)TLS client MUST include and a CNSA (D)TLS server MUST also A CNSA (D)TLS client MUST include and a CNSA (D)TLS server MUST also
accept the "signature_algorithms" extension. The CNSA (D)TLS client accept the "signature_algorithms" extension. The CNSA (D)TLS client
MUST offer and the CNSA (D)TLS server MUST also accept at least one MUST offer and the CNSA (D)TLS server MUST also accept at least one
of the following values in the "signature_algorithms" extensions as of the following values in the "signature_algorithms" extensions as
specified in [RFC8446]: specified in [RFC8446]:
ecdsa_secp384r1_sha384 ecdsa_secp384r1_sha384
rsa_pkcs1_sha384 rsa_pkcs1_sha384
skipping to change at page 9, line 33 skipping to change at line 393
Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only
accept ECDSA or RSA for signatures on ServerKeyExchange messages and accept ECDSA or RSA for signatures on ServerKeyExchange messages and
for certification path validation. for certification path validation.
Other client offerings MAY be included to indicate the acceptable Other client offerings MAY be included to indicate the acceptable
signature algorithms in cipher suites that are offered for signature algorithms in cipher suites that are offered for
interoperability with servers not compliant with CNSA and to indicate interoperability with servers not compliant with CNSA and to indicate
the signature algorithms that are acceptable for ServerKeyExchange the signature algorithms that are acceptable for ServerKeyExchange
messages and for certification path validation in non-compliant CNSA messages and for certification path validation in non-compliant CNSA
(D)TLS connections. These offerings MUST NOT be accepted by a CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-
compliant (D)TLS server. compliant (D)TLS server.
6.3. The signature_algorithms_cert Extension 6.3. The "signature_algorithms_cert" Extension
A CNSA (D)TLS client MAY include the "signature_algorithms_cert" A CNSA (D)TLS client MAY include the "signature_algorithms_cert"
extension. CNSA (D)TLS servers MUST process the extension. CNSA (D)TLS servers MUST process the
"signature_algorithms_cert" extension if it is offered per "signature_algorithms_cert" extension if it is offered per
Section 4.2.3 of [RFC8446]. Section 4.2.3 of [RFC8446].
Both CNSA (D)TLS clients and servers MUST use one of the following Both CNSA (D)TLS clients and servers MUST use one of the following
values for certificate path validation: values for certificate path validation:
ecdsa_secp384r1_sha384 ecdsa_secp384r1_sha384
skipping to change at page 10, line 4 skipping to change at line 413
Both CNSA (D)TLS clients and servers MUST use one of the following Both CNSA (D)TLS clients and servers MUST use one of the following
values for certificate path validation: values for certificate path validation:
ecdsa_secp384r1_sha384 ecdsa_secp384r1_sha384
rsa_pkcs1_sha384 rsa_pkcs1_sha384
And, if supported, SHOULD offer/accept: And, if supported, SHOULD offer/accept:
rsa_pss_pss_sha384 rsa_pss_pss_sha384
rsa_pss_rsae_sha384 rsa_pss_rsae_sha384
6.4. The CertificateRequest Message 6.4. The CertificateRequest Message
When a CNSA (D)TLS server is configured to authenticate the client, When a CNSA (D)TLS server is configured to authenticate the client,
the server MUST include in its the server MUST include the following values in its
CertificateRequest.supported_signature_algorithms [RFC5246] offer: CertificateRequest.supported_signature_algorithms [RFC5246] offer:
ecdsa_secp384r1_sha384 ecdsa_secp384r1_sha384
rsa_pkcs1_sha384 rsa_pkcs1_sha384
And, if supported as specified in [RFC8446], SHOULD offer/accept: And, if supported as specified in [RFC8446], SHOULD offer/accept:
rsa_pss_pss_sha384 rsa_pss_pss_sha384
rsa_pss_rsae_sha384 rsa_pss_rsae_sha384
6.5. The CertificateVerify Message 6.5. The CertificateVerify Message
A CNSA (D)TLS client MUST use ECDSA or RSA when sending the A CNSA (D)TLS client MUST use ECDSA or RSA when sending the
CertificateVerify message. CNSA (D)TLS Servers MUST only accept CertificateVerify message. CNSA (D)TLS servers MUST only accept
ECDSA or RSA in the CertificateVerify message. ECDSA or RSA in the CertificateVerify message.
6.6. The Signature in the ServerKeyExchange Message 6.6. The Signature in the ServerKeyExchange Message
A CNSA (D)TLS server MUST sign the ServerKeyExchange message using A CNSA (D)TLS server MUST sign the ServerKeyExchange message using
ECDSA or RSA. ECDSA or RSA.
6.7. Certificate Status 6.7. Certificate Status
Certificate Authorities providing certificates to a CNSA (D)TLS Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS
server or client MUST provide certificate revocation status server or client MUST provide certificate revocation status
information via a Certificate Revocation List (CRL) distribution information via a Certificate Revocation List (CRL) distribution
point or using the Online Certificate Status Protocol (OCSP). A CNSA point or using the Online Certificate Status Protocol (OCSP). A CNSA
client SHOULD request it according to [RFC8446] Section 4.4.2.1. If client SHOULD request it according to Section 4.4.2.1 of [RFC8446].
OCSP is supported, the (D)TLS server SHOULD provide OCSP responses in If OCSP is supported, the (D)TLS server SHOULD provide OCSP responses
the "CertificateStatus" message. in the CertificateStatus message.
7. (D)TLS 1.3 Requirements 7. (D)TLS 1.3 Requirements
The CNSA (D)TLS client MUST offer the following CipherSuite in the The CNSA (D)TLS client MUST offer the following cipher suite in the
ClientHello: ClientHello:
TLS_AES_256_GCM_SHA384 TLS_AES_256_GCM_SHA384
The CNSA (D)TLS client MUST include at least one of the following The CNSA (D)TLS client MUST include at least one of the following
values in "supported_groups": values in the "supported_groups" extension:
ECDHE: secp384r1 ECDHE: secp384r1
DHE: ffdhe3072 DHE: ffdhe3072
DHE: ffdhe4096 DHE: ffdhe4096
The CNSA cipher suite MUST be the first (most preferred) cipher The CNSA cipher suite MUST be the first (most preferred) cipher suite
suites in the ClientHello message and in the extensions. in the ClientHello message and in the extensions.
A CNSA (D)TLS client that offers interoperability with servers that A CNSA (D)TLS client that offers interoperability with servers that
are not CNSA compliant MAY offer additional cipher suites, but any are not CNSA compliant MAY offer additional cipher suites, but any
additional cipher suites MUST appear after the CNSA compliant cipher additional cipher suites MUST appear after the CNSA-compliant cipher
suites in the ClientHello message. suites in the ClientHello message.
A CNSA (D)TLS server MUST accept one of the CNSA algorithms listed A CNSA (D)TLS server MUST accept one of the CNSA algorithms listed
above if they are offered in the ClientHello message. above if they are offered in the ClientHello message.
If interoperability is not desired with non-CNSA compliant clients or If interoperability is not desired with non-CNSA-compliant clients or
servers, then the session MUST fail if no CNSA suites are offered or servers, then the session MUST fail if no CNSA Suites are offered or
accepted. accepted.
7.1. The "signature_algorithms" Extension 7.1. The "signature_algorithms" Extension
A CNSA (D)TLS client MUST include the "signature_algorithms" A CNSA (D)TLS client MUST include the "signature_algorithms"
extension. The CNSA (D)TLS client MUST offer at least one of the extension. The CNSA (D)TLS client MUST offer at least one of the
following values in the "signature_algorithms" extension: following values in the "signature_algorithms" extension:
ecdsa_secp384r1_sha384 ecdsa_secp384r1_sha384
rsa_pss_pss_sha384 rsa_pss_pss_sha384
rsa_pss_rsae_sha384 rsa_pss_rsae_sha384
Clients that allow negotiating TLS 1.2 MAY offer rsa_pkcs1_sha384 for Clients that allow negotiating TLS 1.2 MAY offer rsa_pkcs1_sha384 for
use with TLS 1.2. Other offerings MAY be included to indicate the use with TLS 1.2. Other offerings MAY be included to indicate the
acceptable signature algorithms in cipher suites that are offered for acceptable signature algorithms in cipher suites that are offered for
interoperability with servers not compliant with CNSA in non- interoperability with servers not compliant with CNSA in non-
compliant CNSA (D)TLS connections. These offerings MUST NOT be compliant CNSA (D)TLS connections. These offerings MUST NOT be
accepted by a CNSA compliant (D)TLS server. accepted by a CNSA-compliant (D)TLS server.
7.2. The "signature_algorithms_cert" Extension 7.2. The "signature_algorithms_cert" Extension
A CNSA (D)TLS client SHOULD include the "signature_algorithms_cert" A CNSA (D)TLS client SHOULD include the "signature_algorithms_cert"
extension. And if offered, the CNSA (D)TLS client MUST offer at extension. And, if offered, the CNSA (D)TLS client MUST offer at
least one of the following values in the "signature_algorithms_cert" least one of the following values in the "signature_algorithms_cert"
extension: extension:
ecdsa_secp384r1_sha384 ecdsa_secp384r1_sha384
rsa_pkcs1_sha384 rsa_pkcs1_sha384
And, if supported, SHOULD offer: And, if supported, SHOULD offer:
rsa_pss_pss_sha384 rsa_pss_pss_sha384
rsa_pss_rsae_sha384 rsa_pss_rsae_sha384
Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only
accept ECDSA or RSA for certificate path validation. accept ECDSA or RSA for certificate path validation.
skipping to change at page 12, line 18 skipping to change at line 526
rsa_pss_pss_sha384 rsa_pss_pss_sha384
rsa_pss_rsae_sha384 rsa_pss_rsae_sha384
Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only
accept ECDSA or RSA for certificate path validation. accept ECDSA or RSA for certificate path validation.
Other offerings MAY be included to indicate the signature algorithms Other offerings MAY be included to indicate the signature algorithms
that are acceptable for certification path validation in non- that are acceptable for certification path validation in non-
compliant CNSA (D)TLS connections. These offerings MUST NOT be compliant CNSA (D)TLS connections. These offerings MUST NOT be
accepted by a CNSA compliant (D)TLS server. accepted by a CNSA-compliant (D)TLS server.
7.3. The "early_data" Extension 7.3. The "early_data" Extension
A CNSA (D)TLS client or server MUST NOT include the "early_data" A CNSA (D)TLS client or server MUST NOT include the "early_data"
extension. See Section 2.3 [RFC8446] for security concerns. extension. See Section 2.3 of [RFC8446] for security concerns.
7.4. Resumption 7.4. Resumption
A CNSA (D)TLS server MAY send a CNSA (D)TLS client a NewSessionTicket A CNSA (D)TLS server MAY send a CNSA (D)TLS client a NewSessionTicket
message to enable resumption. A CNSA (D)TLS client MUST request message to enable resumption. A CNSA (D)TLS client MUST request
"psk_dhe_ke" via the psk_key_exchange_modes ClientHello extension to "psk_dhe_ke" via the "psk_key_exchange_modes" ClientHello extension
resume a session. A CNSA (D)TLS client MUST offer ECDHE with SHA-384 to resume a session. A CNSA (D)TLS client MUST offer Ephemeral
and/or DHE with SHA-384 in the "supported_groups" and/or "key_share" Elliptic Curve Diffie-Hellman (ECDHE) with SHA-384 and/or Ephemeral
extensions. Diffie-Hellman (DHE) with SHA-384 in the "supported_groups" and/or
"key_share" extensions.
7.5. Certificate Status 7.5. Certificate Status
Certificate Authorities providing certificates to a CNSA (D)TLS Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS
server or client MUST provide certificate revocation status server or client MUST provide certificate revocation status
information via a Certificate Revocation List (CRL) distribution information via a Certificate Revocation List (CRL) distribution
point or using the Online Certificate Status Protocol (OCSP). A CNSA point or using the Online Certificate Status Protocol (OCSP). A CNSA
client SHOULD request it according to [RFC8446] Section 4.4.2.1. If client SHOULD request it according to Section 4.4.2.1 of [RFC8446].
OCSP is supported, the (D)TLS server SHOULD provide OCSP responses in If OCSP is supported, the (D)TLS server SHOULD provide OCSP responses
the "CertificateEntry". in the "CertificateEntry".
8. Security Considerations 8. Security Considerations
Most of the security considerations for this document are described Most of the security considerations for this document are described
in [RFC5246], [RFC8446], [RFC6347], and [ID.dtls13]. In addition, in [RFC5246], [RFC8446], [RFC6347], and [RFC9147]. In addition, the
the security consideration for ECC related to TLS are described in security considerations for Elliptic Curve Cryptography (ECC) related
[RFC8422], [RFC5288] and [RFC5289]. Readers should consult those to TLS are described in [RFC8422], [RFC5288], and [RFC5289]. Readers
documents. should consult those documents.
In order to meet the goal of a consistent security level for the In order to meet the goal of a consistent security level for the
entire cipher suite, CNSA (D)TLS implementations MUST only use the entire cipher suite, CNSA (D)TLS implementations MUST only use the
Elliptic Curves, RSA schemes and Finite Fields defined in elliptic curves, RSA schemes, and Finite Fields defined in
Section 5.1, Section 5.2, and Section 5.3 respectively. If this is Section 5.1, Section 5.2, and Section 5.3, respectively. If this is
not the case, then security may be weaker than is required. not the case, then security may be weaker than is required.
As noted in TLS version 1.3 [RFC8446], TLS does not provide inherent As noted in TLS version 1.3 [RFC8446], TLS does not provide inherent
replay protections for early data. For this reason, this profile replay protections for early data. For this reason, this profile
forbids the use of early data. forbids the use of early data.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Announcing the ADVANCED ENCRYPTION STANDARD (AES)",
(AES)", FIPS 197, November 2001, FIPS 197, DOI 10.6028/NIST.FIPS.197, November 2001,
<https://nvlpubs.nist.gov/nistpubs/fips/ <https://nvlpubs.nist.gov/nistpubs/fips/
NIST.FIPS.197.pdf>. NIST.FIPS.197.pdf>.
[CNSA] Committee for National Security Systems, "Use of Public [CNSA] Committee for National Security Systems, "Use of Public
Standards for Secure Information Sharing", CNSSP 15, Standards for Secure Information Sharing", CNSSP 15,
October 2016, October 2016,
<https://www.cnss.gov/CNSS/issuances/Policies.cfm>. <https://www.cnss.gov/CNSS/issuances/Policies.cfm>.
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", NIST Federal Information Signature Standard (DSS)", FIPS PUB 186-4,
Processing Standard 186-4, July 2013, DOI 10.6028/NIST.FIPS.186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[GCM] National Institute of Standards and Technology, [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
"Recommendation for Block Cipher Modes of Operation: Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Galois/Counter Mode (GCM) and GMAC", NIST Special Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
Publication 800-38D, November 2007, November 2007,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-38d.pdf>. nistspecialpublication800-38d.pdf>.
[ID.dtls13] [PWKE-A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Davis, "Recommendation for Pair-Wise Key Establishment
Datagram Transport Layer Security (DTLS) Protocol Version Schemes Using Discrete Logarithm Cryptography", NIST
1.3", May 2020, Special Publication 800-56A Revision 3,
<https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/>. DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
Work in progress.
[PWKE-A] National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A, Revision 3, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar3.pdf>. NIST.SP.800-56Ar3.pdf>.
[PWKE-B] National Institute of Standards and Technology, [PWKE-B] Barker, E., Chen, L., Roginsky, A., Vassilev, A., Davis,
"Recommendation for Pair-Wise Key Establishment Schemes R., and S. Simon, "Recommendation for Pair-Wise Key
Using Integer Factorization Cryptography", NIST Special Establishment Schemes Using Integer Factorization
Publication 800-56B, Revision 2, March 2019, Cryptography", NIST Special Publication 800-56B Revision
2, DOI 10.6028/NIST.SP.800-56Br2, March 2019,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Br2.pdf>. NIST.SP.800-56Br2.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
skipping to change at page 15, line 35 skipping to change at line 679
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security
Algorithm (CNSA) Suite Certificate and Certificate Algorithm (CNSA) Suite Certificate and Certificate
Revocation List (CRL) Profile", RFC 8603, Revocation List (CRL) Profile", RFC 8603,
DOI 10.17487/RFC8603, May 2019, DOI 10.17487/RFC8603, May 2019,
<https://www.rfc-editor.org/info/rfc8603>. <https://www.rfc-editor.org/info/rfc8603>.
[SHS] National Institute of Standards and Technology, "Secure [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Hash Standard (SHS)", NIST Federal Information Processing Datagram Transport Layer Security (DTLS) Protocol Version
Standard 180-4, August 2015, 1.3", RFC 9147, DOI 10.17487/RFC9147, August 2021,
<https://www.rfc-editor.org/rfc/rfc9147>.
[SHS] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4,
FIPS PUB 180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
10.2. Informative References 10.2. Informative References
[SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain
Parameters", February 2010, Parameters", Version 2.0, February 2010,
<http://www.secg.org/download/aid-784/sec2-v2.pdf>. <https://www.secg.org/sec2-v2.pdf>.
[SP80059] National Institute of Standards and Technology, "Guideline [SP80059] Barker, W., "Guideline for Identifying an Information
for Identifying an Information System as a National System as a National Security System",
Security System", Special Publication 800 59, August 2003, DOI 10.6028/NIST.SP.800-59, NIST Special
Publication 800-59, August 2003,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-59.pdf>. nistspecialpublication800-59.pdf>.
Author's Address Author's Address
Dorothy Cooley Dorothy Cooley
National Security Agency National Security Agency
Email: decoole@nsa.gov Email: decoole@nsa.gov
 End of changes. 80 change blocks. 
210 lines changed or deleted 206 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/