idnits 2.17.1 draft-hallambaker-donotissue-01.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 == Line 872 has weird spacing: '...2 01 eb a0 03...' == Line 893 has weird spacing: '...a 69 ae c9 65...' -- The document date (December 2, 2010) is 4893 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC4648' is mentioned on line 775, but not defined == Missing Reference: 'RFC3642' is mentioned on line 772, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 714, but not defined == Missing Reference: 'NIST-ALGS' is mentioned on line 965, but not defined ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) Summary: 1 error (**), 0 flaws (~~), 7 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: June 5, 2011 Comodo CA Ltd. 6 B. Laurie 7 Google Inc. 8 December 2, 2010 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-hallambaker-donotissue-01 13 Abstract 15 The Certification Authority Authorization (CAA) DNS Resource Record 16 allows a DNS domain name holder to specify the certificate signing 17 certificate(s) authorized to issue certificates for that domain. CAA 18 resource records allow a public Certification Authority to implement 19 additional controls to reduce the risk of unintended certificate mis- 20 issue. 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 June 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. The CAA RR type . . . . . . . . . . . . . . . . . . . . . 6 64 2.1.1. Examples of Use. . . . . . . . . . . . . . . . . . . . 7 65 2.2. Certification Authority Processing . . . . . . . . . . . . 9 66 2.2.1. Canonical Domain Name . . . . . . . . . . . . . . . . 10 67 2.2.2. Use of DNS Security . . . . . . . . . . . . . . . . . 10 68 2.2.3. Archive . . . . . . . . . . . . . . . . . . . . . . . 10 69 2.3. Relying Party Application Processing . . . . . . . . . . . 10 70 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.1.1. Suggested Presentation Format . . . . . . . . . . . . 12 73 3.1.1.1. Policy OID Encoding Options . . . . . . . . . . . 13 74 3.1.2. policy Property value . . . . . . . . . . . . . . . . 13 75 3.1.3. path Property value . . . . . . . . . . . . . . . . . 14 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 4.1. Mis-Issue by Authorized Certification Authority . . . . . 15 78 4.2. Suppression or spoofing of CAA records . . . . . . . . . . 15 79 4.2.1. Applications . . . . . . . . . . . . . . . . . . . . . 15 80 4.2.2. Certification Authorities . . . . . . . . . . . . . . 15 81 4.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 16 82 4.4. Anticompetitive Use of the Critical Flag . . . . . . . . . 16 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 5.1. Registration of the CAA Resource Record Type . . . . . . . 16 85 5.2. Certification Authority Authorization Properties . . . . . 16 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 88 6.2. Non Normative References . . . . . . . . . . . . . . . . . 18 89 Appendix A. Object Digest Identifier Calculation . . . . . . . . 18 90 A.1. Example: CA Certificate A . . . . . . . . . . . . . . . . 19 91 A.2. Example: CA Certificate A . . . . . . . . . . . . . . . . 19 92 Appendix B. Example Certificates . . . . . . . . . . . . . . . . 19 93 B.1. CA Certificate A . . . . . . . . . . . . . . . . . . . . . 19 94 Appendix C. ASN.1 Values (Non-Normative) . . . . . . . . . . . . 21 95 C.1. DER Sequence Encoding . . . . . . . . . . . . . . . . . . 21 96 C.2. Object Identifiers for Certificate Types . . . . . . . . . 22 97 C.3. Object Identifiers for Digest Algorithms . . . . . . . . . 22 98 C.4. DER Data Encoding Prefixes . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Definitions 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 1.2. Defined Terms 111 The following terms are used in this document: 113 Abstract Syntax Notation One (ASN.1) A notation for describing 114 abstract types and values, as specified in X.680 [X.680]. 116 Authorization Entry An authorization assertion that grants or denies 117 a specific set of permissions to a specific group of entities. 119 Canonical Domain Name A Domain Name that is not an alias. 121 Canonical Domain Name Value The value of a Canonical Domain Name. 122 The value resulting from applying alias transformations to a 123 Domain Name that is not canonical. 125 Certificate An X.509 Certificate, as specified in RFC 5280 126 [RFC5280]. 128 Certification Policy (CP) Specifies the criteria that a 129 Certification Authority undertakes to meet in its issue of 130 certificates. 132 Certification Practices Statement (CPS) Specifies the means by which 133 the criteria of the Certification Policy are met. In most cases 134 this will be the document against which the operations of the 135 Certification Authority are audited. 137 Certification Authority (CA) An entity that issues Certificates in 138 accordance with a specified Certification Policy. 140 Distinguished Encoding Rules (DER) A set of rules for encoding ASN.1 141 objects, as specified in X.690 [X.690]. 143 Domain The set of resources associated with a DNS Domain Name. 145 Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and 146 revisions. 148 Domain Name System (DNS) The Internet naming system specified in RFC 149 1035 [RFC1035] and revisions. 151 DNS Security (DNSSEC) Extensions to the DNS that provide 152 authentication services as specified in RFC 4033 [RFC4033] and 153 revisions. 155 Extended Issuer Authorization Set The most specific Issuer 156 Authorization Set that is active for a domain. This is either the 157 Issuer Authorization Set for the domain itself, or if that is 158 empty, the Issuer Authorization Set for the corresponding Public 159 Delegation Point. 161 Issuer Authorization Set The set of Authorization Entries for a 162 domain name that are flagged for use by Issuers. Analogous to an 163 Access Control List but with no ordering specified. 165 Public Delegation Point A Domain Name that is obtained from a public 166 DNS registry as defined by a Certification Policy. 168 Public Key Infrastructure X.509 (PKIX) Standards and specifications 169 issued by the IETF that apply the X.509 [X.509] certificate 170 standards specified by the ITU to Internet applications as 171 specified in RFC 5280 [RFC5280] and related documents. 173 Resource Record (RR) A set of attributes bound to a Domain Name. 175 Relying Party A party that makes use of an application whose 176 operation depends on use of a Certificate for making a security 177 decision. 179 Relying Application An application whose operation depends on use of 180 a Certificate for making a security decision. 182 Relying Party Authorization Set The set of Authorization Entries for 183 a domain name that are flagged for use by Relying Party 184 Applications. Analogous to an Access Control List but with no 185 ordering specified. 187 2. Introduction 189 The Certification Authority Authorization (CAA) DNS Resource Record 190 allows a DNS domain name holder to specify the Certification 191 Authorities authorized to issue certificates for that domain. 192 Publication of CAA resource records allow a public Certification 193 Authority (CA) to implement additional controls to reduce the risk of 194 unintended certificate mis-issue. 196 Conformance with a published CAA record is a necessary but not 197 sufficient condition for issue of a certificate. Before issuing a 198 certificate, a PKIX CA is required to validate the request according 199 to the policies set out in its Certificate Policy Statement. In the 200 case of a public CA that validates certificate requests as a third 201 party, the certificate will be typically issued under a public root 202 certificate embedded in one or more relevant reliant applications. 204 Criteria for inclusion of embedded root certificates in applications 205 are outside the scope of this document but typically require the CA 206 to publish a Certificate Practices Statement (CPS) that specifies how 207 the requirements of the Certificate Policy (CP) are achieved and 208 provide an annual audit statement of their performance against their 209 CPS performed by an independent third party auditor. 211 It is the intention of the authors to propose the CAA record defined 212 in this document as the basis for CA validation requirements to be 213 proposed in organizations that publish validation requirements. 215 CAA records only describe the current state of Certification 216 Authority certificate issue authority. Since a certificate is 217 typically valid for at least a year, it is possible that a 218 certificate that is not conformant with the CAA records currently 219 published was conformant with the CAA records published at the time 220 that it was issued. Thus Relying Applications MUST NOT use failure 221 to conform to currently published CAA records as a rejection criteria 222 for certificates unless the published records are flagged as being 223 intended for that use. 225 2.1. The CAA RR type 227 A CAA RR consists of a sequence of property entries. Each property 228 entry MAY be tagged with one or more of the following flag values: 230 Critical If set, indicates that the corresponding property entry tag 231 MUST be understood if the semantics of the CAA record are to be 232 correctly understood by the specified audience. 234 Issuers MUST NOT issue certificates for a domain if the Extended 235 Issuer Authorization Set contains unknown property entry tags that 236 are flagged as critical. 238 Relying Parties MUST NOT attempt to enforce CAA records if the 239 Relying Party Authorization Set contains unknown property entry 240 tags that are flagged as critical 242 Must be Zero This bit is reserved for future use. 244 Issuers MUST NOT issue certificates for a domain if the Extended 245 Issuer Authorization Set contains property entries with the Must 246 Be Zero Tag Set. 248 Relying Parties MUST NOT attempt to enforce CAA records if the 249 Relying Party Authorization Set contains property entries with the 250 Must Be Zero Tag Set. 252 Relying Party Specifies that the corresponding Property Entry is to 253 be used by Relying Party Applications and forms part of the 254 Relying Party Authorization Set for the domain. 256 Issuer Specifies that the corresponding Property Entry is to be used 257 by Issuers and forms part of the Issuer Authorization Set for the 258 domain. 260 The following properties are defined: 262 policy The policy property entry declares 263 an authorization entry granting authorization to issue under the 264 specified Certificate Policy. 266 path The path property entry declares an 267 authorization entry granting authorization to issue end entity 268 certificates under a trust path that includes the specified 269 signing credential. 271 An Object Digest Identifier (ODI) is a means of specifying a 272 reference to an object instance by means of a cryptographic digest 273 function. A CAA path property may use an ODI to specify a 274 certificate trust path by means of: 276 A Certificate Signing Certificate 278 A Public Signing Key 280 In either case a path Authorization Entry authorizes an issuer to 281 issue an End Entity certificate to the corresponding domain if and 282 only if it is possible to form a valid certificate path to it from 283 the referenced certificate or key. 285 2.1.1. Examples of Use. 287 For convenience the examples are presented in the text format 288 suggested in section Section 3.1.1 289 The following example informs CAs that certificates must not be 290 issued except under the Default Deny Security 'Example 1' Certificate 291 Policy (1.3.6.1.4.1.35405.666.1). Since the policy is published at 292 the Public Delegation Point, the policy applies to all subordinate 293 domains under example.com. 295 $ORIGIN example.com 296 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 298 The following example informs CAs that certificates must not be 299 issued except under the Certificate Authority Root certificate 300 specified in Appendix B. 302 $ORIGIN example.com 303 . CAA 1 path MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe 304 XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA== 306 A domain MAY authorize multiple CAs to issue certificates at the same 307 time. The following example allows issue under the Default Deny 308 Security certification policy 'Example 1' or 'Example 2': 310 $ORIGIN example.com 311 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 312 . CAA 1 policy 1.3.6.1.4.1.35405.666.2 314 If Authorization Entries using the path and policy properties are 315 present at a given Domain, compatibility with either is sufficient to 316 authorize the request. 318 Future versions of this specification MAY use the critical flag to 319 introduce new semantics that MUST be understood for correct 320 processing of the record, preventing Certification Authorities that 321 do not recognize the record from issuing certificates. 323 In the following example, the property 'tbs' is flagged as critical. 324 The Default Deny Security CA is not authorized to issue under either 325 policy unless the processing rules for the 'tbs' property tag are 326 understood. 328 $ORIGIN example.com 329 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 330 . CAA 1 policy 1.3.6.1.4.1.35405.666.2 331 . CAA 9 tbs MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe 332 XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA== 334 Enforcement by Relying Party Applications follows the same general 335 principles. A Relying Party Application MUST NOT enforce CAA records 336 unless at least one Property Entry has the Relying Party flag set, 337 that is the Relyin Party Authorization Set is not empty. 339 In the following example, certificates must not be issued except 340 under the Default Deny Security 'Example 1' Certificate Policy and 341 Relying Party Applications MAY reject certificates presented that do 342 not comply with this requirement: 344 $ORIGIN example.com 345 . CAA 3 policy 1.3.6.1.4.1.35405.666.1 347 In the ordinary course of business a Domain administrator may 348 withdraw authorization for issue of new certificates before the 349 previously issued certificates expire. 351 In the following example, Relying Party Applications are informed 352 that certificates issued under either the policy are to be considered 353 to be authorized but new certificates can only be issued under the 354 first. 356 $ORIGIN example.com 357 . CAA 3 policy 1.3.6.1.4.1.35405.666.1 358 . CAA 2 policy 1.3.6.1.4.1.35405.666.2 360 2.2. Certification Authority Processing 362 Before issue of a certificate a compliant CA MUST check for 363 publication of a relevant CAA Resource Record(s) and if such 364 record(s) are published, that the certificate requested is consistent 365 with them. If the certificate requested is not consistent with the 366 relevant CAA RRs, the CA MUST NOT issue the certificate. 368 The Issuer Authorization Set for a domain name consists of the set of 369 all CAA Authorization Entries declared for the canonical form of the 370 specified domain. 372 The Extended Issuer Authorization Set for a domain name consists of 373 the Issuer Authorization Set for that domain name if it is non-empty. 374 Otherwise the Extended Issuer Authorization Set for a domain name 375 consists of the Issuer Authorization Set for the corresponding Public 376 Delegation Point for that domain name. 378 If the Extended Issuer Authorization Set for a domain name is not 379 empty, a Certification Authority MUST NOT issue a certificate unless 380 it conforms to at least one authorization entry in the Extended 381 Issuer Authorization Set. 383 Note that while it MUST be possible to form a certificate validation 384 path that contains at least one certificate that is so specified, it 385 MAY also be possible to form valid certificate paths that are not. 387 For example, a CA that has updated its root certificate to extend the 388 expiry date is entitled to issue certificates for domains where the 389 CAA record only specifies the older root certificate provided that 390 the older root certificate has not actually expired and it is thus 391 possible to form a valid certificate path. 393 2.2.1. Canonical Domain Name 395 The DNS defines the CNAME and DNAME mechanisms for specifying domain 396 name aliases. The canonical name of a DNS name is the name that 397 results from performing all DNS alias operations. 399 A Certification Authority MUST perform CNAME and DNAME processing as 400 defined in the DNS specifications 1035 [RFC1035]. 402 2.2.2. Use of DNS Security 404 Use of DNSSEC to authenticate CAA RRs is strongly recommended but not 405 required. A CA MUST NOT issue certificates if doing so would 406 conflict with the corresponding extended issuer authorization set 407 whether the corresponding DNS records are signed or not. 409 Use of DNSSEC allows a CA to acquire and archive a non-repudiable 410 proof that they were authorized to issue certificates for the domain. 412 2.2.3. Archive 414 A compliant CA SHOULD maintain an archive of the DNS transactions 415 used to verify CAA eligibility. 417 In particular a CA SHOULD ensure that where DNSSEC data is available 418 that the corresponding signature and NSEC/NSEC3 records are preserved 419 so as to enable later compliance audits. 421 2.3. Relying Party Application Processing 423 Relying Party Applications MAY enforce CAA issue restrictions at 424 their option, provided that the Relying Party Authorization set is 425 not empty. 427 The consequences of determining that a certificate is not compatible 428 with the specified CAA relying party restrictions are outside the 429 scope of this document. 431 Domains that opt to flag records for use by Relying Party 432 Applications SHOULD be aware that the Property Entries supported in 433 this version of the specification are only designed to support the 434 requirements of enforcing issuer restrictions. While these Property 435 Entries MAY be sufficient to enable enforcement by Relying Party 436 Applications in some circumstances, they are not intended to provide 437 complete requirements coverage for this purpose. 439 Domains containing CAA issue restrictions intended for use by Relying 440 Party Applications SHOULD be authenticated using DNSSEC or other 441 equivalent means. 443 If DNSSEC is deployed in a domain Relying Party Applications MUST 444 treat failure to authenticate signatures of CAA records or absence of 445 CAA records whose presence is indicated as being equivalent to an 446 inconsistent CAA record. 448 3. Mechanism 450 3.1. Syntax 452 A CAA RR contains a sequence of tag value pairs. Each tag represents 453 a property of the CAA record. The value of a CAA property is that 454 specified in the corresponding value field. 456 A domain name MAY have multiple CAA RRs associated with it and each 457 CAA RR MAY have multiple properties and a given property MAY be 458 specified more than once. 460 This version of the specification makes no distinction as to whether 461 properties are expressed as one record or many, nor are the 462 properties defined sensitive with respect to order. 464 The CAA data field consists of a sequence of at least one property 465 entry. Each property entry consists of a sequence of: 467 Flags One octet containing the following fields: 469 Bits 0-3: Tag Length An unsigned integer specifying the tag 470 length in octets. The tag length MUST be at least 1 and no 471 more than 15. 473 Bit 4: Critical Flag If the value is set (1), the critical flag 474 is asserted and the property MUST be understood if the CAA 475 record is to be correctly processed. 477 A Certification Authority MUST NOT issue certificates for any 478 Domain that contains a CAA critical property for an unknown or 479 unsupported property type. 481 Bit 5: Must Be Zero Bit 5 is reserved and MUST be set to zero. 482 Processors that encounter a CAA record containing a property 483 with this bit set MUST treat the record set as if the critical 484 property was asserted for an unknown record. 486 Bit 6: Relying Application Use If set, the property entry 487 contains an Authorization Entry that forms part of the Relying 488 Application Authorization Set for the corresponding domain. 490 Bit 7: If set, the property entry contains an Authorization Entry 491 that forms part of the Issuer Application Authorization Set for 492 the corresponding domain. 494 Note that according to the conventions set out in RFC 1035 495 [RFC1035] Bit 0 is the Most Significant Bit and Bit 7 is the Least 496 Significant. Thus a flags value of 0x51 indicates a tag length of 497 5 octets and that the property entry is not critical and is not to 498 be used for relying party processing. 500 Tag The property identifier, a sequence of ASCII characters. 502 Tag values MAY contain ASCII characters a through z and the 503 numbers 0 through 9. Tag values MUST NOT contain any other 504 characters. Matching of tag values is case insensitive. 506 Value Length Two octets containing an unsigned integer in network 507 byte order specifying the length of the value field in octets. 509 Value A sequence of octets representing the property value. 510 Property values are encoded as binary values and MAY employ sub- 511 formats. 513 3.1.1. Suggested Presentation Format 515 The canonical presentation format of the CAA record is as follows: 517 CAA 519 Where: 521 flags Is an unsigned integer between 0 and 15. 523 tag Is a non-zero sequence of ASCII letter and numbers in lower 524 case. 526 data Is the Base64 Encoding [RFC4648] of the value field. 528 Implementations SHOULD calculate the tag length bits of the flags 529 field from the specified tag. Implementations MUST NOT specify a tag 530 length field in the flags octet that is inconsistent with the 531 specified tag. 533 3.1.1.1. Policy OID Encoding Options 535 For convenience of administration, implementations MAY support ASN.1 536 Policy OID encoding at their option. 538 The Base64 encoding of data never contains the period character '.', 539 while the encoding of ASN.1 OID values specified in IETF GSER 540 encoding [RFC3642] will always incorporate at least one period 541 character. 543 It follows that a data decoder MAY unambiguously interpret data 544 specified in the Base64 or GSER format without the need for 545 additional disambiguation. 547 Implementations MAY choose to allow use of both formats in both file 548 and presentation formats. 550 3.1.2. policy Property value 552 The policy property value specifies an Authorization Entry by means 553 of an ASN.1 OID specifying a Certification Policy. A Certification 554 Authority is authorized to issue Certificates under a policy 555 Authorization Entry if and only if 557 To be honest The Certification Authority has the right to issue 558 certificates under the specified policy, AND 560 The certificate request is compliant with the requirements of the 561 specified policy, AND 563 The certificate request meets all the criteria under the 564 Certification Policy under which the certificate is to be issued. 566 Each policy property specifies a single ASN.1 OID value consisting of 567 the ASN.1 type, length specifier and OID data. 569 The policy property applies to the specified policy OID and all 570 policy OIDs that fall within the same OID arc. If the OID arc 571 1.3.6.1.4.1.35405.666 is specified, then the policy OIDs 572 1.3.6.1.4.1.35405.666, 1.3.6.1.4.1.35405.666.1, 573 1.3.6.1.4.1.35405.666.2 etc. are all authorized. 575 The Certificate that is issued MAY incorporate the specified policy 576 OID itself but is not required to provided that the issue of the 577 certificate is consistent with the requirements of the specified 578 policy. 580 For example, a CA that offers two levels of Certification Policy such 581 that the higher level of assurance included all the requirements of 582 the lower one MAY rely on a policy property specifying the lower 583 assurance policy as authorization for issue under the higher 584 assurance policy but not vice-versa. 586 3.1.3. path Property value 588 The path property value specifies an Authorization Entry by means of 589 a Certificate Signer Certificate or a Certificate Signing key. A 590 Certification Authority is authorized to issue Certificates under a 591 path Authorization Entry if and only if 593 A valid PKIX trust path can be formed from the specified 594 Certificate Signer Certificate or a Certificate Signing key to the 595 certificate that is to be issued, AND 597 The certificate request meets all the criteria under the 598 Certification Policy under which the certificate is to be issued. 600 4. Security Considerations 602 CAA Records provide an accountability control. They are intended to 603 mitigate undesired behavior rather than preventing it. 605 While a Certification Authority can choose to ignore published CAA 606 records, doing so increases the both the probability that they will 607 mis-issue a certificate and the consequences of doing so. Once it is 608 known that a CA observes CAA records, malicious registration requests 609 will target disproportionately target the negligent CAs that do not, 610 and so the mis-issue rate amongst the negligent CAs will increase. 611 Since the CA could clearly have avoided the mis-issue by performing 612 CAA processing, the likelihood of sanctions against the negligent CA 613 is increased. Failure to observe CAA issue restrictions provides an 614 objective criteria for excluding issuers from embedded roots of 615 trust. 617 In contrast, a Certification Authority that processes CAA records 618 correctly can reasonably claim that any residual mis-issue event 619 could have been avoided had the Domain Name holder published 620 appropriate CAA records. 622 4.1. Mis-Issue by Authorized Certification Authority 624 Use of CAA records does not provide protection against mis-issue by 625 an authorized Certification Authority. 627 Domain name holders SHOULD ensure that the CAs they authorize to 628 issue certificates for their domains employ appropriate controls to 629 ensure that certificates are only issued to authorized parties within 630 their organization. 632 Such controls are most appropriately determined by the domain name 633 holder and the authorized CA(s) directly and are thus out of scope of 634 this document. 636 4.2. Suppression or spoofing of CAA records 638 Suppression of the CAA record or insertion of a bogus CAA record 639 could enable an attacker to obtain a certificate from a CA that was 640 not authorized to issue for that domain name. 642 4.2.1. Applications 644 Applications performing CAA checking SHOULD mitigate the risk of 645 suppresion or spoofing of CAA records by means of DNSSEC validation 646 where present. In cases where DNSSEC validation is not available, 647 CAA checking is of limited security value. 649 4.2.2. Certification Authorities 651 Since a certificate issued by a CA can be valid for several years, 652 the consequences of a spoofing or suppression attack are much greater 653 for Certification Authorities and so additional countermeasures are 654 justified. 656 A CA MUST mitigate this risk by employing DNSSEC verification 657 whenever possible and rejecting certificate requests in any case 658 where it is not possible to verify the non-existence or contents of a 659 relevant CAA record. 661 In cases where DNSSEC is not deployed in a corresponding domain, a CA 662 SHOULD attempt to mitigate this risk by employing appropriate DNS 663 security controls. For example all portions of the DNS lookup 664 process SHOULD be performed against the authoritative name server. 666 Cached data MUST NOT be relied on but MAY be used to support 667 additional anti-spoofing or anti-suppression controls. 669 4.3. Denial of Service 671 Introduction of a malformed or malicious CAA RR could in theory 672 enable a Denial of Service attack. 674 This specific threat is not considered to add significantly to the 675 risk of running an insecure DNS service. 677 4.4. Anticompetitive Use of the Critical Flag 679 A Certification Authority could make use of the critical flag to 680 trick customers into publishing records which prevent competing 681 Certification Authorities from issuing certificates even though the 682 customer intends to authorize multiple providers. 684 In practice, such an attack would be of minimal effect since any 685 competent competitor that found itself unable to issue certificates 686 due to lack of support for a property marked critical is going to 687 investigate the cause and report the reason to the customer who was 688 deceived. It is thus unlikely that the attack would succeed and the 689 attempt might lay the perpetrator open to civil or criminal 690 sanctions. 692 5. IANA Considerations 694 5.1. Registration of the CAA Resource Record Type 696 IANA has assigned Resource Record Type TBD1 for the CAA Resource 697 Record Type and added the line depicted below to the registry named 698 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 699 [RFC5395] and located at 700 http://www.iana.org/assignments/dns-parameters. 702 Value and meaning Reference 703 ----------- --------------------------------------------- --------- 704 CAA TBD1 Certification Authority Restriction [RFCXXXX] 706 5.2. Certification Authority Authorization Properties 708 IANA has created the Certification Authority Authorization Properties 709 registry with the following initial values: 711 Meaning Reference 712 ----------- ----------------------------------------------- --------- 713 path Authorization Entry by Signature Path [RFCXXXX] 714 policy Authorization Entry by Certificate Policy [RFCXXXX] 716 Addition of tag identifiers requires a public specification and 717 expert review as set out in RFC5395 [RFC5395] 719 6. References 721 6.1. Normative References 723 [RFC1035] Mockapetris, P., "Domain names - implementation and 724 specification", STD 13, RFC 1035, November 1987. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 730 Rose, "DNS Security Introduction and Requirements", 731 RFC 4033, March 2005. 733 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 734 Algorithms and Identifiers for RSA Cryptography for use in 735 the Internet X.509 Public Key Infrastructure Certificate 736 and Certificate Revocation List (CRL) Profile", RFC 4055, 737 June 2005. 739 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 740 Housley, R., and W. Polk, "Internet X.509 Public Key 741 Infrastructure Certificate and Certificate Revocation List 742 (CRL) Profile", RFC 5280, May 2008. 744 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 745 Considerations", BCP 42, RFC 5395, November 2008. 747 [X.509] International Telecommunication Union, "ITU-T 748 Recommendation X.509 (11/2008): Information technology - 749 Open systems interconnection - The Directory: Public-key 750 and attribute certificate frameworks", ITU-T 751 Recommendation X.509, November 2008. 753 [X.680] International Telecommunication Union, "ITU-T 754 Recommendation X.680 (11/2008): Information technology - 755 Abstract Syntax Notation One (ASN.1): Specification of 756 basic notation", ITU-T Recommendation X.680, 757 November 2008. 759 [X.690] International Telecommunication Union, "ITU-T 760 Recommendation X.690 (11/2008): Information technology - 761 Abstract Syntax Notation One (ASN.1): Specification of 762 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 763 and Distinguished Encoding Rules (DER)", ITU-T 764 Recommendation X.690, November 2008. 766 6.2. Non Normative References 768 [NIST-ALGS] 769 National Institute of Standards and Technology, 770 "Cryptographic Algorithm Registration", March 2009. 772 [RFC3642] Legg, S., "Common Elements of Generic String Encoding 773 Rules (GSER) Encodings", RFC 3642, October 2003. 775 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 776 Encodings", RFC 4648, October 2006. 778 Appendix A. Object Digest Identifier Calculation 780 An Object Digest is an ASN.1 structure with three components: 782 An ASN.1 Object Identifier specifying the object type of the 783 referenced object 785 An ASN.1 Object Identifier specifying the digest algorithm 787 An ASN.1 DER [X.690] encoded data field containing the digest 788 value of the referenced object processed using the specified 789 digest algorithm. 791 DNSCAA DEFINITIONS ::= 793 BEGIN 795 ObjectDigestIdentifier ::= SEQUENCE { 796 type OBJECT IDENTIFIER, 797 digestAlgorithm OBJECT IDENTIFIER, 798 digest OCTET STRING 799 } 801 END 803 The Object Digest Identifier construction is designed to facilitate 804 implementation in applications that already require ASN.1 handling 805 mechanisms (i.e. most cryptographic applications) without causing an 806 undue coding burden in cases where ASN.1 code is not already 807 supported. Appendix C provides all the necessary information to 808 create a fully compliant Object Digest Identifier implementation. 810 A.1. Example: CA Certificate A 812 The ODI of CA Certificate A (specified in Appendix B.1) is calculated 813 as follows: 815 ASN.1 Sequence tag: "3032" 817 ASN.1 OID id-at-cACertificate (2.5.4.37): "0603550425" 819 ASN.1 OID sha256 (2.16.840.1.101.3.4.2.1): 820 "0609608648016503040201" 822 SHA-256 Digest Value: "042017cc980f6a84fb15e5da3f32afea62360f4ca29 823 627feed68739a13062defe804" 825 The ODI in BASE64 format is MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP 826 zKv6mI2D0yilif+7WhzmhMGLe/oBA==. 828 A.2. Example: CA Certificate A 830 The ODI of the signing key of CA Certificate A (specified in Appendix 831 B.1) is calculated as follows: 833 ASN.1 Sequence tag 835 ASN.1 OID 'CA Signing Key' 837 ASN.1 OID 'SHA-256' 839 SHA-256 Digest Value 841 Appendix B. Example Certificates 843 The following certificates are used in the examples. 845 B.1. CA Certificate A 847 CA Certificate A is a self signed certificate signed with a 2048 bit 848 RSA key: 850 -----BEGIN CERTIFICATE----- 851 MIIDATCCAeugAwIBAgIBATALBgkqhkiG9w0BAQUwKDERMA8GA1UEChMIQWNtZSBJ 852 bmMxEzARBgNVBAMTCkV4YW1wbGUgQ0EwHhcNMTAxMTExMTgxMjAzWhcNMjAxMTA4 853 MTgxMjAzWjAoMREwDwYDVQQKEwhBY21lIEluYzETMBEGA1UEAxMKRXhhbXBsZSBD 854 QTCCAR8wCwYJKoZIhvcNAQEBA4IBDgAwggEJAoIBALHvos3yEe0ugR6Ae2rPATXA 855 pBYGK6BMzGTLkXCg6MZaG9CZpfleZTZ/EgIKBwRJlIXvWdKwjMZ7GBByT+fdMDZp 856 7zkx64UZ4+CJm98NRjdugxovl8HhscIBXnhCHERgamp0U/f8Ho5W8eAxYLZ1XcIG 857 mB7mVknvolaN9EqlEmYn+qHexGJPlpWFmR4NKhVAATE6B1a9z5PCmoOgW9p0Vqic 858 SJ6CdAHKaa7JZS+sqNQDx57H8Q6R9lh52XXmJVVficxBp2K7C+Wvht45t68FG6f1 859 sXWuWDRYc6iUmOxZbzDDvIoFU0pAXESTdMOWvXKI8ZUaYBoZ7/YnSSTaseiW86sC 860 AwEAAaM9MDswDgYDVR0PAQEBBAQDAgAEMA8GA1UdEwEBAQQFMAMBAQEwGAYDVR0g 861 BBEwDzANBgsrBgEEAYKUTYUaATALBgkqhkiG9w0BAQUDggEBAGcNiaQXdyiI9Y5e 862 Ps+XEYdKiWYvmSnRIfbUZuQWaQpPcj5cHzMe91CUZipGDNJYXwqWhIUtQAAGmtrq 863 ZGa4F9Yh0cPFAHBXPHXKGeM1hMtAR7Mv9kHu4DFIhb822O0n4DdBIit8FNas5t/5 864 CbM6crDpWB5hjAsD37U+GZGvTJmag059VWjnjv90NcfCQ6YJ6AA5VKnmrV695VnL 865 dSPaN9VS5RN6heJqU9tcbqPkAEP3MuJtd1QxB8Q34f9e1kTYXxc/dBJK1RQ0F4nc 866 Jc4NbJzakvFq+QcbzEqkhDMiXvjDV0JJt+GkFZrsREi6IgQY4DQHPv65OIvbr3uW 867 329dd+g= 868 -----END CERTIFICATE----- 870 In binary form, the certificate data is: 872 0000 30 82 03 01 30 82 01 eb a0 03 02 01 02 02 01 01 873 0010 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 28 31 874 0020 11 30 0f 06 03 55 04 0a 13 08 41 63 6d 65 20 49 875 0030 6e 63 31 13 30 11 06 03 55 04 03 13 0a 45 78 61 876 0040 6d 70 6c 65 20 43 41 30 1e 17 0d 31 30 31 31 31 877 0050 31 31 38 31 32 30 33 5a 17 0d 32 30 31 31 30 38 878 0060 31 38 31 32 30 33 5a 30 28 31 11 30 0f 06 03 55 879 0070 04 0a 13 08 41 63 6d 65 20 49 6e 63 31 13 30 11 880 0080 06 03 55 04 03 13 0a 45 78 61 6d 70 6c 65 20 43 881 0090 41 30 82 01 1f 30 0b 06 09 2a 86 48 86 f7 0d 01 882 00a0 01 01 03 82 01 0e 00 30 82 01 09 02 82 01 00 b1 883 00b0 ef a2 cd f2 11 ed 2e 81 1e 80 7b 6a cf 01 35 c0 884 00c0 a4 16 06 2b a0 4c cc 64 cb 91 70 a0 e8 c6 5a 1b 885 00d0 d0 99 a5 f9 5e 65 36 7f 12 02 0a 07 04 49 94 85 886 00e0 ef 59 d2 b0 8c c6 7b 18 10 72 4f e7 dd 30 36 69 887 00f0 ef 39 31 eb 85 19 e3 e0 89 9b df 0d 46 37 6e 83 888 0100 1a 2f 97 c1 e1 b1 c2 01 5e 78 42 1c 44 60 6a 6a 889 0110 74 53 f7 fc 1e 8e 56 f1 e0 31 60 b6 75 5d c2 06 890 0120 98 1e e6 56 49 ef a2 56 8d f4 4a a5 12 66 27 fa 891 0130 a1 de c4 62 4f 96 95 85 99 1e 0d 2a 15 40 01 31 892 0140 3a 07 56 bd cf 93 c2 9a 83 a0 5b da 74 56 a8 9c 893 0150 48 9e 82 74 01 ca 69 ae c9 65 2f ac a8 d4 03 c7 894 0160 9e c7 f1 0e 91 f6 58 79 d9 75 e6 25 55 5f 89 cc 895 0170 41 a7 62 bb 0b e5 af 86 de 39 b7 af 05 1b a7 f5 896 0180 b1 75 ae 58 34 58 73 a8 94 98 ec 59 6f 30 c3 bc 897 0190 8a 05 53 4a 40 5c 44 93 74 c3 96 bd 72 88 f1 95 898 01a0 1a 60 1a 19 ef f6 27 49 24 da b1 e8 96 f3 ab 02 899 01b0 03 01 00 01 a3 3d 30 3b 30 0e 06 03 55 1d 0f 01 900 01c0 01 01 04 04 03 02 00 04 30 0f 06 03 55 1d 13 01 901 01d0 01 01 04 05 30 03 01 01 01 30 18 06 03 55 1d 20 902 01e0 04 11 30 0f 30 0d 06 0b 2b 06 01 04 01 82 94 4d 903 01f0 85 1a 01 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 904 0200 03 82 01 01 00 67 0d 89 a4 17 77 28 88 f5 8e 5e 905 0210 3e cf 97 11 87 4a 89 66 2f 99 29 d1 21 f6 d4 66 906 0220 e4 16 69 0a 4f 72 3e 5c 1f 33 1e f7 50 94 66 2a 907 0230 46 0c d2 58 5f 0a 96 84 85 2d 40 00 06 9a da ea 908 0240 64 66 b8 17 d6 21 d1 c3 c5 00 70 57 3c 75 ca 19 909 0250 e3 35 84 cb 40 47 b3 2f f6 41 ee e0 31 48 85 bf 910 0260 36 d8 ed 27 e0 37 41 22 2b 7c 14 d6 ac e6 df f9 911 0270 09 b3 3a 72 b0 e9 58 1e 61 8c 0b 03 df b5 3e 19 912 0280 91 af 4c 99 9a 83 4e 7d 55 68 e7 8e ff 74 35 c7 913 0290 c2 43 a6 09 e8 00 39 54 a9 e6 ad 5e bd e5 59 cb 914 02a0 75 23 da 37 d5 52 e5 13 7a 85 e2 6a 53 db 5c 6e 915 02b0 a3 e4 00 43 f7 32 e2 6d 77 54 31 07 c4 37 e1 ff 916 02c0 5e d6 44 d8 5f 17 3f 74 12 4a d5 14 34 17 89 dc 917 02d0 25 ce 0d 6c 9c da 92 f1 6a f9 07 1b cc 4a a4 84 918 02e0 33 22 5e f8 c3 57 42 49 b7 e1 a4 15 9a ec 44 48 919 02f0 ba 22 04 18 e0 34 07 3e fe b9 38 8b db af 7b 96 920 0300 df 6f 5d 77 e8 922 The SHA-256 digest of the certificate data is: 924 17cc980f6a84fb15e5da3f32afea62360f4ca29627feed68739a13062defe804 926 Appendix C. ASN.1 Values (Non-Normative) 928 Although the Object Digest Identifier form employs ASN.1 DER encoding 929 only a small subset of ASN.1 features are used and a full ASN.1 stack 930 is not necessary. 932 This appendix provides sufficient information to implement an Object 933 Digest Identifier constructor or parser. 935 C.1. DER Sequence Encoding 937 In DER encoding, the enclosing SEQUENCE will always be represented by 938 the type identifier x30 followed by the length specifier. Since the 939 total length of the following data fields will almost certainly be 940 less than 127 bytes, the single byte encoding mechanism in which bit 941 7 is clear and the length value is encoded in the lower 7 bits will 942 be required. 944 C.2. Object Identifiers for Certificate Types 946 OIDs have been defined in connection with the X.500 directory for 947 user certificates, certification authority certificates, revocations 948 of certification authority, and revocations of user certificates. 949 The following table lists the OIDs, their DER encoding, and their 950 type identifier and length-prefixed hex format for use in Object 951 Digest Identifiers. 953 id-at OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) ds(5) 4 } 955 id-at-userCertificate OBJECT IDENTIFIER ::= { id-at 36 } 956 -- 06 03 55 04 24 957 id-at-cACertificate OBJECT IDENTIFIER ::= { id-at 37 } 958 -- 06 03 55 04 25 959 TBS-PUBLIC-KEY-VALUE OBJECT IDENTIFIER ::= { ??? } 960 -- 06 xx xx xx xx 962 C.3. Object Identifiers for Digest Algorithms 964 OIDs have been assigned by NIST for the SHA-2 digest algorithms 965 [NIST-ALGS] [RFC4055] Use of the SHA-1 digest algorithm is not 966 recommended due to concerns for the security of the algorithm. 968 hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 969 country(16) us(840) organization(1) gov(101) csor(3) 970 nistAlgorithm(4) 2 } 972 id-sha256 OBJECT IDENTIFIER ::= { hashAlgs 1 } 973 -- 06 09 60 86 48 01 65 03 04 02 01 974 id-sha384 OBJECT IDENTIFIER ::= { hashAlgs 2 } 975 -- 06 09 60 86 48 01 65 03 04 02 02 976 id-sha512 OBJECT IDENTIFIER ::= { hashAlgs 3 } 977 -- 06 09 60 86 48 01 65 03 04 02 03 978 id-sha224 OBJECT IDENTIFIER ::= { hashAlgs 4 } 979 -- 06 09 60 86 48 01 65 03 04 02 04 981 C.4. DER Data Encoding Prefixes 983 The rules of ASN.1 encoding state that every data value is preceded 984 by a data type identifier and a length identifier. In the case of an 985 Object Digest Identifier the data type identifier is always OCTET 986 STRING (04) and the length for all currently defined digest 987 algorithms will be less than 128 bytes (1024 bits) and thus use the 988 single byte encoding form in which bit 7 is set to 0 and the lower 7 989 bits specify the length. 991 The length prefixes for commonly used digest lengths in hexadecimal 992 notation are thus: 994 160 bits 04 14 996 224 bits 04 1C 998 256 bits 04 20 1000 384 bits 04 30 1002 512 bits 04 40 1004 Authors' Addresses 1006 Phillip Hallam-Baker 1007 Comodo Group Inc. 1009 Email: philliph@comodo.com 1011 Rob Stradling 1012 Comodo CA Ltd. 1014 Email: rob.stradling@comodo.com 1016 Ben Laurie 1017 Google Inc. 1019 Email: benl@google.com