idnits 2.17.1 draft-turner-sodp-profile-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2020) is 1528 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'SP 800-59' is defined on line 895, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jenkins 3 Internet Draft NSA 4 Intended Status: Informational Sean Turner 5 Expires: August 18, 2020 sn3rd 6 February 19, 2020 8 The SODP (Secure Object Delivery Protocol) Server Interfaces: 9 NSA's Profile for Delivery of Certificates, 10 CRLs, and Symmetric Keys to Clients 11 draft-turner-sodp-profile-05.txt 13 Abstract 15 This document specifies protocol interfaces profiled by the US NSA 16 (United States National Security Agency) for NSS (National Security 17 System) servers that provide public key certificates, CRLs 18 (Certificate Revocation Lists), and symmetric keys to NSS clients. 19 Servers that support these interfaces are referred to as SODP (Secure 20 Object Delivery Protocol) servers. The intended audience for this 21 profile comprises developers of client devices that will obtain key 22 management services from NSA-operated SODP servers. Interfaces 23 supported by SODP servers include: EST (Enrollment over Secure 24 Transport) and its extensions as well as CMC (Certificate Management 25 over CMS (Cryptographic Message Syntax)). 27 This profile applies to the capabilities, configuration, and 28 operation of all components of US National Security Systems (SP 800- 29 59). It is also appropriate for other US Government systems that 30 process high-value information. It is made publicly available for use 31 by developers and operators of these and any other system 32 deployments. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Documents to be Familiar With . . . . . . . . . . . . . . . 3 68 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 69 1.3. Environment . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Abstract Syntax Notation One . . . . . . . . . . . . . . . . . 6 71 3. EST Interface . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. Hypertext Transfer Protocol Layer . . . . . . . . . . . . 6 73 3.2. Transport Layer Security . . . . . . . . . . . . . . . . . 6 74 3.3. Eligibility . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 76 3.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 77 3.6. EST and EST Extensions . . . . . . . . . . . . . . . . . . 7 78 3.6.1. /pal . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.6.2. /cacerts . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.6.3. /simpleenroll . . . . . . . . . . . . . . . . . . . . 8 81 3.6.4. /simplereenroll . . . . . . . . . . . . . . . . . . . 8 82 3.6.5. /fullcmc . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.6.6. /serverkeygen . . . . . . . . . . . . . . . . . . . . 8 84 3.6.7. /csrattrs . . . . . . . . . . . . . . . . . . . . . . 9 85 3.6.8. /crls . . . . . . . . . . . . . . . . . . . . . . . . 9 86 3.6.9. /symmetrickeys . . . . . . . . . . . . . . . . . . . . 9 87 3.6.10. /eecerts, /firmware, /tamp . . . . . . . . . . . . . 9 88 4. CMC Interface . . . . . . . . . . . . . . . . . . . . . . . . 10 89 4.1. RFC 5273 Transport Protocols . . . . . . . . . . . . . . . 10 90 4.2. Eligibility . . . . . . . . . . . . . . . . . . . . . . . 10 91 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 10 92 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 93 4.5. Full PKI Requests/Responses . . . . . . . . . . . . . . . 11 94 5. Trust Anchor Profile . . . . . . . . . . . . . . . . . . . . . 11 95 6. Non-Self-Signed Certification Authority Certificate Profile . 11 96 7. End-Entity Certificate Profile . . . . . . . . . . . . . . . . 13 97 7.1. Source of Authority Certificate Profile . . . . . . . . . 13 98 7.2. Client Certificate Profile . . . . . . . . . . . . . . . . 14 99 8. Relying Party Applications . . . . . . . . . . . . . . . . . . 14 100 9. CRL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 102 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 105 12.2. Informative References . . . . . . . . . . . . . . . . . 20 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 108 1. Introduction 110 This document specifies protocol interfaces profiled by the US NSA 111 (United States National Security Agency) for NSS (National Security 112 System) servers that provide public key certificates, CRLs 113 (Certificate Revocation Lists), and symmetric keys to NSS clients. 114 Servers that support these interfaces are referred to as SODP (Secure 115 Object Delivery Protocol) servers. The purpose of this document is 116 to indicate options from, and requirements additional to, the base 117 specifications listed in Section 1.1 that are necessary for client 118 interoperability with NSA-operated SODP servers. Clients are always 119 devices, and need not implement all of the interfaces specified 120 herein; clients are free to choose which interfaces to implement 121 based on their operational requirements. Interfaces supported by 122 SODP servers include: 124 o EST (Enrollment over Secure Transport) [RFC7030] and its 125 extensions [RFC8295], and 126 o CMC (Certificate Management over CMS (Cryptographic Message 127 Syntax)) [RFC5274][RFC6402] for both Simple PKI (Public Key 128 Infrastructure) requests and responses (i.e., PKCS#10 requests 129 and PKCS#7 responses) and Full PKI requests and responses. 131 This profile applies to the capabilities, configuration, and 132 operation of all components of US National Security Systems [SP 800- 133 59]. It is also appropriate for other US Government systems that 134 process high-value information. It is made publicly available for use 135 by developers and operators of these and any other system 136 deployments. 138 This profile conforms to the existing requirements of NSA's 139 Commercial National Security Algorithms. As operational needs evolve 140 over time, this profile will be updated to incorporate new commercial 141 algorithms and protocols as they are developed and approved for use. 143 1.1. Documents to be Familiar With 144 Familiarity with the follow specifications is assumed: 146 o EST [RFC7030] and EST extensions [RFC8295]; 147 o PKI-related specifications [RFC2986], [RFC3739], [RFC5274], 148 [RFC5280], [RFC5912], [RFC5913], [RFC5916], [RFC5917], [RFC6010], 149 and [RFC6402]; 150 o Key-format-related specifications [RFC5915], [RFC5958], 151 [RFC5959], [RFC6031], [RFC6032], [RFC6160], [RFC6161], [RFC6162], 152 [RFC7191], [RFC7192], [RFC7292], and [RFC7906]; 153 o CMS-related (Cryptographic Message Syntax) RFCs [RFC5652], 154 [RFC6268], and; 155 o CNSA-related (Commercial National Security Algorithm) drafts 156 [RFC8603], [ID.cnsa-smime-profile], [ID.cnsa-cmc-profile], and 157 [ID.cnsa-tls-profile]. The profile defined herein does not 158 support RSA-based or DHE-based algorithms. 160 The requirements from RFCs apply throughout this profile and are 161 generally not repeated here. This document is purposely written 162 without [RFC2119] language. 164 1.2. Document Organization 166 The document is organized as follows: 168 o The remainder of this section describes the operational 169 environment used by clients to retrieve secure objects. 170 o Section 2 specifies the version of ASN.1 (Abstract Syntax 171 Notation One) version used. 172 o Section 3 specifies SODP's EST interface. 173 o Section 4 specifies SODP's CMC interfaces; one section each for 174 Simple PKI requests/responses and Full PKI requests/responses. 175 o Sections 5-9 respectively specify TA, CA, and EE certificates as 176 well as CRL. 178 1.3. Environment 180 The environment is Client-Server-based from which clients obtain 181 secure "objects" or "packages". Objects/packages vary based on the 182 SOA (Source of Authority) but all objects are "secured" minimally 183 through the use of one or more digital signatures and zero or more 184 layers of encryption, as profiled in this document. An SOA is the 185 authority for the creation of objects that the client will recognize 186 as valid. An SOA can delegate its authority to other actors; 187 delegation occurs through the issuance of certificates. An object or 188 package is the generic term for certificates, certificate status 189 information, and keys (both asymmetric and symmetric). All of the 190 objects except for the certificates and certificate status 191 information are directly encapsulated in and protected by CMS content 192 types. CMS content types that provide security are referred to as 193 CMS-protecting content types. All others are simply referred to as 194 CMS content types. All secured objects are distributed either as CMS 195 packages or as part of a CMS package. 197 In the following example depicted in Figure 1, there are two SOAs: 198 one for symmetric keys, as depicted by the KTA (Key Trust Anchor), 199 and one for public key certificates, as depicted by the PKI TA (Trust 200 Anchor). The KTA is responsible for the creation and distribution of 201 symmetric keys. The KTA delegates the creation and distribution 202 responsibilities to separate entities through the issuance of 203 certificates to a KSA (Key Source Authority) and a KDA (Key 204 Distribution Authority). The KSA generates the keys, digitally signs 205 the keys, and encrypts the key for the end client using CMS content 206 types for each step. The KDA distributes the KSA-generated and - 207 protected key to the client; the key may also be signed by the KDA. 208 The resulting CMS package is provided to the client through the EST 209 extension's /symmetrickey service. The PKI TA is responsible for the 210 creation, distribution, and management of public key certificates. 211 The PKI TA delegates these responsibilities to CAs (Certification 212 Authorities) and CAs in turn are responsible for creating, 213 distributing, and managing EEs (End-Entities) certificates; CAs 214 distribute PKI-related information through the /cacerts, /crls, 215 /eecerts, /fulcmc, /simpleenroll, /simplereenroll, /csrattrs EST and 216 EST extension services. 218 +-----+ +--------+ 219 | KTA | | PKI TA | 220 +-----+ +--------+ 221 | | 222 | Signs | Signs 223 | | 224 +-------------+ V 225 | | +----+ 226 V V | CA | 227 +-----+ +-----+ +----+ 228 | KSA | | KDA | | 229 +-----+ +-----+ | Signs 230 | | | 231 | Signs & | Optionally +---------------+ 232 | Encrypts | Signs | | 233 | | V V 234 | | +-------------+ +-------------+ 235 | V | Certificate | | Certificate | 236 +---|-------------+ +-------------+ | Revocation | 237 | V | CMS Content | List | 238 | +-------------+ | Types +-------------+ 239 | | Key Package | | 240 | +-------------+ | 241 +-----------------+ 243 Figure 1 - Operating Environment (Key and PKI Sources of Authority) 245 For clients that support the CMC interface and not the EST interface, 246 the environment includes only the PKI TAs. 248 2. Abstract Syntax Notation One 250 Implementations of this specification use the '02/'08 ASN.1 (Abstract 251 Syntax Notation One) version; '02/'08 ASN.1 modules can be found in 252 [RFC5911], [RFC5912], and [RFC6268] (use RFC 6268 for the CMS syntax) 253 while other specifications already include the '02/'08 ASN.1 along 254 with the '88 ASN.1. See Section 1.1 of [RFC6268] for a discussion 255 about the differences between the '02 and '08 ASN.1 versions. 257 3. EST Interface 259 EST [RFC7030] and EST extensions [RFC8295] client options are 260 specified in this section. 262 3.1. Hypertext Transfer Protocol Layer 264 Clients that receive redirection responses (3xx status codes) will 265 terminate the connection ([RFC7030], Section 3.2.1). 267 Clients include an HTTP Accept header with each HTTP GET request to 268 indicate the PAL Package Type supported ([RFC8295], Section 2.1.1). 270 3.2. Transport Layer Security 272 TLS implementations are configured as specified in 273 [ID.cnsa-tls-profile]; the notable exceptions are that RSA-based and 274 DHE-based algorithms are not used. 276 3.3. Eligibility 278 At the EST interface, servers enroll only clients that they have an 279 established relationship with. To accomplish this, client 280 owners/operators interact in person with the human acting as the RA 281 (Registration Authority) to ensure the information included in the 282 transmitted certificate request, which is sometimes called a CSR 283 (Certificate Signing Request), is associated with a client. The 284 mechanism by which the owner/operator interact with the RA as well as 285 the information provided is beyond the scope of this document. The 286 information exchanged by the owner/operator might be something as 287 simple as the subject name included in the to-be sent CSR or a copy 288 of an entire certificate that will be used to verify the certificate 289 request. 291 3.4. Authentication 293 Mutual authentication occurs via "Certificate TLS Authentication" 294 ([RFC7030], Section 2.1). Clients provide their certificate to 295 servers in the TLS Certificate message, which is sent in response to 296 the server's TLS Certificate Request message. Clients reject all 297 server attempts to authenticate that do not validate back to a TA. 299 3.5. Authorization 301 Clients always use an explicit TA database ([RFC7030], Section 302 3.6.1). At a minimum, clients support two TAs; one for the PKI and 303 one for symmetric keys. 305 Clients check that the server's certificate includes the id-kp-cmcRA 306 EKU (Extended Key Usage) value ([RFC6402], Section 2.10). 308 Clients that support processing the CMS Content Constraints extension 309 [RFC6010] ensure returned CMS content is from an SOA or is from an 310 entity authorized by an SOA for that CMS content; see Section 6.0 for 311 SOA certificates. 313 3.6. EST and EST Extensions 315 This section profiles SODP's EST [RFC7030] and EST Extensions 316 [RFC8295] interfaces. 318 3.6.1. /pal 320 The PAL (Package Availability List) is limited to 32 entries, where 321 the 32nd PAL entry links to an additional PAL (i.e., is PAL Package 322 Type 0001). 324 The PAL is XML [XML]. 326 3.6.2. /cacerts 328 The CA certificates located in the explicit TA database are 329 distributed to the client when it is registered. This TA 330 distribution mechanism is out-of-scope. 332 CA certificates provided through this service are as specified in 333 Sections 5 and 6 of this document. 335 3.6.3. /simpleenroll 337 CSRs follow the specifications in Section 5.1 of [ID.cnsa-cmc- 338 profile], with two exceptions. First, the Change Subject Name and 339 the POP Link Witness V2 attributes, which are CMC-specific 340 requirements do not apply. Second, RSA-based algorithms are not 341 used. 343 Client requests include the tls-unique value in the challenge- 344 password attribute, as specified in [RFC7030], or the id-aa- 345 estIdentityLinking attribute, as specified in [RFC7894]. 347 Client certificates provided through this service are as specified in 348 Section 7 of this document. 350 The HTTP content-type of "text/plain" ([RFC2046], Section 4.1) is 351 used to return human readable errors. 353 3.6.4. /simplereenroll 355 There are no additional requirements for requests beyond those 356 specified in Sections 3.4 and 3.6.3 of this document. 358 The HTTP content-type of "text/plain" ([RFC2046], Section 4.1) is 359 used to return human readable errors. 361 3.6.5. /fullcmc 363 Requests are as specified in [ID.cnsa-cmc-profile] with the notable 364 exception that RSA-based algorithms are not used. 366 Additional attributes for returned CMS packages can be found in 367 [RFC7906]. 369 Certificates provided through this service are as specified in 370 Section 7 of this document. 372 3.6.6. /serverkeygen 374 PKCS#12 [RFC7292], sometimes referred to as "PFX" (Personal 375 inFormation eXchange), "P12", and "PKCS#12" files, are used to 376 provide server-generated asymmetric private keys and the associated 377 certificate to clients. This interface is a one-way interface as the 378 RA requests these from the server. 380 PFXs [RFC7292] are exchanged using both password privacy mode and 381 integrity password mode. The PRF algorithm for both the PBES2 and 382 PBMAC1 is HMAC-SHA-384 and the PBES2 encryption scheme is AES-256. 384 The HTTP content-type of "text/plain" ([RFC2046], Section 4.1) is 385 used to return human readable errors. 387 /serverkeygen/return is not supported at this time. 389 3.6.7. /csrattrs 391 Clients use this service to retrieve partially filled PKIRequests: 392 PKIRequests with no public key or proof-of-possession signature, 393 i.e., their values are set to zero length either a zero length BIT 394 STRING or OCTET STRING. The pKCS7PDU attribute, defined in 395 [RFC2985], includes the partially filled PKIRequest as the only 396 element in the CsrAttrs sequence. Even though the CsrAttrs syntax is 397 defined as a set, there is only ever exactly one instance of values 398 present. 400 3.6.8. /crls 402 CRLs provided through this service are as specified in Section 9 of 403 this document. 405 3.6.9. /symmetrickeys 407 Clients that claim to support SODP-interoperation will be able to 408 process the following messages from a SODP server: additional 409 encryption and origin authentication ([RFC8295], Section 5); server- 410 provided Symmetric Key Content Type [RFC6032] encapsulated in an 411 Encrypted Key Content Type using the EnvelopedData choice [RFC6033] 412 with a SOA certificate that includes the CMS Content Constraints 413 extension (see Section 7.1). 415 Client-supported algorithms to decrypt the server-returned symmetric 416 key are as follows: 418 o Message Digest: See Section 5 of [ID.cnsa-smime-profile]. 419 o Digital Signature Algorithm: See Section 6.1 of 420 [ID.cnsa-smime-profile]. 421 o Key Agreement: See Section 7.1 of [ID.cnsa-smime-profile]. 422 o Key Wrap: AES-256 Key Wrap with Padding [RFC6033] is used. AES- 423 128 Key Wrap with Padding is not used. 424 o Content Encryption: AES-256 Key Wrap with Padding [RFC6033] is 425 used. AES-128 Key Wrap with Padding is not used. 427 /serverkeygen/return is not used at this time. 429 3.6.10. /eecerts, /firmware, /tamp 431 /eecerts, /firmware, /tamp are not used at this time. 433 4. CMC Interface 435 CMC [RFC5274][RFC6402] clients options are specified in this section. 437 4.1. RFC 5273 Transport Protocols 439 Clients use only the HTTPS-based transport; the TLS implementation 440 and configuration is as specified in [ID.cnsa-tls-profile]; the 441 notable exceptions are that RSA-based and DHE-based algorithms are 442 not used. 444 Clients that receive HTTP redirection responses (3xx status codes) 445 will terminate the connection ([RFC7030], Section 3.2.1). 447 4.2. Eligibility 449 At the CMC interface, servers enroll only clients that they have an 450 established relationship with. To accomplish this, client 451 owners/operators interact in person with the human acting as the RA 452 (Registration Authority) to ensure the information included in the 453 transmitted certificate request, which is sometimes called a CSR 454 (Certificate Signing Request), is associated with a client. The 455 mechanism by which the owner/operator interact with the RA as well as 456 the information provided is beyond the scope of this document. The 457 information exchanged by the owner/operator might be something as 458 simple as the subject name included in the to-be sent CSR or a copy 459 of an entire certificate that will be used to verify the certificate 460 request. 462 4.3. Authentication 464 Mutual authentication occurs via client and server signing of CMC 465 protocol elements, as required by [ID.cnsa-cmc-profile]. All such 466 signatures must be validated against an installed TA; any that fail 467 validation are rejected. 469 4.4. Authorization 471 Clients support the simultaneous presence of as many TAs as are 472 required for all of the functions of the client, and only these TAs. 474 Clients check that the server's certificate includes the id-kp-cmcRA 475 EKU (Extended Key Usage) value [RFC6402], Section 2.10. 477 Clients that support processing the CMS Content Constraints extension 478 [RFC6010] ensure returned CMS content is from an SOA or is from an 479 entity authorized by an SOA for that CMS content; see Section 6.0 for 480 SOA certificates 482 4.5. Full PKI Requests/Responses 484 Requests are as specified in [ID.cnsa-cmc-profile] with the notable 485 exception that RSA-based algorithms are not used. 487 Additional attributes for returned CMC packages can be found in 488 [RFC7906]. 490 Certificates provided through this service are as specified in 491 Section 7 of this document. 493 5. Trust Anchor Profile 495 Clients are free to store the TA in format of their choosing; 496 however, servers provide TA information in the form of self-signed CA 497 certificates. This section documents requirements for self-signed 498 certificates in addition to those specified in [RFC8603], which in 499 turn specifies requirements in addition to those in [RFC5280]. 501 RSA-based algorithms are not used. 503 Issuer and subject names are composed of only the following naming 504 attributes: country name, domain component, organization name, 505 organizational unit name, common name, state or province name, 506 distinguished name qualifier, and serial number. 508 In the Subject Key Identifier extension, the keyIdentifier is the 64 509 low-order bits of the subject's subjectPublicKey field. 511 In the Key Usage extension, the nonRepudiation bit is never set. 513 6. Non-Self-Signed Certification Authority Certificate Profile 515 This section documents requirements for non-self signed CA 516 certificates in addition to those specified in [RFC8603], which in 517 turn specifies requirements in addition to those in [RFC5280]. 519 RSA-based algorithms are not used. 521 Subject names are composed of only the following naming attributes: 522 country name, domain component, organization name, organizational 523 unit name, common name, state or province name, distinguished name 524 qualifier, and serial number. 526 In the Authority Key Identifier extension, the keyIdentifier choice 527 is always used. The keyIdentifier is the 64 low-order bits of the 528 issuer's subjectPublicKey field. 530 In the Subject Key Identifier extension, the keyIdentifier is the 64 531 low-order bits of the subject's subjectPublicKey field. 533 In the Key Usage extension, the nonRepudiation bit is never set. 535 The Certificate Policies extension is always included and 536 policyQualifiers are never used. 538 Non-self-signed CA certificates can also include the following: 540 o Name Constraints: permittedSubtrees constraints are applied and 541 excludedSubstree constraints are not. Of the GeneralName 542 choices, issuers support the following: rfc822Name, dNSName, 543 uniformResourceIdentifier, and iPAddress (both IPv4 and IPv6) as 544 well as hardwareModuleName, which is defined in [RFC4108]. Note 545 that rfc822Name, dNSName, and uniformResourceIdentifier are 546 defined as IA5 strings and the character sets allowed is not 547 uniform amongst these three name forms. 549 o CRL Distribution Points: A distributionPoint is always the 550 fullName choice; the uniformResourceIdentifier GeneralName choice 551 is always included but others can also be used as long as the 552 first element in the sequence of CRLDistributionPoints is the 553 uniformResourceIdentifier choice; the reasons and CRLIssuer 554 fields are never populated. This extension is never marked 555 critical. 557 o Authority Information Access: Only one instance of 558 AccessDescription is included. accessMethod is id-caIssuers and 559 accessLocation's GeneralName is always the 560 uniformResourceIdentifier choice. 562 o Extended Key Usage: EST servers and RAs include the id-kp-cmcRA 563 EKU and the CAs include the id-kp-cmcCA, which are both specified 564 in [RFC6402]. 566 Issuers include the Authority Clearance Constraints extension 567 [RFC5913] in non-self-signed CA certificates that are issued to non- 568 SOAs; values for the CP (Certificate Policy) OID (Object IDentifier) 569 and the supported classList values are found in the Issuer's CP. 570 Criticality is determined by the issuer and a securityCategories is 571 never included. Only one instance of Clearance is generated in the 572 AuthorityClearanceConstraints sequence. 574 Issuers include a critical CMS Content Constraints extension 575 [RFC6010] in CA certificates used to issue SOA certificates. The 576 content types included depend on the packages the SOA sources, but 577 include key packages (i.e., Encrypted Key Packages, Symmetric Key 578 Packages, and Asymmetric Key Packages). 580 7. End-Entity Certificate Profile 582 This section documents requirements for EE signature and key 583 establishment certificates in addition to those listed in [RFC8603], 584 which in turn specifies requirements in addition to those in 585 [RFC5280]. 587 RSA-based algorithms are not used. 589 Subject names are composed of the following naming attributes: 590 country name, domain component, organization name, organizational 591 unit name, common name, state or province name, distinguished name 592 qualifier, and serial number. 594 In the Authority Key Identifier extension, the keyIdentifier choice 595 is always used. The keyIdentifier is the 64 low-order bits of the 596 issuer's subjectPublicKey field. 598 In the Subject Key Identifier extension, the keyIdentifier is the 64 599 low-order bits of the subject's subjectPublicKey field. 601 In the Key Usage extension, signature certificates only assert 602 digitalSignature and key establishment certificates only assert 603 keyAgreement. 605 The Certificate Policies extension is always included and 606 policyQualifiers are never used. 608 When included, the non-critical CRL Distribution Point extension's 609 distributionPoint is always identified by the fullName choice; the 610 uniformResourceIdentifier GeneralName choice is always included but 611 others can also be used as long as the first element in the sequence 612 of distribution points is the URI choice and it is an HTTP/HTTPS 613 scheme; the reasons and cRLIssuer fields are never populated. 615 The following subsections provide additional requirements for the 616 different types of EE certificates. 618 7.1. Source of Authority Certificate Profile 620 This section specifies the format for SOA certificates, i.e., 621 certificates issued to those entities that are authorized to create, 622 digitally sign, encrypt, and distribute key packages; these 623 certificates are issued by non-PKI TAs. 625 The Subject Alternative Name extension is always included. The 626 following choices are supported rfc822Name, dnsName, ediPartyName, 627 uniformResourceIdentifier, or ipAddress (both IPv4 and IPv6). This 628 extension is never critical. 630 A critical CMS Content Constraints extension [RFC6010] is included in 631 SOA signature certificates. The content types included depend on the 632 packages the SOA sources (e.g., Encrypted Key Packages, Symmetric Key 633 Packages, Asymmetric Key Packages). 635 7.2. Client Certificate Profile 637 This section specifies the format for certificates issued to clients. 639 A non-critical Subject Directory Attributes extension is always 640 included with the following attributes: 642 o Device Owner [RFC5916] 643 o Clearance Sponsor [RFC5917] 644 o Clearance [RFC5913] 646 The following extensions are also included at the discretion of the 647 CA: 649 o The Authority Information Access extension with only one instance 650 of the accessMethod id-caIssuers and the accessLocation's 651 GeneralName using the uniformResourceIdentifier choice. 653 o A non-critical Subject Alternative Name extension that includes 654 the hardwareModuleName form [RFC4108], rfc822Name, or 655 uniformResourceIdentifier. 657 o A critical Subject Alternative Name extension that includes: 658 dNSName, rfc822Name, ediPartyName, uniformResourceIdentifier, or 659 ipAddress (both IPv4 and IPv6). 661 8. Relying Party Applications 663 This section documents requirements for RPs (Relying Parties) in 664 addition to those listed in [RFC8603], which in turn specifies 665 requirements in addition to those in [RFC5280]. 667 RSA-based algorithms are not used. 669 RPs support the Authority Key Identifier and the Subject Key 670 Identifier extensions. 672 RPs should support the following extensions: CRL Distribution Points, 673 Authority Information Access, Subject Directory Attribute, Authority 674 Clearance Constraints, and CMS Content Constraints extensions. 676 Within the Subject Directory Attribute extension, RPs should support 677 the Clearance Sponsor, Clearance, and Device Owner attributes. 679 RPs support the id-kp-cmcRA and id-kp-cmcCA EKUs. 681 Failure to support extensions in this section might limit the 682 suitability of a device for certain applications. 684 9. CRL Profile 686 This section documents requirements for CRLs in addition to those 687 listed in [RFC8603], which in turn specifies requirements in addition 688 to those in [RFC5280]. 690 RSA-based algorithms are not used. 692 Two types of CRLs are produced: complete base CRLs and partitioned 693 base CRLs. 695 crlEntryExtensions are never included and the reasons and cRLIssuer 696 fields are never populated. 698 All CRLs include the following CRL extensions: 700 o The Authority Key Identifier extension: The keyIdentifier is the 701 64 low-order bits of the issuer's subjectPublicKey field. 703 o As per [RFC5280], the CRL Number extension. 705 The only other extension included in partitioned base CRLs is the 706 Issuing Distribution Point extension. The distributionPoint is 707 always identified by the fullName choice; the 708 uniformResourceIdenifier GeneralName choice is always included but 709 others can also be used as long as the first element in the sequence 710 of distribution points is the uniformResourceIdenifier choice and the 711 scheme is an HTTP/HTTPS scheme; all other fields are omitted. 713 10. IANA Considerations 715 None. 717 11. Security Considerations 719 This entire document is about security. This document profiles the 720 use of many protocols and services: EST, CMC, and PKCS#10/#7/#12 as 721 well as certificates, CRLs, and their extensions [RFC5280]. These 722 have been referred to throughout this document and those 723 specifications should be consulted for security considerations 724 related to implemented protocol and services. 726 12. References 728 12.1. Normative References 730 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 731 Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 732 10.17487/RFC2046, November 1996, . 735 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 736 Classes and Attribute Types Version 2.0", RFC 2985, DOI 737 10.17487/RFC2985, November 2000, . 740 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 741 Request Syntax Specification Version 1.7", RFC 2986, DOI 742 10.17487/RFC2986, November 2000, . 745 [RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 746 Public Key Infrastructure: Qualified Certificates Profile", 747 RFC 3739, DOI 10.17487/RFC3739, March 2004, 748 . 750 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 751 Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, 752 August 2005, . 754 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 755 over CMS (CMC): Compliance Requirements", RFC 5274, DOI 756 10.17487/RFC5274, June 2008, . 759 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 760 Housley, R., and W. Polk, "Internet X.509 Public Key 761 Infrastructure Certificate and Certificate Revocation List 762 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 763 . 765 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 766 RFC 5652, DOI 10.17487/RFC5652, September 2009, 767 . 769 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 770 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 771 DOI 10.17487/RFC5911, June 2010, . 774 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 775 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 776 DOI 10.17487/RFC5912, June 2010, . 779 [RFC5913] Turner, S. and S. Chokhani, "Clearance Attribute and 780 Authority Clearance Constraints Certificate Extension", 781 RFC 5913, DOI 10.17487/RFC5913, June 2010, 782 . 784 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 785 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 786 . 788 [RFC5916] Turner, S., "Device Owner Attribute", RFC 5916, DOI 789 10.17487/RFC5916, June 2010, . 792 [RFC5917] Turner, S., "Clearance Sponsor Attribute", RFC 5917, DOI 793 10.17487/RFC5917, June 2010, . 796 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 797 10.17487/RFC5958, August 2010, . 800 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 801 Type", RFC 5959, DOI 10.17487/RFC5959, August 2010, 802 . 804 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 805 Message Syntax (CMS) Content Constraints Extension", 806 RFC 6010, DOI 10.17487/RFC6010, September 2010, 807 . 809 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 810 (CMS) Symmetric Key Package Content Type", RFC 6031, DOI 811 10.17487/RFC6031, December 2010, . 814 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 815 (CMS) Encrypted Key Package Content Type", RFC 6032, DOI 816 10.17487/RFC6032, December 2010, . 819 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 820 (CMS) Encrypted Key Package Content Type", RFC 6033, DOI 821 10.17487/RFC6033, December 2010, . 824 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 825 (CMS) Protection of Symmetric Key Package Content Types", 826 RFC 6160, DOI 10.17487/RFC6160, April 2011, 827 . 829 [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic 830 Message Syntax (CMS) Encrypted Key Package Content Type", 831 RFC 6161, DOI 10.17487/RFC6161, April 2011, 832 . 834 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 835 Message Syntax (CMS) Asymmetric Key Package Content Type", 836 RFC 6162, DOI 10.17487/RFC6162, April 2011, 837 . 839 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for 840 the Cryptographic Message Syntax (CMS) and the Public Key 841 Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 842 10.17487/RFC6268, July 2011, . 845 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 846 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 847 . 849 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 850 "Enrollment over Secure Transport", RFC 7030, DOI 851 10.17487/RFC7030, October 2013, . 854 [RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key 855 Package Receipt and Error Content Types", RFC 7191, DOI 856 10.17487/RFC7191, April 2014, . 859 [RFC7192] Turner, S., "Algorithms for Cryptographic Message Syntax 860 (CMS) Key Package Receipt and Error Content Types", 861 RFC 7192, DOI 10.17487/RFC7192, April 2014, 862 . 864 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 865 and M. Scott, "PKCS #12: Personal Information Exchange 866 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 867 . 869 [RFC7894] Pritikin, M. and C. Wallace, "Alternative Challenge 870 Password Attributes for Enrollment over Secure Transport", 871 RFC 7894, DOI 10.17487/RFC7894, June 2016, 872 . 874 [RFC7906] Timmel, P., Housley, R., and S. Turner, "NSA's 875 Cryptographic Message Syntax (CMS) Key Management 876 Attributes", RFC 7906, DOI 10.17487/RFC7906, June 2016, 877 . 879 [RFC8295] Turner, S., "EST (Enrollment over Secure Transport) 880 Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, 881 . 883 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 884 Algorithm (CNSA) Suite Certificate and Certificate 885 Revocation List (CRL) Profile", RFC 8603, DOI 886 10.17487/RFC8603, May 2019, . 889 [XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 890 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 891 Edition)", World Wide Web Consortium Recommendation 892 REC-xml-20081126, November 2008, 893 . 895 [SP 800-59] National Institute of Standards and Technology, 896 "Guideline for Identifying an Information System as a 897 National Security System", SP 800-59, August 2003, 898 . 901 [ID.cnsa-smime-profile] Jenkins, M., "Using CNSA Suite Algorithms in 902 Secure/Multipurpose Internet Mail Extensions(S/MIME)", 903 work-in-progress, . 906 [ID.cnsa-cmc-profile] Jenkins, M. and L. Zieglar, "Commercial 907 National Security Algorithm (CNSA) Suite Profile of 908 Certificate Management over CMS", work-in-progress, 909 . 912 [ID.cnsa-tls-profile] Authors, "Commercial National Security 913 Algorithm (CNSA) Suite Profile of TLS", work-in-progress, 914 . 917 12.2. Informative References 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, DOI 921 10.17487/RFC2119, March 1997, . 924 None. 926 Authors' Addresses 928 Michael Jenkins 929 National Security Agency 931 EMail: mjjenki@nsa.gov 933 Sean Turner 934 sn3rd 936 EMail: sean@sn3rd.com