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

[Phillip Hallam-Baker <[e-mail]>]

Yes, thank you very much for doing this while trying to juggle infants!

Any comments on the draft are welcome.

On Wed, Apr 6, 2011 at 8:07 PM, Andrew Sullivan <[e-mail]> wrote:

> 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.
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>



-- 
Website: http://hallambaker.com/