Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
RFC 8657

Document Type RFC - Proposed Standard (November 2019; No errata)
Last updated 2019-11-26
Replaces draft-landau-acme-caa
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Daniel McCarney
Shepherd write-up Show (last changed 2018-07-05)
IESG IESG state RFC 8657 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Roman Danyliw
Send notices to Daniel McCarney <cpu@letsencrypt.org>
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions


Internet Engineering Task Force (IETF)                         H. Landau
Request for Comments: 8657                                 November 2019
Category: Standards Track                                               
ISSN: 2070-1721

   Certification Authority Authorization (CAA) Record Extensions for
  Account URI and Automatic Certificate Management Environment (ACME)
                             Method Binding

Abstract

   The Certification Authority Authorization (CAA) DNS record allows a
   domain to communicate an issuance policy to Certification Authorities
   (CAs) but only allows a domain to define a policy with CA-level
   granularity.  However, the CAA specification (RFC 8659) also provides
   facilities for an extension to admit a more granular, CA-specific
   policy.  This specification defines two such parameters: one allowing
   specific accounts of a CA to be identified by URIs and one allowing
   specific methods of domain control validation as defined by the
   Automatic Certificate Management Environment (ACME) protocol to be
   required.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8657.

Copyright Notice

   Copyright (c) 2019 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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Extensions to the CAA Record: The "accounturi" Parameter
     3.1.  Use with ACME
     3.2.  Use without ACME
   4.  Extensions to the CAA Record: The "validationmethods" Parameter
   5.  Security Considerations
     5.1.  Limited to CAs Processing CAA Records
     5.2.  Restrictions Ineffective without CA Recognition
     5.3.  Mandatory Consistency in CA Recognition
     5.4.  URI Ambiguity
     5.5.  Authorization Freshness
     5.6.  Use with and without DNSSEC
     5.7.  Restrictions Supersedable by DNS Delegation
     5.8.  Misconfiguration Hazards
     5.9.  Revelation of Account URIs
   6.  IANA Considerations
   7.  Normative References
   Appendix A.  Examples
   Author's Address

1.  Introduction

   This specification defines two parameters for the "issue" and
   "issuewild" Properties of the Certification Authority Authorization
   (CAA) DNS resource record [RFC8659].  The first, "accounturi", allows
   authorization conferred by a CAA policy to be restricted to specific
   accounts of a Certification Authority (CA), which are identified by
   URIs.  The second, "validationmethods", allows the set of validation
   methods supported by a CA to validate domain control to be limited to
   a subset of the full set of methods that it supports.

2.  Terminology

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Extensions to the CAA Record: The "accounturi" Parameter

   This document defines the "accounturi" CAA parameter for the "issue"
   and "issuewild" Properties defined by [RFC8659].  The value of this
   parameter, if specified, MUST be a URI [RFC3986] identifying a
   specific CA account.

   "CA account" means an object that is maintained by a specific CA,
   that may request the issuance of certificates, and that represents a
   specific entity or group of related entities.

   The presence of this parameter constrains the Property to which it is
   attached.  Where a CAA Property has an "accounturi" parameter, a CA
   MUST only consider that Property to authorize issuance in the context
   of a given certificate issuance request if the CA recognizes the URI
   specified in the value portion of that parameter as identifying the
   account making that request.

   A Property without an "accounturi" parameter matches any account.  A
   Property with an invalid or unrecognized "accounturi" parameter is
Show full document text