idnits 2.17.1 draft-ietf-pkix-caa-11.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 16, 2012) is 4302 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 715, but not defined == Missing Reference: 'RFC-THIS' is mentioned on line 655, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'DANE' ** 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 (==), 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: Standards Track R. Stradling 5 Expires: January 17, 2013 Comodo CA Ltd. 6 July 16, 2012 8 DNS Certification Authority Authorization (CAA) Resource Record 9 draft-ietf-pkix-caa-11 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 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 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. Non-Compliance by Certification Authority . . . . . . . . 13 69 5.2. Mis-Issue by Authorized Certification Authority . . . . . 13 70 5.3. Suppression or spoofing of CAA records . . . . . . . . . . 13 71 5.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 72 5.5. Abuse of the Critical Flag . . . . . . . . . . . . . . . . 14 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Registration of the CAA Resource Record Type . . . . . . . 14 75 6.2. Certification Authority Authorization Properties . . . . . 15 76 6.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 15 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 7.2. Informative References . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Definitions 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 1.2. Defined Terms 92 The following terms are used in this document: 94 Authorization Entry: An authorization assertion that grants or 95 denies a specific set of permissions to a specific group of 96 entities. 98 Canonical Domain Name: A Domain Name that is not an alias. See 99 [RFC1035] and future successors for definition of CNAME alias 100 records. 102 Canonical Domain Name Value: The value of a Canonical Domain Name. 103 The value resulting from applying alias transformations to a 104 Domain Name that is not canonical. 106 Certificate: An X.509 Certificate, as specified in [RFC5280]. 108 Certificate Evaluator: A party other than a Relying Party that 109 evaluates the trustworthiness of certificates issued by 110 Certification Authorities. 112 Certification Authority (CA): An Issuer that issues Certificates in 113 accordance with a specified Certificate Policy. 115 Certificate Policy (CP): Specifies the criteria that a Certification 116 Authority undertakes to meet in its issue of certificates. See 117 [RFC3647]. 119 Certification Practices Statement (CPS): Specifies the means by 120 which the criteria of the Certificate Policy are met. In most 121 cases this will be the document against which the operations of 122 the Certification Authority are audited. See [RFC3647]. 124 Domain: The set of resources associated with a DNS Domain Name. 126 Domain Name: A DNS Domain name as specified in [RFC1035] and 127 revisions. 129 Domain Name System (DNS): The Internet naming system specified in 130 [RFC1035] and revisions. 132 DNS Security (DNSSEC): Extensions to the DNS that provide 133 authentication services as specified in [RFC4033]. and revisions. 135 Issuer: An entity that issues Certificates. See [RFC5280]. 137 Extended Issuer Authorization Set: The most specific Issuer 138 Authorization Set that is active for a domain. This is either the 139 Issuer Authorization Set for the domain itself, or if that is 140 empty, the Issuer Authorization Set for the corresponding Public 141 Delegation Point. 143 Issuer Authorization Set: The set of Authorization Entries for a 144 domain name that are flagged for use by Issuers. Analogous to an 145 Access Control List but with no ordering specified. 147 Property: The tag-value portion of a CAA Resource Record. 149 Property Tag: The tag portion of a CAA Resource Record. 151 Property Value: The value portion of a CAA Resource Record. 153 Public Delegation Point: The Domain Name suffix under which DNS 154 names are delegated by a public DNS registry such as a Top Level 155 Directory. 157 Public Key Infrastructure X.509 (PKIX): Standards and specifications 158 issued by the IETF that apply the [X.509] certificate standards 159 specified by the ITU to Internet applications as specified in 160 [RFC5280] and related documents. 162 Resource Record (RR): A set of attributes bound to a Domain Name as 163 defined in [RFC1035]. 165 Relying Party: A party that makes use of an application whose 166 operation depends on use of a Certificate for making a security 167 decision. See [RFC5280]. 169 Relying Application: An application whose operation depends on use 170 of a Certificate for making a security decision. 172 2. Introduction 174 The Certification Authority Authorization (CAA) DNS Resource Record 175 allows a DNS domain name holder to specify the Certification 176 Authorities authorized to issue certificates for that domain. 177 Publication of CAA resource records allow a public Certification 178 Authority (CA) to implement additional controls to reduce the risk of 179 unintended certificate mis-issue. 181 Like the TLSA record defined in DNS-Based Authentication of Named 182 Entities (DANE) [DANE], CAA records are used as a part of a mechanism 183 for checking PKIX certificate data. The distinction between the two 184 specifications is that CAA records specify a authorization control to 185 be performed by a certificate issuer before issue of a certificate 186 and TLSA records specify a verification control to be performed by a 187 Relying Party after the certificate is issued. 189 Conformance with a published CAA record is a necessary but not 190 sufficient condition for issueance of a certificate. Before issuing 191 a certificate, a PKIX CA is required to validate the request 192 according to the policies set out in its Certificate Policy. In the 193 case of a public CA that validates certificate requests as a third 194 party, the certificate will be typically issued under a public trust 195 anchor certificate embedded in one or more relevant Relying 196 Applications. 198 Criteria for inclusion of embedded trust anchor certificates in 199 applications are outside the scope of this document. Typically such 200 criteria require the CA to publish a Certificate Practices Statement 201 (CPS) that specifies how the requirements of the Certificate Policy 202 (CP) are achieved. It is also common for a CA to engage an 203 independent third party auditor to prepare an annual audit statement 204 of its performance against its CPS. 206 A set of CAA records describes only current grants of authority to 207 issue certificates for the corresponding DNS domain. Since a 208 certificate is typically valid for at least a year, it is possible 209 that a certificate that is not conformant with the CAA records 210 currently published was conformant with the CAA records published at 211 the time that the certificate was issued. Relying Applications MUST 212 NOT use CAA records as part of certificate validation. 214 CAA Records MAY be used by Certificate Evaluators as a possible 215 indicator of a security policy violation. Such use SHOULD take 216 account of the possibility that published CAA records changed between 217 the time a certificate was issued and the time at which the 218 certificate was observed by the Certificate Evaluator. 220 2.1. The CAA RR type 222 A CAA RR consists of a flags byte and a tag-value pair referred to as 223 a property. Multiple properties MAY be associated with the same 224 domain name by publishing multiple CAA RRs at that domain name. The 225 following flag is defined: 227 Issuer Critical: If set, indicates that the corresponding property 228 entry tag MUST be understood if the semantics of the CAA record 229 are to be correctly interpreted by an issuer. 231 Issuers MUST NOT issue certificates for a domain if the Extended 232 Issuer Authorization Set contains unknown property entry tags that 233 have the Critical bit set. 235 The following property tags are defined: 237 issue [; ]* : The issue property 238 entry authorizes the holder of the domain name or a party acting under the explicit authority of the holder 240 of that domain name to issue certificates for the domain in which 241 the property is published. 243 iodef : Specifies a URL to which an issuer MAY report 244 certificate issue requests that are inconsistent with the issuer's 245 Certification Practices or Certificate Policy, or that a 246 certificate evaluator may use to report observation of a possible 247 policy violation. The IODEF format is used [RFC5070]. 249 The following example informs CAs that certificates MUST NOT be 250 issued except by the holder of the domain name 'ca.example.net' or an 251 authorized agent thereof. Since the policy is published at the 252 Public Delegation Point, the policy applies to all subordinate 253 domains under example.com. 255 $ORIGIN example.com 256 . CAA 0 issue "ca.example.net" 258 If the domain name holder specifies one or more iodef properties, a 259 certificate issuer MAY report invalid certificate requests to that 260 address. In the following example the domain name holder specifies 261 that reports MAY be made by means of email with the IODEF data as an 262 attachment, a Web service [RFC6546] or both: 264 $ORIGIN example.com 265 . CAA 0 issue "ca.example.net" 266 . CAA 0 iodef "mailto:security@example.com" 267 . CAA 0 iodef "http://iodef.example.com/" 269 A certificate issuer MAY specify additional parameters that allow 270 customers to specify additional parameters governing certificate 271 issuance. This might be the Certificate Policy under which the 272 certificate is to be issued, the authentication process to be used 273 might be specified or an account number specified by the CA to enable 274 these parameters to be retrieved. 276 For example, the CA 'ca.example.net' has requested its customer 277 'example.com' to specify the CA's account number '230123' in each of 278 the customer's CAA records. 280 $ORIGIN example.com 281 . CAA 0 issue "ca.example.net; account=230123" 283 The syntax and semantics of such parameters is left to site policy 284 and is outside the scope of this document. 286 Future versions of this specification MAY use the critical flag to 287 introduce new semantics that MUST be understood for correct 288 processing of the record, preventing conforming CAs that do not 289 recognize the record from issuing certificates for the indicated 290 domains. 292 In the following example, the property 'tbs' is flagged as critical. 293 Neither the example.net CA, nor any other issuer is authorized to 294 issue under either policy unless the processing rules for the 'tbs' 295 property tag are understood. 297 $ORIGIN example.com 298 . CAA 0 issue "ca.example.net; policy=ev" 299 . CAA 128 tbs "Unknown" 301 Note that the above restrictions only apply to issue of certificates. 302 Since the validity of an end entity certificate is typically a year 303 or more, it is quite possible that the CAA records published at a 304 domain will change between the time a certificate was issued and 305 validation by a relying party. 307 3. Certification Authority Processing 309 Before issuing a certificate, a compliant CA MUST check for 310 publication of a relevant CAA Resource Record(s). If such record(s) 311 are published, the requested certificate MUST consistent with them if 312 it is to be issued. If the certificate requested is not consistent 313 with the relevant CAA RRs, the CA MUST NOT issue the certificate. 315 The Issuer Authorization Set for a domain name consists of the set of 316 all CAA Authorization Entries declared for the canonical form of the 317 specified domain. 319 The DNS defines the CNAME and DNAME mechanisms for specifying domain 320 name aliases. The canonical name of a DNS name is the name that 321 results from performing all DNS alias operations. An issuer MUST 322 perform CNAME and DNAME processing as defined in the DNS 323 specifications [RFC1035] to resolve CAA records. 325 The Extended Issuer Authorization Set for a domain name is determined 326 as follows: 328 o If the Issuer Authorization Set of the domain is not empty, the 329 Extended Issuer Authorization Set is the Issuer Authorization Set 330 of the domain. 332 o If the immediately superior node in the DNS hierarchy is a Public 333 Delegation Point, the Extended Issuer Authorization Set is empty. 335 o Otherwise the Extended Issuer Authorization Set is that of the 336 immediately superior node in the DNS hierarchy. 338 For example, if the zone example.com has a CAA record defined for 339 caa.example.com and no other domain in the zone, the Issuer 340 Authorization Set is empty for all domains other than 341 caa.example.com. The Extended Issuer Authorization Set is empty for 342 example.com (because .com is a Public Delegation Point) and for 343 x.example.com. The Extended Issuer set for x.caa.example.com, 344 x.x.caa.example.com, etc. is the Issuer Authorization Set for 345 caa.example.com. 347 If the Extended Issuer Authorization Set for a domain name is not 348 empty, a Certification Authority MUST NOT issue a certificate unless 349 the certificate conforms to at least one authorization entry in the 350 Extended Issuer Authorization Set. 352 3.1. Use of DNS Security 354 Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not 355 required. An issuer MUST NOT issue certificates if doing so would 356 conflict with the corresponding extended issuer authorization set, 357 irrespective of whether the corresponding DNS records are signed. 359 Use of DNSSEC allows an issuer to acquire and archive a non- 360 repudiable proof that they were authorized to issue certificates for 361 the domain. Verification of such archives MAY be an audit 362 requirement to verify CAA record processing compliance. Publication 363 of such archives MAY be a transparency requirement to verify CAA 364 record processing compliance. 366 3.2. Archive 368 A compliant issuer SHOULD maintain an archive of the DNS transactions 369 used to verify CAA eligibility. 371 In particular an issuer SHOULD ensure that where DNSSEC data is 372 available that the corresponding signature and NSEC/NSEC3 records are 373 preserved so as to enable later compliance audits. 375 4. Mechanism 377 4.1. Syntax 379 A CAA RR contains a single property entry consisting of a tag value 380 pair. Each tag represents a property of the CAA record. The value 381 of a CAA property is that specified in the corresponding value field. 383 A domain name MAY have multiple CAA RRs associated with it and a 384 given property MAY be specified more than once. 386 The CAA data field contains one property entry. A property entry 387 consists of the following data fields: 389 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 390 | Flags | Tag Length = n | 391 +----------------+----------------+...+---------------+ 392 | Tag char 0 | Tag Char 1 |...| Tag Char n-1 | 393 +----------------+----------------+...+---------------+ 394 +----------------+----------------+.....+----------------+ 395 | Value byte 0 | Value byte 1 |.....| Value byte m-1 | 396 +----------------+----------------+.....+----------------+ 398 Where n is the length specified in the Tag length field and m is the 399 remaining octets in the Value field (m = d - n - 2) where d is the 400 length of the RDATA section. 402 The data fields are defined as follows: 404 Flags: One octet containing the following fields: 406 Bit 0: Issuer Critical Flag If the value is set (1), the critical 407 flag is asserted and the property MUST be understood if the CAA 408 record is to be correctly processed by a certificate issuer. 410 A Certification Authority MUST NOT issue certificates for any 411 Domain that contains a CAA critical property for an unknown or 412 unsupported property tag that for which the issuer critical 413 flag is set. 415 Note that according to the conventions set out in RFC 1035 416 [RFC1035] Bit 0 is the Most Significant Bit and Bit 7 is the Least 417 Significant Bit. Thus the Flags value 1 means that bit 7 is set 418 while a value of 128 means that bit 0 is set according to this 419 convention. 421 All other bit positions are reserved for future use. 423 To ensure compatibility with future extensions to CAA, DNS records 424 compliant with this version of the CAA specification MUST clear 425 (set to "0") all reserved flags bits. Applications that interpret 426 CAA records MUST ignore the value of all reserved flag bits. 428 Tag Length: A single octet containing an unsigned integer specifying 429 the tag length in octets. The tag length MUST be at least 1 and 430 SHOULD be no more than 15. 432 Tag: The property identifier, a sequence of ASCII characters. 434 Tag values MAY contain ASCII characters 'a' through 'z', 'A' 435 through 'Z' and the numbers 0 through 9. Tag values SHOULD NOT 436 contain any other characters. Matching of tag values is case 437 insensitive. 439 Tag values submitted for registration by IANA MUST NOT contain any 440 characters other than the (lowercase) ASCII characters 'a' through 441 'z' and the numbers 0 through 9. 443 Value: A sequence of octets representing the property value. 444 Property values are encoded as binary values and MAY employ sub- 445 formats. 447 The length of the value field is specified implicitly as the 448 remaining length of the enclosing Resource Record data field. 450 4.1.1. Canonical Presentation Format 452 The canonical presentation format of the CAA record is as follows: 454 CAA 456 Where: 458 Flags: Is an unsigned integer between 0 and 255. 460 Tag: Is a non-zero sequence of ASCII letter and numbers in lower 461 case. 463 Value: Is the US-ASCII text Encoding of the value field 465 4.2. CAA issue Property 467 The issue property tag is used to request that certificate issuers 468 perform CAA issue restriction processing for the domain and to grant 469 authorization to specific certificate issuers. 471 The CAA issue property value has the following sub-syntax (specified 472 in ABNF as per [RFC5234]). 474 Property = space [domain] * (space ";" parameter) space 476 domain = label *("." label) 477 label = 1* (ALPHA / DIGIT / "-" ) 479 space = *(SP / HTAB) 481 parameter = / space tag "=" value 483 tag = 1* (ALPHA / DIGIT) 485 value = *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE 487 A CAA record with an issue parameter tag that does not specify a 488 domain name is a request that certificate issuers perform CAA issue 489 restriction processing for the corresponding domain without granting 490 authorization to any certificate issuer. 492 This form of issue restriction would be appropriate to specify that 493 no certificates are to be issued for the domain in question. 495 For example, the following CAA record set requests that no 496 certificates be issued for the domain 'nocerts.example.com' by any 497 certificate issuer. 499 nocerts.example.com CAA 0 issue ";" 501 A CAA record with an issue parameter tag that specifies a domain name 502 is a request that certificate issuers perform CAA issue restriction 503 processing for the corresponding domain and grants authorization to 504 the certificate issuer specified by the domain name. 506 For example, the following CAA record set requests that no 507 certificates be issued for the domain 'certs.example.com' by any 508 certificate issuer other than the example.net certificate issuer. 510 certs.example.com CAA 0 issue "example.net" 512 CAA authorizations are additive. thus the result of specifying both 513 the empty issuer and a specified issuer is the same as specifying 514 just the specified issuer alone. 516 An issuer MAY choose to specify issuer-parameters that further 517 constrain the issue of certificates by that issuer. For example 518 specifying that certificates are to be subject to specific validation 519 polices, billed to certain accounts or issued under specific trust 520 anchors. 522 The syntax and semantics of issuer-parameters are determined by the 523 issuer alone. 525 4.3. CAA iodef Property 527 The iodef property specifies a means of reporting certificate issue 528 requests or cases of certificate issue for the corresponding domain, 529 that violate the security policy of the issuer or the domain name 530 holder. 532 The Incident Object Description Exchange Format (IODEF) [RFC5070] is 533 used to present the incident report in machine readable form. 535 The iodef property takes a URL as its parameter. The URL scheme type 536 determines the method used for reporting: 538 mailto: The IODEF incident report is reported as a MIME email 539 attachment to an SMTP email that is submitted to the mail address 540 specified. The mail message sent SHOULD contain a brief text 541 message to alert the recipient to the nature of the attachment. 543 http or https: The IODEF report is submitted as a Web Service 544 request to the HTTP address specified using the protocol specified 545 in [RFC6546]. 547 5. Security Considerations 549 CAA Records assert a security policy that the holder of a domain name 550 wishes to be observed by certificate issuers. The effectiveness of 551 CAA records as an access control mechanism is thus dependent on 552 observance of CAA constraints by issuers. 554 The objective of the CAA record properties described in this document 555 is to reduce the risk of certificate mis-issue rather than avoid 556 reliance on a certificate that has ben mis-issued. DANE [DANE] 557 describes a mechanism for avoiding reliance on mis-issued 558 certificates. 560 5.1. Non-Compliance by Certification Authority 562 CAA records offer CAs a cost-effective means of mitigating the risk 563 of certificate mis-issue: The cost of implementing CAA checks is very 564 small and the potential costs of a mis-issue event include the 565 removal of an embedded trust anchor. 567 5.2. Mis-Issue by Authorized Certification Authority 569 Use of CAA records does not prevent mis-issue by an authorized 570 Certification Authority. , i.e., a CA that is authorized to issue 571 certificates for the domain in question by CAA records.. 573 Domain name holders SHOULD verify that the CAs they authorize to 574 issue certificates for their domains employ appropriate controls to 575 ensure that certificates are issued only to authorized parties within 576 their organization. 578 Such controls are most appropriately determined by the domain name 579 holder and the authorized CA(s) directly and are thus out of scope of 580 this document. 582 5.3. Suppression or spoofing of CAA records 584 Suppression of the CAA record or insertion of a bogus CAA record 585 could enable an attacker to obtain a certificate from a CA that was 586 not authorized to issue for that domain name. 588 A CA MUST mitigate this risk by employing DNSSEC verification 589 whenever possible and rejecting certificate requests in any case 590 where it is not possible to verify the non-existence or contents of a 591 relevant CAA record. 593 In cases where DNSSEC is not deployed in a corresponding domain, a CA 594 SHOULD attempt to mitigate this risk by employing appropriate DNS 595 security controls. For example all portions of the DNS lookup 596 process SHOULD be performed against the authoritative name server. 597 Data cached by third parties MUST NOT be relied on but MAY be used to 598 support additional anti-spoofing or anti-suppression controls. 600 5.4. Denial of Service 602 Introduction of a malformed or malicious CAA RR could in theory 603 enable a Denial of Service attack. 605 This specific threat is not considered to add significantly to the 606 risk of running an insecure DNS service. 608 An attacker could, in principle, perform a Denial of Service attack 609 against an issuer by requesting a certificate with a maliciously long 610 DNS name. In practice, the DNS protocol imposes a maximum name 611 length and CAA processing does not exacerbate the existing need to 612 mitigate Denial of Service attacks to any meaningful degree. 614 5.5. Abuse of the Critical Flag 616 A Certification Authority could make use of the critical flag to 617 trick customers into publishing records which prevent competing 618 Certification Authorities from issuing certificates even though the 619 customer intends to authorize multiple providers. 621 In practice, such an attack would be of minimal effect since any 622 competent competitor that found itself unable to issue certificates 623 due to lack of support for a property marked critical SHOULD 624 investigate the cause and report the reason to the customer who will 625 thus discover that they had been deceived. 627 6. IANA Considerations 629 6.1. Registration of the CAA Resource Record Type 631 [Note to IANA, the CAA resource record has already been assigned. On 632 issue of this draft as an RFC, the record should be updated to 633 reflect this document as the authoritative specification and this 634 paragraph (but not the following ones deleted] 636 IANA has assigned Resource Record Type 257 for the CAA Resource 637 Record Type and added the line depicted below to the registry named 638 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 [RFC6195] 639 and located at http://www.iana.org/assignments/dns-parameters. 641 RR Name Value and meaning Reference 642 ----------- --------------------------------------------- --------- 643 CAA 257 Certification Authority Restriction [RFC-THIS] 644 6.2. Certification Authority Authorization Properties 646 [Note to IANA, this is a new registry that needs to be created and 647 this paragraph but not the following ones deleted.] 649 IANA has created the Certification Authority Authorization Properties 650 registry with the following initial values: 652 Tag Meaning Reference 653 ----------- ----------------------------------------------- --------- 654 issue Authorization Entry by Domain [RFC-THIS] 655 iodef Report incident by means of IODEF format report [RFC-THIS] 656 auth Reserved 657 path Reserved 658 policy Reserved 660 Addition of tag identifiers requires a public specification and 661 expert review as set out in [RFC6195] 663 6.3. Acknowledgements 665 The authors would like to thank the following people who contributed 666 to the design and documentation of this work item: Chris Evans, 667 Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam 668 Langley, Ben Laurie, Chris Palmer, Scott Schmit, Sean Turner and Ben 669 Wilson. 671 7. References 673 7.1. Normative References 675 [DANE] P. Hoffman., J. Schlyter, "draft-ietf-dane-protocol-23: 676 Replace with reference to RFC before issue.", 2012. 678 [RFC1035] Mockapetris, P., "Domain names - implementation and 679 specification", STD 13, RFC 1035, November 1987. 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, March 1997. 684 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 685 Rose, "DNS Security Introduction and Requirements", 686 RFC 4033, March 2005. 688 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 689 Object Description Exchange Format", RFC 5070, 690 December 2007. 692 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 693 Specifications: ABNF", STD 68, RFC 5234, January 2008. 695 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 696 Housley, R., and W. Polk, "Internet X.509 Public Key 697 Infrastructure Certificate and Certificate Revocation List 698 (CRL) Profile", RFC 5280, May 2008. 700 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 701 Considerations", BCP 42, RFC 6195, March 2011. 703 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 704 Defense (RID) Messages over HTTP/TLS", RFC 6546, 705 April 2012. 707 [X.509] International Telecommunication Union, "ITU-T 708 Recommendation X.509 (11/2008): Information technology - 709 Open systems interconnection - The Directory: Public-key 710 and attribute certificate frameworks", ITU-T 711 Recommendation X.509, November 2008. 713 7.2. Informative References 715 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 716 Wu, "Internet X.509 Public Key Infrastructure Certificate 717 Policy and Certification Practices Framework", RFC 3647, 718 November 2003. 720 Authors' Addresses 722 Phillip Hallam-Baker 723 Comodo Group Inc. 725 Email: philliph@comodo.com 727 Rob Stradling 728 Comodo CA Ltd. 730 Email: rob.stradling@comodo.com