Re: [dnsext] CAA RRTYPE review - result [IANA #434639]

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

Thanks very much to Frederico for paying attention to this while yet
attending to his infant!  That is great dedication to duty.  My deep
gratitude, Fred.

This means that IANA will be assigning a code point soon.  Please look
for it.

There remain some concerns about the document and the way it is
structured.  I trust that DNSEXT participants will offer the authors
constructive proposals on how to make the document say more clearly
what it has been trying to say.

Best regards,

Andrew

On Wed, Apr 06, 2011 at 06:27:57PM -0300, Frederico A C Neves wrote:
> Dear Colleagues,
> 
> Sorry for the extra delay, family matters distracted my attention from
> the ML.
> 
> This message ends the review process for the CAA RRTYPE, according to
> my judgment this request meets both requirements of section 3.1.1 and
> none of section 3.1.2 of RFC5395 and should be accepted.
> 
> Best Regards,
> Frederico Neves
> 
> On Fri, Feb 18, 2011 at 07:34:53PM -0200, 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
> > 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: [e-mail]
> >            International telephone number: [phone]
> >            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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.