idnits 2.17.1 draft-ietf-pkix-caa-02.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 (Sept 7, 2011) is 4879 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: 'TBS' is mentioned on line 396, but not defined == Missing Reference: 'RFC-THIS' is mentioned on line 510, but not defined == Unused Reference: 'RFC4055' is defined on line 530, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) Summary: 1 error (**), 0 flaws (~~), 4 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: March 10, 2012 Comodo CA Ltd. 6 B. Laurie 7 Google Inc. 8 Sept 7, 2011 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-ietf-pkix-caa-02 13 Abstract 15 The Certification Authority Authorization (CAA) DNS Resource Record 16 allows a DNS domain name holder to specify the certificate signing 17 certificate(s) authorized to issue certificates for that domain. CAA 18 resource records allow a public Certification Authority to implement 19 additional controls to reduce the risk of unintended certificate mis- 20 issue. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 10, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. The CAA RR type . . . . . . . . . . . . . . . . . . . . . 5 61 3. Certification Authority Processing . . . . . . . . . . . . . . 6 62 3.1. Canonical Domain Name . . . . . . . . . . . . . . . . . . 7 63 3.2. Use of DNS Security . . . . . . . . . . . . . . . . . . . 7 64 3.3. Archive . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1.1. Canonical Presentation Format . . . . . . . . . . . . 9 68 4.2. CAA issue Property . . . . . . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 5.1. Mis-Issue by Authorized Certification Authority . . . . . 10 71 5.2. Suppression or spoofing of CAA records . . . . . . . . . . 10 72 5.2.1. Applications . . . . . . . . . . . . . . . . . . . . . 10 73 5.2.2. Certification Authorities . . . . . . . . . . . . . . 10 74 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 11 75 5.4. Abuse of the Critical Flag . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 6.1. Registration of the CAA Resource Record Type . . . . . . . 11 78 6.2. Certification Authority Authorization Properties . . . . . 11 79 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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 RFC 2119 [RFC2119]. 90 1.2. Defined Terms 92 The following terms are used in this document: 94 Authorization Entry An authorization assertion that grants or denies 95 a specific set of permissions to a specific group of entities. 97 Canonical Domain Name A Domain Name that is not an alias. 99 Canonical Domain Name Value The value of a Canonical Domain Name. 100 The value resulting from applying alias transformations to a 101 Domain Name that is not canonical. 103 Certificate An X.509 Certificate, as specified in RFC 5280 104 [RFC5280]. 106 Certification Policy (CP) Specifies the criteria that a 107 Certification Authority undertakes to meet in its issue of 108 certificates. 110 Certification Practices Statement (CPS) Specifies the means by which 111 the criteria of the Certification Policy are met. In most cases 112 this will be the document against which the operations of the 113 Certification Authority are audited. 115 Certification Authority (CA) An entity that issues Certificates in 116 accordance with a specified Certification Policy. 118 Domain The set of resources associated with a DNS Domain Name. 120 Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and 121 revisions. 123 Domain Name System (DNS) The Internet naming system specified in RFC 124 1035 [RFC1035] and revisions. 126 DNS Security (DNSSEC) Extensions to the DNS that provide 127 authentication services as specified in RFC 4033 [RFC4033] and 128 revisions. 130 Extended Issuer Authorization Set The most specific Issuer 131 Authorization Set that is active for a domain. This is either the 132 Issuer Authorization Set for the domain itself, or if that is 133 empty, the Issuer Authorization Set for the corresponding Public 134 Delegation Point. 136 Issuer Authorization Set The set of Authorization Entries for a 137 domain name that are flagged for use by Issuers. Analogous to an 138 Access Control List but with no ordering specified. 140 Public Delegation Point A Domain Name that is obtained from a public 141 DNS registry. 143 Public Key Infrastructure X.509 (PKIX) Standards and specifications 144 issued by the IETF that apply the X.509 [X.509] certificate 145 standards specified by the ITU to Internet applications as 146 specified in RFC 5280 [RFC5280] and related documents. 148 Resource Record (RR) A set of attributes bound to a Domain Name. 150 Relying Party A party that makes use of an application whose 151 operation depends on use of a Certificate for making a security 152 decision. 154 Relying Application An application whose operation depends on use of 155 a Certificate for making a security decision. 157 2. Introduction 159 The Certification Authority Authorization (CAA) DNS Resource Record 160 allows a DNS domain name holder to specify the Certification 161 Authorities authorized to issue certificates for that domain. 162 Publication of CAA resource records allow a public Certification 163 Authority (CA) to implement additional controls to reduce the risk of 164 unintended certificate mis-issue. 166 Conformance with a published CAA record is a necessary but not 167 sufficient condition for issue of a certificate. Before issuing a 168 certificate, a PKIX CA is required to validate the request according 169 to the policies set out in its Certificate Policy Statement. In the 170 case of a public CA that validates certificate requests as a third 171 party, the certificate will be typically issued under a public root 172 certificate embedded in one or more relevant Relying Applications. 174 Criteria for inclusion of embedded root certificates in applications 175 are outside the scope of this document but typically require the CA 176 to publish a Certificate Practices Statement (CPS) that specifies how 177 the requirements of the Certificate Policy (CP) are achieved and 178 provide an annual audit statement of their performance against their 179 CPS performed by an independent third party auditor. 181 It is the intention of the authors to propose the CAA record defined 182 in this document as the basis for CA validation requirements to be 183 proposed in organizations that publish validation requirements. 185 CAA records only describe the current state of Certification 186 Authority certificate issue authority. Since a certificate is 187 typically valid for at least a year, it is possible that a 188 certificate that is not conformant with the CAA records currently 189 published was conformant with the CAA records published at the time 190 that it was issued. Thus Relying Applications MUST NOT use failure 191 to conform to currently published CAA records specifying issue 192 authorization as a certificate validity criteria. 194 2.1. The CAA RR type 196 A CAA RR publishes a CAA property entry that corresponds to the 197 specified domain name. Multiple property entries MAY be associated 198 with the same domain name by publishing multiple CAA RRs at that 199 domain name. Each property entry MAY be tagged with one or more of 200 the following flag values: 202 Critical If set, indicates that the corresponding property entry tag 203 MUST be understood if the semantics of the CAA record are to be 204 correctly understood by the specified audience. 206 Issuers MUST NOT issue certificates for a domain if the Extended 207 Issuer Authorization Set contains unknown property entry tags that 208 have both the Issuer and Critical bits set. 210 Issuer Specifies that the corresponding Property Entry is to be used 211 by Issuers and forms part of the Issuer Authorization Set for the 212 domain. 214 The following properties are defined: 216 issue [; ]* The policy property entry 217 declares an authorization entry granting authorization to issue 218 under the specified Certificate Policy to the holder of the 219 specified domain. 221 The following example informs CAs that certificates must not be 222 issued except by the holder of the domain name 'ca.example.net' or an 223 authorized agent thereof. Since the policy is published at the 224 Public Delegation Point, the policy applies to all subordinate 225 domains under example.com. 227 $ORIGIN example.com 228 . CAA 1 issue "ca.example.net" 230 A certificate issuer MAY specify additional parameters that allow 231 customers to specify additional parameters governing certificate 232 issue. For example, the Certification Policy under which the 233 certificate is to be issued or the authentication process to be used. 235 $ORIGIN example.com 236 . CAA 1 issue "ca.example.net; account=230123" 238 The syntax and semantics of such parameters is left to site policy 239 and is outside the scope of this document. 241 Future versions of this specification MAY use the critical flag to 242 introduce new semantics that MUST be understood for correct 243 processing of the record, preventing Certification Authorities that 244 do not recognize the record from issuing certificates. 246 In the following example, the property 'tbs' is flagged as critical. 247 The example.net CA is not authorized to issue under either policy 248 unless the processing rules for the 'tbs' property tag are 249 understood. 251 $ORIGIN example.com 252 . CAA 1 issue "ca.example.net; policy=ev" 253 . CAA 129 tbs "Unknown" 255 Note that the above restrictions only apply to issue of certificates. 256 Since the validity of an end entity certificate is typically a year 257 or more it is quite possible that the CAA records published at a 258 domain will change between the issue of the certificate and 259 verification by a relying party. 261 3. Certification Authority Processing 263 Before issue of a certificate, a compliant CA MUST check for 264 publication of a relevant CAA Resource Record(s) and if such 265 record(s) are published, that the certificate requested is consistent 266 with them. If the certificate requested is not consistent with the 267 relevant CAA RRs, the CA MUST NOT issue the certificate. 269 The Issuer Authorization Set for a domain name consists of the set of 270 all CAA Authorization Entries declared for the canonical form of the 271 specified domain. 273 The Extended Issuer Authorization Set for a domain name consists of 274 the Issuer Authorization Set for that domain name if it is non-empty. 275 Otherwise the Extended Issuer Authorization Set for a domain name 276 consists of the Issuer Authorization Set for the corresponding Public 277 Delegation Point for that domain name. 279 If the Extended Issuer Authorization Set for a domain name is not 280 empty, a Certification Authority MUST NOT issue a certificate unless 281 it conforms to at least one authorization entry in the Extended 282 Issuer Authorization Set. 284 3.1. Canonical Domain Name 286 The DNS defines the CNAME and DNAME mechanisms for specifying domain 287 name aliases. The canonical name of a DNS name is the name that 288 results from performing all DNS alias operations. 290 A Certification Authority MUST perform CNAME and DNAME processing as 291 defined in the DNS specifications 1035 [RFC1035] to resolve CAA 292 records. 294 3.2. Use of DNS Security 296 Use of DNSSEC to authenticate CAA RRs is strongly recommended but not 297 required. A CA MUST NOT issue certificates if doing so would 298 conflict with the corresponding extended issuer authorization set 299 whether the corresponding DNS records are signed or not. 301 Use of DNSSEC allows a CA to acquire and archive a non-repudiable 302 proof that they were authorized to issue certificates for the domain. 304 3.3. Archive 306 A compliant CA SHOULD maintain an archive of the DNS transactions 307 used to verify CAA eligibility. 309 In particular a CA SHOULD ensure that where DNSSEC data is available 310 that the corresponding signature and NSEC/NSEC3 records are preserved 311 so as to enable later compliance audits. 313 4. Mechanism 315 4.1. Syntax 317 A CAA RR contains a single property entry consisting of a tag value 318 pair. Each tag represents a property of the CAA record. The value 319 of a CAA property is that specified in the corresponding value field. 321 A domain name MAY have multiple CAA RRs associated with it and a 322 given property MAY be specified more than once. 324 The CAA data field contains one property entry. A property entry 325 consists of the following data fields: 327 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 328 | Flags | Tag Length = n | 329 +----------------+----------------+...+---------------+ 330 | Tag char 0 | Tag Char 1 |...| Tag Char n-1 | 331 +----------------+----------------+...+---------------+ 332 +----------------+----------------+.....+---------------+ 333 | Data byte 0 | Data byte 1 |.....| Data byte m-1 | 334 +----------------+----------------+.....+---------------+ 336 Where n is the length specified in the tag length field and m is the 337 remaining octets in the data field (m = d - n - 2) where d is the 338 length of the data section. 340 The data fields are defined as follows: 342 Flags One octet containing the following fields: 344 Bit 0: Critical Flag If the value is set (1), the critical flag 345 is asserted and the property MUST be understood if the CAA 346 record is to be correctly processed. 348 A Certification Authority MUST NOT issue certificates for any 349 Domain that contains a CAA critical property for an unknown or 350 unsupported property type that has the issuer bit set. 352 Bit 7: Issuer Use If set, the property entry contains an 353 Authorization Entry that forms part of the Issuer Application 354 Authorization Set for the corresponding domain. 356 Note that according to the conventions set out in RFC 1035 357 [RFC1035] Bit 0 is the Most Significant Bit and Bit 7 is the Least 358 Significant. Thus the flags value 1 means that bit 7 is set while 359 a value of 128 means that bit 0 is set according to this 360 convention. 362 Tag Length A single octet containing an unsigned integer specifying 363 the tag length in octets. The tag length MUST be at least 1 and 364 SHOULD be no more than 15. 366 Tag The property identifier, a sequence of ASCII characters. 368 Tag values MAY contain ASCII characters a through z and the 369 numbers 0 through 9. Tag values MUST NOT contain any other 370 characters. Matching of tag values is case insensitive. 372 Value A sequence of octets representing the property value. 373 Property values are encoded as binary values and MAY employ sub- 374 formats. 376 The length of the value field is specified implicitly as the 377 remaining length of the enclosing Resource Record data field. 379 4.1.1. Canonical Presentation Format 381 The canonical presentation format of the CAA record is as follows: 383 CAA 385 Where: 387 flags Is an unsigned integer between 0 and 15. 389 tag Is a non-zero sequence of ASCII letter and numbers in lower 390 case. 392 data Is the ascii text Encoding of the value field 394 4.2. CAA issue Property 396 [TBS] 398 5. Security Considerations 400 CAA Records provide an accountability control. They are intended to 401 deter rather than prevent undesired behavior. 403 While a Certification Authority can choose to ignore published CAA 404 records, doing so increases the both the probability that they will 405 mis-issue a certificate and the consequences of doing so. Once it is 406 known that a CA observes CAA records, malicious registration requests 407 will disproportionately target the negligent CAs that do not, and so 408 the mis-issue rate amongst the negligent CAs will increase. Since 409 the CA could clearly have avoided the mis-issue by performing CAA 410 processing, the likelihood of sanctions against the negligent CA is 411 increased. Failure to observe CAA issue restrictions provides an 412 objective criteria for excluding issuers from embedded roots of 413 trust. 415 In contrast, a Certification Authority that processes CAA records 416 correctly can reasonably claim that any residual mis-issue event 417 could have been avoided had the Domain Name holder published 418 appropriate CAA records. 420 5.1. Mis-Issue by Authorized Certification Authority 422 Use of CAA records does not provide protection against mis-issue by 423 an authorized Certification Authority. 425 Domain name holders SHOULD ensure that the CAs they authorize to 426 issue certificates for their domains employ appropriate controls to 427 ensure that certificates are only issued to authorized parties within 428 their organization. 430 Such controls are most appropriately determined by the domain name 431 holder and the authorized CA(s) directly and are thus out of scope of 432 this document. 434 5.2. Suppression or spoofing of CAA records 436 Suppression of the CAA record or insertion of a bogus CAA record 437 could enable an attacker to obtain a certificate from a CA that was 438 not authorized to issue for that domain name. 440 5.2.1. Applications 442 Applications performing CAA checking SHOULD mitigate the risk of 443 suppresion or spoofing of CAA records by means of DNSSEC validation 444 where present. In cases where DNSSEC validation is not available, 445 CAA checking is of limited security value. 447 5.2.2. Certification Authorities 449 Since a certificate issued by a CA can be valid for several years, 450 the consequences of a spoofing or suppression attack are much greater 451 for Certification Authorities and so additional countermeasures are 452 justified. 454 A CA MUST mitigate this risk by employing DNSSEC verification 455 whenever possible and rejecting certificate requests in any case 456 where it is not possible to verify the non-existence or contents of a 457 relevant CAA record. 459 In cases where DNSSEC is not deployed in a corresponding domain, a CA 460 SHOULD attempt to mitigate this risk by employing appropriate DNS 461 security controls. For example all portions of the DNS lookup 462 process SHOULD be performed against the authoritative name server. 463 Cached data MUST NOT be relied on but MAY be used to support 464 additional anti-spoofing or anti-suppression controls. 466 5.3. Denial of Service 468 Introduction of a malformed or malicious CAA RR could in theory 469 enable a Denial of Service attack. 471 This specific threat is not considered to add significantly to the 472 risk of running an insecure DNS service. 474 5.4. Abuse of the Critical Flag 476 A Certification Authority could make use of the critical flag to 477 trick customers into publishing records which prevent competing 478 Certification Authorities from issuing certificates even though the 479 customer intends to authorize multiple providers. 481 In practice, such an attack would be of minimal effect since any 482 competent competitor that found itself unable to issue certificates 483 due to lack of support for a property marked critical is going to 484 investigate the cause and report the reason to the customer who was 485 deceived. It is thus unlikely that the attack would succeed and the 486 attempt might lay the perpetrator open to civil or criminal 487 sanctions. 489 6. IANA Considerations 491 6.1. Registration of the CAA Resource Record Type 493 IANA has assigned Resource Record Type 257 for the CAA Resource 494 Record Type and added the line depicted below to the registry named 495 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 496 [RFC5395] and located at 497 http://www.iana.org/assignments/dns-parameters. 499 Value and meaning Reference 500 ----------- --------------------------------------------- --------- 501 CAA 257 Certification Authority Restriction [RFC-THIS] 503 6.2. Certification Authority Authorization Properties 505 IANA has created the Certification Authority Authorization Properties 506 registry with the following initial values: 508 Meaning Reference 509 ----------- ----------------------------------------------- --------- 510 issue Authorization Entry by Domain [RFC-THIS] 511 auth Reserved 512 path Reserved 513 policy Reserved 515 Addition of tag identifiers requires a public specification and 516 expert review as set out in RFC5395 [RFC5395] 518 7. Normative References 520 [RFC1035] Mockapetris, P., "Domain names - implementation and 521 specification", STD 13, RFC 1035, November 1987. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 527 Rose, "DNS Security Introduction and Requirements", 528 RFC 4033, March 2005. 530 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 531 Algorithms and Identifiers for RSA Cryptography for use in 532 the Internet X.509 Public Key Infrastructure Certificate 533 and Certificate Revocation List (CRL) Profile", RFC 4055, 534 June 2005. 536 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 537 Housley, R., and W. Polk, "Internet X.509 Public Key 538 Infrastructure Certificate and Certificate Revocation List 539 (CRL) Profile", RFC 5280, May 2008. 541 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 542 Considerations", RFC 5395, November 2008. 544 [X.509] International Telecommunication Union, "ITU-T 545 Recommendation X.509 (11/2008): Information technology - 546 Open systems interconnection - The Directory: Public-key 547 and attribute certificate frameworks", ITU-T 548 Recommendation X.509, November 2008. 550 Authors' Addresses 552 Phillip Hallam-Baker 553 Comodo Group Inc. 555 Email: philliph@comodo.com 557 Rob Stradling 558 Comodo CA Ltd. 560 Email: rob.stradling@comodo.com 562 Ben Laurie 563 Google Inc. 565 Email: benl@google.com