[dnsext] CAA RRTYPE review - Comments period end Mar 11th

Frederico A C Neves <fneves@registro.br> Fri, 18 February 2011 21:34 UTC

Return-Path: <fneves@registro.br>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C91B03A6AAE for <dnsext@core3.amsl.com>; Fri, 18 Feb 2011 13:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.446
X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id y6WOPOTg9HFD for <dnsext@core3.amsl.com>; Fri, 18 Feb 2011 13:34:23 -0800 (PST)
Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by core3.amsl.com (Postfix) with ESMTP id 719E83A6EA5 for <dnsext@ietf.org>; Fri, 18 Feb 2011 13:34:23 -0800 (PST)
Received: by clone.registro.br (Postfix, from userid 1000) id 35F7DE04AC; Fri, 18 Feb 2011 19:34:53 -0200 (BRST)
Date: Fri, 18 Feb 2011 19:34:53 -0200
From: Frederico A C Neves <fneves@registro.br>
To: dnsext@ietf.org
Message-ID: <20110218213453.GB96163@registro.br>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Subject: [dnsext] CAA RRTYPE review - Comments period end Mar 11th
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Feb 2011 21:34:24 -0000

Dear Colleagues,

Bellow is a completed template requesting a new RRTYPE assignment
under the procedures of RFC5395.

This message starts a 3 weeks period for an expert-review of the DNS
RRTYPE parameter allocation for CAA specified in
IANA #412190

If you have comments regarding this request please post them here
before Mar 11th 18:00 UTC.

Best Regards,
Frederico Neves

--begin 5395 template CAA--
  A.    Submission Date: 3 Dec 2010

  B.    Submission Type:
        [X] New RRTYPE
        [ ] Modification to existing RRTYPE

  C.    Contact Information for submitter:
           Name: Phillip Hallam-Baker
           Email Address: phill@hallambaker.com
           International telephone number: +1 617 395 4123
           Other contact handles:

           (Note: This information will be publicly posted.)

  D.    Motivation for the new RRTYPE application?
        Please keep this part at a high level to inform the Expert and
        reviewers about uses of the RRTYPE.  Remember most reviewers
        will be DNS experts that may have limited knowledge of your
        application space.

 The Certification Authority Authorization (CAA) DNS Resource Record
  allows a DNS domain name holder to specify the certificate signing
  certificate(s) 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. And is designed to be extensible in order to support related
  concerns including enforcement of issue restriction in applications.

  E.    Description of the proposed RR type.
        This description can be provided in-line in the template, as an
        attachment, or with a publicly available URL:

A detailed specification is posted is given in


  F.    What existing RRTYPE or RRTYPEs come closest to filling that
        need and why are they unsatisfactory?

The only current means by which this information can be expressed
in the DNS is via a TXT record which is not differentiated for this

The approach here addfresses purposes that are clearly outside
the purpose of the CERT record and similar 'keys-in-DNS'

  G.    What mnemonic is requested for the new RRTYPE (optional)?
        Note: This can be left blank and the mnemonic decided after the
        template is accepted.

The proposed mnemonic is CAA standing for Certification Authority

  H.    Does the requested RRTYPE make use of any existing IANA
        Registry or require the creation of a new IANA sub-registry in
        DNS Parameters?

        If so, please indicate which registry is to be used or created.
        If a new sub-registry is needed, specify the allocation policy
        for it and its initial contents.  Also include what the
        modification procedures will be.

Yes, the following registry assignment is requested.

5.2.  Certification Authority Authorization Properties

  IANA [is requested to create] the Certification Authority
Authorization Properties
  registry with the following initial values:

             Meaning                                          Reference
 -----------  -----------------------------------------------  ---------
 path         Authorization Entry by Signature Path            [RFCXXXX]
 policy       Authorization Entry by Certificate Policy        [RFCXXXX]

  Addition of tag identifiers requires a public specification and
  expert review as set out in RFC5395 [RFC5395]

Note that information carried in this record addresses application
layer concerns. As such it is highly desirable to employ a tag-value
approach to attribute specification than the code-value approach that
is employed at lower layers in the stack.

  I.    Does the proposal require/expect any changes in DNS
        servers/resolvers that prevent the new type from being
        processed as an unknown RRTYPE (see [RFC3597])?


  J.    Comments:

While the CAA proposal made in the accompanying Internet Draft
represents a complete technical proposal, development of a full CAA
standard will require further work that cannot be begun until a DNS RR
assignment is made.

In particular the CAA proposal MAY be proposed as the basis of future
minimum issue guidelines for Domain Validated Certificates published
by CA-Browser Forum. It is hard to see how such a proposal could be
made without first obtaining significant experience of enforcing CAA
issue restrictions.

The CAA proposal MAY also be relevant to ongoing work in the IETF
Applications area (WEBSEC) and the security area (TLS, IPSEC, Proposed

Given the large number of moving parts, the proposal has been crafted
with the intention of minimizing the number of dependencies in the
--end 5395 template CAA--