idnits 2.17.1 draft-ietf-pkix-caa-10.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 -- The document date (July 2, 2012) is 4314 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: 'RFC3647' is mentioned on line 710, but not defined == Missing Reference: 'RFC-THIS' is mentioned on line 653, but not defined ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) Summary: 2 errors (**), 0 flaws (~~), 3 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 3, 2013 Comodo CA Ltd. 6 July 2, 2012 8 DNS Certification Authority Authorization (CAA) Resource Record 9 draft-ietf-pkix-caa-10 11 Abstract 13 The Certification Authority Authorization (CAA) DNS Resource Record 14 allows a DNS domain name holder to specify one or more Certification 15 Authorities (CAs) authorized to issue certificates for that domain. 16 CAA resource records allow a public Certification Authority to 17 implement additional controls to reduce the risk of unintended 18 certificate mis-issue. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 3, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. The CAA RR type . . . . . . . . . . . . . . . . . . . . . 5 59 3. Certification Authority Processing . . . . . . . . . . . . . . 7 60 3.1. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8 61 3.2. Archive . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1.1. Canonical Presentation Format . . . . . . . . . . . . 10 65 4.2. CAA issue Property . . . . . . . . . . . . . . . . . . . . 11 66 4.3. CAA iodef Property . . . . . . . . . . . . . . . . . . . . 12 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 5.1. Mis-Issue by Authorized Certification Authority . . . . . 13 69 5.2. Suppression or spoofing of CAA records . . . . . . . . . . 13 70 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 71 5.4. Abuse of the Critical Flag . . . . . . . . . . . . . . . . 14 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 6.1. Registration of the CAA Resource Record Type . . . . . . . 14 74 6.2. Certification Authority Authorization Properties . . . . . 15 75 6.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 15 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 78 7.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Definitions 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 1.2. Defined Terms 91 The following terms are used in this document: 93 Authorization Entry: An authorization assertion that grants or 94 denies a specific set of permissions to a specific group of 95 entities. 97 Canonical Domain Name: A Domain Name that is not an alias. See 98 [RFC1035] and future successors for definition of CNAME alias 99 records. 101 Canonical Domain Name Value: The value of a Canonical Domain Name. 102 The value resulting from applying alias transformations to a 103 Domain Name that is not canonical. 105 Certificate: An X.509 Certificate, as specified in [RFC5280]. 107 Certificate Evaluator: A party other than a Relying Party that 108 evaluates the trustworthiness of certificates issued by 109 Certification Authorities. 111 Certification Authority (CA): An Issuer that issues Certificates in 112 accordance with a specified Certificate Policy. 114 Certificate Policy (CP): Specifies the criteria that a Certification 115 Authority undertakes to meet in its issue of certificates. See 116 [RFC3647]. 118 Certification Practices Statement (CPS): Specifies the means by 119 which the criteria of the Certificate Policy are met. In most 120 cases this will be the document against which the operations of 121 the Certification Authority are audited. See [RFC3647]. 123 Domain: The set of resources associated with a DNS Domain Name. 125 Domain Name: A DNS Domain name as specified in [RFC1035] and 126 revisions. 128 Domain Name System (DNS): The Internet naming system specified in 129 [RFC1035] and revisions. 131 DNS Security (DNSSEC): Extensions to the DNS that provide 132 authentication services as specified in [RFC4033]. and revisions. 134 Issuer: An entity that issues Certificates. See [RFC5280]. 136 Extended Issuer Authorization Set: The most specific Issuer 137 Authorization Set that is active for a domain. This is either the 138 Issuer Authorization Set for the domain itself, or if that is 139 empty, the Issuer Authorization Set for the corresponding Public 140 Delegation Point. 142 Issuer Authorization Set: The set of Authorization Entries for a 143 domain name that are flagged for use by Issuers. Analogous to an 144 Access Control List but with no ordering specified. 146 Property: The tag-value portion of a CAA Resource Record. 148 Property Tag: The tag portion of a CAA Resource Record. 150 Property Value: The value portion of a CAA Resource Record. 152 Public Delegation Point: The Domain Name suffix under which DNS 153 names are delegated by a public DNS registry such as a Top Level 154 Directory. 156 Public Key Infrastructure X.509 (PKIX): Standards and specifications 157 issued by the IETF that apply the [X.509] certificate standards 158 specified by the ITU to Internet applications as specified in 159 [RFC5280] and related documents. 161 Resource Record (RR): A set of attributes bound to a Domain Name as 162 defined in [RFC1035]. 164 Relying Party: A party that makes use of an application whose 165 operation depends on use of a Certificate for making a security 166 decision. See [RFC5280]. 168 Relying Application: An application whose operation depends on use 169 of a Certificate for making a security decision. 171 2. Introduction 173 The Certification Authority Authorization (CAA) DNS Resource Record 174 allows a DNS domain name holder to specify the Certification 175 Authorities authorized to issue certificates for that domain. 176 Publication of CAA resource records allow a public Certification 177 Authority (CA) to implement additional controls to reduce the risk of 178 unintended certificate mis-issue. 180 Conformance with a published CAA record is a necessary but not 181 sufficient condition for issueance of a certificate. Before issuing 182 a certificate, a PKIX CA is required to validate the request 183 according to the policies set out in its Certificate Policy 184 Statement. In the case of a public CA that validates certificate 185 requests as a third party, the certificate will be typically issued 186 under a public trust anchor certificate embedded in one or more 187 relevant Relying Applications. 189 Criteria for inclusion of embedded trust anchor certificates in 190 applications are outside the scope of this document. Typically such 191 criteria require the CA to publish a Certificate Practices Statement 192 (CPS) that specifies how the requirements of the Certificate Policy 193 (CP) are achieved. It is also common for a CA to engage an 194 independent third party auditor to prepare an annual audit statement 195 of its performance against its CPS. 197 A set of CAA records describes only current grants of authority to 198 issue certificates for the corresponding DNS domain. Since a 199 certificate is typically valid for at least a year, it is possible 200 that a certificate that is not conformant with the CAA records 201 currently published was conformant with the CAA records published at 202 the time that the certificate was issued. Relying Applications MUST 203 NOT use CAA records as part of certificate validation. 205 CAA Records MAY be used by Certificate Evaluators as a possible 206 indicator of a security policy violation. Such use SHOULD take 207 account of the possibility that published CAA records changed between 208 the time a certificate was issued and the time at which the 209 certificate was observed by the Certificate Evaluator. 211 2.1. The CAA RR type 213 A CAA RR consists of a flags byte and a tag-value pair referred to as 214 a property. Multiple properties MAY be associated with the same 215 domain name by publishing multiple CAA RRs at that domain name. The 216 following flag is defined: 218 Issuer Critical: If set, indicates that the corresponding property 219 entry tag MUST be understood if the semantics of the CAA record 220 are to be correctly interpreted by an issuer. 222 Issuers MUST NOT issue certificates for a domain if the Extended 223 Issuer Authorization Set contains unknown property entry tags that 224 have the Critical bit set. 226 The following property tags are defined: 228 issue [; ]* : The issue property 229 entry authorizes the holder of the domain name or a party acting under the express written authority of the 231 holder of that domain name to issue certificates for the domain in 232 which the property is published. 234 iodef : Specifies a URL to which an issuer MAY report 235 certificate issue requests that are inconsistent with the issuer's 236 Certification Practices or Certificate Policy, or that a 237 certificate evaluator may use to report observation of a possible 238 policy violation. The IODEF format is used [RFC5070]. 240 The following example informs CAs that certificates MUST NOT be 241 issued except by the holder of the domain name 'ca.example.net' or an 242 authorized agent thereof. Since the policy is published at the 243 Public Delegation Point, the policy applies to all subordinate 244 domains under example.com. 246 $ORIGIN example.com 247 . CAA 0 issue "ca.example.net" 249 If the domain name holder specifies one or more iodef properties, a 250 certificate issuer MAY report invalid certificate requests to that 251 address. In the following example the domain name holder specifies 252 that reports MAY be made by means of email with the IODEF data as an 253 attachment or a Web service or both: 255 $ORIGIN example.com 256 . CAA 0 issue "ca.example.net" 257 . CAA 0 iodef "mailto:security@example.com" 258 . CAA 0 iodef "http://iodef.example.com/" 260 A certificate issuer MAY specify additional parameters that allow 261 customers to specify additional parameters governing certificate 262 issuance. This might be the Certificate Policy under which the 263 certificate is to be issued, the authentication process to be used 264 might be specified or an account number specified by the CA to enable 265 these parameters to be retrieved. 267 For example, the CA 'ca.example.net' has requested its customer 268 'example.com' to specify the CA's account number '230123' in each of 269 the customer's CAA records. 271 $ORIGIN example.com 272 . CAA 0 issue "ca.example.net; account=230123" 274 The syntax and semantics of such parameters is left to site policy 275 and is outside the scope of this document. 277 Future versions of this specification MAY use the critical flag to 278 introduce new semantics that MUST be understood for correct 279 processing of the record, preventing conforming CAs that do not 280 recognize the record from issuing certificates for the indicated 281 domains. 283 In the following example, the property 'tbs' is flagged as critical. 284 Neither the example.net CA, nor any other issuer is authorized to 285 issue under either policy unless the processing rules for the 'tbs' 286 property tag are understood. 288 $ORIGIN example.com 289 . CAA 0 issue "ca.example.net; policy=ev" 290 . CAA 128 tbs "Unknown" 292 Note that the above restrictions only apply to issue of certificates. 293 Since the validity of an end entity certificate is typically a year 294 or more, it is quite possible that the CAA records published at a 295 domain will change between the time a certificate was issued and 296 validation by a relying party. 298 3. Certification Authority Processing 300 Before issuing a certificate, a compliant CA MUST check for 301 publication of a relevant CAA Resource Record(s). If such record(s) 302 are published, the requested certificate MUST consistent with them if 303 it is to be issued. If the certificate requested is not consistent 304 with the relevant CAA RRs, the CA MUST NOT issue the certificate. 306 The Issuer Authorization Set for a domain name consists of the set of 307 all CAA Authorization Entries declared for the canonical form of the 308 specified domain. 310 The DNS defines the CNAME and DNAME mechanisms for specifying domain 311 name aliases. The canonical name of a DNS name is the name that 312 results from performing all DNS alias operations. An issuer MUST 313 perform CNAME and DNAME processing as defined in the DNS 314 specifications [RFC1035] to resolve CAA records. 316 The Extended Issuer Authorization Set for a domain name is determined 317 as follows: 319 o If the Issuer Authorization Set of the domain is not empty, the 320 Extended Issuer Authorization Set is the Issuer Authorization Set 321 of the domain. 323 o If the immediately superior node in the DNS hierarchy is a Public 324 Delegation Point, the Extended Issuer Authorization Set is empty. 326 o Otherwise the Extended Issuer Authorization Set is that of the 327 immediately superior node in the DNS hierarchy. 329 For example, if the zone example.com has a CAA record defined for 330 caa.example.com and no other domain in the zone, the Issuer 331 Authorization Set is empty for all domains other than 332 caa.example.com. The Extended Issuer Authorization Set is empty for 333 example.com (because .com is a Public Delegation Point) and for 334 x.example.com. The Extended Issuer set for x.caa.example.com, 335 x.x.caa.example.com, etc. is the Issuer Authorization Set for 336 caa.example.com. 338 If the Extended Issuer Authorization Set for a domain name is not 339 empty, a Certification Authority MUST NOT issue a certificate unless 340 the certificate conforms to at least one authorization entry in the 341 Extended Issuer Authorization Set. 343 3.1. Use of DNS Security 345 Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not 346 required. An issuer MUST NOT issue certificates if doing so would 347 conflict with the corresponding extended issuer authorization set, 348 irrespective of whether the corresponding DNS records are signed. 350 Use of DNSSEC allows an issuer to acquire and archive a non- 351 repudiable proof that they were authorized to issue certificates for 352 the domain. Verification of such archives MAY be an audit 353 requirement to verify CAA record processing compliance. Publication 354 of such archives MAY be a transparency requirement to verify CAA 355 record processing compliance. 357 3.2. Archive 359 A compliant issuer SHOULD maintain an archive of the DNS transactions 360 used to verify CAA eligibility. 362 In particular an issuer SHOULD ensure that where DNSSEC data is 363 available that the corresponding signature and NSEC/NSEC3 records are 364 preserved so as to enable later compliance audits. 366 4. Mechanism 368 4.1. Syntax 370 A CAA RR contains a single property entry consisting of a tag value 371 pair. Each tag represents a property of the CAA record. The value 372 of a CAA property is that specified in the corresponding value field. 374 A domain name MAY have multiple CAA RRs associated with it and a 375 given property MAY be specified more than once. 377 The CAA data field contains one property entry. A property entry 378 consists of the following data fields: 380 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 381 | Flags | Tag Length = n | 382 +----------------+----------------+...+---------------+ 383 | Tag char 0 | Tag Char 1 |...| Tag Char n-1 | 384 +----------------+----------------+...+---------------+ 385 +----------------+----------------+.....+----------------+ 386 | Value byte 0 | Value byte 1 |.....| Value byte m-1 | 387 +----------------+----------------+.....+----------------+ 389 Where n is the length specified in the Tag length field and m is the 390 remaining octets in the Value field (m = d - n - 2) where d is the 391 length of the RDATA section. 393 The data fields are defined as follows: 395 Flags: One octet containing the following fields: 397 Bit 0: Issuer Critical Flag If the value is set (1), the critical 398 flag is asserted and the property MUST be understood if the CAA 399 record is to be correctly processed by a certificate issuer. 401 A Certification Authority MUST NOT issue certificates for any 402 Domain that contains a CAA critical property for an unknown or 403 unsupported property tag that for which the issuer critical 404 flag is set. 406 Note that according to the conventions set out in RFC 1035 407 [RFC1035] Bit 0 is the Most Significant Bit and Bit 7 is the Least 408 Significant Bit. Thus the Flags value 1 means that bit 7 is set 409 while a value of 128 means that bit 0 is set according to this 410 convention. 412 All other bit positions are reserved for future use. 414 To ensure compatibility with future extensions to CAA, DNS records 415 compliant with this version of the CAA specification MUST clear 416 (set to "0") all reserved flags bits. Applications that interpret 417 CAA records MUST ignore the value of all reserved flag bits. 419 Tag Length: A single octet containing an unsigned integer specifying 420 the tag length in octets. The tag length MUST be at least 1 and 421 SHOULD be no more than 15. 423 Tag: The property identifier, a sequence of ASCII characters. 425 Tag values MAY contain ASCII characters 'a' through 'z', 'A' 426 through 'Z' and the numbers 0 through 9. Tag values SHOULD NOT 427 contain any other characters. Matching of tag values is case 428 insensitive. 430 Tag values submitted for registration by IANA MUST NOT contain any 431 characters other than the (lowercase) ASCII characters 'a' through 432 'z' and the numbers 0 through 9. 434 Value: A sequence of octets representing the property value. 435 Property values are encoded as binary values and MAY employ sub- 436 formats. 438 The length of the value field is specified implicitly as the 439 remaining length of the enclosing Resource Record data field. 441 4.1.1. Canonical Presentation Format 443 The canonical presentation format of the CAA record is as follows: 445 CAA 447 Where: 449 Flags: Is an unsigned integer between 0 and 255. 451 Tag: Is a non-zero sequence of ASCII letter and numbers in lower 452 case. 454 Value: Is the US-ASCII text Encoding of the value field 456 4.2. CAA issue Property 458 The issue property tag is used to request that certificate issuers 459 perform CAA issue restriction processing for the domain and to grant 460 authorization to specific certificate issuers. 462 The CAA issue property value has the following sub-syntax (specified 463 in ABNF as per [RFC5234]). 465 Property = space [domain] * (space ";" parameter) space 467 domain = label *("." label) 468 label = 1* (ALPHA / DIGIT / "-" ) 470 space = *(SP / HTAB) 472 parameter = / space tag "=" value 474 tag = 1* (ALPHA / DIGIT) 476 value = *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE 478 A CAA record with an issue parameter tag that does not specify a 479 domain name is a request that certificate issuers perform CAA issue 480 restriction processing for the corresponding domain without granting 481 authorization to any certificate issuer. 483 This form of issue restriction would be appropriate to specify that 484 no certificates are to be issued for the domain in question. 486 For example, the following CAA record set requests that no 487 certificates be issued for the domain 'nocerts.example.com' by any 488 certificate issuer. 490 nocerts.example.com CAA 0 issue ";" 492 A CAA record with an issue parameter tag that specifies a domain name 493 is a request that certificate issuers perform CAA issue restriction 494 processing for the corresponding domain and grants authorization to 495 the certificate issuer specified by the domain name. 497 For example, the following CAA record set requests that no 498 certificates be issued for the domain 'certs.example.com' by any 499 certificate issuer other than the example.net certificate issuer. 501 certs.example.com CAA 0 issue "example.net" 502 CAA authorizations are additive. thus the result of specifying both 503 the empty issuer and a specified issuer is the same as specifying 504 just the specified issuer alone. 506 An issuer MAY choose to specify issuer-parameters that further 507 constrain the issue of certificates by that issuer. For example 508 specifying that certificates are to be subject to specific validation 509 polices, billed to certain accounts or issued under specific trust 510 anchors. 512 The syntax and semantics of issuer-parameters are determined by the 513 issuer alone. 515 4.3. CAA iodef Property 517 The iodef property specifies a means of reporting certificate issue 518 requests or cases of certificate issue for the corresponding domain, 519 that violate the security policy of the issuer or the domain name 520 holder. 522 The Incident Object Description Exchange Format (IODEF) [RFC5070] is 523 used to present the incident report in machine readable form. 525 The iodef property takes a URL as its parameter. The URL scheme type 526 determines the method used for reporting: 528 mailto: The IODEF incident report is reported as a MIME email 529 attachment to an SMTP email that is submitted to the mail address 530 specified. The mail message sent SHOULD contain a brief text 531 message to alert the recipient to the nature of the attachment. 533 http or https: The IODEF report is submitted as a Web Service 534 request to the HTTP address specified using the protocol specified 535 in [RFC6546]. 537 5. Security Considerations 539 CAA Records assert a security policy that the holder of a domain name 540 wishes to be observed by certificate issuers. The effectiveness of 541 CAA records as an access control mechanism is thus dependent on 542 observance of CAA constraints by issuers. 544 Observance of CAA records by issuers is subject to accountability 545 controls. 547 While a Certification Authority can choose to ignore published CAA 548 records, doing so increases both the probability that they will mis- 549 issue a certificate and the consequences of doing so. Once it is 550 known that a CA observes CAA records, malicious registration requests 551 may disproportionately target the (negligent) CAs that do not, and so 552 the mis-issue rate amongst the negligent CAs will likely increase. 553 Since a CA could have avoided the mis-issue by performing CAA 554 processing, the likelihood of sanctions against a negligent CA is 555 increased. Failure to observe CAA issue restrictions provides an 556 objective criteria for excluding issuers from embedded trust anchors. 558 In the case that a mis-issue event occurs for a domain that does not 559 have CAA records published, a conformant CA may be able to claim that 560 the incident could have been avoided had the domain name owner 561 published appropriate records. 563 5.1. Mis-Issue by Authorized Certification Authority 565 Use of CAA records does not prevent mis-issue by an authorized 566 Certification Authority. , i.e., a CA that is authorized to issue 567 certificates for the domain in question by CAA records.. 569 Domain name holders SHOULD verify that the CAs they authorize to 570 issue certificates for their domains employ appropriate controls to 571 ensure that certificates are issued only to authorized parties within 572 their organization. 574 Such controls are most appropriately determined by the domain name 575 holder and the authorized CA(s) directly and are thus out of scope of 576 this document. 578 5.2. Suppression or spoofing of CAA records 580 Suppression of the CAA record or insertion of a bogus CAA record 581 could enable an attacker to obtain a certificate from a CA that was 582 not authorized to issue for that domain name. 584 A CA MUST mitigate this risk by employing DNSSEC verification 585 whenever possible and rejecting certificate requests in any case 586 where it is not possible to verify the non-existence or contents of a 587 relevant CAA record. 589 In cases where DNSSEC is not deployed in a corresponding domain, a CA 590 SHOULD attempt to mitigate this risk by employing appropriate DNS 591 security controls. For example all portions of the DNS lookup 592 process SHOULD be performed against the authoritative name server. 593 Data cached by third parties MUST NOT be relied on but MAY be used to 594 support additional anti-spoofing or anti-suppression controls. 596 5.3. Denial of Service 598 Introduction of a malformed or malicious CAA RR could in theory 599 enable a Denial of Service attack. 601 This specific threat is not considered to add significantly to the 602 risk of running an insecure DNS service. 604 An attacker could, in principle, perform a Denial of Service attack 605 against an issuer by requesting a certificate with a maliciously long 606 DNS name. In practice, the DNS protocol imposes a maximum name 607 length and CAA processing does not exacerbate the existing need to 608 mitigate Denial of Service attacks to any meaningful degree. 610 5.4. Abuse of the Critical Flag 612 A Certification Authority could make use of the critical flag to 613 trick customers into publishing records which prevent competing 614 Certification Authorities from issuing certificates even though the 615 customer intends to authorize multiple providers. 617 In practice, such an attack would be of minimal effect since any 618 competent competitor that found itself unable to issue certificates 619 due to lack of support for a property marked critical SHOULD 620 investigate the cause and report the reason to the customer who will 621 thus discover the deception. It is thus unlikely that the attack 622 would succeed and the attempt might lay the perpetrator open to civil 623 or criminal sanctions. 625 6. IANA Considerations 627 6.1. Registration of the CAA Resource Record Type 629 [Note to IANA, the CAA resource record has already been assigned. On 630 issue of this draft as an RFC, the record should be updated to 631 reflect this document as the authoritative specification and this 632 paragraph (but not the following ones deleted] 634 IANA has assigned Resource Record Type 257 for the CAA Resource 635 Record Type and added the line depicted below to the registry named 636 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 [RFC6195] 637 and located at http://www.iana.org/assignments/dns-parameters. 639 RR Name Value and meaning Reference 640 ----------- --------------------------------------------- --------- 641 CAA 257 Certification Authority Restriction [RFC-THIS] 642 6.2. Certification Authority Authorization Properties 644 [Note to IANA, this is a new registry that needs to be created and 645 this paragraph but not the following ones deleted.] 647 IANA has created the Certification Authority Authorization Properties 648 registry with the following initial values: 650 Tag Meaning Reference 651 ----------- ----------------------------------------------- --------- 652 issue Authorization Entry by Domain [RFC-THIS] 653 iodef Report incident by means of IODEF format report [RFC-THIS] 654 auth Reserved 655 path Reserved 656 policy Reserved 658 Addition of tag identifiers requires a public specification and 659 expert review as set out in [RFC6195] 661 6.3. Acknowledgements 663 The authors would like to thank the following people who contributed 664 to the design and documentation of this work item: Chris Evans, 665 Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam 666 Langley, Ben Laurie, Chris Palmer, Scott Schmit, Sean Turner and Ben 667 Wilson. 669 7. References 671 7.1. Normative References 673 [RFC1035] Mockapetris, P., "Domain names - implementation and 674 specification", STD 13, RFC 1035, November 1987. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, March 1997. 679 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 680 Rose, "DNS Security Introduction and Requirements", 681 RFC 4033, March 2005. 683 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 684 Object Description Exchange Format", RFC 5070, 685 December 2007. 687 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 688 Specifications: ABNF", STD 68, RFC 5234, January 2008. 690 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 691 Housley, R., and W. Polk, "Internet X.509 Public Key 692 Infrastructure Certificate and Certificate Revocation List 693 (CRL) Profile", RFC 5280, May 2008. 695 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 696 Considerations", BCP 42, RFC 6195, March 2011. 698 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 699 Defense (RID) Messages over HTTP/TLS", RFC 6546, 700 April 2012. 702 [X.509] International Telecommunication Union, "ITU-T 703 Recommendation X.509 (11/2008): Information technology - 704 Open systems interconnection - The Directory: Public-key 705 and attribute certificate frameworks", ITU-T 706 Recommendation X.509, November 2008. 708 7.2. Informative References 710 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 711 Wu, "Internet X.509 Public Key Infrastructure Certificate 712 Policy and Certification Practices Framework", RFC 3647, 713 November 2003. 715 Authors' Addresses 717 Phillip Hallam-Baker 718 Comodo Group Inc. 720 Email: philliph@comodo.com 722 Rob Stradling 723 Comodo CA Ltd. 725 Email: rob.stradling@comodo.com