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