]> Google

aac@google.com

Security Limited Additional Mechanisms for PKIX and SMIME lamps This document specifies a new DNS CAA Resource Record Property that allows an IP Address holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that IP Address. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The CAA Resource Records specified in allow a domain holder to limit the CAs that are authorized to issue certificates for that domain. However, there is no mechanism to provide the same functionality for IP Addresses that can be included in certificates. This document specifies a new Property for CAA records that exist in the Reverse DNS Zones that can achieve the same effect. A new Property is required so as not to interfere with certificate issuance for the subdomains of these two zones, and issue and issuewild continue to be valid.

Conventions and Definitions

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Defined Terms This document uses the same defined terms as Section 2.2 of . The following term is redefined in this document:

Relevant Resource Record Set (Relevant RRset):

A set of CAA Resource Records resulting from calculating the IP Address Reverse DNS FQDN for an IP Address.

The following terms are additionally defined:

IP Address:

An IPv6 or IPv4 address.

Reverse DNS Zones:

The DNS zones ip6.arpa and in-addr.arpa.

IP Address Reverse DNS FQDN:

The FQDN that corresponds to an IP Address within the Reverse DNS Zones that can be calculated by using the algorithms described in Section 2.5 of and Section 3.5 of .

Relevant Resource Record Set In order to determine the Relevant RRset, a compliant CA must calculate the IP Address Reverse DNS FQDN. Then, it must apply the algorithm specified in Section 3 of for the calculated FQDN. The search stops at the Reverse DNS Zones, but does not include them.

CAA ip Property If the ip Property Tag is present in the Relevant RRset for an IP Address, it is a request that Issuers: Perform CAA issue restriction processing for the IP Address, and Grant authorization to issue certificates containing that IP Address to the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name. The CAA ip Property Value has the following sub-syntax (specified in ABNF as per ):

The following CAA RRset requests that no certificates be issued for the IP Address "2001:db8::1" by any Issuer other than ca1.example.net:

The following CAA RRset requests that no certificates be issued for the IP Address "192.0.2.2" by any Issuer other than ca2.example.org:

The following CAA RRset requests that no certificates be issued for the IP Address "192.0.2.1" by any Issuer other than ca1.example.net, and that no certificates be issued for the domain "1.2.0.192.in-addr.arpa" by any Issuer other than ca2.example.org:

An ip Property Tag where the issue-value does not match the ABNF grammar MUST be treated the same as one specifying an empty issuer-domain-name. For example, the following malformed CAA RRset forbids issuance:

The CAA ip Property Tag MUST be ignored if the FQDN is not a valid IP Address Reverse DNS FQDN. An Issuer MAY choose to specify parameters that further constrain the issue of certificates by that Issuer -- for example, specifying that certificates are to be subject to specific validation policies, billed to certain accounts, or issued under specific trust anchors. For example, if ca1.example.net has requested that its customer that wants a certificate with the IP Address 192.0.2.32 specified their account number "110995" in each of the customer's CAA records using the (CA-defined) "account" parameter, it would look like this:

Security Considerations The same Security Considerations described in Section 5 of apply to this document. On top of these, as the IP Address Reverse DNS FQDN is not checked by CAs that do not comply to this document, the critical flag, described in Section 4.5 of , may have reduced efficacy.

Deployment Considerations The same Deployment Considerations described in Section 6 of apply to this document. On top of these, deployment of CAA ip Property Tags will increase the amount of DNS queries required when issuing certificates for IPv6 addresses, as it can include up to 32 DNS queries to the ip6.arpa zone if there are no Relevant RRsets.

IANA Considerations The "Certification Authority Restriction Properties" registry needs to be updated to include the following entry:

Tag:

ip

Meaning:

Authorization Entry by IP Address

Reference:

This document

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 name. CAA Resource Records allow a public CA 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 CAs.This document obsoletes RFC 6844. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

Acknowledgments