Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th
Phillip Hallam-Baker <hallam@gmail.com> Wed, 09 March 2011 18:32 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E033A6944 for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 10:32:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.047
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tSiBD6qCsFz for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 10:32:35 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 176603A6933 for <dnsext@ietf.org>; Wed, 9 Mar 2011 10:32:35 -0800 (PST)
Received: by iyj8 with SMTP id 8so981334iyj.31 for <dnsext@ietf.org>; Wed, 09 Mar 2011 10:33:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=gmail.com; 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 10.42.77.74 with SMTP id h10mr7827402ick.99.1299695631386; Wed, 09 Mar 2011 10:33:51 -0800 (PST)
Received: by 10.43.61.80 with HTTP; Wed, 9 Mar 2011 10:33:51 -0800 (PST)
In-Reply-To: <20110218213453.GB96163@registro.br>
References: <20110218213453.GB96163@registro.br>
Date: Wed, 09 Mar 2011 13:33:51 -0500
Message-ID: <AANLkTi=gfTHvyBrBJhZ4TQhq6xumFuFZuyP-JgSOyZOK@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Frederico A C Neves <fneves@registro.br>, Ben Laurie <benl@google.com>, Rob Stradling <rob.stradling@comodo.com>
Content-Type: multipart/alternative; boundary="20cf3005dc066cc955049e10f8ea"
Cc: dnsext@ietf.org
Subject: Re: [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: 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 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| | 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 <fneves@registro.br>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 > http://tools.ietf.org/html/draft-hallambaker-donotissue-02 > 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 > draft-hallambaker-donotissue: > > https://datatracker.ietf.org/doc/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 > KIDNS). > > 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 > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/
- [dnsext] CAA RRTYPE review - Comments period end … Frederico A C Neves
- Re: [dnsext] CAA RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - Comments period … Andrew Sullivan
- Re: [dnsext] CAA RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - Comments period … Andrew Sullivan
- Re: [dnsext] CAA RRTYPE review - Comments period … Samuel Weiler
- Re: [dnsext] CAA RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - Comments period … Samuel Weiler
- Re: [dnsext] CAA RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - Comments period … Andrew Sullivan
- [dnsext] [IANA #434639] Re: CAA RRTYPE review - C… Amanda Baber via RT
- Re: [dnsext] CAA RRTYPE review - Comments period … Paul Hoffman
- Re: [dnsext] [IANA #434639] Re: CAA RRTYPE review… Andrew Sullivan
- Re: [dnsext] CAA RRTYPE review - result [IANA #43… Frederico A C Neves
- Re: [dnsext] CAA RRTYPE review - result [IANA #43… Andrew Sullivan
- Re: [dnsext] CAA RRTYPE review - result [IANA #43… Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - result [IANA #43… Paul Wouters