idnits 2.17.1 draft-hallambaker-donotissue-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 (October 18, 2010) is 4938 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5395' is mentioned on line 424, but not defined ** Obsolete undefined reference: RFC 5395 (Obsoleted by RFC 6195) == Missing Reference: 'RFCXXXX' is mentioned on line 455, but not defined == Missing Reference: 'NIST-ALGS' is mentioned on line 509, but not defined == Missing Reference: 'RFC5280' is mentioned on line 479, but not defined Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Experimental R. Stradling 5 Expires: April 21, 2011 Comodo CA, Ltd. 6 October 18, 2010 8 DNS Certification Authority Authorization (CAA) Resource Record 9 draft-hallambaker-donotissue-00 11 Abstract 13 The Certification Authority Authorization (CAA) DNS Resource Record 14 allows a DNS domain name holder to specify the certificate signing 15 certificate(s) authorized to issue certificates for that domain. CAA 16 resource records allow a public Certification Authority to implement 17 additional controls to reduce the risk of unintended certificate mis- 18 issue. In additon, the CAA mechanism may be extended in future 19 revisions to allow for use client enforcement of issuing 20 restrictions. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, except to format it 27 for publication as an RFC or to translate it into languages other 28 than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. The CAA RR type . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Certification Authority Processing . . . . . . . . . . . . 4 64 2.2.1. Corresponding Domain Name . . . . . . . . . . . . . . 5 65 2.2.2. Archive . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Application Processing . . . . . . . . . . . . . . . . . . 5 67 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1.1. dauth Property value . . . . . . . . . . . . . . . . . 7 70 3.1.1.1. Object Digest Identifier Calculation . . . . . . . 7 71 3.1.2. pauth Property value . . . . . . . . . . . . . . . . . 8 72 3.1.3. app Property value . . . . . . . . . . . . . . . . . . 8 73 3.2. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 4.1. Mis-Issue by Authorized Certification Authority . . . . . 8 76 4.2. Suppression or spoofing of CAA records . . . . . . . . . . 9 77 4.2.1. Applications . . . . . . . . . . . . . . . . . . . . . 9 78 4.2.2. Certification Authorities . . . . . . . . . . . . . . 9 79 4.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 5.1. Registration of the CAA Resource Record Type . . . . . . . 9 82 5.2. Certification Authority Authorization Properties . . . . . 10 83 5.3. Certification Authority Authorization Application 84 Properties . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 87 6.2. Non Normative References . . . . . . . . . . . . . . . . . 11 88 Appendix A. ASN.1 Values (Non-Normative) . . . . . . . . . . . . 11 89 A.1. Object Identifiers for Certificate Types . . . . . . . . . 11 90 A.2. Object Identifiers for Digest Algorithms . . . . . . . . . 11 91 A.3. DER Data Encoding Prefixes . . . . . . . . . . . . . . . . 12 92 A.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 93 A.3.1.1. SHA2-256 Bit . . . . . . . . . . . . . . . . . . . 13 94 A.3.1.2. SHA2-512 Bit . . . . . . . . . . . . . . . . . . . 13 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 97 1. Definitions 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. Requirements 107 The Certification Authority Authorization (CAA) DNS Resource Record 108 allows a DNS domain name holder to specify the certificate signing 109 certificate(s) authorized to issue certificates for that domain. CAA 110 resource records allow a public Certification Authority (CA) to 111 implement additional controls to reduce the risk of unintended 112 certificate mis-issue. 114 Before issuing a certificate, a PKIX CA is required to validate the 115 request according to the policies set out in its Certificate Policy 116 Statement. In the case of a public CA that validates certificate 117 requests as a third party, the certificate will be typically issued 118 under a public root certificate embedded in one or more relevant 119 reliant applications. 121 Criteria for inclusion of embedded root certificates in applications 122 are outside the scope of this document but typically require the CA 123 to publish a Certificate Practices Statement (CPS) that specifies how 124 the requirements of the Certificate Policy (CP) are achieved and 125 provide an annual audit statement of their performance against their 126 CPS performed by an independent third party auditor. 128 It is the intention of the authors to propose the CAA record defined 129 in this document as the basis for CA validation requirements to be 130 proposed in organizations that publish validation requirements such 131 as the CA-Browser forum. 133 2.1. The CAA RR type 135 A CAA RR consists of a sequence of properties. The following 136 properties are defined: 138 dauth Identifies authorized issuers or end entity certificates by 139 means of an Object Digest Identifier 140 An issuer is identified by means of an Object Digest Identifier 141 that corresponds to a certificate signing certificate under which 142 the issuer is authorized to issue certificates. An end entity 143 certificate is identified by the digest of the certificate itself. 145 pauth Identifies authorized issuers or end entity certificates by 146 means of a PKIX certificate policy OID. 148 A pauth property states that an issuer is authorized to issue 149 certificates for the corresponding domain that contain a policy 150 OID within the specified polic arc, provided that this is 151 consitent with both the CPS of the issuer and the requirements of 152 the specified policy. 154 app Is used to inform clients that they MAY or MUST NOT use 155 information in the CAA record to enforce CA issuing restrictions 156 at the application level. 158 Authorization to act as an issuer for a domain does not entail 159 authorization to issue a certificate in response to a specific 160 request. An authorized issuer MUST comply with the requirements of 161 its Certificate Policy and Certificate Practices Statement regardless 162 of whether a CAA record is specified in a corresponding DNS domain or 163 not. 165 The authorizations specified in the dauth and pauth properties are 166 additive. If multiple authorization properties are specified it is 167 sufficient for a single authorization property to match. If no 168 authorization property grants an issuer authorization, an issuer is 169 not authorized and MUST NOT issue a certificate for that domain. 171 For efficiency, certificates are identified in the dauth property by 172 means of an Object Digest Identifier, a triple consisting of an ASN.1 173 object identifier specifying the type of the referenced object, an 174 ASN.1 object identifier specifying a digest algorithm and the digest 175 value obtained by applying the specified digest algorithm to the 176 referenced object. 178 2.2. Certification Authority Processing 180 Before issue of a certificate a compliant CA MUST check for 181 publication of a relevant CAA Resource Record and if a record is 182 published that the certificate requested is consistent with it. If 183 the certificate requested is not consistent with the CAA RR 184 authorization, the CA MUST NOT issue the certificate. 186 A certificate request is consistent with a relevant CAA Resource 187 Record if and only if a valid certificate chain can be formed that: 189 Includes the certificate to be issued as an end entity 190 certificate. 192 Contains at least one certificate specified as the object digest 193 identifier value in an auth property. 195 Note that while it MUST be possible to form a certificate validation 196 path that contains at least one certificate that is so specified, it 197 MAY also be possible to form valid certificate paths that are not. 199 For example, a CA that has updated its root certificate to extend the 200 expiry date is entitled to issue certificates for domains where the 201 CAA record only specifies the older root certificate provided that 202 the older root certificate has not actually expired and it is thus 203 possible to form a valid certificate path. 205 2.2.1. Corresponding Domain Name 207 A CA MUST observe constraints published in a CAA record corresponding 208 to any domain name specified as a subject name or subjectAltName in 209 the requested certificate. 211 A CA MUST observe constraints published in any CAA record that 212 corresponds to a public DNS domain name issuing point for any domain 213 name superior in the DNS hierarchy to any domain name specified as a 214 subject name or subjectAltName in the requested certificate. 216 For example, if a certificate is for an SSL server for the domain 217 name www.example.com the CA MUST observe the constraints of any CAA 218 record published at www.example.com and observe the constraints of 219 any CAA record published at example.com. 221 2.2.2. Archive 223 A compliant CA SHOULD maintain an archive of the DNS transactions 224 used to verify CAA eligibility. 226 In particular a CA SHOULD ensure that where DNSSEC data is available 227 that the corresponding signature and NSEC/NSEC3 records are preserved 228 so as to enable later compliance audits. 230 2.3. Application Processing 232 While it is in theory possible to apply information contained in a 233 CAA record to enforce certificate issue constraints at the 234 application level, support for such processing is not a design goal 235 for this version of the specification. 237 The information provided in the CAA record MAY be used for 238 application level enforcement of the CA authorization restrictions if 239 the CAA RR property app=true is specified. 241 An application MUST NOT use the information specified in a CAA RR if 242 the app property is not specified or has the value false. Use of app 243 property values other than true or false is not defined. 245 Application level enforcement of CAA restrictions faces the practical 246 difficulty that different clients frequently use different trust 247 chains to verify the same certificate chain. 249 For example, a CA root embedded in 1995 might be replaced by a 'roll- 250 over' certificate for the same subject and public key and a later 251 expiry date in 2000, 2005 and 2010. 253 While tracking such details is a requirement for a well run CA, a 254 certificate subject rarely knows if or when a public CA root their 255 certificate is issued under has been rolled over and has no means of 256 predicting when it might be rolled over in the future. 258 3. Mechanism 260 3.1. Syntax 262 A CAA RR contains a sequence of tag value pairs. Each tag represents 263 a property of the CAA record. The value of a CAA property is that 264 specified in the corresponding value field. 266 A domain name MAY have multiple CAA RRs associated with it and each 267 CAA RR MAY have multiple properties and a given property MAY be 268 specified more than once. 270 This version of the specification makes no distinction as to whether 271 properties are expressed as one record or many, nor are the 272 properties defined sensitive with respect to order. 274 The CAA data field consists of a sequence of at least one property 275 entry. Each property entry consists of a sequence of: 277 Tag Length One octet containing an unsigned integer specifying the 278 tag length in octets. The tag length MUST be 15 octets or less. 280 Tag The property identifier, a sequence of lower case ascii 281 characters 283 Value Length Two octets containing an unsigned integer in network 284 byte order specifying the length of the value field in octets. 286 Value A sequence of octets representing the property value. 287 Property values are encoded as binary values and MAY employ sub- 288 formats. 290 It is suggested that CAA records be represented in DNS configuration 291 files (somehow). 293 Implementations MUST allow CAA records to specify unknown tag values 294 provided that they meet the tag length criteria. In such cases 295 implementations MUST allow tag values to be specified as Base64 296 representations of binary strings and SHOULD allow tag values to be 297 encoded as ASCII strings. 299 Examples... 301 3.1.1. dauth Property value 303 Each dauth property specifies a single Object Digest Identifier 304 value. If dauth properties are to be declared for multiple 305 certificates, a separate dauth property is required for each one. 307 3.1.1.1. Object Digest Identifier Calculation 309 An Object Digest is a binary structure with three components: 311 An ASN.1 Object Identifier specifying the object type of the 312 referenced object 314 An ASN.1 Object Identifier specifying the digest algorithm 316 An ASN.1 DER encoded data field containing the digest value of the 317 referenced object processed using the specified digest algorithm. 319 Examples... 321 The Object Digest Identifier construction is designed to facilitate 322 implementation in applications that already require ASN.1 handling 323 mechanisms (i.e. most cryptographic applications) without causing an 324 undue coding burden in cases where ASN.1 code is not already 325 supported. Appendix A provides all the necessary information to 326 create a fully compliant Object Digest Identifier implementation. 328 3.1.2. pauth Property value 330 Each pauth property specifies a single ASN.1 OID value consisting of 331 the ASN.1 type, length specifier and OID data. 333 The pauth property applies to the specified policy OID and all policy 334 OIDs that fall within the same OID arc. If the OID arc 1.2.3 is 335 specified, then the policy OIDs 1.2.3, 1.2.3.1, 1.2.3.1.2 etc. are 336 all authorized. 338 3.1.3. app Property value 340 Tha app property is a case insensitive ASCII string. Currently 341 defined values are: 343 true Applications MAY use the pauth and dauth properties to enforce 344 issuer authorization restrictions as certificate validity 345 restrictions. 347 false (default) Applications MUST NOT use the data specified in the 348 CAA record to enforce issuer authorization restrictions as 349 certificate validity restrictions. 351 3.2. Use of DNS Security 353 Use of DNSSEC to authenticate CAA RRs is strongly recommended but not 354 required. A CA MUST observe a CAA RR that is returned whether it is 355 signed using DNSSEC or not. 357 Use of DNSSEC allows a CA to acquire and archive a non-repudiable 358 proof that they were authorized to issue certificates for the domain 360 4. Security Considerations 362 4.1. Mis-Issue by Authorized Certification Authority 364 Use of CAA records does not provide protection against mis-issue by 365 an authorized Certification Authority. 367 Domain name holders SHOULD ensure that the CAs they authorize to 368 issue certificates for their domains employ appropriate controls to 369 ensure that certificates are only issued to authorized parties within 370 their organization. 372 Such controls are most appropriately determined by the domain name 373 holder and the authorized CA(s) directly and are thus out of scope of 374 this document. 376 4.2. Suppression or spoofing of CAA records 378 Suppression of the CAA record or insertion of a bogus CAA record 379 could enable an attacker to obtain a certificate from a CA that was 380 not authorized to issue for that domain name. 382 4.2.1. Applications 384 Applications performing CAA checking SHOULD mitigate the risk of 385 suppresion or spoofing of CAA records by means of DNSSEC validation 386 where present. In cases where DNSSEC validation is not available, 387 CAA checking is of limited security value. 389 4.2.2. Certification Authorities 391 Since a certificate issued by a CA can be valid for several years, 392 the consequences of a spoofing or suppression attack are much greater 393 for Certification Authorities and so additional countermeasures are 394 justified. 396 A CA MUST mitigate this risk by employing DNSSEC verification 397 whenever possible and rejecting certificate requests in any case 398 where it is not possible to verify the non-existence or contents of a 399 relevant CAA record. 401 In cases where DNSSEC is not deployed in a corresponding domain, a CA 402 SHOULD attempt to mitigate this risk by employing appropriate DNS 403 security controls. For example all portions of the DNS lookup 404 process SHOULD be performed against the authoritative name server. 405 Cached data MUST NOT be relied on but MAY be used to support 406 additional anti-spoofing or anti-suppression controls. 408 4.3. Denial of Service 410 Introduction of a malformed or malicious CAA RR could in theory 411 enable a Denial of Service attack. 413 This specific threat is not considered to add significantly to the 414 risk of running an insecure DNS service. 416 5. IANA Considerations 418 5.1. Registration of the CAA Resource Record Type 420 IANA has assigned Resource Record Type TBD1 for the CAA Resource 421 Record Type and added the line depicted below to the registry named 422 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 424 [RFC5395] and located at 425 http://www.iana.org/assignments/dns-parameters. 427 < Value and meaning Reference 428 ----------- --------------------------------------------- --------- 429 CAA TBD1 Certification Authority Restriction [RFCXXXX] 431 5.2. Certification Authority Authorization Properties 433 IANA has created the Certification Authority Authorization Properties 434 registry with the following initial values: 436 < 437 Meaning Reference 438 ----------- ----------------------------------------------- --------- 439 dauth Object digest of authorized signing certificate [RFCXXXX] 440 pauth Object Identifier of authorized policy [RFCXXXX] 441 app Application Processing Flag [RFCXXXX] 443 Addition of tag identifiers requires a public specification and 444 expert review. 446 5.3. Certification Authority Authorization Application Properties 448 IANA has created the Certification Authority Authorization 449 Application Properties registry with the following initial values: 451 < 452 Meaning Reference 453 ----------- ----------------------------------------------- --------- 454 true Applications MAY process pauth and dauth data [RFCXXXX] 455 false Applications MUST NOT process CAA records [RFCXXXX] 457 Addition of tag identifiers requires a public specification and 458 expert review. 460 6. References 462 6.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 468 Algorithms and Identifiers for RSA Cryptography for use in 469 the Internet X.509 Public Key Infrastructure Certificate 470 and Certificate Revocation List (CRL) Profile", RFC 4055, 471 June 2005. 473 6.2. Non Normative References 475 [NIST-ALGS] 476 National Institute of Standards and Technology, 477 "Cryptographic Algorithm Registration", March 2009. 479 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 480 Housley, R., and W. Polk, "Internet X.509 Public Key 481 Infrastructure Certificate and Certificate Revocation List 482 (CRL) Profile", RFC 5280, May 2008. 484 Appendix A. ASN.1 Values (Non-Normative) 486 Although the Object Digest Identifier form employs ASN.1 DER encoding 487 only a small subset of ASN.1 features are used and a full ASN.1 stack 488 is not necessary. 490 This appendix provides sufficient information to implement an Object 491 Digest Identifier constructor or parser for the common 493 A.1. Object Identifiers for Certificate Types 495 OIDs have been defined in connection with the X.500 directory for 496 user certificates, certification authority certificates, revocations 497 of certification authority, and revocations of user certificates. 498 The following table lists the OIDs, their BER encoding, and their 499 type identifier and length-prefixed hex format for use in Object 500 Digest Identifiers. 502 == 06 03 55 04 24 504 == 06 03 55 04 25 506 A.2. Object Identifiers for Digest Algorithms 508 OIDS have been assigned by NIST for the SHA2 digest algorithms 509 [NIST-ALGS] [RFC4055] Use of the SHA1 digest algorithm is not 510 recommended due to concerns for the security of the algorithm. 512 The OID arc in each case is hashAlgs OBJECT IDENTIFIER ::= {joint- 513 iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) 514 nistAlgorithm(4) hashAlgs (2)} 516 == 06 09 60 86 48 01 65 03 04 02 01 518 == 06 09 60 86 48 01 65 03 04 02 02 520 == 06 09 60 86 48 01 65 03 04 02 03 522 == 06 09 60 86 48 01 65 03 04 02 04 524 A.3. DER Data Encoding Prefixes 526 The rules of ASN.1 encoding state that every data value is preceded 527 by a data type identifier and a length identifier. In the case of an 528 Object Digest Identifier the data type identifier is always OCTET 529 STRING (04) and the length for all currently defined digest 530 algorithms will be less than 128 bytes (1024 bits) and thus use the 531 single byte encoding form in which bit 7 is set to 0 and the lower 7 532 bits specify the length. 534 The length prefixes for commonly used digest lengths in hexadecimal 535 notation are thus: 537 160 bits 04 14 539 224 bits 04 1C 541 256 bits 04 20 543 384 bits 04 30 545 512 bits 04 40 547 A.3.1. Examples 549 The following examples demonstrate the formation of Object Digest 550 Identifiers for the string 'test' using the ASN.1 OID value id-at- 551 description = { joint-iso-ccitt(2) ds(5) at(4) 13 } 553 A.3.1.1. SHA2-256 Bit 555 The SHA2-256 digest value is 9F 86... 08 557 The OID data in hexadecimal notation is: 559 06 03 55 04 0D 561 06 09 60 86 48 01 65 03 04 02 01 563 04 20 9F 86 D0 81 88 4C 7D 65 9A 2F EA A0 C5 5A D0 15 A3 BF 4F 1B 564 2B 0B 82 2C D1 5D 6C 15 B0 F0 0A 08 566 The Base64 encoded digest value is: 568 BgNVBA0GCWCGSAFlAwQCAQMgn4bQgYhMfWWaL+qgxVrQFaO 569 /TxsrC4Is0V1sFbDwCgg= 571 A.3.1.2. SHA2-512 Bit 573 The SHA2-256 digest value is EE 26 ... FF 575 The OID data in hexadecimal notation is: 577 06 03 55 04 0D 579 06 09 60 86 48 01 65 03 04 02 03 581 04 40 EE 26 B0 DD 4A F7 E7 49 AA 1A 8E E3 C1 0A E9 92 3F 61 89 80 582 77 2E 47 3F 88 19 A5 D4 94 0E 0D B2 7A C1 85 F8 A0 E1 D5 F8 4F 88 583 BC 88 7F D6 7B 14 37 32 C3 04 CC 5F A9 AD 8E 6F 57 F5 00 28 A8 FF 585 The Base64 encoded digest value is: 587 BgNVBA0GCWCGSAFlAwQCAwNA7iaw3Ur350mqGo7jwQrpkj9 588 hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBM 589 xfqa2Ob1f1ACio/w== 591 Authors' Addresses 593 Phillip Hallam-Baker 594 Comodo Group Inc. 596 Email: philliph@comodo.com 597 Rob Stradling 598 Comodo CA, Ltd. 600 Email: rob.stradling@comodo.com