One document matched: draft-landau-acme-caa-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-landau-acme-caa-00" category="info">

  <front>
    <title abbrev="ACME-CAA">ACME Account Key Binding via CAA Records</title>

    <author initials="H." surname="Landau" fullname="Hugo Landau">
      <organization></organization>
      <address>
        <email>hlandau@devever.net</email>
      </address>
    </author>

    <date year="2016" month="April" day="21"/>

    <area>General</area>
    <workgroup>ACME Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The ACME protocol provides a means for hosts to automatically request and
obtain X.509 certificates from certificate authorities. Certification
authorities which implement ACME may also choose to implement the CAA DNS
record, which allows a domain to communicate issuance policy to CAs. The CAA
specification alone allows a domain to define policy with CA-level granularity.
However, the CAA specification also provides facilities for extension to admit
more granular, CA-specific policy. This specification defines such a parameter.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>This specification defines a parameter for the ‘issue’ and ‘issuewild’
properties of the Certification Authority Authorization (CAA) DNS resource
record <xref target="RFC6844"/>, allowing authorization conferred by a CAA policy to be
restricted to specific ACME <xref target="I-D.ietf-acme-acme"/> accounts. The accounts are
identified by account key thumbprint.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be
interpreted as described in BCP 14, RFC 2119 <xref target="RFC2119"/> and indicate
requirement levels for compliant ACME-CAA implementations.</t>

</section>
<section anchor="extensions-to-the-caa-record" title="Extensions to the CAA Record">

<section anchor="acme-ak-parameter" title="acme-ak Parameter">

<t>A CAA parameter “acme-ak” is defined for the ‘issue’ and ‘issuewild’ properties
defined by <xref target="RFC6844"/>. The value of this parameter, if specified, MUST be the
base64url <xref target="RFC4648"/> encoding (without padding) of the JWK thumbprint
<xref target="RFC7517"/> of the ACME account key <xref target="I-D.ietf-acme-acme"/>.</t>

<t>If an ACME server finds multiple CAA records pertaining to it (i.e., having
property ‘issue’ or ‘issuewild’ as applicable and a domain that the ACME server
recognises as its own) with different “acme-ak” parameters, the ACME server
MUST NOT consider the CAA record set to authorize issuance unless at least one
of the specified account key thumbprints matches the requesting ACME account
key. A property without an “acme-ak” parameter matches any account key. A
property with an invalid “acme-ak” parameter (i.e. not 43 characters long or
not a valid base64url string), or multiple “acme-ak” parameters is
unsatisfiable.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This specification describes an extension to the CAA record specification
increasing the granularity at which CAA policy can be expressed for ACME-based
CAs. This allows the set of entities capable of successfully requesting
issuance of certificates for a given domain to be restricted beyond that which
would otherwise be possible, while still allowing issuance for specific ACME
account keys. This improves the security of issuance for domains which choose
to employ it, when combined with a CA which implements this specification.</t>

<section anchor="dnssec" title="DNSSEC">

<t>Where a domain chooses to secure its nameservers using DNSSEC, the authenticity
of an ACME account key nomination placed in a CAA record can be assured,
providing that a CA makes all DNS resolutions via an appropriate, trusted
DNSSEC-validating resolver. In this case and so long as control of nominated
keys is retained, a domain is protected from the threat posed by a global
adversary capable of performing man-in-the-middle attacks, which could
otherwise forge DNS responses and successfully obtain ACME authorizations and
certificates for the domain.</t>

</section>
<section anchor="authorization-freshness" title="Authorization Freshness">

<t>The CAA specification governs the act of issuance by a CA. The act of
authorization as described by the ACME protocol occurs separately to issuance
and may occur substantially prior to an issuance request. The CAA policy
expressed by a domain may have changed in the meantime, creating the risk that
a CA will issue certificates in a manner inconsistent with the presently
published CAA policy.</t>

<t>CAs SHOULD consider adopting practices to reduce the risk of such
circumstances. Possible countermeasures include issuing ACME authorizations
with very limited validity periods, such as an hour, or revalidating the CAA
policy for a domain at certificate issuance time.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>None. As per the CAA specification, the parameter namespace for the CAA ‘issue’
and ‘issuewild’ properties has CA-defined semantics. This document merely
specifies a RECOMMENDED semantic for a parameter of the name “acme-ak” for
ACME-based CAs.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC4648' target='http://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization /></author>
<date year='2006' month='October' />
<abstract><t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>



<reference  anchor='RFC6844' target='http://www.rfc-editor.org/info/rfc6844'>
<front>
<title>DNS Certification Authority Authorization (CAA) Resource Record</title>
<author initials='P.' surname='Hallam-Baker' fullname='P. Hallam-Baker'><organization /></author>
<author initials='R.' surname='Stradling' fullname='R. Stradling'><organization /></author>
<date year='2013' month='January' />
<abstract><t>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. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6844'/>
<seriesInfo name='DOI' value='10.17487/RFC6844'/>
</reference>



<reference  anchor='RFC7517' target='http://www.rfc-editor.org/info/rfc7517'>
<front>
<title>JSON Web Key (JWK)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<date year='2015' month='May' />
<abstract><t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.  This specification also defines a JWK Set JSON data structure that represents a set of JWKs.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7517'/>
<seriesInfo name='DOI' value='10.17487/RFC7517'/>
</reference>



<reference anchor='I-D.ietf-acme-acme'>
<front>
<title>Automatic Certificate Management Environment (ACME)</title>

<author initials='R' surname='Barnes' fullname='Richard Barnes'>
    <organization />
</author>

<author initials='J' surname='Hoffman-Andrews' fullname='Jacob Hoffman-Andrews'>
    <organization />
</author>

<author initials='J' surname='Kasten' fullname='James Kasten'>
    <organization />
</author>

<date month='March' day='21' year='2016' />

<abstract><t>Certificates in the Web's X.509 PKI (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names.  Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate.  Today, this verification is done through a collection of ad hoc mechanisms.  This document describes a protocol that a certificate authority (CA) and an applicant can use to automate the process of verification and certificate issuance.  The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-acme-acme-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-acme-acme-02.txt' />
</reference>




    </references>



<section anchor="examples" title="Examples">

<t>The following shows an example DNS configuration which nominates two account
keys as authorized to issue certificates for the domain “example.com”. Issuance
is restricted to the CA “example.net”.</t>

<figure><artwork><![CDATA[
example.com. IN CAA 0 issue "example.net; \
  acme-ak=UKNmi2whPhuAhDvAxGa_aOZgPzyJDhhsrt-8Bt2fWh0"
example.com. IN CAA 0 issue "example.net; \
  acme-ak=rlp4OZPOR9MKejkOdZAKQ5Tfwce6llawmrDIh-BtNJ0"
]]></artwork></figure>

</section>


  </back>
</rfc>