idnits 2.17.1 draft-turner-sodp-profile-01.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 (June 1, 2019) is 1781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'SP 800-59' is defined on line 903, 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: December 3, 2019 sn3rd 6 June 1, 2019 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-01.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 This profile conforms to the existing requirements of NSA's 35 Commercial National Security Algorithms. As operational needs evolve 36 over time, this profile will be updated to incorporate new commercial 37 algorithms and protocols as they are developed and approved for use. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Documents to be Familiar With . . . . . . . . . . . . . . . 3 73 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 74 1.3. Environment . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Abstract Syntax Notation One . . . . . . . . . . . . . . . . . 6 76 3. EST Interface . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1. Hypertext Transfer Protocol Layer . . . . . . . . . . . . 6 78 3.2. Transport Layer Security . . . . . . . . . . . . . . . . . 6 79 3.3. Eligibility . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 81 3.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 82 3.6. EST and EST Extensions . . . . . . . . . . . . . . . . . . 7 83 3.6.1. /pal . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 3.6.2. /cacerts . . . . . . . . . . . . . . . . . . . . . . . 7 85 3.6.3. /simpleenroll . . . . . . . . . . . . . . . . . . . . 8 86 3.6.4. /simplereenroll . . . . . . . . . . . . . . . . . . . 8 87 3.6.5. /fullcmc . . . . . . . . . . . . . . . . . . . . . . . 8 88 3.6.6. /serverkeygen . . . . . . . . . . . . . . . . . . . . 8 89 3.6.7. /csrattrs . . . . . . . . . . . . . . . . . . . . . . 9 90 3.6.8. /crls . . . . . . . . . . . . . . . . . . . . . . . . 9 91 3.6.9. /symmetrickeys . . . . . . . . . . . . . . . . . . . . 9 92 3.6.10. /eecerts, /firmware, /tamp . . . . . . . . . . . . . 9 93 4. CMC Interface . . . . . . . . . . . . . . . . . . . . . . . . 10 94 4.1. RFC 5273 Transport Protocols . . . . . . . . . . . . . . . 10 95 4.2. Eligibility . . . . . . . . . . . . . . . . . . . . . . . 10 96 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 10 97 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 98 4.5. Simple PKI Requests/Responses . . . . . . . . . . . . . . 11 99 4.6. Full PKI Requests/Responses . . . . . . . . . . . . . . . 11 100 5. Trust Anchor Profile . . . . . . . . . . . . . . . . . . . . . 11 101 6. Non-Self-Signed Certification Authority Certificate Profile . 11 102 7. End-Entity Certificate Profile . . . . . . . . . . . . . . . . 13 103 7.1. Source of Authority Certificate Profile . . . . . . . . . 14 104 7.2. Client Certificate Profile . . . . . . . . . . . . . . . . 14 105 8. Relying Party Applications . . . . . . . . . . . . . . . . . . 14 106 9. CRL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 15 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 108 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 110 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 111 12.2. Informative References . . . . . . . . . . . . . . . . . 20 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 114 1. Introduction 116 This document specifies protocol interfaces profiled by the US NSA 117 (United States National Security Agency) for NSS (National Security 118 System) servers that provide public key certificates, CRLs 119 (Certificate Revocation Lists), and symmetric keys to NSS clients. 120 Servers that support these interfaces are referred to as SODP (Secure 121 Object Delivery Protocol) servers. The purpose of this document is 122 to indicate options from, and requirements additional to, the base 123 specifications listed in Section 1.1 that are necessary for client 124 interoperability with NSA-operated SODP servers. Clients are always 125 devices, and need not implement all of the interfaces specified 126 herein; clients are free to choose which interfaces to implement 127 based on their operational requirements. Interfaces supported by 128 SODP servers include: 130 o EST (Enrollment over Secure Transport) [RFC7030] and its 131 extensions [RFC8295], and 132 o CMC (Certificate Management over CMS (Cryptographic Message 133 Syntax)) [RFC5274][RFC6402] for both Simple PKI (Public Key 134 Infrastructure) requests and responses (i.e., PKCS#10 requests 135 and PKCS#7 responses) and Full PKI requests and responses. 137 This profile applies to the capabilities, configuration, and 138 operation of all components of US National Security Systems [SP 800- 139 59]. It is also appropriate for other US Government systems that 140 process high-value information. It is made publicly available for use 141 by developers and operators of these and any other system 142 deployments. 144 1.1. Documents to be Familiar With 145 Familiarity with the follow specifications is assumed: 147 o EST [RFC7030] and EST extensions [RFC8295]; 148 o PKI-related specifications [RFC2986], [RFC3739], [RFC5274], 149 [RFC5280], [RFC5912], [RFC5913], [RFC5916], [RFC5917], [RFC6010], 150 and [RFC6402]; 151 o Key-format-related specifications [RFC5915], [RFC5958], 152 [RFC5959], [RFC6031], [RFC6032], [RFC6160], [RFC6161], [RFC6162], 153 [RFC7191], [RFC7192], [RFC7292], and [RFC7906]; 154 o CMS-related (Cryptographic Message Syntax) RFCs [RFC5652], 155 [RFC6268], and; 156 o CNSA-related (Commercial National Security Algorithm) drafts 157 [RFC8603], [ID.cnsa-smime-profile], [ID.cnsa-cmc-profile], and 158 [ID.cnsa-tls-profile]. The profile defined herein does not 159 support RSA-based algorithms. 161 The requirements from RFCs apply throughout this profile and are 162 generally not repeated here. This document is purposely written 163 without RFC 2119-language. 165 1.2. Document Organization 167 The document is organized as follows: 169 o The remainder of this section describes the operational 170 environment used by clients to retrieve secure objects. 171 o Section 2 specifies the version of ASN.1 (Abstract Syntax 172 Notation One) version used. 173 o Section 3 specifies SODP's EST interface. 174 o Section 4 specifies SODP's CMC interfaces; one section each for 175 Simple PKI requests/responses and Full PKI requests/responses. 176 o Sections 5-9 respectively specify TA, CA, and EE certificates as 177 well as CRL. 179 1.3. Environment 181 The environment is Client-Server-based from which clients obtain 182 secure "objects" or "packages". Objects/packages vary based on the 183 SOA (Source of Authority) but all objects are "secured" minimally 184 through the use of one or more digital signatures and zero or more 185 layers of encryption, as profiled in this document. An SOA is the 186 authority for the creation of objects that the client will recognize 187 as valid. An SOA can delegate its authority to other actors; 188 delegation occurs through the issuance of certificates. An object or 189 package is the generic term for certificates, certificate status 190 information, and keys (both asymmetric and symmetric). All of the 191 objects except for the certificates and certificate status 192 information are directly encapsulated in and protected by CMS content 193 types. CMS content types that provide security are referred to as 194 CMS-protecting content types. All others are simply referred to as 195 CMS content types. All secured objects are distributed either as CMS 196 packages or as part of a CMS package. 198 In the following example depicted in Figure 1, there are two SOAs: 199 one for symmetric keys, as depicted by the KTA (Key Trust Anchor), 200 and one for public key certificates, as depicted by the PKI TA (Trust 201 Anchor). The KTA is responsible for the creation and distribution of 202 symmetric keys. The KTA delegates the creation and distribution 203 responsibilities to separate entities through the issuance of 204 certificates to a KSA (Key Source Authority) and a KDA (Key 205 Distribution Authority). The KSA generates the keys, digitally signs 206 the keys, and encrypts the key for the end client using CMS content 207 types for each step. The KDA distributes the KSA-generated and - 208 protected key to the client; the key may also be signed by the KDA. 209 The resulting CMS package is provided to the client through the EST 210 extension's /symmetrickey service. The PKI TA is responsible for the 211 creation, distribution, and management of public key certificates. 212 The PKI TA delegates these responsibilities to CAs (Certification 213 Authorities) and CAs in turn are responsible for creating, 214 distributing, and managing EEs (End-Entities) certificates; CAs 215 distribute PKI-related information through the /cacerts, /crls, 216 /eecerts, /fulcmc, /simpleenroll, /simplereenroll, /csrattrs EST and 217 EST extension services. 219 +-----+ +--------+ 220 | KTA | | PKI TA | 221 +-----+ +--------+ 222 | | 223 | Signs | Signs 224 | | 225 +-------------+ V 226 | | +----+ 227 V V | CA | 228 +-----+ +-----+ +----+ 229 | KSA | | KDA | | 230 +-----+ +-----+ | Signs 231 | | | 232 | Signs & | Optionally +---------------+ 233 | Encrypts | Signs | | 234 | | V V 235 | | +-------------+ +-------------+ 236 | V | Certificate | | Certificate | 237 +---|-------------+ +-------------+ | Revocation | 238 | V | CMS Content | List | 239 | +-------------+ | Type(s) +-------------+ 240 | | Key Package | | 241 | +-------------+ | 242 +-----------------+ 244 Figure 1 - Operating Environment (Key and PKI Sources of Authority) 246 For clients that support the CMC interface and not the EST interface, 247 the environment includes only the PKI TA(s). 249 2. Abstract Syntax Notation One 251 Implementations of this specification use the '02/'08 ASN.1 (Abstract 252 Syntax Notation One) version; '02/'08 ASN.1 modules can be found in 253 [RFC5911], [RFC5912], and [RFC6268] (use RFC 6268 for the CMS syntax) 254 while other specifications already include the '02/'08 ASN.1 along 255 with the '88 ASN.1. See Section 1.1 of [RFC6268] for a discussion 256 about the differences between the '02 and '08 ASN.1 versions. 258 3. EST Interface 260 EST [RFC7030] and EST extensions [RFC8295] client options are 261 specified in this section. 263 3.1. Hypertext Transfer Protocol Layer 265 Clients that receive redirection responses (3xx status codes) will 266 terminate the connection ([RFC7030], Section 3.2.1). 268 Clients include an HTTP Accept header with each HTTP GET request to 269 indicate the PAL Package Type supported ([RFC8295], Section 2.1.1). 271 3.2. Transport Layer Security 273 TLS implementations are configured as specified in 274 [ID.cnsa-tls-profile]; the notable exception is that RSA-based 275 algorithms are not supported. 277 3.3. Eligibility 279 Servers enroll only clients that they have an established 280 relationship with. To accomplish this, client owners/operators 281 interact in person with the human acting as the RA (Registration 282 Authority) to ensure the information included in the transmitted 283 certificate request, which is sometimes called a CSR (Certificate 284 Signing Request), is associated with a client. The mechanism by 285 which the owner/operator interact with the RA as well as the 286 information provided is beyond the scope of this document. The 287 information exchanged by the owner/operator might be something as 288 simple as the subject name included in the to-be sent CSR or a copy 289 of an entire certificate that will be used to verify the certificate 290 request. 292 3.4. Authentication 294 Mutual authentication occurs via "Certificate TLS Authentication" 295 ([RFC7030], Section 2.1). Clients provide their certificate to 296 servers in the TLS Certificate message, which is sent in response to 297 the server's TLS Certificate Request message. Clients reject all 298 server attempts to authenticate that do not validate back to a TA. 300 3.5. Authorization 302 Clients always use an explicit TA database ([RFC7030], Section 303 3.6.1). At a minimum, clients support two TAs; one for the PKI and 304 one for symmetric keys. 306 Clients check that the server's certificate includes the id-kp-cmcRA 307 EKU (Extended Key Usage) value ([RFC6402], Section 2.10). 309 Clients that support processing the CMS Content Constraints extension 310 [RFC6010] ensure returned CMS content is from an SOA or is from an 311 entity authorized by an SOA for that CMS content; see Section 6.0 for 312 SOA certificates. 314 3.6. EST and EST Extensions 316 This section profiles SODP's EST [RFC7030] and EST Extensions 317 [RFC8295] interfaces. 319 3.6.1. /pal 321 The PAL (Package Availability List) is limited to 32 entries, where 322 the 32nd PAL entry links to an additional PAL (i.e., is PAL Package 323 Type 0001). 325 The PAL is XML [XML]. 327 3.6.2. /cacerts 329 The CA certificates located in the explicit TA database are 330 distributed to the client when it is registered. This TA 331 distribution mechanism is out-of-scope. 333 CA certificates provided through this service are as specified in 334 Sections 5 and 6 of this document. 336 3.6.3. /simpleenroll 338 CSRs follow the specifications in Section 5.1 of [ID.cnsa-cmc- 339 profile], with two exceptions. First, the Change Subject Name and 340 the POP Link Witness V2 attributes, which are CMC-specific 341 requirements do not apply. Second, RSA-based algorithms are not 342 supported. 344 Client requests include the tls-unique value in the challenge- 345 password attribute, as specified in [RFC7030], or the id-aa- 346 estIdentityLinking attribute, as specified in [RFC7894]. 348 Client certificates provided through this service are as specified in 349 Section 7 of this document. 351 The HTTP content-type of "text/plain" ([RFC2046], Section 4.1) is 352 used to return human readable errors. 354 3.6.4. /simplereenroll 356 Nothing additional for requests beyond what is specified in Sections 357 3.4 and 3.6.3 of this document. 359 The HTTP content-type of "text/plain" ([RFC2046], Section 4.1) is 360 used to return human readable errors. 362 3.6.5. /fullcmc 364 Requests are as specified in [ID.cnsa-cmc-profile] with the notable 365 exception that RSA-based algorithms are not supported. 367 Additional attributes for returned CMS packages can be found in 368 [RFC7906]. 370 Certificates provided through this service are as specified in 371 Section 7 of this document. 373 3.6.6. /serverkeygen 375 PKCS#12 [RFC7292], sometimes referred to as "PFX" (Personal 376 inFormation eXchange), "P12", and "PKCS#12" files, are used to 377 provide server-generated asymmetric private keys and the associated 378 certificate to clients. This interface is a one-way interface as the 379 RA requests these from the server. 381 PFXs [RFC7292] are exchanged using both password privacy mode and 382 integrity password mode. The PRF algorithm for both the PBES2 and 383 PBMAC1 is HMAC-SHA-384 and the PBES2 encryption scheme is AES-256. 385 The HTTP content-type of "text/plain" ([RFC2046], Section 4.1) is 386 used to return human readable errors. 388 /serverkeygen/return is not supported at this time. 390 3.6.7. /csrattrs 392 Clients use this service to retrieve partially filled PKIRequests; 393 PKIRequests with no public key or proof-of-possession signature, 394 i.e., their values are set to zero length either a zero length BIT 395 STRING or OCTET STRING. The pKCS7PDU attribute, defined in 396 [RFC2985], includes the partially filled PKIRequest as the only 397 element in the CsrAttrs sequence. Even though the CsrAttrs syntax is 398 defined as a set, there is only ever exactly one instance of values 399 present. 401 3.6.8. /crls 403 CRLs provided through this service are as specified in Section 9 of 404 this document. 406 3.6.9. /symmetrickeys 408 Clients that claim to support SODP-interoperation will be able to 409 process the following messages from a SODP server: additional 410 encryption and origin authentication ([RFC8295], Section 5); server- 411 provided Symmetric Key Content Type [RFC6032] encapsulated in an 412 Encrypted Key Content Type using the EnvelopedData choice [RFC6033] 413 with a SOA certificate that includes the CMS Content Constraints 414 extension (see Section 7.1). 416 Client-supported algorithms to decrypt the server-returned symmetric 417 key are as follows: 419 o Message Digest: See Section 5 of [ID.cnsa-smime-profile]. 420 o Digital Signature Algorithm: See Section 6.1 of 421 [ID.cnsa-smime-profile]. 422 o Key Agreement: See Section 7.1 of [ID.cnsa-smime-profile]. 423 o Key Wrap: AES-256 Key Wrap with Padding [RFC6033] is used. AES- 424 128 Key Wrap with Padding is not used. 425 o Content Encryption: AES-256 Key Wrap with Padding [RFC6033] is 426 used. AES-128 Key Wrap with Padding is not used. 428 /serverkeygen/return is not supported at this time. 430 3.6.10. /eecerts, /firmware, /tamp 432 /eecerts, /firmware, /tamp are not supported at this time. 434 4. CMC Interface 436 CMC [RFC5274][RFC6402] clients options are specified in this section. 438 4.1. RFC 5273 Transport Protocols 440 Clients use only the HTTPS-based transport; the TLS implementation 441 and configuration is as specified in [ID.cnsa-tls-profile]; the 442 notable exception is that RSA-based algorithms are not supported. 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 Servers enroll only clients that they have an established 450 relationship with. To accomplish this, client owners/operators 451 interact in person with the human acting as the RA (Registration 452 Authority) to ensure the information included in the transmitted 453 certificate request, which is sometimes called a CSR (Certificate 454 Signing Request), is associated with a client. The mechanism by 455 which the owner/operator interact with the RA as well as the 456 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. Simple PKI Requests/Responses 484 CSRs follow the specifications in Section 5.1 of [ID.cnsa-cmc- 485 profile], with two exceptions. First, the Change Subject Name and 486 the POP Link Witness V2 attributes, which are CMC-specific 487 requirements do not apply. Second, RSA-based algorithms are not 488 supported. 490 Certificates provided through this service are as specified in 491 Section 7 of this document. 493 4.6. Full PKI Requests/Responses 495 Requests are as specified in [ID.cnsa-cmc-profile] with the notable 496 exception that RSA-based algorithms are not supported. 498 Additional attributes for returned CMC packages can be found in 499 [RFC7906]. 501 Certificates provided through this service are as specified in 502 Section 7 of this document. 504 5. Trust Anchor Profile 506 Clients are free to store the TA in format of their choosing; 507 however, servers provide TA information in the form of self-signed CA 508 certificates. This section documents requirements for self-signed 509 certificates in addition to those specified in [RFC8603], which in 510 turn specifies requirements in addition to those in [RFC5280]. 512 RSA-based algorithms are not supported. 514 Issuer and subject names are composed of only the following naming 515 attributes: country name, domain component, organization name, 516 organizational unit name, common name, state or province name, 517 distinguished name qualifier, and serial number. 519 In the Subject Key Identifier extension, the keyIdentifier is the 64 520 low-order bits of the subject's subjectPublicKey field. 522 In the Key Usage extension, the nonRepudiation bit is never set. 524 6. Non-Self-Signed Certification Authority Certificate Profile 526 This section documents requirements for non-self signed CA 527 certificates in addition to those specified in [RFC8603], which in 528 turn specifies requirements in addition to those in [RFC5280]. 530 RSA-based algorithms are not supported. 532 Subject names are composed of only the following naming attributes: 533 country name, domain component, organization name, organizational 534 unit name, common name, state or province name, distinguished name 535 qualifier, and serial number. 537 In the Authority Key Identifier extension, the keyIdentifier choice 538 is always used. The keyIdentifier is the 64 low-order bits of the 539 issuer's subjectPublicKey field. 541 In the Subject Key Identifier extension, the keyIdentifier is the 64 542 low-order bits of the subject's subjectPublicKey field. 544 In the Key Usage extension, the nonRepudiation bit is never set. 546 The Certificate Policies extension is always included and 547 policyQualifiers are never used. 549 Non-self-signed CA certificates can also include the following: 551 o Name Constraints: permittedSubtrees constraints are applied and 552 excludedSubstree constraints are not. Of the GeneralName 553 choices, issuers support the following: rfc822Name, dNSName, 554 uniformResourceIdentifier, and iPAddress (both IPv4 and IPv6) as 555 well as hardwareModuleName, which is defined in [RFC4108]. Note 556 that rfc822Name, dNSName, and uniformResourceIdentifier are 557 defined as IA5 strings and the character sets allowed is not 558 uniform amongst these three name forms. 560 o CRL Distribution Points: A distributionPoint is always the 561 fullName choice; the uniformResourceIdentifier GeneralName choice 562 is always included but others can also be used as long as the 563 first element in the sequence of CRLDistributionPoints is the 564 uniformResourceIdentifier choice; the reasons and CRLIssuer 565 fields are never populated. This extension is never marked 566 critical. 568 o Authority Information Access: Only one instance of 569 AccessDescription is included. accessMethod is id-caIssuers and 570 accessLocation's GeneralName is always the 571 uniformResourceIdentifier choice. 573 o Extended Key Usage: EST servers and RAs include the id-kp-cmcRA 574 EKU and the CAs include the id-kp-cmcCA, which are both specified 575 in [RFC6402]. 577 Issuers include the Authority Clearance Constraints extension 579 [RFC5913] in non-self-signed CA certificates that are issued to non- 580 SOAs; values for the CP (Certificate Policy) OID (Object IDentifier) 581 and the supported classList values are found in the Issuer's CP. 582 Criticality is determined by the issuer and a securityCategories is 583 never included. Only one instance of Clearance is generated in the 584 AuthorityClearanceConstraints sequence. 586 Issuers include a critical CMS Content Constraints extension 587 [RFC6010] in CA certificates used to issue SOA certificates. The 588 content types included depend on the packages the SOA sources, but 589 include key packages (i.e., Encrypted Key Packages, Symmetric Key 590 Packages, and Asymmetric Key Packages). 592 7. End-Entity Certificate Profile 594 This section documents requirements for EE signature and key 595 establishment certificates in addition to those listed in [RFC8603], 596 which in turn specifies requirements in addition to those in 597 [RFC5280]. 599 RSA-based algorithms are not supported. 601 Subject names are composed of the following naming attributes: 602 country name, domain component, organization name, organizational 603 unit name, common name, state or province name, distinguished name 604 qualifier, and serial number. 606 In the Authority Key Identifier extension, the keyIdentifier choice 607 is always used. The keyIdentifier is the 64 low-order bits of the 608 issuer's subjectPublicKey field. 610 In the Subject Key Identifier extension, the keyIdentifier is the 64 611 low-order bits of the subject's subjectPublicKey field. 613 In the Key Usage extension, signature certificates only assert 614 digitalSignature and key establishment certificates only assert 615 keyAgreement. 617 The Certificate Policies extension is always included and 618 policyQualifiers are never used. 620 When included, the non-critical CRL Distribution Point extension's 621 distributionPoint is always identified by the fullName choice; the 622 uniformResourceIdentifier GeneralName choice is always included but 623 others can also be used as long as the first element in the sequence 624 of distribution points is the URI choice and it is an HTTP/HTTPS 625 scheme; the reasons and cRLIssuer fields are never populated. 627 The following subsections provide additional requirements for the 628 different types of EE certificates. 630 RSA-based algorithms are not supported. 632 7.1. Source of Authority Certificate Profile 634 This section specifies the format for SOAs certificates, i.e., 635 certificates issued to those entities that are authorized to create, 636 digitally sign, encrypt, and distribute key packages; these 637 certificates are issued by non-PKI TAs. 639 The Subject Alternative Name extension is always included. The 640 following choices are supported rfc822Name, dnsName, ediPartyName, 641 uniformResourceIdentifier, or ipAddress (both IPv4 and IPv6). This 642 extension is never critical. 644 A critical CMS Content Constraints extension [RFC6010] is included in 645 SOA signature certificates. The content types included depend on the 646 packages the SOA sources (e.g., Encrypted Key Packages, Symmetric Key 647 Packages, Asymmetric Key Packages). 649 7.2. Client Certificate Profile 651 This section specifies the format for certificates issued to clients. 653 A non-critical Subject Directory Attributes extension is always 654 included with the following attributes: 656 o Device Owner [RFC5916] 657 o Clearance Sponsor [RFC5917] 658 o Clearance [RFC5913] 660 The following extensions are also included when needed: 662 o The Authority Information Access extension with only one instance 663 of the accessMethod id-caIssuers and the accessLocation's 664 GeneralName using the uniformResourceIdentifier choice. 666 o A non-critical Subject Alternative Name extension that includes 667 the hardwareModuleName form [RFC4108], rfc822Name, or 668 uniformResourceIdentifier. 670 o A critical Subject Alternative Name extension that includes: 671 dNSName, rfc822Name, ediPartyName, uniformResourceIdentifier, or 672 ipAddress (both IPv4 and IPv6). 674 8. Relying Party Applications 675 This section documents requirements for RPs (Relying Parties) in 676 addition to those listed in [RFC8603], which in turn specifies 677 requirements in addition to those in [RFC5280]. 679 RSA-based algorithms are not supported. 681 RPs support the Authority Key Identifier and the Subject Key 682 Identifier extensions. 684 RPs should support the following extensions: CRL Distribution Points, 685 Authority Information Access, Subject Directory Attribute, Authority 686 Clearance Constraints, and CMS Content Constraints extensions. 688 Within the Subject Directory Attribute extension, RPs should support 689 the Clearance Sponsor, Clearance, and Device Owner attributes. 691 RPs support the id-kp-cmcRA and id-kp-cmcCA EKUs. 693 9. CRL Profile 695 This section documents requirements in addition to those listed in 696 [RFC8603], which in turn specifies requirements in addition to those 697 in [RFC5280], for CRLs. 699 RSA-based algorithms are not supported. 701 Two types of CRLs are produced: complete base CRLs and partitioned 702 base CRLs. 704 crlEntryExtensions are never included and the reasons and cRLIssuer 705 fields are never populated. 707 All CRLs include the following CRL extensions: 709 o The Authority Key Identifier extension: The keyIdentifier is the 710 64 low-order bits of the issuer's subjectPublicKey field. 712 o As per [RFC5280], the CRL Number extension. 714 The only other extension included in partitioned base CRLs is the 715 Issuing Distribution Point extension. The distributionPoint is 716 always identified by the fullName choice; the 717 uniformResourceIdenifier GeneralName choice is always included but 718 others can also be used as long as the first element in the sequence 719 of distribution points is the uniformResourceIdenifier choice and the 720 scheme is an HTTP/HTTPS scheme; all other fields are omitted. 722 10. IANA Considerations 723 None. 725 11. Security Considerations 727 This entire document is about security. This document profiles the 728 use of many protocols and services: EST, CMC, and PKCS#10/#7/#12 as 729 well as X.509 certificates and extensions. These have been referred 730 to throughout this document and those specifications should be 731 consulted for security considerations related to implemented protocol 732 and services. 734 12. References 736 12.1. Normative References 738 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 739 Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 740 10.17487/RFC2046, November 1996, . 743 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 744 Classes and Attribute Types Version 2.0", RFC 2985, DOI 745 10.17487/RFC2985, November 2000, . 748 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 749 Request Syntax Specification Version 1.7", RFC 2986, DOI 750 10.17487/RFC2986, November 2000, . 753 [RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 754 Public Key Infrastructure: Qualified Certificates Profile", 755 RFC 3739, DOI 10.17487/RFC3739, March 2004, 756 . 758 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 759 Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, 760 August 2005, . 762 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 763 over CMS (CMC): Compliance Requirements", RFC 5274, DOI 764 10.17487/RFC5274, June 2008, . 767 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 768 Housley, R., and W. Polk, "Internet X.509 Public Key 769 Infrastructure Certificate and Certificate Revocation List 770 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 771 . 773 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 774 RFC 5652, DOI 10.17487/RFC5652, September 2009, 775 . 777 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 778 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 779 DOI 10.17487/RFC5911, June 2010, . 782 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 783 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 784 DOI 10.17487/RFC5912, June 2010, . 787 [RFC5913] Turner, S. and S. Chokhani, "Clearance Attribute and 788 Authority Clearance Constraints Certificate Extension", 789 RFC 5913, DOI 10.17487/RFC5913, June 2010, 790 . 792 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 793 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 794 . 796 [RFC5916] Turner, S., "Device Owner Attribute", RFC 5916, DOI 797 10.17487/RFC5916, June 2010, . 800 [RFC5917] Turner, S., "Clearance Sponsor Attribute", RFC 5917, DOI 801 10.17487/RFC5917, June 2010, . 804 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 805 10.17487/RFC5958, August 2010, . 808 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 809 Type", RFC 5959, DOI 10.17487/RFC5959, August 2010, 810 . 812 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 813 Message Syntax (CMS) Content Constraints Extension", 814 RFC 6010, DOI 10.17487/RFC6010, September 2010, 815 . 817 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 818 (CMS) Symmetric Key Package Content Type", RFC 6031, DOI 819 10.17487/RFC6031, December 2010, . 822 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 823 (CMS) Encrypted Key Package Content Type", RFC 6032, DOI 824 10.17487/RFC6032, December 2010, . 827 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 828 (CMS) Encrypted Key Package Content Type", RFC 6033, DOI 829 10.17487/RFC6033, December 2010, . 832 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 833 (CMS) Protection of Symmetric Key Package Content Types", 834 RFC 6160, DOI 10.17487/RFC6160, April 2011, 835 . 837 [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic 838 Message Syntax (CMS) Encrypted Key Package Content Type", 839 RFC 6161, DOI 10.17487/RFC6161, April 2011, 840 . 842 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 843 Message Syntax (CMS) Asymmetric Key Package Content Type", 844 RFC 6162, DOI 10.17487/RFC6162, April 2011, 845 . 847 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for 848 the Cryptographic Message Syntax (CMS) and the Public Key 849 Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 850 10.17487/RFC6268, July 2011, . 853 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 854 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 855 . 857 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 858 "Enrollment over Secure Transport", RFC 7030, DOI 859 10.17487/RFC7030, October 2013, . 862 [RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key 863 Package Receipt and Error Content Types", RFC 7191, DOI 864 10.17487/RFC7191, April 2014, . 867 [RFC7192] Turner, S., "Algorithms for Cryptographic Message Syntax 868 (CMS) Key Package Receipt and Error Content Types", 869 RFC 7192, DOI 10.17487/RFC7192, April 2014, 870 . 872 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 873 and M. Scott, "PKCS #12: Personal Information Exchange 874 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 875 . 877 [RFC7894] Pritikin, M. and C. Wallace, "Alternative Challenge 878 Password Attributes for Enrollment over Secure Transport", 879 RFC 7894, DOI 10.17487/RFC7894, June 2016, 880 . 882 [RFC7906] Timmel, P., Housley, R., and S. Turner, "NSA's 883 Cryptographic Message Syntax (CMS) Key Management 884 Attributes", RFC 7906, DOI 10.17487/RFC7906, June 2016, 885 . 887 [RFC8295] Turner, S., "EST (Enrollment over Secure Transport) 888 Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, 889 . 891 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 892 Algorithm (CNSA) Suite Certificate and Certificate 893 Revocation List (CRL) Profile", RFC 8603, DOI 894 10.17487/RFC8603, May 2019, . 897 [XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 898 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 899 Edition)", World Wide Web Consortium Recommendation 900 REC-xml-20081126, November 2008, 901 . 903 [SP 800-59] National Institute of Standards and Technology, 904 "Guideline for Identifying an Information System as a 905 National Security System", SP 800-59, August 2003, 906 . 909 [ID.cnsa-smime-profile] Jenkins, M., "Using CNSA Suite Algorithms in 910 Secure/Multipurpose Internet Mail Extensions(S/MIME)", 911 work-in-progress, . 914 [ID.cnsa-cmc-profile] Jenkins, M. and L. Zieglar, "Commercial 915 National Security Algorithm (CNSA) Suite Profile of 916 Certificate Management over CMS", work-in-progress, 917 . 920 [ID.cnsa-tls-profile] Authors, "Commercial National Security 921 Algorithm (CNSA) Suite Profile of TLS", work-in-progress, 922 . 925 12.2. Informative References 927 None. 929 Authors' Addresses 931 Michael Jenkins 932 National Security Agency 934 EMail: mjjenki@nsa.gov 936 Sean Turner 937 sn3rd 939 EMail: sean@sn3rd.com