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

Phillip Hallam-Baker <> Wed, 09 March 2011 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02E033A6944 for <>; Wed, 9 Mar 2011 10:32:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.047
X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9tSiBD6qCsFz for <>; Wed, 9 Mar 2011 10:32:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 176603A6933 for <>; Wed, 9 Mar 2011 10:32:35 -0800 (PST)
Received: by iyj8 with SMTP id 8so981334iyj.31 for <>; Wed, 09 Mar 2011 10:33:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gO6QWQJll10LHB5BGn/A8m9USHEy6BEsr+/G10hKesM=; b=vmbV3PC/2nOvJGwIuUO8g0ahs9arCMSVFBjf0ql7zUJXOq9Auus7DBVkpFfQoM/0BU P33dZmrQTXTb5SeqqUHOfeZCCIGRJyoDyQcRe0qpRQSdY1U0VqCoUpkbAM/K8rThfGHx 6YRuYsvvhYMJGO/Fi3vptX3xAXzn2YkI1RMMI=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PV+My0mxl7GGMRS94xouSNStAeit36TKUn5R6fWplO7TGZSekBObsE+6Nxx2QUpIvF Gfjp3jlBx4nA4yBlDZkcNzWzc91qmBamVoW8JnvGFAzVlb/Nxk5HvMlanb1nsvKWw/eu lp9bePa/D+WMPfkBYguntht6dDBDrvnONibEI=
MIME-Version: 1.0
Received: by with SMTP id h10mr7827402ick.99.1299695631386; Wed, 09 Mar 2011 10:33:51 -0800 (PST)
Received: by with HTTP; Wed, 9 Mar 2011 10:33:51 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Wed, 09 Mar 2011 13:33:51 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Frederico A C Neves <>, Ben Laurie <>, Rob Stradling <>
Content-Type: multipart/alternative; boundary="20cf3005dc066cc955049e10f8ea"
Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Mar 2011 18:32:37 -0000

Just to be clear here, what is being proposed here is the version of the
specification described in the -02 version of the draft which was simplified
in response to feedback from the list.

In particular we removed a feature from the previous version of the
specification that allowed a single CAA RR to contain a list of property
entries. That was considered to be confusing

Looking through the draft, there is a typo where some text in 3.1 seems to
have escaped this change and may be the source of confusion.

The CAA data field consists of a sequence of at least one property entry.
 Each property entry consists of a sequence of:

This should read.

The CAA data field contains one property entry.  A property entry consists
of a sequence of:

I also note that I did not do a block diagram of the data section. This
should be

| Flags          | Tag Length = n |
| Tag char 0     | Tag Char 1     |...| Tag Char n    |
| Data byte 0    | Data byte 1    |...| Data byte m   |

Where n is the length specified in the tag length field and m is the
remaining octets in the data field (m = l - n - 2) where l is the length of
the data section.

I will make these corrections to the editing copy of the draft.

This does not change the intended semantics of the proposal.

On Fri, Feb 18, 2011 at 4:34 PM, Frederico A C Neves <>wrote:

> 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:
>           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
> draft-hallambaker-donotissue:
>  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
> purpose.
> The approach here addfresses purposes that are clearly outside
> the purpose of the CERT record and similar 'keys-in-DNS'
> approaches.
>  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
> Authorization.
>  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])?
> No.
>  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
> system.
> --end 5395 template CAA--
> _______________________________________________
> dnsext mailing list