idnits 2.17.1 draft-solinas-suiteb-cert-profile-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (July 1, 2009) is 5405 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Solinas 3 Intended Status: Informational L. Zieglar 4 NSA 5 Expires January 1, 2009 July 1, 2009 7 Suite B Certificate and Certificate 8 Revocation List (CRL) Profile 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your 42 rights and restrictions with respect to this document. 44 Abstract 46 This document specifies a base profile for X.509 v3 Certificates and 47 X.509 v2 Certificate Revocation Lists (CRLs) for use with the United 48 States National Security Agency's Suite B Cryptography. The reader 49 is assumed to have familiarity with RFC 5280, "Internet X.509 Public 50 Key Infrastructure Certificate and Certificate Revocation List 51 (CRL) Profile." 53 Table of Contents 55 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Terminology. . . . . . . . . . . . . . . . . . . 2 57 3. Requirements and Assumptions. . . . . . . . . . . . . . . . . 3 58 3.1. Implementing Suite B. . . . . . . . . . . . . . . . . . . 3 59 3.2. Suite B Object Identifiers. . . . . . . . . . . . . . . . 4 60 4. Suite B Certificates and Certificate Extensions Profile . . . 4 61 4.1. signatureAlgorithm. . . . . . . . . . . . . . . . . . . . 4 62 4.2. signatureValue. . . . . . . . . . . . . . . . . . . . . . 4 63 4.3. Version . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.4. SubjectPublicKeyInfo. . . . . . . . . . . . . . . . . . . 5 65 4.5. Certificate Extensions for Particular Types of 66 Certificates. . . . . . . . . . . . . . . . . . . . . . . 7 67 4.5.1. Suite B Self-Signed CA Certificates . . . . . . . . 7 68 4.5.2 Suite B Non-Self-Signed CA Certificates . . . . . . 7 69 4.5.3. Suite B End Entity Signature and Key Establishment. 70 Certificates. . . . . . . . . . . . . . . . . . . . 8 71 5. Suite B CRL and CRL Extensions Profile. . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.2 Informative. . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 This document specifies a base profile for X.509 v3 Certificates and 81 X.509 v2 Certificate Revocation Lists (CRLs) for use by applications 82 that support the United States National Security Agency's Suite B 83 Cryptography. 85 The reader is assumed to have familiarity with [RFC5280]. This 86 Suite B Certificate and CRL Profile is a profile of RFC 5280. 87 All MUST-level requirements of RFC 5280 apply throughout this 88 profile and are generally not repeated here. In cases where a 89 MUST-level requirement is repeated for emphasis, the text notes 90 the requirement is "in adherence with [RFC5280]." This profile 91 contains changes that elevate some MAY-level options in RFC 5280 to 92 SHOULD-level and MUST-level in this profile; this profile also 93 contains changes that elevate some SHOULD-level options in RFC 5280 94 to MUST-level for this profile. All options from RFC 5280 that are 95 not listed in this profile remain at the requirements level of 96 RFC 5280. 98 The reader is also assumed to have familiarity with [RFC5480], 99 which specifies the syntax and semantics for the Subject Public 100 Key Information field in certificates that support Elliptic Curve 101 Cryptography and [sha2-dsa-ecdsa] which specifies algorithm 102 identifiers for ECDSA. 104 2. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 108 this document are to be interpreted as described in [RFC2119]. 110 3. Requirements and Assumptions 112 The goal of this document is to define a base set of certificate and 113 CRL formats to support interoperability among Suite B solutions. 114 Specific communities, such as the US National Security Systems, may 115 define community profiles which further restrict certificate and CRL 116 formats by mandating the presence of extensions which are optional in 117 this base profile, defining new optional or critical extension types, 118 or restricting the values and/or presence of fields within existing 119 extensions. However, communications between distinct communities 120 MUST use the formats specified in this document when interoperability 121 is desired. (Applications may add additional non-critical extensions 122 to these formats but they MUST NOT assume that a remote peer will be 123 able to process them.) 125 3.1 Implementing Suite B 127 Every Suite B certificate MUST use the X.509 v3 format, and contain 128 either: 130 * An ECDSA capable signing key, using curve P-256 or P-384; or 131 * An ECDH capable key establishment key, using curve P-256 or 132 P-384. 134 Every Suite B certificate and CRL MUST be signed using ECDSA. The 135 signing Certification Authority's (CA's) key MUST be on the curve 136 P-256 or P-384 if the certificate contains a key on the curve P-256. 137 If the certificate contains a key on the curve P-384, the signing 138 CA's key MUST be on the curve P-384. Any certificate and CRL MUST be 139 hashed using SHA-256 or SHA-384, matched to the size of the signing 140 CA's key. 142 3.2 Suite B Object Identifiers 144 The primary OID structure for Suite B is as follows per [x9.62], 145 [SEC2], [RFC5480] and [sha2-dsa-ecdsa]. 147 ansi-X9-62 OBJECT IDENTIFIER ::= { 148 iso(1) member-body(2) us(840) 10045 } 150 certicom-arc OBJECT IDENTIFIER ::= { 151 iso(1) identified-organization(3) certicom(132) } 153 id-ecPublicKey OBJECT IDENTIFIER ::= { 154 ansi-X9-62 keyType(2) 1 } 156 id-ecDh OBJECT IDENTIFIER ::= { 157 certicom-arc schemes(1) ecdh(12) } 159 secp256r1 OBJECT IDENTIFIER ::= { 160 ansi-X9-62 curves(3) prime(1) 7 } 162 secp384r1 OBJECT IDENTIFIER ::= { 163 certicom-arc curve(0) 34 } 165 id-ecSigType OBJECT IDENTIFER ::= { 166 ansi X9-62 signatures(4) } 168 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 169 id-ecSigType ecdsa-with-SHA2(3) 2 } 171 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 172 id-ecSigType ecdsa-with-SHA2(3) 3 } 174 4. Suite B Certificate and Certificate Extensions Profile 176 This Suite B certificate profile is a profile of [RFC5280]. 177 The changes in the requirements from RFC 5280 are listed here. 178 Note that RFC 5280 has varying mandates for marking extensions as 179 critical or non-critical. This profile changes some of those 180 mandates for extensions that are included in Suite B certificates. 182 4.1. signatureAlgorithm 184 The two algorithm identifiers used by Suite B are: 185 1.2.840.10045.4.3.2 for ecdsa-with-SHA256 and 186 1.2.840.10045.4.3.3 for ecdsa-with-SHA384, as described in 187 [sha2-dsa-ecdsa] AND [x9.62]. 189 The parameters MUST be absent as per [sha2-dsa-ecdsa]. 191 4.2. signatureValue 193 ECDSA digital signature generation is described in [FIPS 186-3]. An 194 ECDSA signature value is comprised of two unsigned integers, denoted 195 as r and s. r and s MUST be represented as ASN.1 INTEGERs. If the 196 high order bit of the unsigned integer is a 1, an octet with the 197 value 0x00 MUST be prepended to the binary representation before 198 enconding it as an ASN.1 INTEGER. Unsigned integers for the P-256 199 and P-384 curves can be a maximum of 32 and 48 bytes, respectively. 200 Therefore, converting each r and s to an ASN.1 INTEGER will result in 201 a maximum of 33 bytes for the P-256 curve and 49 bytes for the P-384 202 curve. 204 The ECDSA signatureValue in an X.509 certificate is encoded as a BIT 205 STRING value of a DER encoded SEQUENCE of the two INTEGERS. As per 206 [RFC5480], the structure, included for convenience, is as follows: 208 ECDSA-Sig-Value ::= SEQUENCE { 209 r INTEGER, 210 s INTEGER 211 } 213 For example, in a signature using P-256 and hex notation: 215 r= 52e3f7b7 27fba9e8 eddb1d08 3b75c188 216 2517e6dc 63ded9c0 524f8f9a 45dc8661 218 s= b8930438 de8d33bd ab12c3a2 bdad9795 219 92a1fd65 76d1734c 3eb0af34 0456aef4 221 r represented as a DER encoded INTEGER: 222 022052e3 f7b727fb a9e8eddb 1d083b75 223 c1882517 e6dc63de d9c0524f 8f9a45dc 224 8661 226 s represented as a DER encoded INTEGER: 227 022100b8 930438de 8d33bdab 12c3a2bd 228 ad979592 a1fd6576 d1734c3e b0af3404 229 56aef4 231 Representation of SEQUENCE of r and s: 232 30450220 52e3f7b7 27fba9e8 eddb1d08 233 3b75c188 2517e6dc 63ded9c0 524f8f9a 234 45dc8661 022100b8 930438de 8d33bdab 235 12c3a2bd ad979592 a1fd6576 d1734c3e 236 b0af3404 56aef4 238 Representation of resulting signatureValue: 239 03480030 45022052 e3f7b727 fba9e8ed 240 db1d083b 75c18825 17e6dc63 ded9c052 241 4f8f9a45 dc866102 2100b893 0438de8d 242 33bdab12 c3a2bdad 979592a1 fd6576d1 243 734c3eb0 af340456 aef4 245 4.3. Version 247 For this profile, Version MUST be 3, which means the value MUST be 248 set to 2. 250 4.4. SubjectPublicKeyInfo 252 For ECDSA signing keys, the algorithm ID, id-ecPublicKey, MUST be 253 used. For ECDH key establishment keys, either the algorithm ID, 254 id-ecPublicKey, or the algorithm ID, id-ecDh, MAY be used, as 255 described in [RFC5480]. However, for interoperability 256 purposes all relying parties MUST be prepared to process the 257 algorithm ID id-ecPublicKey. 259 The parameters of the AlgorithmIdentifier in this field MUST use 260 the namedCurve option. The specifiedCurve and implicitCurve options 261 described in [RFC5480] MUST NOT be used. The namedCurve 262 MUST be either the OID for secp256r1 (curve P-256) or secp384r1 263 (curve P-384) [RFC5480]. 265 The elliptic curve public key, ECPoint, SHALL be the OCTET STRING 266 representation of an elliptic curve point following the conversion 267 routine in section 2.2 of [RFC5480] and sections 2.3.1 and 2.3.2 268 of [SEC1]. 270 Suite B implementations MAY use either the uncompressed form or the 271 compressed form of the elliptic curve point [RFC5480]. For 272 interoperability purposes, all relying parties MUST be prepared to 273 process the uncompressed form. 275 The elliptic curve public key (an ECPoint which is an OCTET STRING) 276 is mapped to a subjectPublicKey (a BIT STRING) as follows: the most 277 significant bit of the OCTET STRING becomes the most significant bit 278 of the BIT STRING and the least significant bit of the OCTET STRING 279 becomes the least significant bit of the BIT STRING [RFC5480]. 281 An octet string representation of a P-256 uncompressed elliptic curve 282 point: 284 046cc93a 2cdb0308 47fa0734 2bc8e130 285 4c77f04f 63557372 43f3a5d7 f51baa82 286 23d21ebf b87d9944 f7ec170d 64f9924e 287 9ce20e4d 361c2db5 f1d52257 4259edad 288 5e 290 A DER encoded bit string representation of the subject public key: 292 03420004 6cc93a2c db030847 fa07342b 293 c8e1304c 77f04f63 55737243 f3a5d7f5 294 1baa8223 d21ebfb8 7d9944f7 ec170d64 295 f9924e9c e20e4d36 1c2db5f1 d5225742 296 59edad5e 298 A DER encoded representation of the AlgorithmIdentifier: 300 30130607 2a8648ce 3d020106 082a8648 301 ce3d0301 07 303 A DER encoded representation of the subjectPublicKeyInfo using the 304 P-256 curve: 306 30593013 06072a86 48ce3d02 0106082a 307 8648ce3d 03010703 4200046c c93a2cdb 308 030847fa 07342bc8 e1304c77 f04f6355 309 737243f3 a5d7f51b aa8223d2 1ebfb87d 310 9944f7ec 170d64f9 924e9ce2 0e4d361c 311 2db5f1d5 22574259 edad5e 313 4.5. Certificate Extensions for Particular Types of Certificates 315 Different types of certificates in this profile have different 316 required and recommended extensions. Those are listed in this 317 section. Those extensions from RFC 5280 not explicitly listed 318 in this profile remain at the requirement levels of RFC 5280. 320 4.5.1. Suite B Self-Signed CA Certificates 322 In adherence with [RFC5280], self-signed CA certificates in this 323 profile MUST contain the subjectKeyIdentifier, keyUsage, and 324 basicConstraints extensions. 326 The keyUsage extension MUST be marked as critical. The keyCertSign 327 and cRLSign bits MUST be set. The digitalSignature and 328 nonRepudiation bits MAY be set. All other bits MUST NOT be set. 330 In adherence with [RFC5280], the basicConstraints extension MUST be 331 marked as critical. The cA boolean MUST be set to indicate that the 332 subject is a CA and the pathLenConstraint MUST NOT be present. 334 4.5.2. Suite B Non-Self-Signed CA Certificates 336 Non-self-signed CA Certificates in this profile MUST contain the 337 authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, 338 basicConstraints and certificatePolicies extensions. 340 The keyUsage extension MUST be marked as critical. The keyCertSign 341 and CRLSign bits MUST be set. The digitalSignature and 342 nonRepudiation bits MAY be set. All other bits MUST NOT be set. 344 In adherence with [RFC5280], the basicConstraints extension MUST be 345 marked as critical. The cA boolean MUST be set to indicate that the 346 subject is a CA and the pathLenConstraint subfield is OPTIONAL. 348 If a policy is asserted, the certificatePolicies extension MUST be 349 marked as non-critical, MUST contain the OIDs for the applicable 350 certificate policies and SHOULD NOT use the policyQualifiers option. 351 If a policy is not asserted, the certificatePolicies extension MUST 352 be omitted. 354 Relying party applications conforming to this profile MUST be 355 prepared to process the policyMappings, policyConstraints and 356 inhibitAnyPolicy extensions, regardless of criticality, following 357 the guidance in [RFC5280] when they appear in non-self-signed CA 358 certificates. 360 4.5.3. Suite B End Entity Signature and Key Establishment Certificates 362 In adherence with [RFC5280], end entity certificates in this profile 363 MUST contain the authorityKeyIdentifier, keyUsage and 364 certificatePolicies extensions. End entity certificates SHOULD 365 contain the subjectKeyIdentifier extension. 367 The keyUsage extension MUST be marked as critical. 369 For end entity digital signature certificates, the keyUsage extension 370 MUST be set for digitalSignature. The nonRepudiation bit MAY be set. 371 All other bits in the keyUsage extension MUST NOT be set. 373 For end entity key establishment certificates, the keyUsage extension 374 MUST BE set for keyAgreement. The encipherOnly or decipherOnly bit 375 MAY be set. All other bits in the keyUsage extension MUST NOT be 376 set. 378 If a policy is asserted, the certificatePolicies extension MUST be 379 marked as non-critical, MUST contain the OIDs for the applicable 380 certificate policies and SHOULD NOT use the policyQualifiers option. 381 If a policy is not asserted, the certificatePolicies extension MUST 382 be omitted. 384 5. Suite B CRL and CRL Extensions Profile 386 This Suite B CRL profile is a profile of [RFC5280]. There are 387 changes in the requirements from [RFC5280] for the signatures on 388 CRLs of this profile. 390 The signatures on CRLs in this profile MUST follow the same rules 391 from this profile that apply to signatures in the certificates, see 392 section 4. 394 6. Security Considerations 396 The security considerations in [RFC5280], [RFC5480], 397 and [sha2-dsa-ecdsa] apply. 399 A single key pair SHOULD NOT be used for both signature and key 400 establishment per [SP-800-57]. 402 The Suite B algorithms provide significantly improved performance 403 when compared to equivalent-strength cryptography that does not 404 employ elliptic curve cryptography. Where performance has previously 405 been an impediment, use of Suite B may permit employment of PKI-based 406 cryptographic security mechanisms. 408 7. IANA Considerations 410 This document makes extensive use of object identifiers to register 411 public key types, elliptic curves, and algorithms. Most of them are 412 registered in the ANSI X9.62 arc with the exception of some of the 413 curves, which are in the Certicom, Inc. arc (these curves have been 414 adopted by ANSI and NIST). Extensions in certificates and CRLs are 415 identified using the object identifiers defined in an arc delegated 416 by IANA to the PKIX working group. No further action by IANA is 417 necessary for this document or any anticipated updates. 419 8. References 421 8.1 Normative 423 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 424 Requirement Levels", BCP 14, March 1997. 426 [RFC5280] Cooper, D., Santesson, S. Farrell., S., Boeyen, S., 427 Housley, R., Polk, W., "Internet X.509 Public Key Infrastructure 428 Certificate and Certificate Revocation List (CRL) Profile", 429 May 2008. 431 8.2 Informative 433 [FIPS 186-3] "Digital Signature Standard (DSS)", June 2009. 435 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., Polk, T., 436 "Elliptic Curve Cryptography Subject Public Key Information", 437 March 2009. 439 [SEC1] Standards for Efficient Cryptography, "SEC1: Elliptic 440 Curve Cryptography", September 2000. 442 [SEC2] Standards for Efficient Cryptography, "SEC 2: Recommended 443 Elliptic Curve Domain Parameters", September 2000. 445 [sha2-dsa-ecdsa] Dang, Q., Moriarty, K., Brown, D., Polk, T., 446 "Internet X.509 Public Key Infrastructure: Additional Algorithms 447 and Identifiers for DSA and ECDSA", 448 draft-ietf-pkix-sha2-dsa-ecdsa-06.txt., work-in-progress, March 449 2009. 451 [SP-800-57] Barker, E., Barker, W., Burr, W., Polk, W. Smid, M., 452 "NIST SP-800-57:Recommendation for Key Management-Part 1: 453 General", March 2007. 455 [X9.62] ANS X9.62, "Public Key Cryptography for the Financial 456 Services Industry; The Elliptic Curve Digital Signature 457 Algorithm (ECDSA)", December 2005. 459 [X9.63] ANS X9.63, "Public Key Cryptography for the Financial 460 Services Industry; Key Agreement and Key Transport Using Elliptic 461 Curve Cryptography", December 2001. 463 Author's Address 465 Solinas, J. 466 National Information Assurance Research Laboratory 467 National Security Agency 468 Email: jasolin@orion.ncsc.mil 470 Zieglar, L. 471 National Information Assurance Research Laboratory 472 National Security Agency 473 Email: llziegl@tycho.ncsc.mil