idnits 2.17.1 draft-ietf-pkix-caa-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 829 has weird spacing: '...2 01 eb a0 03...' == Line 850 has weird spacing: '...a 69 ae c9 65...' -- The document date (July 7, 2011) is 4674 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4648' is mentioned on line 733, but not defined == Missing Reference: 'RFC3642' is mentioned on line 730, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 672, but not defined == Missing Reference: 'NIST-ALGS' is mentioned on line 922, but not defined ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: Standards Track R. Stradling 5 Expires: January 8, 2012 Comodo CA Ltd. 6 B. Laurie 7 Google Inc. 8 July 7, 2011 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-ietf-pkix-caa-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. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 8, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. The CAA RR type . . . . . . . . . . . . . . . . . . . . . 5 61 2.1.1. Examples of Use. . . . . . . . . . . . . . . . . . . . 7 62 2.2. Certification Authority Processing . . . . . . . . . . . . 8 63 2.2.1. Canonical Domain Name . . . . . . . . . . . . . . . . 8 64 2.2.2. Use of DNS Security . . . . . . . . . . . . . . . . . 9 65 2.2.3. Archive . . . . . . . . . . . . . . . . . . . . . . . 9 66 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1.1. Canonical Presentation Format . . . . . . . . . . . . 11 69 3.1.1.1. Policy OID Encoding Options . . . . . . . . . . . 11 70 3.1.2. policy Property value . . . . . . . . . . . . . . . . 11 71 3.1.3. path Property value . . . . . . . . . . . . . . . . . 12 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 4.1. Mis-Issue by Authorized Certification Authority . . . . . 13 74 4.2. Suppression or spoofing of CAA records . . . . . . . . . . 13 75 4.2.1. Applications . . . . . . . . . . . . . . . . . . . . . 13 76 4.2.2. Certification Authorities . . . . . . . . . . . . . . 13 77 4.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 78 4.4. Abuse of the Critical Flag . . . . . . . . . . . . . . . . 14 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 5.1. Registration of the CAA Resource Record Type . . . . . . . 14 81 5.2. Certification Authority Authorization Properties . . . . . 15 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 6.2. Non Normative References . . . . . . . . . . . . . . . . . 16 85 Appendix A. Object Digest Identifier Calculation . . . . . . . . 16 86 A.1. Example: CA Certificate A . . . . . . . . . . . . . . . . 17 87 A.2. Example: CA Certificate A . . . . . . . . . . . . . . . . 17 88 Appendix B. Example Certificates . . . . . . . . . . . . . . . . 18 89 B.1. CA Certificate A . . . . . . . . . . . . . . . . . . . . . 18 90 Appendix C. ASN.1 Values (Non-Normative) . . . . . . . . . . . . 19 91 C.1. DER Sequence Encoding . . . . . . . . . . . . . . . . . . 20 92 C.2. Object Identifiers for Certificate Types . . . . . . . . . 20 93 C.3. Object Identifiers for Digest Algorithms . . . . . . . . . 20 94 C.4. DER Data Encoding Prefixes . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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 1.2. Defined Terms 107 The following terms are used in this document: 109 Abstract Syntax Notation One (ASN.1) A notation for describing 110 abstract types and values, as specified in X.680 [X.680]. 112 Authorization Entry An authorization assertion that grants or denies 113 a specific set of permissions to a specific group of entities. 115 Canonical Domain Name A Domain Name that is not an alias. 117 Canonical Domain Name Value The value of a Canonical Domain Name. 118 The value resulting from applying alias transformations to a 119 Domain Name that is not canonical. 121 Certificate An X.509 Certificate, as specified in RFC 5280 122 [RFC5280]. 124 Certification Policy (CP) Specifies the criteria that a 125 Certification Authority undertakes to meet in its issue of 126 certificates. 128 Certification Practices Statement (CPS) Specifies the means by which 129 the criteria of the Certification Policy are met. In most cases 130 this will be the document against which the operations of the 131 Certification Authority are audited. 133 Certification Authority (CA) An entity that issues Certificates in 134 accordance with a specified Certification Policy. 136 Distinguished Encoding Rules (DER) A set of rules for encoding ASN.1 137 objects, as specified in X.690 [X.690]. 139 Domain The set of resources associated with a DNS Domain Name. 141 Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and 142 revisions. 144 Domain Name System (DNS) The Internet naming system specified in RFC 145 1035 [RFC1035] and revisions. 147 DNS Security (DNSSEC) Extensions to the DNS that provide 148 authentication services as specified in RFC 4033 [RFC4033] and 149 revisions. 151 Extended Issuer Authorization Set The most specific Issuer 152 Authorization Set that is active for a domain. This is either the 153 Issuer Authorization Set for the domain itself, or if that is 154 empty, the Issuer Authorization Set for the corresponding Public 155 Delegation Point. 157 Issuer Authorization Set The set of Authorization Entries for a 158 domain name that are flagged for use by Issuers. Analogous to an 159 Access Control List but with no ordering specified. 161 Public Delegation Point A Domain Name that is obtained from a public 162 DNS registry as defined by a Certification Policy. 164 Public Key Infrastructure X.509 (PKIX) Standards and specifications 165 issued by the IETF that apply the X.509 [X.509] certificate 166 standards specified by the ITU to Internet applications as 167 specified in RFC 5280 [RFC5280] and related documents. 169 Resource Record (RR) A set of attributes bound to a Domain Name. 171 Relying Party A party that makes use of an application whose 172 operation depends on use of a Certificate for making a security 173 decision. 175 Relying Application An application whose operation depends on use of 176 a Certificate for making a security decision. 178 Relying Party Authorization Set The set of Authorization Entries for 179 a domain name that are flagged for use by Relying Party 180 Applications. Analogous to an Access Control List but with no 181 ordering specified. 183 2. Introduction 185 The Certification Authority Authorization (CAA) DNS Resource Record 186 allows a DNS domain name holder to specify the Certification 187 Authorities authorized to issue certificates for that domain. 188 Publication of CAA resource records allow a public Certification 189 Authority (CA) to implement additional controls to reduce the risk of 190 unintended certificate mis-issue. 192 Conformance with a published CAA record is a necessary but not 193 sufficient condition for issue of a certificate. Before issuing a 194 certificate, a PKIX CA is required to validate the request according 195 to the policies set out in its Certificate Policy Statement. In the 196 case of a public CA that validates certificate requests as a third 197 party, the certificate will be typically issued under a public root 198 certificate embedded in one or more relevant reliant applications. 200 Criteria for inclusion of embedded root certificates in applications 201 are outside the scope of this document but typically require the CA 202 to publish a Certificate Practices Statement (CPS) that specifies how 203 the requirements of the Certificate Policy (CP) are achieved and 204 provide an annual audit statement of their performance against their 205 CPS performed by an independent third party auditor. 207 It is the intention of the authors to propose the CAA record defined 208 in this document as the basis for CA validation requirements to be 209 proposed in organizations that publish validation requirements. 211 CAA records only describe the current state of Certification 212 Authority certificate issue authority. Since a certificate is 213 typically valid for at least a year, it is possible that a 214 certificate that is not conformant with the CAA records currently 215 published was conformant with the CAA records published at the time 216 that it was issued. Thus Relying Applications MUST NOT use failure 217 to conform to currently published CAA records as a rejection criteria 218 for certificates unless the published records are flagged as being 219 intended for that use. 221 2.1. The CAA RR type 223 A CAA RR publishes a CAA property entry that corresponds to the 224 specified domain name. Multiple property entries MAY be associated 225 with the same domain name by publiching multiple CAA RRs at that 226 domain name. Each property entry MAY be tagged with one or more of 227 the following flag values: 229 Critical If set, indicates that the corresponding property entry tag 230 MUST be understood if the semantics of the CAA record are to be 231 correctly understood by the specified audience. 233 Issuers MUST NOT issue certificates for a domain if the Extended 234 Issuer Authorization Set contains unknown property entry tags that 235 are flagged as critical. 237 Relying Parties MUST NOT attempt to enforce CAA records if the 238 Relying Party Authorization Set contains unknown property entry 239 tags that are flagged as critical 241 Must be Zero This bit is reserved for future use. 243 Issuers MUST NOT issue certificates for a domain if the Extended 244 Issuer Authorization Set contains property entries with the Must 245 Be Zero Tag Set. 247 Relying Parties MUST NOT attempt to enforce CAA records if the 248 Relying Party Authorization Set contains property entries with the 249 Must Be Zero Tag Set. 251 Relying Party This bit is reserved to specify that the corresponding 252 Property Entry MAY be used by Relying Party Applications. 254 Relying Parties MUST NOT attempt to enforce properties specified 255 in CAA records with the Relying Party bit set clear. 257 Issuer Specifies that the corresponding Property Entry is to be used 258 by Issuers and forms part of the Issuer Authorization Set for the 259 domain. 261 The following properties are defined: 263 policy The policy property entry declares 264 an authorization entry granting authorization to issue under the 265 specified Certificate Policy. 267 path The path property entry declares an 268 authorization entry granting authorization to issue end entity 269 certificates under a trust path that includes the specified 270 signing credential. 272 An Object Digest Identifier (ODI) is a means of specifying a 273 reference to an object instance by means of a cryptographic digest 274 function. A CAA path property may use an ODI to specify a 275 certificate trust path by means of: 277 A Certificate Signing Certificate 279 A Public Signing Key 281 In either case a path Authorization Entry authorizes an issuer to 282 issue an End Entity certificate to the corresponding domain if and 283 only if it is possible to form a valid certificate path to it from 284 the referenced certificate or key. 286 2.1.1. Examples of Use. 288 For convenience the examples are presented in the text format 289 suggested in section Section 3.1.1 291 The following example informs CAs that certificates must not be 292 issued except under the Default Deny Security 'Example 1' Certificate 293 Policy (1.3.6.1.4.1.35405.666.1). Since the policy is published at 294 the Public Delegation Point, the policy applies to all subordinate 295 domains under example.com. 297 $ORIGIN example.com 298 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 300 The following example informs CAs that certificates must not be 301 issued except under the Certificate Authority Root certificate 302 specified in Appendix B. 304 $ORIGIN example.com 305 . CAA 1 path MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe 306 XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA== 308 A domain MAY authorize multiple CAs to issue certificates at the same 309 time. The following example allows issue under the Default Deny 310 Security certification policy 'Example 1' or 'Example 2': 312 $ORIGIN example.com 313 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 314 . CAA 1 policy 1.3.6.1.4.1.35405.666.2 316 If Authorization Entries using the path and policy properties are 317 present at a given Domain, compatibility with either is sufficient to 318 authorize the request. 320 Future versions of this specification MAY use the critical flag to 321 introduce new semantics that MUST be understood for correct 322 processing of the record, preventing Certification Authorities that 323 do not recognize the record from issuing certificates. 325 In the following example, the property 'tbs' is flagged as critical. 326 The Default Deny Security CA is not authorized to issue under either 327 policy unless the processing rules for the 'tbs' property tag are 328 understood. 330 $ORIGIN example.com 331 . CAA 1 policy 1.3.6.1.4.1.35405.666.1 332 . CAA 1 policy 1.3.6.1.4.1.35405.666.2 333 . CAA 129 tbs MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe 334 XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA== 336 Note that the above restrictions only apply to issue of certificates. 337 Since the validity of an end entity certificate is typically a year 338 or more it is quite possible that the CAA records published at a 339 domain will change between the issue of the certificate and 340 verification by a relying party. 342 2.2. Certification Authority Processing 344 Before issue of a certificate, a compliant CA MUST check for 345 publication of a relevant CAA Resource Record(s) and if such 346 record(s) are published, that the certificate requested is consistent 347 with them. If the certificate requested is not consistent with the 348 relevant CAA RRs, the CA MUST NOT issue the certificate. 350 The Issuer Authorization Set for a domain name consists of the set of 351 all CAA Authorization Entries declared for the canonical form of the 352 specified domain. 354 The Extended Issuer Authorization Set for a domain name consists of 355 the Issuer Authorization Set for that domain name if it is non-empty. 356 Otherwise the Extended Issuer Authorization Set for a domain name 357 consists of the Issuer Authorization Set for the corresponding Public 358 Delegation Point for that domain name. 360 If the Extended Issuer Authorization Set for a domain name is not 361 empty, a Certification Authority MUST NOT issue a certificate unless 362 it conforms to at least one authorization entry in the Extended 363 Issuer Authorization Set. 365 Note that while it MUST be possible to form a certificate validation 366 path that contains at least one certificate that is so specified, it 367 MAY also be possible to form valid certificate paths that are not. 369 For example, a CA that has updated its root certificate to extend the 370 expiry date is entitled to issue certificates for domains where the 371 CAA record only specifies the older root certificate provided that 372 the older root certificate has not actually expired and it is thus 373 possible to form a valid certificate path. 375 2.2.1. Canonical Domain Name 377 The DNS defines the CNAME and DNAME mechanisms for specifying domain 378 name aliases. The canonical name of a DNS name is the name that 379 results from performing all DNS alias operations. 381 A Certification Authority MUST perform CNAME and DNAME processing as 382 defined in the DNS specifications 1035 [RFC1035]. 384 2.2.2. Use of DNS Security 386 Use of DNSSEC to authenticate CAA RRs is strongly recommended but not 387 required. A CA MUST NOT issue certificates if doing so would 388 conflict with the corresponding extended issuer authorization set 389 whether the corresponding DNS records are signed or not. 391 Use of DNSSEC allows a CA to acquire and archive a non-repudiable 392 proof that they were authorized to issue certificates for the domain. 394 2.2.3. Archive 396 A compliant CA SHOULD maintain an archive of the DNS transactions 397 used to verify CAA eligibility. 399 In particular a CA SHOULD ensure that where DNSSEC data is available 400 that the corresponding signature and NSEC/NSEC3 records are preserved 401 so as to enable later compliance audits. 403 3. Mechanism 405 3.1. Syntax 407 A CAA RR contains a single property entry consisting of a tag value 408 pair. Each tag represents a property of the CAA record. The value 409 of a CAA property is that specified in the corresponding value field. 411 A domain name MAY have multiple CAA RRs associated with it and a 412 given property MAY be specified more than once. 414 The CAA data field contains one property entry. A property entry 415 consists of the following data fields: 417 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 418 | Flags | Tag Length = n | 419 +----------------+----------------+...+---------------+ 420 | Tag char 0 | Tag Char 1 |...| Tag Char n-1 | 421 +----------------+----------------+...+---------------+ 422 +----------------+----------------+.....+---------------+ 423 | Data byte 0 | Data byte 1 |.....| Data byte m-1 | 424 +----------------+----------------+.....+---------------+ 426 Where n is the length specified in the tag length field and m is the 427 remaining octets in the data field (m = d - n - 2) where d is the 428 length of the data section. 430 The data fields are defined as follows: 432 Flags One octet containing the following fields: 434 Bit 0: Critical Flag If the value is set (1), the critical flag 435 is asserted and the property MUST be understood if the CAA 436 record is to be correctly processed. 438 A Certification Authority MUST NOT issue certificates for any 439 Domain that contains a CAA critical property for an unknown or 440 unsupported property type. 442 Bit 5: Must Be Zero Bit 5 is reserved and MUST be set to zero. 443 Processors that encounter a CAA record containing a property 444 with this bit set MUST treat the record set as if the critical 445 property was asserted for an unknown record. 447 Bit 6: Relying Application Use If set, the property entry 448 contains an Authorization Entry that forms part of the Relying 449 Application Authorization Set for the corresponding domain. 451 Bit 7: Issuer Use If set, the property entry contains an 452 Authorization Entry that forms part of the Issuer Application 453 Authorization Set for the corresponding domain. 455 Note that according to the conventions set out in RFC 1035 456 [RFC1035] Bit 0 is the Most Significant Bit and Bit 7 is the Least 457 Significant. Thus a flags value of 0x51 indicates a tag length of 458 5 octets and that the property entry is not critical and is not to 459 be used for relying party processing. 461 Tag Length A single octet containing an unsigned integer specifying 462 the tag length in octets. The tag length MUST be at least 1 and 463 SHOULD be no more than 15. 465 Tag The property identifier, a sequence of ASCII characters. 467 Tag values MAY contain ASCII characters a through z and the 468 numbers 0 through 9. Tag values MUST NOT contain any other 469 characters. Matching of tag values is case insensitive. 471 Value A sequence of octets representing the property value. 472 Property values are encoded as binary values and MAY employ sub- 473 formats. 475 The length of the value field is specified implicitly as the 476 remaining length of the enclosing Resource Record data field. 478 3.1.1. Canonical Presentation Format 480 The canonical presentation format of the CAA record is as follows: 482 CAA 484 Where: 486 flags Is an unsigned integer between 0 and 15. 488 tag Is a non-zero sequence of ASCII letter and numbers in lower 489 case. 491 data Is the Base64 Encoding [RFC4648] of the value field. 493 3.1.1.1. Policy OID Encoding Options 495 For convenience of administration, implementations MAY support ASN.1 496 Policy OID encoding at their option. 498 The Base64 encoding of data never contains the period character '.', 499 while the encoding of ASN.1 OID values specified in IETF GSER 500 encoding [RFC3642] will always incorporate at least one period 501 character. 503 It follows that a data decoder MAY unambiguously interpret data 504 specified in the Base64 or GSER format without the need for 505 additional disambiguation. 507 Implementations MAY choose to allow use of both formats in both file 508 and presentation formats. 510 3.1.2. policy Property value 512 The policy property value specifies an Authorization Entry by means 513 of an ASN.1 OID specifying a Certification Policy. A Certification 514 Authority is authorized to issue Certificates under a policy 515 Authorization Entry if and only if 517 The Certification Authority has the right to issue certificates 518 under the specified policy, AND 520 The certificate request is compliant with the requirements of the 521 specified policy, AND 522 The certificate request meets all the criteria under the 523 Certification Policy under which the certificate is to be issued. 525 Each policy property specifies a single ASN.1 OID value consisting of 526 the ASN.1 type, length specifier and OID data. 528 The policy property applies to the specified policy OID and all 529 policy OIDs that fall within the same OID arc. If the OID arc 530 1.3.6.1.4.1.35405.666 is specified, then the policy OIDs 531 1.3.6.1.4.1.35405.666, 1.3.6.1.4.1.35405.666.1, 532 1.3.6.1.4.1.35405.666.2 etc. are all authorized. 534 The Certificate that is issued MAY incorporate the specified policy 535 OID itself but is not required to provided that the issue of the 536 certificate is consistent with the requirements of the specified 537 policy. 539 For example, a CA that offers two levels of Certification Policy such 540 that the higher level of assurance included all the requirements of 541 the lower one MAY rely on a policy property specifying the lower 542 assurance policy as authorization for issue under the higher 543 assurance policy but not vice-versa. 545 3.1.3. path Property value 547 The path property value specifies an Authorization Entry by means of 548 a Certificate Signer Certificate or a Certificate Signing key. A 549 Certification Authority is authorized to issue Certificates under a 550 path Authorization Entry if and only if 552 A valid PKIX trust path can be formed from the specified 553 Certificate Signer Certificate or a Certificate Signing key to the 554 certificate that is to be issued, AND 556 The certificate request meets all the criteria under the 557 Certification Policy under which the certificate is to be issued. 559 4. Security Considerations 561 CAA Records provide an accountability control. They are intended to 562 deter rather than prevent undesired behavior. 564 While a Certification Authority can choose to ignore published CAA 565 records, doing so increases the both the probability that they will 566 mis-issue a certificate and the consequences of doing so. Once it is 567 known that a CA observes CAA records, malicious registration requests 568 will target disproportionately target the negligent CAs that do not, 569 and so the mis-issue rate amongst the negligent CAs will increase. 570 Since the CA could clearly have avoided the mis-issue by performing 571 CAA processing, the likelihood of sanctions against the negligent CA 572 is increased. Failure to observe CAA issue restrictions provides an 573 objective criteria for excluding issuers from embedded roots of 574 trust. 576 In contrast, a Certification Authority that processes CAA records 577 correctly can reasonably claim that any residual mis-issue event 578 could have been avoided had the Domain Name holder published 579 appropriate CAA records. 581 4.1. Mis-Issue by Authorized Certification Authority 583 Use of CAA records does not provide protection against mis-issue by 584 an authorized Certification Authority. 586 Domain name holders SHOULD ensure that the CAs they authorize to 587 issue certificates for their domains employ appropriate controls to 588 ensure that certificates are only issued to authorized parties within 589 their organization. 591 Such controls are most appropriately determined by the domain name 592 holder and the authorized CA(s) directly and are thus out of scope of 593 this document. 595 4.2. Suppression or spoofing of CAA records 597 Suppression of the CAA record or insertion of a bogus CAA record 598 could enable an attacker to obtain a certificate from a CA that was 599 not authorized to issue for that domain name. 601 4.2.1. Applications 603 Applications performing CAA checking SHOULD mitigate the risk of 604 suppresion or spoofing of CAA records by means of DNSSEC validation 605 where present. In cases where DNSSEC validation is not available, 606 CAA checking is of limited security value. 608 4.2.2. Certification Authorities 610 Since a certificate issued by a CA can be valid for several years, 611 the consequences of a spoofing or suppression attack are much greater 612 for Certification Authorities and so additional countermeasures are 613 justified. 615 A CA MUST mitigate this risk by employing DNSSEC verification 616 whenever possible and rejecting certificate requests in any case 617 where it is not possible to verify the non-existence or contents of a 618 relevant CAA record. 620 In cases where DNSSEC is not deployed in a corresponding domain, a CA 621 SHOULD attempt to mitigate this risk by employing appropriate DNS 622 security controls. For example all portions of the DNS lookup 623 process SHOULD be performed against the authoritative name server. 624 Cached data MUST NOT be relied on but MAY be used to support 625 additional anti-spoofing or anti-suppression controls. 627 4.3. Denial of Service 629 Introduction of a malformed or malicious CAA RR could in theory 630 enable a Denial of Service attack. 632 This specific threat is not considered to add significantly to the 633 risk of running an insecure DNS service. 635 4.4. Abuse of the Critical Flag 637 A Certification Authority could make use of the critical flag to 638 trick customers into publishing records which prevent competing 639 Certification Authorities from issuing certificates even though the 640 customer intends to authorize multiple providers. 642 In practice, such an attack would be of minimal effect since any 643 competent competitor that found itself unable to issue certificates 644 due to lack of support for a property marked critical is going to 645 investigate the cause and report the reason to the customer who was 646 deceived. It is thus unlikely that the attack would succeed and the 647 attempt might lay the perpetrator open to civil or criminal 648 sanctions. 650 5. IANA Considerations 652 5.1. Registration of the CAA Resource Record Type 654 IANA has assigned Resource Record Type TBD1 for the CAA Resource 655 Record Type and added the line depicted below to the registry named 656 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 657 [RFC5395] and located at 658 http://www.iana.org/assignments/dns-parameters. 660 Value and meaning Reference 661 ----------- --------------------------------------------- --------- 662 CAA TBD1 Certification Authority Restriction [RFCXXXX] 664 5.2. Certification Authority Authorization Properties 666 IANA has created the Certification Authority Authorization Properties 667 registry with the following initial values: 669 Meaning Reference 670 ----------- ----------------------------------------------- --------- 671 path Authorization Entry by Signature Path [RFCXXXX] 672 policy Authorization Entry by Certificate Policy [RFCXXXX] 674 Addition of tag identifiers requires a public specification and 675 expert review as set out in RFC5395 [RFC5395] 677 6. References 679 6.1. Normative References 681 [RFC1035] Mockapetris, P., "Domain names - implementation and 682 specification", STD 13, RFC 1035, November 1987. 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 688 Rose, "DNS Security Introduction and Requirements", 689 RFC 4033, March 2005. 691 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 692 Algorithms and Identifiers for RSA Cryptography for use in 693 the Internet X.509 Public Key Infrastructure Certificate 694 and Certificate Revocation List (CRL) Profile", RFC 4055, 695 June 2005. 697 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 698 Housley, R., and W. Polk, "Internet X.509 Public Key 699 Infrastructure Certificate and Certificate Revocation List 700 (CRL) Profile", RFC 5280, May 2008. 702 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 703 Considerations", RFC 5395, November 2008. 705 [X.509] International Telecommunication Union, "ITU-T 706 Recommendation X.509 (11/2008): Information technology - 707 Open systems interconnection - The Directory: Public-key 708 and attribute certificate frameworks", ITU-T 709 Recommendation X.509, November 2008. 711 [X.680] International Telecommunication Union, "ITU-T 712 Recommendation X.680 (11/2008): Information technology - 713 Abstract Syntax Notation One (ASN.1): Specification of 714 basic notation", ITU-T Recommendation X.680, 715 November 2008. 717 [X.690] International Telecommunication Union, "ITU-T 718 Recommendation X.690 (11/2008): Information technology - 719 Abstract Syntax Notation One (ASN.1): Specification of 720 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 721 and Distinguished Encoding Rules (DER)", ITU-T 722 Recommendation X.690, November 2008. 724 6.2. Non Normative References 726 [NIST-ALGS] 727 National Institute of Standards and Technology, 728 "Cryptographic Algorithm Registration", March 2009. 730 [RFC3642] Legg, S., "Common Elements of Generic String Encoding 731 Rules (GSER) Encodings", RFC 3642, October 2003. 733 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 734 Encodings", RFC 4648, October 2006. 736 Appendix A. Object Digest Identifier Calculation 738 An Object Digest is an ASN.1 structure with three components: 740 An ASN.1 Object Identifier specifying the object type of the 741 referenced object 743 An ASN.1 Object Identifier specifying the digest algorithm 745 An ASN.1 DER [X.690] encoded data field containing the digest 746 value of the referenced object processed using the specified 747 digest algorithm. 749 DNSCAA DEFINITIONS ::= 751 BEGIN 753 ObjectDigestIdentifier ::= SEQUENCE { 754 type OBJECT IDENTIFIER, 755 digestAlgorithm OBJECT IDENTIFIER, 756 digest OCTET STRING 757 } 759 END 761 The Object Digest Identifier construction is designed to facilitate 762 implementation in applications that already require ASN.1 handling 763 mechanisms (i.e. most cryptographic applications) without causing an 764 undue coding burden in cases where ASN.1 code is not already 765 supported. Appendix C provides all the necessary information to 766 create a fully compliant Object Digest Identifier implementation. 768 A.1. Example: CA Certificate A 770 The ODI of CA Certificate A (specified in Appendix B.1) is calculated 771 as follows: 773 ASN.1 Sequence tag: "3032" 775 ASN.1 OID id-at-cACertificate (2.5.4.37): "0603550425" 777 ASN.1 OID sha256 (2.16.840.1.101.3.4.2.1): 778 "0609608648016503040201" 780 SHA-256 Digest Value: "042017cc980f6a84fb15e5da3f32afea62360f4ca29 781 627feed68739a13062defe804" 783 The ODI in BASE64 format is MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP 784 zKv6mI2D0yilif+7WhzmhMGLe/oBA==. 786 A.2. Example: CA Certificate A 788 The ODI of the signing key of CA Certificate A (specified in Appendix 789 B.1) is calculated as follows: 791 ASN.1 Sequence tag 793 ASN.1 OID 'CA Signing Key' 795 ASN.1 OID 'SHA-256' 796 SHA-256 Digest Value 798 Appendix B. Example Certificates 800 The following certificates are used in the examples. 802 B.1. CA Certificate A 804 CA Certificate A is a self signed certificate signed with a 2048 bit 805 RSA key: 807 -----BEGIN CERTIFICATE----- 808 MIIDATCCAeugAwIBAgIBATALBgkqhkiG9w0BAQUwKDERMA8GA1UEChMIQWNtZSBJ 809 bmMxEzARBgNVBAMTCkV4YW1wbGUgQ0EwHhcNMTAxMTExMTgxMjAzWhcNMjAxMTA4 810 MTgxMjAzWjAoMREwDwYDVQQKEwhBY21lIEluYzETMBEGA1UEAxMKRXhhbXBsZSBD 811 QTCCAR8wCwYJKoZIhvcNAQEBA4IBDgAwggEJAoIBALHvos3yEe0ugR6Ae2rPATXA 812 pBYGK6BMzGTLkXCg6MZaG9CZpfleZTZ/EgIKBwRJlIXvWdKwjMZ7GBByT+fdMDZp 813 7zkx64UZ4+CJm98NRjdugxovl8HhscIBXnhCHERgamp0U/f8Ho5W8eAxYLZ1XcIG 814 mB7mVknvolaN9EqlEmYn+qHexGJPlpWFmR4NKhVAATE6B1a9z5PCmoOgW9p0Vqic 815 SJ6CdAHKaa7JZS+sqNQDx57H8Q6R9lh52XXmJVVficxBp2K7C+Wvht45t68FG6f1 816 sXWuWDRYc6iUmOxZbzDDvIoFU0pAXESTdMOWvXKI8ZUaYBoZ7/YnSSTaseiW86sC 817 AwEAAaM9MDswDgYDVR0PAQEBBAQDAgAEMA8GA1UdEwEBAQQFMAMBAQEwGAYDVR0g 818 BBEwDzANBgsrBgEEAYKUTYUaATALBgkqhkiG9w0BAQUDggEBAGcNiaQXdyiI9Y5e 819 Ps+XEYdKiWYvmSnRIfbUZuQWaQpPcj5cHzMe91CUZipGDNJYXwqWhIUtQAAGmtrq 820 ZGa4F9Yh0cPFAHBXPHXKGeM1hMtAR7Mv9kHu4DFIhb822O0n4DdBIit8FNas5t/5 821 CbM6crDpWB5hjAsD37U+GZGvTJmag059VWjnjv90NcfCQ6YJ6AA5VKnmrV695VnL 822 dSPaN9VS5RN6heJqU9tcbqPkAEP3MuJtd1QxB8Q34f9e1kTYXxc/dBJK1RQ0F4nc 823 Jc4NbJzakvFq+QcbzEqkhDMiXvjDV0JJt+GkFZrsREi6IgQY4DQHPv65OIvbr3uW 824 329dd+g= 825 -----END CERTIFICATE----- 827 In binary form, the certificate data is: 829 0000 30 82 03 01 30 82 01 eb a0 03 02 01 02 02 01 01 830 0010 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 28 31 831 0020 11 30 0f 06 03 55 04 0a 13 08 41 63 6d 65 20 49 832 0030 6e 63 31 13 30 11 06 03 55 04 03 13 0a 45 78 61 833 0040 6d 70 6c 65 20 43 41 30 1e 17 0d 31 30 31 31 31 834 0050 31 31 38 31 32 30 33 5a 17 0d 32 30 31 31 30 38 835 0060 31 38 31 32 30 33 5a 30 28 31 11 30 0f 06 03 55 836 0070 04 0a 13 08 41 63 6d 65 20 49 6e 63 31 13 30 11 837 0080 06 03 55 04 03 13 0a 45 78 61 6d 70 6c 65 20 43 838 0090 41 30 82 01 1f 30 0b 06 09 2a 86 48 86 f7 0d 01 839 00a0 01 01 03 82 01 0e 00 30 82 01 09 02 82 01 00 b1 840 00b0 ef a2 cd f2 11 ed 2e 81 1e 80 7b 6a cf 01 35 c0 841 00c0 a4 16 06 2b a0 4c cc 64 cb 91 70 a0 e8 c6 5a 1b 842 00d0 d0 99 a5 f9 5e 65 36 7f 12 02 0a 07 04 49 94 85 843 00e0 ef 59 d2 b0 8c c6 7b 18 10 72 4f e7 dd 30 36 69 844 00f0 ef 39 31 eb 85 19 e3 e0 89 9b df 0d 46 37 6e 83 845 0100 1a 2f 97 c1 e1 b1 c2 01 5e 78 42 1c 44 60 6a 6a 846 0110 74 53 f7 fc 1e 8e 56 f1 e0 31 60 b6 75 5d c2 06 847 0120 98 1e e6 56 49 ef a2 56 8d f4 4a a5 12 66 27 fa 848 0130 a1 de c4 62 4f 96 95 85 99 1e 0d 2a 15 40 01 31 849 0140 3a 07 56 bd cf 93 c2 9a 83 a0 5b da 74 56 a8 9c 850 0150 48 9e 82 74 01 ca 69 ae c9 65 2f ac a8 d4 03 c7 851 0160 9e c7 f1 0e 91 f6 58 79 d9 75 e6 25 55 5f 89 cc 852 0170 41 a7 62 bb 0b e5 af 86 de 39 b7 af 05 1b a7 f5 853 0180 b1 75 ae 58 34 58 73 a8 94 98 ec 59 6f 30 c3 bc 854 0190 8a 05 53 4a 40 5c 44 93 74 c3 96 bd 72 88 f1 95 855 01a0 1a 60 1a 19 ef f6 27 49 24 da b1 e8 96 f3 ab 02 856 01b0 03 01 00 01 a3 3d 30 3b 30 0e 06 03 55 1d 0f 01 857 01c0 01 01 04 04 03 02 00 04 30 0f 06 03 55 1d 13 01 858 01d0 01 01 04 05 30 03 01 01 01 30 18 06 03 55 1d 20 859 01e0 04 11 30 0f 30 0d 06 0b 2b 06 01 04 01 82 94 4d 860 01f0 85 1a 01 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 861 0200 03 82 01 01 00 67 0d 89 a4 17 77 28 88 f5 8e 5e 862 0210 3e cf 97 11 87 4a 89 66 2f 99 29 d1 21 f6 d4 66 863 0220 e4 16 69 0a 4f 72 3e 5c 1f 33 1e f7 50 94 66 2a 864 0230 46 0c d2 58 5f 0a 96 84 85 2d 40 00 06 9a da ea 865 0240 64 66 b8 17 d6 21 d1 c3 c5 00 70 57 3c 75 ca 19 866 0250 e3 35 84 cb 40 47 b3 2f f6 41 ee e0 31 48 85 bf 867 0260 36 d8 ed 27 e0 37 41 22 2b 7c 14 d6 ac e6 df f9 868 0270 09 b3 3a 72 b0 e9 58 1e 61 8c 0b 03 df b5 3e 19 869 0280 91 af 4c 99 9a 83 4e 7d 55 68 e7 8e ff 74 35 c7 870 0290 c2 43 a6 09 e8 00 39 54 a9 e6 ad 5e bd e5 59 cb 871 02a0 75 23 da 37 d5 52 e5 13 7a 85 e2 6a 53 db 5c 6e 872 02b0 a3 e4 00 43 f7 32 e2 6d 77 54 31 07 c4 37 e1 ff 873 02c0 5e d6 44 d8 5f 17 3f 74 12 4a d5 14 34 17 89 dc 874 02d0 25 ce 0d 6c 9c da 92 f1 6a f9 07 1b cc 4a a4 84 875 02e0 33 22 5e f8 c3 57 42 49 b7 e1 a4 15 9a ec 44 48 876 02f0 ba 22 04 18 e0 34 07 3e fe b9 38 8b db af 7b 96 877 0300 df 6f 5d 77 e8 879 The SHA-256 digest of the certificate data is: 881 17cc980f6a84fb15e5da3f32afea62360f4ca29627feed68739a13062defe804 883 Appendix C. ASN.1 Values (Non-Normative) 885 Although the Object Digest Identifier form employs ASN.1 DER encoding 886 only a small subset of ASN.1 features are used and a full ASN.1 stack 887 is not necessary. 889 This appendix provides sufficient information to implement an Object 890 Digest Identifier constructor or parser. 892 C.1. DER Sequence Encoding 894 In DER encoding, the enclosing SEQUENCE will always be represented by 895 the type identifier x30 followed by the length specifier. Since the 896 total length of the following data fields will almost certainly be 897 less than 127 bytes, the single byte encoding mechanism in which bit 898 7 is clear and the length value is encoded in the lower 7 bits will 899 be required. 901 C.2. Object Identifiers for Certificate Types 903 OIDs have been defined in connection with the X.500 directory for 904 user certificates, certification authority certificates, revocations 905 of certification authority, and revocations of user certificates. 906 The following table lists the OIDs, their DER encoding, and their 907 type identifier and length-prefixed hex format for use in Object 908 Digest Identifiers. 910 id-at OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) ds(5) 4 } 912 id-at-userCertificate OBJECT IDENTIFIER ::= { id-at 36 } 913 -- 06 03 55 04 24 914 id-at-cACertificate OBJECT IDENTIFIER ::= { id-at 37 } 915 -- 06 03 55 04 25 916 TBS-PUBLIC-KEY-VALUE OBJECT IDENTIFIER ::= { ??? } 917 -- 06 xx xx xx xx 919 C.3. Object Identifiers for Digest Algorithms 921 OIDs have been assigned by NIST for the SHA-2 digest algorithms 922 [NIST-ALGS] [RFC4055] Use of the SHA-1 digest algorithm is not 923 recommended due to concerns for the security of the algorithm. 925 hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 926 country(16) us(840) organization(1) gov(101) csor(3) 927 nistAlgorithm(4) 2 } 929 id-sha256 OBJECT IDENTIFIER ::= { hashAlgs 1 } 930 -- 06 09 60 86 48 01 65 03 04 02 01 931 id-sha384 OBJECT IDENTIFIER ::= { hashAlgs 2 } 932 -- 06 09 60 86 48 01 65 03 04 02 02 933 id-sha512 OBJECT IDENTIFIER ::= { hashAlgs 3 } 934 -- 06 09 60 86 48 01 65 03 04 02 03 935 id-sha224 OBJECT IDENTIFIER ::= { hashAlgs 4 } 936 -- 06 09 60 86 48 01 65 03 04 02 04 938 C.4. DER Data Encoding Prefixes 940 The rules of ASN.1 encoding state that every data value is preceded 941 by a data type identifier and a length identifier. In the case of an 942 Object Digest Identifier the data type identifier is always OCTET 943 STRING (04) and the length for all currently defined digest 944 algorithms will be less than 128 bytes (1024 bits) and thus use the 945 single byte encoding form in which bit 7 is set to 0 and the lower 7 946 bits specify the length. 948 The length prefixes for commonly used digest lengths in hexadecimal 949 notation are thus: 951 160 bits 04 14 953 224 bits 04 1C 955 256 bits 04 20 957 384 bits 04 30 959 512 bits 04 40 961 Authors' Addresses 963 Phillip Hallam-Baker 964 Comodo Group Inc. 966 Email: philliph@comodo.com 968 Rob Stradling 969 Comodo CA Ltd. 971 Email: rob.stradling@comodo.com 973 Ben Laurie 974 Google Inc. 976 Email: benl@google.com