idnits 2.17.1 draft-wicinski-lamps-caa-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC6844]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC6844, but the abstract doesn't seem to directly say this. It does mention RFC6844 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 24, 2019) is 1832 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) ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group T. Wicinski 3 Internet-Draft Salesforce 4 Updates: 6844 (if approved) March 24, 2019 5 Intended status: Standards Track 6 Expires: September 25, 2019 8 Alternative DNS Certification Authority Authorization (CAA) Resource 9 Record 10 draft-wicinski-lamps-caa-00 12 Abstract 14 [RFC6844] defines the Certification Authority Authorization (CAA) DNS 15 Resource Record type to specify one or more Certification Authorities 16 (CAs) authorized to issue certificates for that domain name. With 17 large domains covering multiple web properties, defining all possible 18 certificate authorities for the domain has security implications. It 19 would be beneficial to define a CAA for individual host names. This 20 will allow CAA records that can be managed with fine grain control. 22 This document provides an alternative CAA record using a _caa prefix 23 label that will take precedent on a per Fully Qualified Domain Name 24 (FQDN), if it exists. It will override any CAA record at the zone 25 apex. This will not change current CAA record behavior, but will be 26 an additional option. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 25, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. The _caa prefix label . . . . . . . . . . . . . . . . . . . . 2 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 66 4. Normative References . . . . . . . . . . . . . . . . . . . . 3 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1. Introduction 71 In [RFC6844] the Certification Authority Authorization (CAA) DNS 72 Resource Record is defined to allow a DNS domain name holder to 73 specify the Certification Authorities (CAs) authorized to issue 74 certificates for that domain name. 76 1.1. Definitions 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 80 "OPTIONAL" in this document are to be interpreted as described in BCP 81 14 [RFC2119] [RFC8174] when, and only when, they appear in all 82 capitals, as shown here. 84 2. The _caa prefix label 86 [_caa.www.example.com CAA 0 issue "ca.example.net" 88 _caa.www.example.com CNAME _caa.cdn.example.net 90 _] 92 3. IANA Considerations 94 IANA is requested to add an entry in the "Underscored and Globally 95 Scoped DNS Node Names" Registry with the fields "RR Type" = "CAA" and 96 "Node Name" = "_caa", 98 4. Normative References 100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 101 Requirement Levels", BCP 14, RFC 2119, 102 DOI 10.17487/RFC2119, March 1997, 103 . 105 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 106 Authority Authorization (CAA) Resource Record", RFC 6844, 107 DOI 10.17487/RFC6844, January 2013, 108 . 110 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 111 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 112 May 2017, . 114 Author's Address 116 Tim Wicinski 117 Salesforce 118 US 120 Email: tjw.ietf@gmail.com