--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 at 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--