--- 1/draft-ietf-lamps-rfc6844bis-03.txt 2018-12-03 11:13:12.502268346 -0800 +++ 2/draft-ietf-lamps-rfc6844bis-04.txt 2018-12-03 11:13:12.538269207 -0800 @@ -1,21 +1,21 @@ Network Working Group P. Hallam-Baker Internet-Draft Comodo Group, Inc Obsoletes: 6844 (if approved) R. Stradling Intended status: Standards Track Sectigo -Expires: May 10, 2019 J. Hoffman-Andrews +Expires: June 6, 2019 J. Hoffman-Andrews Let's Encrypt - November 06, 2018 + December 03, 2018 DNS Certification Authority Authorization (CAA) Resource Record - draft-ietf-lamps-rfc6844bis-03 + draft-ietf-lamps-rfc6844bis-04 Abstract The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 10, 2019. + This Internet-Draft will expire on June 6, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,49 +59,47 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 3. The CAA RR Type . . . . . . . . . . . . . . . . . . . . . . . 5 4. Certification Authority Processing . . . . . . . . . . . . . 7 4.1. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8 5. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Canonical Presentation Format . . . . . . . . . . . . 10 - 5.2. CAA issue Property . . . . . . . . . . . . . . . . . . . 10 + 5.2. CAA issue Property . . . . . . . . . . . . . . . . . . . 11 5.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 12 - 5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 12 + 5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.1. Non-Compliance by Certification Authority . . . . . . . . 13 6.2. Mis-Issue by Authorized Certification Authority . . . . . 13 6.3. Suppression or Spoofing of CAA Records . . . . . . . . . 14 6.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 6.5. Abuse of the Critical Flag . . . . . . . . . . . . . . . 14 - 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 + 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 7.1. Blocked Queries or Responses . . . . . . . . . . . . . . 15 7.2. Rejected Queries and Malformed Responses . . . . . . . . 15 7.3. Delegation to Private Nameservers . . . . . . . . . . . . 15 7.4. Bogus DNSSEC Responses . . . . . . . . . . . . . . . . . 15 8. Differences versus RFC6844 . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 9.1. Certification Authority Restriction Flags . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 11.2. Informative References . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + 11.2. Informative References . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. - Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are used as a part of a mechanism for checking PKIX certificate data. The distinction between the two specifications is that CAA records specify an authorization control to be performed by a certificate issuer before issue of a certificate and TLSA records specify a verification @@ -244,66 +242,66 @@ Certification Practices or Certificate Policy, or that a Certificate Evaluator may use to report observation of a possible policy violation. The Incident Object Description Exchange Format (IODEF) format is used [RFC7970]. The following example is a DNS zone file (see [RFC1035]) that informs CAs that certificates are not to be issued except by the holder of the domain name 'ca.example.net' or an authorized agent thereof. This policy applies to all subordinate domains under example.com. - $ORIGIN example.com - . CAA 0 issue "ca.example.net" + $ORIGIN example.com. + CAA 0 issue "ca.example.net" If the domain name holder specifies one or more iodef properties, a certificate issuer MAY report invalid certificate requests to that address. In the following example, the domain name holder specifies that reports may be made by means of email with the IODEF data as an attachment, a Web service [RFC6546], or both: - $ORIGIN example.com - . CAA 0 issue "ca.example.net" - . CAA 0 iodef "mailto:security@example.com" - . CAA 0 iodef "http://iodef.example.com/" + $ORIGIN example.com. + CAA 0 issue "ca.example.net" + CAA 0 iodef "mailto:security@example.com" + CAA 0 iodef "http://iodef.example.com/" A certificate issuer MAY specify additional parameters that allow customers to specify additional parameters governing certificate issuance. This might be the Certificate Policy under which the certificate is to be issued, the authentication process to be used might be specified, or an account number specified by the CA to enable these parameters to be retrieved. For example, the CA 'ca.example.net' has requested its customer 'example.com' to specify the CA's account number '230123' in each of the customer's CAA records. - $ORIGIN example.com - . CAA 0 issue "ca.example.net; account=230123" + $ORIGIN example.com. + CAA 0 issue "ca.example.net; account=230123" The syntax of additional parameters is a sequence of name-value pairs as defined in Section 5.2. The semantics of such parameters is left to site policy and is outside the scope of this document. The critical flag is intended to permit future versions of CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated domains. In the following example, the property 'tbs' is flagged as critical. Neither the example.net CA nor any other issuer is authorized to issue under either policy unless the processing rules for the 'tbs' property tag are understood. - $ORIGIN example.com - . CAA 0 issue "ca.example.net; policy=ev" - . CAA 128 tbs "Unknown" + $ORIGIN example.com. + CAA 0 issue "ca.example.net; policy=ev" + CAA 128 tbs "Unknown" Note that the above restrictions only apply at certificate issue. Since the validity of an end entity certificate is typically a year or more, it is quite possible that the CAA records published at a domain will change between the time a certificate was issued and validation by a relying party. 4. Certification Authority Processing Before issuing a certificate, a compliant CA MUST check for @@ -455,22 +453,25 @@ CAA Where: Flags: Is an unsigned integer between 0 and 255. Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case. - Value: Is the encoding of the value field as - specified in [RFC1035], Section 5.1. + Value: The value field, expressed as a contiguous set of characters + without interior spaces, or as a quoted string. See the the + format specified in [RFC1035], Section 5.1, but + note that the value field contains no length byte and is not limited + to 255 characters. 5.2. CAA issue Property The issue property tag is used to request that certificate issuers perform CAA issue restriction processing for the domain and to grant authorization to specific certificate issuers. The CAA issue property value has the following sub-syntax (specified in ABNF as per [RFC5234]). @@ -736,45 +736,31 @@ This document clarifies the ABNF grammar for issue and issuewild tags and resolves some inconsistencies with the document text. In particular, it specifies that parameters are separated with hyphens. It also allows hyphens in property names. This document also clarifies processing of a CAA RRset that is not empty, but contains no issue or issuewild tags. 9. IANA Considerations - This document has no IANA actions. - -9.1. Certification Authority Restriction Flags - - IANA has created the "Certification Authority Restriction Flags" - registry with the following initial values: - - +------+----------------------+-----------+ - | Flag | Meaning | Reference | - +------+----------------------+-----------+ - | 0 | Issuer Critical Flag | [RFC6844] | - | | | | - | 1-7 | Reserved> | [RFC6844] | - +------+----------------------+-----------+ - - Assignment of new flags follows the RFC Required policy set out in - [RFC8126], Section 4.1. + IANA is requested to add [[[ RFC Editor: Please replace with this RFC + ]]] as a reference for the Certification Authority Restriction Flags + and Certification Authority Restriction Properties registries. 10. Acknowledgements The authors would like to thank the following people who contributed - to the design and documentation of this work item: Chris Evans, - Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam - Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean - Turner, and Ben Wilson. + to the design and documentation of this work item: Tim Hollebeek, + Corey Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul + Hoffman, Stephen Kent, Adam Langley, Ben Laurie, James Manager, Chris + Palmer, Scott Schmit, Sean Turner, and Ben Wilson. 11. References 11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and @@ -824,34 +810,24 @@ [RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, DOI 10.17487/RFC6546, April 2012, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . - [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification - Authority Authorization (CAA) Resource Record", RFC 6844, - DOI 10.17487/RFC6844, January 2013, - . - [RFC7970] Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, November 2016, . - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - 11.2. Informative References [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003, . Authors' Addresses