idnits 2.17.1 draft-hallambaker-donotissue-04.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 878 has weird spacing: '...2 01 eb a0 03...' == Line 899 has weird spacing: '...a 69 ae c9 65...' -- The document date (May 10, 2011) is 4725 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC4648' is mentioned on line 782, but not defined == Missing Reference: 'RFC3642' is mentioned on line 779, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 721, but not defined == Missing Reference: 'NIST-ALGS' is mentioned on line 971, 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: November 11, 2011 Comodo CA Ltd. 6 B. Laurie 7 Google Inc. 8 May 10, 2011 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-hallambaker-donotissue-04 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 November 11, 2011. 42 Copyright Notice 44 Copyright (c) 2011 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. . . . . . . . . . . . . . . . . . . . 8 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. Canonical Presentation Format . . . . . . . . . . . . 13 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. Abuse 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 . . . . . 17 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 . . . . . . . . . . . . . . . . 20 93 B.1. CA Certificate A . . . . . . . . . . . . . . . . . . . . . 20 94 Appendix C. ASN.1 Values (Non-Normative) . . . . . . . . . . . . 21 95 C.1. DER Sequence Encoding . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 23 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 (257) publishes a CAA property entry that corresponds to the 228 specified domain name. Multiple property entries MAY be associated 229 with the same domain name by publiching multiple CAA RRs at that 230 domain name. Each property entry MAY be tagged with one or more of 231 the following flag values: 233 Critical If set, indicates that the corresponding property entry tag 234 MUST be understood if the semantics of the CAA record are to be 235 correctly understood by the specified audience. 237 Issuers MUST NOT issue certificates for a domain if the Extended 238 Issuer Authorization Set contains unknown property entry tags that 239 are flagged as critical. 241 Relying Parties MUST NOT attempt to enforce CAA records if the 242 Relying Party Authorization Set contains unknown property entry 243 tags that are flagged as critical 245 Must be Zero This bit is reserved for future use. 247 Issuers MUST NOT issue certificates for a domain if the Extended 248 Issuer Authorization Set contains property entries with the Must 249 Be Zero Tag Set. 251 Relying Parties MUST NOT attempt to enforce CAA records if the 252 Relying Party Authorization Set contains property entries with the 253 Must Be Zero Tag Set. 255 Relying Party Specifies that the corresponding Property Entry is to 256 be used by Relying Party Applications and forms part of the 257 Relying Party Authorization Set for the domain. 259 Issuer Specifies that the corresponding Property Entry is to be used 260 by Issuers and forms part of the Issuer Authorization Set for the 261 domain. 263 The following properties are defined: 265 policy The policy property entry declares 266 an authorization entry granting authorization to issue under the 267 specified Certificate Policy. 269 path The path property entry declares an 270 authorization entry granting authorization to issue end entity 271 certificates under a trust path that includes the specified 272 signing credential. 274 An Object Digest Identifier (ODI) is a means of specifying a 275 reference to an object instance by means of a cryptographic digest 276 function. A CAA path property may use an ODI to specify a 277 certificate trust path by means of: 279 A Certificate Signing Certificate 281 A Public Signing Key 283 In either case a path Authorization Entry authorizes an issuer to 284 issue an End Entity certificate to the corresponding domain if and 285 only if it is possible to form a valid certificate path to it from 286 the referenced certificate or key. 288 2.1.1. Examples of Use. 290 For convenience the examples are presented in the text format 291 suggested in section Section 3.1.1 293 The following example informs CAs that certificates must not be 294 issued except under the Default Deny Security 'Example 1' Certificate 295 Policy (1.3.6.1.4.1.35405.666.1). Since the policy is published at 296 the Public Delegation Point, the policy applies to all subordinate 297 domains under example.com. 299 $ORIGIN example.com 300 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 302 The following example informs CAs that certificates must not be 303 issued except under the Certificate Authority Root certificate 304 specified in Appendix B. 306 $ORIGIN example.com 307 . CAA 1 path MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe 308 XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA== 310 A domain MAY authorize multiple CAs to issue certificates at the same 311 time. The following example allows issue under the Default Deny 312 Security certification policy 'Example 1' or 'Example 2': 314 $ORIGIN example.com 315 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 316 . CAA 1 policy 1.3.6.1.4.1.35405.666.2 318 If Authorization Entries using the path and policy properties are 319 present at a given Domain, compatibility with either is sufficient to 320 authorize the request. 322 Future versions of this specification MAY use the critical flag to 323 introduce new semantics that MUST be understood for correct 324 processing of the record, preventing Certification Authorities that 325 do not recognize the record from issuing certificates. 327 In the following example, the property 'tbs' is flagged as critical. 328 The Default Deny Security CA is not authorized to issue under either 329 policy unless the processing rules for the 'tbs' property tag are 330 understood. 332 $ORIGIN example.com 333 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 334 . CAA 1 policy 1.3.6.1.4.1.35405.666.2 335 . CAA 129 tbs MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe 336 XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA== 338 Enforcement by Relying Party Applications follows the same general 339 principles. A Relying Party Application MUST NOT enforce CAA records 340 unless at least one Property Entry has the Relying Party flag set, 341 that is the Relyin Party Authorization Set is not empty. 343 In the following example, certificates must not be issued except 344 under the Default Deny Security 'Example 1' Certificate Policy and 345 Relying Party Applications MAY reject certificates presented that do 346 not comply with this requirement: 348 $ORIGIN example.com 349 . CAA 3 policy 1.3.6.1.4.1.35405.666.1 351 In the ordinary course of business a Domain administrator may 352 withdraw authorization for issue of new certificates before the 353 previously issued certificates expire. 355 In the following example, Relying Party Applications are informed 356 that certificates issued under either the policy are to be considered 357 to be authorized but new certificates can only be issued under the 358 first. 360 $ORIGIN example.com 361 . CAA 3 policy 1.3.6.1.4.1.35405.666.1 362 . CAA 2 policy 1.3.6.1.4.1.35405.666.2 364 2.2. Certification Authority Processing 366 Before issue of a certificate a compliant CA MUST check for 367 publication of a relevant CAA Resource Record(s) and if such 368 record(s) are published, that the certificate requested is consistent 369 with them. If the certificate requested is not consistent with the 370 relevant CAA RRs, the CA MUST NOT issue the certificate. 372 The Issuer Authorization Set for a domain name consists of the set of 373 all CAA Authorization Entries declared for the canonical form of the 374 specified domain. 376 The Extended Issuer Authorization Set for a domain name consists of 377 the Issuer Authorization Set for that domain name if it is non-empty. 378 Otherwise the Extended Issuer Authorization Set for a domain name 379 consists of the Issuer Authorization Set for the corresponding Public 380 Delegation Point for that domain name. 382 If the Extended Issuer Authorization Set for a domain name is not 383 empty, a Certification Authority MUST NOT issue a certificate unless 384 it conforms to at least one authorization entry in the Extended 385 Issuer Authorization Set. 387 Note that while it MUST be possible to form a certificate validation 388 path that contains at least one certificate that is so specified, it 389 MAY also be possible to form valid certificate paths that are not. 391 For example, a CA that has updated its root certificate to extend the 392 expiry date is entitled to issue certificates for domains where the 393 CAA record only specifies the older root certificate provided that 394 the older root certificate has not actually expired and it is thus 395 possible to form a valid certificate path. 397 2.2.1. Canonical Domain Name 399 The DNS defines the CNAME and DNAME mechanisms for specifying domain 400 name aliases. The canonical name of a DNS name is the name that 401 results from performing all DNS alias operations. 403 A Certification Authority MUST perform CNAME and DNAME processing as 404 defined in the DNS specifications 1035 [RFC1035]. 406 2.2.2. Use of DNS Security 408 Use of DNSSEC to authenticate CAA RRs is strongly recommended but not 409 required. A CA MUST NOT issue certificates if doing so would 410 conflict with the corresponding extended issuer authorization set 411 whether the corresponding DNS records are signed or not. 413 Use of DNSSEC allows a CA to acquire and archive a non-repudiable 414 proof that they were authorized to issue certificates for the domain. 416 2.2.3. Archive 418 A compliant CA SHOULD maintain an archive of the DNS transactions 419 used to verify CAA eligibility. 421 In particular a CA SHOULD ensure that where DNSSEC data is available 422 that the corresponding signature and NSEC/NSEC3 records are preserved 423 so as to enable later compliance audits. 425 2.3. Relying Party Application Processing 427 Relying Party Applications MAY enforce CAA issue restrictions at 428 their option, provided that the Relying Party Authorization set is 429 not empty. 431 The consequences of determining that a certificate is not compatible 432 with the specified CAA relying party restrictions are outside the 433 scope of this document. 435 Domains that opt to flag records for use by Relying Party 436 Applications SHOULD be aware that the Property Entries supported in 437 this version of the specification are only designed to support the 438 requirements of enforcing issuer restrictions. While these Property 439 Entries MAY be sufficient to enable enforcement by Relying Party 440 Applications in some circumstances, they are not intended to provide 441 complete requirements coverage for this purpose. 443 Domains containing CAA issue restrictions intended for use by Relying 444 Party Applications SHOULD be authenticated using DNSSEC or other 445 equivalent means. 447 If DNSSEC is deployed in a domain Relying Party Applications MUST 448 treat failure to authenticate signatures of CAA records or absence of 449 CAA records whose presence is indicated as being equivalent to an 450 inconsistent CAA record. 452 3. Mechanism 454 3.1. Syntax 456 A CAA RR contains a single property entry consisting of a tag value 457 pair. Each tag represents a property of the CAA record. The value 458 of a CAA property is that specified in the corresponding value field. 460 A domain name MAY have multiple CAA RRs associated with it and a 461 given property MAY be specified more than once. 463 The CAA data field contains one property entry. A property entry 464 consists of the following data fields: 466 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 467 | Flags | Tag Length = n | 468 +----------------+----------------+...+---------------+ 469 | Tag char 0 | Tag Char 1 |...| Tag Char n-1 | 470 +----------------+----------------+...+---------------+ 471 +----------------+----------------+.....+---------------+ 472 | Data byte 0 | Data byte 1 |.....| Data byte m-1 | 473 +----------------+----------------+.....+---------------+ 475 Where n is the length specified in the tag length field and m is the 476 remaining octets in the data field (m = d - n - 2) where d is the 477 length of the data section. 479 The data fields are defined as follows: 481 Flags One octet containing the following fields: 483 Bit 0: Critical Flag If the value is set (1), the critical flag 484 is asserted and the property MUST be understood if the CAA 485 record is to be correctly processed. 487 A Certification Authority MUST NOT issue certificates for any 488 Domain that contains a CAA critical property for an unknown or 489 unsupported property type. 491 Bit 5: Must Be Zero Bit 5 is reserved and MUST be set to zero. 492 Processors that encounter a CAA record containing a property 493 with this bit set MUST treat the record set as if the critical 494 property was asserted for an unknown record. 496 Bit 6: Relying Application Use If set, the property entry 497 contains an Authorization Entry that forms part of the Relying 498 Application Authorization Set for the corresponding domain. 500 Bit 7: Issuer Use If set, the property entry contains an 501 Authorization Entry that forms part of the Issuer Application 502 Authorization Set for the corresponding domain. 504 Note that according to the conventions set out in RFC 1035 505 [RFC1035] Bit 0 is the Most Significant Bit and Bit 7 is the Least 506 Significant. Thus a flags value of 0x51 indicates a tag length of 507 5 octets and that the property entry is not critical and is not to 508 be used for relying party processing. 510 Tag Length A single octet containing an unsigned integer specifying 511 the tag length in octets. The tag length MUST be at least 1 and 512 SHOULD be no more than 15. 514 Tag The property identifier, a sequence of ASCII characters. 516 Tag values MAY contain ASCII characters a through z and the 517 numbers 0 through 9. Tag values MUST NOT contain any other 518 characters. Matching of tag values is case insensitive. 520 Value A sequence of octets representing the property value. 521 Property values are encoded as binary values and MAY employ sub- 522 formats. 524 The length of the value field is specified implicitly as the 525 remaining length of the enclosing Resource Record data field. 527 3.1.1. Canonical Presentation Format 529 The canonical presentation format of the CAA record is as follows: 531 CAA 533 Where: 535 flags Is an unsigned integer between 0 and 15. 537 tag Is a non-zero sequence of ASCII letter and numbers in lower 538 case. 540 data Is the Base64 Encoding [RFC4648] of the value field. 542 3.1.1.1. Policy OID Encoding Options 544 For convenience of administration, implementations MAY support ASN.1 545 Policy OID encoding at their option. 547 The Base64 encoding of data never contains the period character '.', 548 while the encoding of ASN.1 OID values specified in IETF GSER 549 encoding [RFC3642] will always incorporate at least one period 550 character. 552 It follows that a data decoder MAY unambiguously interpret data 553 specified in the Base64 or GSER format without the need for 554 additional disambiguation. 556 Implementations MAY choose to allow use of both formats in both file 557 and presentation formats. 559 3.1.2. policy Property value 561 The policy property value specifies an Authorization Entry by means 562 of an ASN.1 OID specifying a Certification Policy. A Certification 563 Authority is authorized to issue Certificates under a policy 564 Authorization Entry if and only if 566 The Certification Authority has the right to issue certificates 567 under the specified policy, AND 569 The certificate request is compliant with the requirements of the 570 specified policy, AND 571 The certificate request meets all the criteria under the 572 Certification Policy under which the certificate is to be issued. 574 Each policy property specifies a single ASN.1 OID value consisting of 575 the ASN.1 type, length specifier and OID data. 577 The policy property applies to the specified policy OID and all 578 policy OIDs that fall within the same OID arc. If the OID arc 579 1.3.6.1.4.1.35405.666 is specified, then the policy OIDs 580 1.3.6.1.4.1.35405.666, 1.3.6.1.4.1.35405.666.1, 581 1.3.6.1.4.1.35405.666.2 etc. are all authorized. 583 The Certificate that is issued MAY incorporate the specified policy 584 OID itself but is not required to provided that the issue of the 585 certificate is consistent with the requirements of the specified 586 policy. 588 For example, a CA that offers two levels of Certification Policy such 589 that the higher level of assurance included all the requirements of 590 the lower one MAY rely on a policy property specifying the lower 591 assurance policy as authorization for issue under the higher 592 assurance policy but not vice-versa. 594 3.1.3. path Property value 596 The path property value specifies an Authorization Entry by means of 597 a Certificate Signer Certificate or a Certificate Signing key. A 598 Certification Authority is authorized to issue Certificates under a 599 path Authorization Entry if and only if 601 A valid PKIX trust path can be formed from the specified 602 Certificate Signer Certificate or a Certificate Signing key to the 603 certificate that is to be issued, AND 605 The certificate request meets all the criteria under the 606 Certification Policy under which the certificate is to be issued. 608 4. Security Considerations 610 CAA Records provide an accountability control. They are intended to 611 deter rather than prevent undesired behavior. 613 While a Certification Authority can choose to ignore published CAA 614 records, doing so increases the both the probability that they will 615 mis-issue a certificate and the consequences of doing so. Once it is 616 known that a CA observes CAA records, malicious registration requests 617 will target disproportionately target the negligent CAs that do not, 618 and so the mis-issue rate amongst the negligent CAs will increase. 619 Since the CA could clearly have avoided the mis-issue by performing 620 CAA processing, the likelihood of sanctions against the negligent CA 621 is increased. Failure to observe CAA issue restrictions provides an 622 objective criteria for excluding issuers from embedded roots of 623 trust. 625 In contrast, a Certification Authority that processes CAA records 626 correctly can reasonably claim that any residual mis-issue event 627 could have been avoided had the Domain Name holder published 628 appropriate CAA records. 630 4.1. Mis-Issue by Authorized Certification Authority 632 Use of CAA records does not provide protection against mis-issue by 633 an authorized Certification Authority. 635 Domain name holders SHOULD ensure that the CAs they authorize to 636 issue certificates for their domains employ appropriate controls to 637 ensure that certificates are only issued to authorized parties within 638 their organization. 640 Such controls are most appropriately determined by the domain name 641 holder and the authorized CA(s) directly and are thus out of scope of 642 this document. 644 4.2. Suppression or spoofing of CAA records 646 Suppression of the CAA record or insertion of a bogus CAA record 647 could enable an attacker to obtain a certificate from a CA that was 648 not authorized to issue for that domain name. 650 4.2.1. Applications 652 Applications performing CAA checking SHOULD mitigate the risk of 653 suppresion or spoofing of CAA records by means of DNSSEC validation 654 where present. In cases where DNSSEC validation is not available, 655 CAA checking is of limited security value. 657 4.2.2. Certification Authorities 659 Since a certificate issued by a CA can be valid for several years, 660 the consequences of a spoofing or suppression attack are much greater 661 for Certification Authorities and so additional countermeasures are 662 justified. 664 A CA MUST mitigate this risk by employing DNSSEC verification 665 whenever possible and rejecting certificate requests in any case 666 where it is not possible to verify the non-existence or contents of a 667 relevant CAA record. 669 In cases where DNSSEC is not deployed in a corresponding domain, a CA 670 SHOULD attempt to mitigate this risk by employing appropriate DNS 671 security controls. For example all portions of the DNS lookup 672 process SHOULD be performed against the authoritative name server. 673 Cached data MUST NOT be relied on but MAY be used to support 674 additional anti-spoofing or anti-suppression controls. 676 4.3. Denial of Service 678 Introduction of a malformed or malicious CAA RR could in theory 679 enable a Denial of Service attack. 681 This specific threat is not considered to add significantly to the 682 risk of running an insecure DNS service. 684 4.4. Abuse of the Critical Flag 686 A Certification Authority could make use of the critical flag to 687 trick customers into publishing records which prevent competing 688 Certification Authorities from issuing certificates even though the 689 customer intends to authorize multiple providers. 691 In practice, such an attack would be of minimal effect since any 692 competent competitor that found itself unable to issue certificates 693 due to lack of support for a property marked critical is going to 694 investigate the cause and report the reason to the customer who was 695 deceived. It is thus unlikely that the attack would succeed and the 696 attempt might lay the perpetrator open to civil or criminal 697 sanctions. 699 5. IANA Considerations 701 5.1. Registration of the CAA Resource Record Type 703 IANA has assigned Resource Record Type 257 for the CAA Resource 704 Record Type and added the line depicted below to the registry named 705 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 706 [RFC5395] and located at 707 http://www.iana.org/assignments/dns-parameters. 709 Value and meaning Reference 710 ----------- --------------------------------------------- --------- 711 CAA 257 Certification Authority Restriction [RFCXXXX] 713 5.2. Certification Authority Authorization Properties 715 IANA has created the Certification Authority Authorization Properties 716 registry with the following initial values: 718 Meaning Reference 719 ----------- ----------------------------------------------- --------- 720 path Authorization Entry by Signature Path [RFCXXXX] 721 policy Authorization Entry by Certificate Policy [RFCXXXX] 723 Addition of tag identifiers requires a public specification and 724 expert review as set out in RFC5395 [RFC5395] 726 6. References 728 6.1. Normative References 730 [RFC1035] Mockapetris, P., "Domain names - implementation and 731 specification", STD 13, RFC 1035, November 1987. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 737 Rose, "DNS Security Introduction and Requirements", 738 RFC 4033, March 2005. 740 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 741 Algorithms and Identifiers for RSA Cryptography for use in 742 the Internet X.509 Public Key Infrastructure Certificate 743 and Certificate Revocation List (CRL) Profile", RFC 4055, 744 June 2005. 746 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 747 Housley, R., and W. Polk, "Internet X.509 Public Key 748 Infrastructure Certificate and Certificate Revocation List 749 (CRL) Profile", RFC 5280, May 2008. 751 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 752 Considerations", RFC 5395, November 2008. 754 [X.509] International Telecommunication Union, "ITU-T 755 Recommendation X.509 (11/2008): Information technology - 756 Open systems interconnection - The Directory: Public-key 757 and attribute certificate frameworks", ITU-T 758 Recommendation X.509, November 2008. 760 [X.680] International Telecommunication Union, "ITU-T 761 Recommendation X.680 (11/2008): Information technology - 762 Abstract Syntax Notation One (ASN.1): Specification of 763 basic notation", ITU-T Recommendation X.680, 764 November 2008. 766 [X.690] International Telecommunication Union, "ITU-T 767 Recommendation X.690 (11/2008): Information technology - 768 Abstract Syntax Notation One (ASN.1): Specification of 769 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 770 and Distinguished Encoding Rules (DER)", ITU-T 771 Recommendation X.690, November 2008. 773 6.2. Non Normative References 775 [NIST-ALGS] 776 National Institute of Standards and Technology, 777 "Cryptographic Algorithm Registration", March 2009. 779 [RFC3642] Legg, S., "Common Elements of Generic String Encoding 780 Rules (GSER) Encodings", RFC 3642, October 2003. 782 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 783 Encodings", RFC 4648, October 2006. 785 Appendix A. Object Digest Identifier Calculation 787 An Object Digest is an ASN.1 structure with three components: 789 An ASN.1 Object Identifier specifying the object type of the 790 referenced object 792 An ASN.1 Object Identifier specifying the digest algorithm 794 An ASN.1 DER [X.690] encoded data field containing the digest 795 value of the referenced object processed using the specified 796 digest algorithm. 798 DNSCAA DEFINITIONS ::= 800 BEGIN 802 ObjectDigestIdentifier ::= SEQUENCE { 803 type OBJECT IDENTIFIER, 804 digestAlgorithm OBJECT IDENTIFIER, 805 digest OCTET STRING 806 } 808 END 810 The Object Digest Identifier construction is designed to facilitate 811 implementation in applications that already require ASN.1 handling 812 mechanisms (i.e. most cryptographic applications) without causing an 813 undue coding burden in cases where ASN.1 code is not already 814 supported. Appendix C provides all the necessary information to 815 create a fully compliant Object Digest Identifier implementation. 817 A.1. Example: CA Certificate A 819 The ODI of CA Certificate A (specified in Appendix B.1) is calculated 820 as follows: 822 ASN.1 Sequence tag: "3032" 824 ASN.1 OID id-at-cACertificate (2.5.4.37): "0603550425" 826 ASN.1 OID sha256 (2.16.840.1.101.3.4.2.1): 827 "0609608648016503040201" 829 SHA-256 Digest Value: "042017cc980f6a84fb15e5da3f32afea62360f4ca29 830 627feed68739a13062defe804" 832 The ODI in BASE64 format is MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP 833 zKv6mI2D0yilif+7WhzmhMGLe/oBA==. 835 A.2. Example: CA Certificate A 837 The ODI of the signing key of CA Certificate A (specified in Appendix 838 B.1) is calculated as follows: 840 ASN.1 Sequence tag 842 ASN.1 OID 'CA Signing Key' 844 ASN.1 OID 'SHA-256' 845 SHA-256 Digest Value 847 Appendix B. Example Certificates 849 The following certificates are used in the examples. 851 B.1. CA Certificate A 853 CA Certificate A is a self signed certificate signed with a 2048 bit 854 RSA key: 856 -----BEGIN CERTIFICATE----- 857 MIIDATCCAeugAwIBAgIBATALBgkqhkiG9w0BAQUwKDERMA8GA1UEChMIQWNtZSBJ 858 bmMxEzARBgNVBAMTCkV4YW1wbGUgQ0EwHhcNMTAxMTExMTgxMjAzWhcNMjAxMTA4 859 MTgxMjAzWjAoMREwDwYDVQQKEwhBY21lIEluYzETMBEGA1UEAxMKRXhhbXBsZSBD 860 QTCCAR8wCwYJKoZIhvcNAQEBA4IBDgAwggEJAoIBALHvos3yEe0ugR6Ae2rPATXA 861 pBYGK6BMzGTLkXCg6MZaG9CZpfleZTZ/EgIKBwRJlIXvWdKwjMZ7GBByT+fdMDZp 862 7zkx64UZ4+CJm98NRjdugxovl8HhscIBXnhCHERgamp0U/f8Ho5W8eAxYLZ1XcIG 863 mB7mVknvolaN9EqlEmYn+qHexGJPlpWFmR4NKhVAATE6B1a9z5PCmoOgW9p0Vqic 864 SJ6CdAHKaa7JZS+sqNQDx57H8Q6R9lh52XXmJVVficxBp2K7C+Wvht45t68FG6f1 865 sXWuWDRYc6iUmOxZbzDDvIoFU0pAXESTdMOWvXKI8ZUaYBoZ7/YnSSTaseiW86sC 866 AwEAAaM9MDswDgYDVR0PAQEBBAQDAgAEMA8GA1UdEwEBAQQFMAMBAQEwGAYDVR0g 867 BBEwDzANBgsrBgEEAYKUTYUaATALBgkqhkiG9w0BAQUDggEBAGcNiaQXdyiI9Y5e 868 Ps+XEYdKiWYvmSnRIfbUZuQWaQpPcj5cHzMe91CUZipGDNJYXwqWhIUtQAAGmtrq 869 ZGa4F9Yh0cPFAHBXPHXKGeM1hMtAR7Mv9kHu4DFIhb822O0n4DdBIit8FNas5t/5 870 CbM6crDpWB5hjAsD37U+GZGvTJmag059VWjnjv90NcfCQ6YJ6AA5VKnmrV695VnL 871 dSPaN9VS5RN6heJqU9tcbqPkAEP3MuJtd1QxB8Q34f9e1kTYXxc/dBJK1RQ0F4nc 872 Jc4NbJzakvFq+QcbzEqkhDMiXvjDV0JJt+GkFZrsREi6IgQY4DQHPv65OIvbr3uW 873 329dd+g= 874 -----END CERTIFICATE----- 876 In binary form, the certificate data is: 878 0000 30 82 03 01 30 82 01 eb a0 03 02 01 02 02 01 01 879 0010 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 28 31 880 0020 11 30 0f 06 03 55 04 0a 13 08 41 63 6d 65 20 49 881 0030 6e 63 31 13 30 11 06 03 55 04 03 13 0a 45 78 61 882 0040 6d 70 6c 65 20 43 41 30 1e 17 0d 31 30 31 31 31 883 0050 31 31 38 31 32 30 33 5a 17 0d 32 30 31 31 30 38 884 0060 31 38 31 32 30 33 5a 30 28 31 11 30 0f 06 03 55 885 0070 04 0a 13 08 41 63 6d 65 20 49 6e 63 31 13 30 11 886 0080 06 03 55 04 03 13 0a 45 78 61 6d 70 6c 65 20 43 887 0090 41 30 82 01 1f 30 0b 06 09 2a 86 48 86 f7 0d 01 888 00a0 01 01 03 82 01 0e 00 30 82 01 09 02 82 01 00 b1 889 00b0 ef a2 cd f2 11 ed 2e 81 1e 80 7b 6a cf 01 35 c0 890 00c0 a4 16 06 2b a0 4c cc 64 cb 91 70 a0 e8 c6 5a 1b 891 00d0 d0 99 a5 f9 5e 65 36 7f 12 02 0a 07 04 49 94 85 892 00e0 ef 59 d2 b0 8c c6 7b 18 10 72 4f e7 dd 30 36 69 893 00f0 ef 39 31 eb 85 19 e3 e0 89 9b df 0d 46 37 6e 83 894 0100 1a 2f 97 c1 e1 b1 c2 01 5e 78 42 1c 44 60 6a 6a 895 0110 74 53 f7 fc 1e 8e 56 f1 e0 31 60 b6 75 5d c2 06 896 0120 98 1e e6 56 49 ef a2 56 8d f4 4a a5 12 66 27 fa 897 0130 a1 de c4 62 4f 96 95 85 99 1e 0d 2a 15 40 01 31 898 0140 3a 07 56 bd cf 93 c2 9a 83 a0 5b da 74 56 a8 9c 899 0150 48 9e 82 74 01 ca 69 ae c9 65 2f ac a8 d4 03 c7 900 0160 9e c7 f1 0e 91 f6 58 79 d9 75 e6 25 55 5f 89 cc 901 0170 41 a7 62 bb 0b e5 af 86 de 39 b7 af 05 1b a7 f5 902 0180 b1 75 ae 58 34 58 73 a8 94 98 ec 59 6f 30 c3 bc 903 0190 8a 05 53 4a 40 5c 44 93 74 c3 96 bd 72 88 f1 95 904 01a0 1a 60 1a 19 ef f6 27 49 24 da b1 e8 96 f3 ab 02 905 01b0 03 01 00 01 a3 3d 30 3b 30 0e 06 03 55 1d 0f 01 906 01c0 01 01 04 04 03 02 00 04 30 0f 06 03 55 1d 13 01 907 01d0 01 01 04 05 30 03 01 01 01 30 18 06 03 55 1d 20 908 01e0 04 11 30 0f 30 0d 06 0b 2b 06 01 04 01 82 94 4d 909 01f0 85 1a 01 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 910 0200 03 82 01 01 00 67 0d 89 a4 17 77 28 88 f5 8e 5e 911 0210 3e cf 97 11 87 4a 89 66 2f 99 29 d1 21 f6 d4 66 912 0220 e4 16 69 0a 4f 72 3e 5c 1f 33 1e f7 50 94 66 2a 913 0230 46 0c d2 58 5f 0a 96 84 85 2d 40 00 06 9a da ea 914 0240 64 66 b8 17 d6 21 d1 c3 c5 00 70 57 3c 75 ca 19 915 0250 e3 35 84 cb 40 47 b3 2f f6 41 ee e0 31 48 85 bf 916 0260 36 d8 ed 27 e0 37 41 22 2b 7c 14 d6 ac e6 df f9 917 0270 09 b3 3a 72 b0 e9 58 1e 61 8c 0b 03 df b5 3e 19 918 0280 91 af 4c 99 9a 83 4e 7d 55 68 e7 8e ff 74 35 c7 919 0290 c2 43 a6 09 e8 00 39 54 a9 e6 ad 5e bd e5 59 cb 920 02a0 75 23 da 37 d5 52 e5 13 7a 85 e2 6a 53 db 5c 6e 921 02b0 a3 e4 00 43 f7 32 e2 6d 77 54 31 07 c4 37 e1 ff 922 02c0 5e d6 44 d8 5f 17 3f 74 12 4a d5 14 34 17 89 dc 923 02d0 25 ce 0d 6c 9c da 92 f1 6a f9 07 1b cc 4a a4 84 924 02e0 33 22 5e f8 c3 57 42 49 b7 e1 a4 15 9a ec 44 48 925 02f0 ba 22 04 18 e0 34 07 3e fe b9 38 8b db af 7b 96 926 0300 df 6f 5d 77 e8 928 The SHA-256 digest of the certificate data is: 930 17cc980f6a84fb15e5da3f32afea62360f4ca29627feed68739a13062defe804 932 Appendix C. ASN.1 Values (Non-Normative) 934 Although the Object Digest Identifier form employs ASN.1 DER encoding 935 only a small subset of ASN.1 features are used and a full ASN.1 stack 936 is not necessary. 938 This appendix provides sufficient information to implement an Object 939 Digest Identifier constructor or parser. 941 C.1. DER Sequence Encoding 943 In DER encoding, the enclosing SEQUENCE will always be represented by 944 the type identifier x30 followed by the length specifier. Since the 945 total length of the following data fields will almost certainly be 946 less than 127 bytes, the single byte encoding mechanism in which bit 947 7 is clear and the length value is encoded in the lower 7 bits will 948 be required. 950 C.2. Object Identifiers for Certificate Types 952 OIDs have been defined in connection with the X.500 directory for 953 user certificates, certification authority certificates, revocations 954 of certification authority, and revocations of user certificates. 955 The following table lists the OIDs, their DER encoding, and their 956 type identifier and length-prefixed hex format for use in Object 957 Digest Identifiers. 959 id-at OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) ds(5) 4 } 961 id-at-userCertificate OBJECT IDENTIFIER ::= { id-at 36 } 962 -- 06 03 55 04 24 963 id-at-cACertificate OBJECT IDENTIFIER ::= { id-at 37 } 964 -- 06 03 55 04 25 965 TBS-PUBLIC-KEY-VALUE OBJECT IDENTIFIER ::= { ??? } 966 -- 06 xx xx xx xx 968 C.3. Object Identifiers for Digest Algorithms 970 OIDs have been assigned by NIST for the SHA-2 digest algorithms 971 [NIST-ALGS] [RFC4055] Use of the SHA-1 digest algorithm is not 972 recommended due to concerns for the security of the algorithm. 974 hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 975 country(16) us(840) organization(1) gov(101) csor(3) 976 nistAlgorithm(4) 2 } 978 id-sha256 OBJECT IDENTIFIER ::= { hashAlgs 1 } 979 -- 06 09 60 86 48 01 65 03 04 02 01 980 id-sha384 OBJECT IDENTIFIER ::= { hashAlgs 2 } 981 -- 06 09 60 86 48 01 65 03 04 02 02 982 id-sha512 OBJECT IDENTIFIER ::= { hashAlgs 3 } 983 -- 06 09 60 86 48 01 65 03 04 02 03 984 id-sha224 OBJECT IDENTIFIER ::= { hashAlgs 4 } 985 -- 06 09 60 86 48 01 65 03 04 02 04 987 C.4. DER Data Encoding Prefixes 989 The rules of ASN.1 encoding state that every data value is preceded 990 by a data type identifier and a length identifier. In the case of an 991 Object Digest Identifier the data type identifier is always OCTET 992 STRING (04) and the length for all currently defined digest 993 algorithms will be less than 128 bytes (1024 bits) and thus use the 994 single byte encoding form in which bit 7 is set to 0 and the lower 7 995 bits specify the length. 997 The length prefixes for commonly used digest lengths in hexadecimal 998 notation are thus: 1000 160 bits 04 14 1002 224 bits 04 1C 1004 256 bits 04 20 1006 384 bits 04 30 1008 512 bits 04 40 1010 Authors' Addresses 1012 Phillip Hallam-Baker 1013 Comodo Group Inc. 1015 Email: philliph@comodo.com 1017 Rob Stradling 1018 Comodo CA Ltd. 1020 Email: rob.stradling@comodo.com 1022 Ben Laurie 1023 Google Inc. 1025 Email: benl@google.com