idnits 2.17.1 draft-ietf-pkix-caa-07.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 (April 25, 2012) is 4376 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 702, but not defined == Missing Reference: 'RFC-THIS' is mentioned on line 644, but not defined == Unused Reference: 'RFC2045' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'RFC4055' is defined on line 669, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) ** Obsolete normative reference: RFC 6046 (Obsoleted by RFC 6546) Summary: 4 errors (**), 0 flaws (~~), 5 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: October 27, 2012 Comodo CA Ltd. 6 April 25, 2012 8 DNS Certification Authority Authorization (CAA) Resource Record 9 draft-ietf-pkix-caa-07 11 Abstract 13 The Certification Authority Authorization (CAA) DNS Resource Record 14 allows a DNS domain name holder to specify the certificate signing 15 certificate(s) authorized to issue certificates for that domain. CAA 16 resource records allow a public Certification Authority to implement 17 additional controls to reduce the risk of unintended certificate mis- 18 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 October 27, 2012. 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. Canonical Domain Name . . . . . . . . . . . . . . . . . . 8 61 3.2. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8 62 3.3. Archive . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.1.1. Canonical Presentation Format . . . . . . . . . . . . 10 66 4.2. CAA issue Property . . . . . . . . . . . . . . . . . . . . 10 67 4.3. CAA iodef Property . . . . . . . . . . . . . . . . . . . . 11 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 5.1. Mis-Issue by Authorized Certification Authority . . . . . 12 70 5.2. Suppression or spoofing of CAA records . . . . . . . . . . 13 71 5.2.1. Certification Authorities . . . . . . . . . . . . . . 13 72 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 13 73 5.3.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.4. Abuse of the Critical Flag . . . . . . . . . . . . . . . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 6.1. Registration of the CAA Resource Record Type . . . . . . . 14 77 6.2. Certification Authority Authorization Properties . . . . . 14 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 7.2. Non Normative References . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Definitions 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 1.2. Defined Terms 93 The following terms are used in this document: 95 Authorization Entry An authorization assertion that grants or denies 96 a specific set of permissions to a specific group of entities. 98 Canonical Domain Name A Domain Name that is not an alias. 100 Canonical Domain Name Value The value of a Canonical Domain Name. 101 The value resulting from applying alias transformations to a 102 Domain Name that is not canonical. 104 Certificate An X.509 Certificate, as specified in RFC 5280 105 [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 RFC 3647 [RFC3647]. 118 Certification Practices Statement (CPS) Specifies the means by which 119 the criteria of the Certificate Policy are met. In most cases 120 this will be the document against which the operations of the 121 Certification Authority are audited. See RFC 3647 [RFC3647] 123 Domain The set of resources associated with a DNS Domain Name. 125 Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and 126 revisions. 128 Domain Name System (DNS) The Internet naming system specified in RFC 129 1035 [RFC1035] and revisions. 131 DNS Security (DNSSEC) Extensions to the DNS that provide 132 authentication services as specified in RFC 4033 [RFC4033] and 133 revisions. 135 Issuer An entity that issues Certificates. 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 Public Delegation Point The Domain Name suffix under which DNS names 148 are delegated by a public DNS registry such as a Top Level 149 Directory. 151 Public Key Infrastructure X.509 (PKIX) Standards and specifications 152 issued by the IETF that apply the X.509 [X.509] certificate 153 standards specified by the ITU to Internet applications as 154 specified in RFC 5280 [RFC5280] and related documents. 156 Resource Record (RR) A set of attributes bound to a Domain Name. 158 Relying Party A party that makes use of an application whose 159 operation depends on use of a Certificate for making a security 160 decision. 162 Relying Application An application whose operation depends on use of 163 a Certificate for making a security decision. 165 2. Introduction 167 The Certification Authority Authorization (CAA) DNS Resource Record 168 allows a DNS domain name holder to specify the Certification 169 Authorities authorized to issue certificates for that domain. 170 Publication of CAA resource records allow a public Certification 171 Authority (CA) to implement additional controls to reduce the risk of 172 unintended certificate mis-issue. 174 Conformance with a published CAA record is a necessary but not 175 sufficient condition for issue of a certificate. Before issuing a 176 certificate, a PKIX CA is required to validate the request according 177 to the policies set out in its Certificate Policy Statement. In the 178 case of a public CA that validates certificate requests as a third 179 party, the certificate will be typically issued under a public root 180 certificate embedded in one or more relevant Relying Applications. 182 Criteria for inclusion of embedded root certificates in applications 183 are outside the scope of this document but typically require the CA 184 to publish a Certificate Practices Statement (CPS) that specifies how 185 the requirements of the Certificate Policy (CP) are achieved and 186 provide an annual audit statement of their performance against their 187 CPS performed by an independent third party auditor. 189 CAA records only describe the current state of Certification 190 Authority certificate issue authority. Since a certificate is 191 typically valid for at least a year, it is possible that a 192 certificate that is not conformant with the CAA records currently 193 published was conformant with the CAA records published at the time 194 that it was issued. Thus Relying Applications MUST NOT use failure 195 to conform to currently published CAA records specifying issue 196 authorization as a certificate validity criteria. 198 CAA Records MAY be used by Certificate Evaluators as a possible 199 indicator of a security policy violation. Such use SHOULD take 200 account of the possibility that the published CAA records changed 201 between the time the certificate was issued and the time that they 202 were observed by the Certificate Evaluator. 204 2.1. The CAA RR type 206 A CAA RR publishes a CAA property entry that corresponds to the 207 specified domain name. Multiple property entries MAY be associated 208 with the same domain name by publishing multiple CAA RRs at that 209 domain name. Each property entry MAY be tagged with one or more of 210 the following flag values: 212 Critical If set, indicates that the corresponding property entry tag 213 MUST be understood if the semantics of the CAA record are to be 214 correctly understood by the specified audience. 216 Issuers MUST NOT issue certificates for a domain if the Extended 217 Issuer Authorization Set contains unknown property entry tags that 218 have both the Issuer and Critical bits set. 220 The following properties are defined: 222 issue [; ]* The issue property entry 223 declares an authorization entry granting authorization to issue to 224 the holder of the specified domain name or a party acting under 225 the express written authority of the holder of the domain name. 227 iodef Specifies a URL to which an issuer MAY report 228 certificate issue requests that are inconsistent with the issuer's 229 Certification Practices or Certificate Policy or that a 230 certificate evaluator may use to report observation of a possible 231 policy violation. The IODEF format is used. [RFC5070] 233 The following example informs CAs that certificates MUST NOT be 234 issued except by the holder of the domain name 'ca.example.net' or an 235 authorized agent thereof. Since the policy is published at the 236 Public Delegation Point, the policy applies to all subordinate 237 domains under example.com. 239 $ORIGIN example.com 240 . CAA 0 issue "ca.example.net" 242 If the domain name holder specifies one or more iodef properties, a 243 certificate issuer MAY report invalid certificate requests to that 244 address. In the following example the domain name holder specifies 245 that reports MAY be made by means of email with the IODEF data as an 246 attachment or a Web service or both: 248 $ORIGIN example.com 249 . CAA 0 issue "ca.example.net" 250 . CAA 0 iodef "mailto:security@example.com" 251 . CAA 0 iodef "http://iodef.example.com/" 253 A certificate issuer MAY specify additional parameters that allow 254 customers to specify additional parameters governing certificate 255 issue. For example, the Certificate Policy under which the 256 certificate is to be issued or the authentication process to be used. 258 $ORIGIN example.com 259 . CAA 0 issue "ca.example.net; account=230123" 261 The syntax and semantics of such parameters is left to site policy 262 and is outside the scope of this document. 264 Future versions of this specification MAY use the critical flag to 265 introduce new semantics that MUST be understood for correct 266 processing of the record, preventing Certification Authorities that 267 do not recognize the record from issuing certificates. 269 In the following example, the property 'tbs' is flagged as critical. 271 Neither the example.net CA, nor any other issuer is authorized to 272 issue under either policy unless the processing rules for the 'tbs' 273 property tag are understood. 275 $ORIGIN example.com 276 . CAA 0 issue "ca.example.net; policy=ev" 277 . CAA 128 tbs "Unknown" 279 Note that the above restrictions only apply to issue of certificates. 280 Since the validity of an end entity certificate is typically a year 281 or more it is quite possible that the CAA records published at a 282 domain will change between the issue of the certificate and 283 verification by a relying party. 285 3. Certification Authority Processing 287 Before issue of a certificate, a compliant CA MUST check for 288 publication of a relevant CAA Resource Record(s) and if such 289 record(s) are published, that the certificate requested is consistent 290 with them. If the certificate requested is not consistent with the 291 relevant CAA RRs, the CA MUST NOT issue the certificate. 293 The Issuer Authorization Set for a domain name consists of the set of 294 all CAA Authorization Entries declared for the canonical form of the 295 specified domain. 297 The Extended Issuer Authorization Set for a domain name is determined 298 as follows: 300 o If the Issuer Authorization Set for the domain is empty, the 301 Extended Issuer Authorization Set is empty. 303 o If the immediately superior node in the DNS hierarchy is a Public 304 Delegation Point, the Extended Issuer Authorization Set is empty. 306 o Otherwise the Extended Issuer Authorization Set is that of the 307 immediately superior node in the DNS hierarchy. 309 For example, if the zone example.com has a CAA record defined for 310 caa.example.com and no other domain in the zone, the Issuer 311 Authorization Set is empty for all domains other than 312 caa.example.com. The Extended Issuer Authorization Set is empty for 313 example.com (because .com is a Public Delegation Point) and for 314 x.example.com. The Extended Issuer set for x.caa.example.com, 315 x.x.caa.example.com, etc. is the Issuer Authorization Set for 316 caa.example.com. 318 If the Extended Issuer Authorization Set for a domain name is not 319 empty, a Certification Authority MUST NOT issue a certificate unless 320 it conforms to at least one authorization entry in the Extended 321 Issuer Authorization Set. 323 3.1. Canonical Domain Name 325 The DNS defines the CNAME and DNAME mechanisms for specifying domain 326 name aliases. The canonical name of a DNS name is the name that 327 results from performing all DNS alias operations. 329 An issuer MUST perform CNAME and DNAME processing as defined in the 330 DNS specifications 1035 [RFC1035] to resolve CAA records. 332 3.2. Use of DNS Security 334 Use of DNSSEC to authenticate CAA RRs is strongly recommended but not 335 required. An issuer MUST NOT issue certificates if doing so would 336 conflict with the corresponding extended issuer authorization set 337 whether the corresponding DNS records are signed or not. 339 Use of DNSSEC allows an issuer to acquire and archive a non- 340 repudiable proof that they were authorized to issue certificates for 341 the domain. 343 3.3. Archive 345 A compliant issuer SHOULD maintain an archive of the DNS transactions 346 used to verify CAA eligibility. 348 In particular an issuer SHOULD ensure that where DNSSEC data is 349 available that the corresponding signature and NSEC/NSEC3 records are 350 preserved so as to enable later compliance audits. 352 4. Mechanism 354 4.1. Syntax 356 A CAA RR contains a single property entry consisting of a tag value 357 pair. Each tag represents a property of the CAA record. The value 358 of a CAA property is that specified in the corresponding value field. 360 A domain name MAY have multiple CAA RRs associated with it and a 361 given property MAY be specified more than once. 363 The CAA data field contains one property entry. A property entry 364 consists of the following data fields: 366 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 367 | Flags | Tag Length = n | 368 +----------------+----------------+...+---------------+ 369 | Tag char 0 | Tag Char 1 |...| Tag Char n-1 | 370 +----------------+----------------+...+---------------+ 371 +----------------+----------------+.....+---------------+ 372 | Data byte 0 | Data byte 1 |.....| Data byte m-1 | 373 +----------------+----------------+.....+---------------+ 375 Where n is the length specified in the tag length field and m is the 376 remaining octets in the data field (m = d - n - 2) where d is the 377 length of the data section. 379 The data fields are defined as follows: 381 Flags One octet containing the following fields: 383 Bit 0: Issuer Critical Flag If the value is set (1), the critical 384 flag is asserted and the property MUST be understood if the CAA 385 record is to be correctly processed by a certificate issuer. 387 A Certification Authority MUST NOT issue certificates for any 388 Domain that contains a CAA critical property for an unknown or 389 unsupported property type that has the issuer bit set. 391 Note that according to the conventions set out in RFC 1035 392 [RFC1035] Bit 0 is the Most Significant Bit and Bit 7 is the Least 393 Significant. Thus the flags value 1 means that bit 7 is set while 394 a value of 128 means that bit 0 is set according to this 395 convention. 397 All other bit positions are reserved for future use. 399 To ensure compatibility with future extensions to CAA, DNS records 400 compliant with this version of the CAA specification MUST clear 401 (0) all reserved flags bits. Applications that interpret CAA 402 records MUST ignore the value of all reserved flag bits. 404 Tag Length A single octet containing an unsigned integer specifying 405 the tag length in octets. The tag length MUST be at least 1 and 406 SHOULD be no more than 15. 408 Tag The property identifier, a sequence of ASCII characters. 410 Tag values MAY contain ASCII characters a through z and the 411 numbers 0 through 9. Tag values MUST NOT contain any other 412 characters. Matching of tag values is case insensitive. 414 Value A sequence of octets representing the property value. 415 Property values are encoded as binary values and MAY employ sub- 416 formats. 418 The length of the value field is specified implicitly as the 419 remaining length of the enclosing Resource Record data field. 421 4.1.1. Canonical Presentation Format 423 The canonical presentation format of the CAA record is as follows: 425 CAA 427 Where: 429 flags Is an unsigned integer between 0 and 255. 431 tag Is a non-zero sequence of ASCII letter and numbers in lower 432 case. 434 data Is the ascii text Encoding of the value field 436 4.2. CAA issue Property 438 The issue property is used to request that certificate issuers 439 perform CAA issue restriction processing for the domain and to grant 440 authorization to specific certificate issuers. 442 The CAA issue property value has the following sub-syntax (specified 443 in ABNF as per [RFC4234]). 445 Property = space [domain] * (space ";" parameter) space 447 domain = label *("." label) 448 label = 1* (ALPHA / DIGIT / "_" / "-" ) 450 space = *(SP / HTAB) 452 parameter = / space tag "=" value 454 tag = 1* (ALPHA / DIGIT) 456 value = *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE 458 A CAA record with an issue parameter tag that does not specify a 459 domain name is a request that certificate issuers perform CAA issue 460 restriction processing for the corresponding domain without granting 461 authorization to any certificate issuer. 463 This form of issue restriction would be appropriate for use with a 464 domain that the domain name owner does not intend to be used. 466 For example, the following CAA record set requests that no 467 certificates be issued for the domain 'nocerts.example.com' by any 468 certificate issuer. 470 nocerts.example.com CAA 0 issue ";" 472 A CAA record with an issue parameter tag that specifies a domain name 473 is a request that certificate issuers perform CAA issue restriction 474 processing for the corresponding domain and grants authorization to 475 the certificate issuer specified by the domain name. 477 For example, the following CAA record set requests that no 478 certificates be issued for the domain 'certs.example.com' by any 479 certificate issuer other than the example.net certificate issuer. 481 certs.example.com CAA 0 issue "example.net" 483 CAA authorizations are additive. thus the result of specifying both 484 the empty issuer and a specified issuer is the same as specifying 485 just the specified issuer alone. 487 An issuer MAY choose to specify issuer-parameters that further 488 constrain the issue of certificates by that issuer. For example 489 specifying that certificates are to be subject to specific validation 490 polices, billed to certain accounts or issued off specific roots. 492 The syntax and semantics of issuer-parameters are determined by the 493 issuer alone. 495 4.3. CAA iodef Property 497 The iodef property specifies a means of reporting certificate issue 498 requests or cases of certificate issue for the corresponding domain 499 that violate the security policy of the issuer or the domain name 500 holder. 502 The Incident Object Description Exchange Format (IODEF) [RFC5070] is 503 used to present the incident report in machine readable form. 505 The iodef property takes a URL as its parameter. The URL scheme type 506 determines the method used for reporting: 508 mailto The IODEF incident report is reported as a MIME email 509 attachment to an SMTP email that is submitted to the mail address 510 specified. The mail message sent SHOULD contain a brief text 511 message to alert the recipient to the nature of the attachment. 513 http or https The IODEF report is submitted as a Web Service request 514 to the HTTP address specified using the protocol specified in 515 [RFC6046]. 517 5. Security Considerations 519 CAA Records assert a security policy that the holder of a domain name 520 wishes to be observed by certificate issuers. The effectiveness of 521 CAA records as an access control is thus dependent on observance of 522 CAA constraints by issuers. 524 Observance of CAA records by issuers is subject to accountability 525 controls and proposed industry requirements. 527 While a Certification Authority can choose to ignore published CAA 528 records, doing so increases the both the probability that they will 529 mis-issue a certificate and the consequences of doing so. Once it is 530 known that a CA observes CAA records, malicious registration requests 531 will disproportionately target the negligent CAs that do not, and so 532 the mis-issue rate amongst the negligent CAs will increase. Since 533 the CA could clearly have avoided the mis-issue by performing CAA 534 processing, the likelihood of sanctions against the negligent CA is 535 increased. Failure to observe CAA issue restrictions provides an 536 objective criteria for excluding issuers from embedded roots of 537 trust. 539 In contrast, a Certification Authority that processes CAA records 540 correctly can reasonably claim that any residual mis-issue event 541 could have been avoided had the Domain Name holder published 542 appropriate CAA records. 544 5.1. Mis-Issue by Authorized Certification Authority 546 Use of CAA records does not provide protection against mis-issue by 547 an authorized Certification Authority. 549 Domain name holders SHOULD ensure that the CAs they authorize to 550 issue certificates for their domains employ appropriate controls to 551 ensure that certificates are only issued to authorized parties within 552 their organization. 554 Such controls are most appropriately determined by the domain name 555 holder and the authorized CA(s) directly and are thus out of scope of 556 this document. 558 5.2. Suppression or spoofing of CAA records 560 Suppression of the CAA record or insertion of a bogus CAA record 561 could enable an attacker to obtain a certificate from a CA that was 562 not authorized to issue for that domain name. 564 5.2.1. Certification Authorities 566 Since a certificate issued by a CA can be valid for several years, 567 the consequences of a spoofing or suppression attack are much greater 568 for Certification Authorities and so additional countermeasures are 569 justified. 571 A CA MUST mitigate this risk by employing DNSSEC verification 572 whenever possible and rejecting certificate requests in any case 573 where it is not possible to verify the non-existence or contents of a 574 relevant CAA record. 576 In cases where DNSSEC is not deployed in a corresponding domain, a CA 577 SHOULD attempt to mitigate this risk by employing appropriate DNS 578 security controls. For example all portions of the DNS lookup 579 process SHOULD be performed against the authoritative name server. 580 Cached data MUST NOT be relied on but MAY be used to support 581 additional anti-spoofing or anti-suppression controls. 583 5.3. Denial of Service 585 Introduction of a malformed or malicious CAA RR could in theory 586 enable a Denial of Service attack. 588 This specific threat is not considered to add significantly to the 589 risk of running an insecure DNS service. 591 5.3.1. Issuer 593 An attacker could in principle perform a Denial of Service attack 594 against an issuer by requesting a certificate with a maliciously long 595 DNS name. In practice the DNS protocol imposes a maximum name length 596 and the protocol does not exacerbate the existing need to mitigate 597 Denial of Service attacks to any meaningful degree. 599 5.4. Abuse of the Critical Flag 601 A Certification Authority could make use of the critical flag to 602 trick customers into publishing records which prevent competing 603 Certification Authorities from issuing certificates even though the 604 customer intends to authorize multiple providers. 606 In practice, such an attack would be of minimal effect since any 607 competent competitor that found itself unable to issue certificates 608 due to lack of support for a property marked critical SHOULD 609 investigate the cause and report the reason to the customer who will 610 thus discover the deception. It is thus unlikely that the attack 611 would succeed and the attempt might lay the perpetrator open to civil 612 or criminal sanctions. 614 6. IANA Considerations 616 6.1. Registration of the CAA Resource Record Type 618 [Note to IANA, the CAA resource record has already been assigned. On 619 issue of this draft as an RFC, the record should be updated to 620 reflect this document as the authoritative specificaton and this 621 paragraph (but not the following ones deleted] 623 IANA has assigned Resource Record Type 257 for the CAA Resource 624 Record Type and added the line depicted below to the registry named 625 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 626 [RFC5395] and located at 627 http://www.iana.org/assignments/dns-parameters. 629 Value and meaning Reference 630 ----------- --------------------------------------------- --------- 631 CAA 257 Certification Authority Restriction [RFC-THIS] 633 6.2. Certification Authority Authorization Properties 635 [Note to IANA, this is a new registry that needs to be created and 636 this paragraph but not the following ones deleted.] 638 IANA has created the Certification Authority Authorization Properties 639 registry with the following initial values: 641 Meaning Reference 642 ----------- ----------------------------------------------- --------- 643 issue Authorization Entry by Domain [RFC-THIS] 644 iodef Report incident by means of IODEF format report [RFC-THIS] 645 auth Reserved 646 path Reserved 647 policy Reserved 648 Addition of tag identifiers requires a public specification and 649 expert review as set out in RFC5395 [RFC5395] 651 7. References 653 7.1. Normative References 655 [RFC1035] Mockapetris, P., "Domain names - implementation and 656 specification", STD 13, RFC 1035, November 1987. 658 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 659 Extensions (MIME) Part One: Format of Internet Message 660 Bodies", RFC 2045, November 1996. 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 666 Rose, "DNS Security Introduction and Requirements", 667 RFC 4033, March 2005. 669 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 670 Algorithms and Identifiers for RSA Cryptography for use in 671 the Internet X.509 Public Key Infrastructure Certificate 672 and Certificate Revocation List (CRL) Profile", RFC 4055, 673 June 2005. 675 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 676 Specifications: ABNF", RFC 4234, October 2005. 678 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 679 Object Description Exchange Format", RFC 5070, 680 December 2007. 682 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 683 Housley, R., and W. Polk, "Internet X.509 Public Key 684 Infrastructure Certificate and Certificate Revocation List 685 (CRL) Profile", RFC 5280, May 2008. 687 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 688 Considerations", RFC 5395, November 2008. 690 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 691 Inter-network Defense (RID) Messages", RFC 6046, 692 November 2010. 694 [X.509] International Telecommunication Union, "ITU-T 695 Recommendation X.509 (11/2008): Information technology - 696 Open systems interconnection - The Directory: Public-key 697 and attribute certificate frameworks", ITU-T 698 Recommendation X.509, November 2008. 700 7.2. Non Normative References 702 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 703 Wu, "Internet X.509 Public Key Infrastructure Certificate 704 Policy and Certification Practices Framework", RFC 3647, 705 November 2003. 707 Authors' Addresses 709 Phillip Hallam-Baker 710 Comodo Group Inc. 712 Email: philliph@comodo.com 714 Rob Stradling 715 Comodo CA Ltd. 717 Email: rob.stradling@comodo.com