DNS Certification Authority Authorization (CAA) Resource Record
draft-ietf-pkix-caa-15

IANA has reviewed draft-ietf-pkix-caa-15 and has the following comments:

IANA has questions about the IANA actions requested in this document.

IANA understands that, upon approval of this document, there are three actions
which IANA must complete.

First, IANA has made a provisional registration which will be made permanent and
which will have its reference updated to [ RCF-to-be ].

In the Resource Record (RR) TYPEs subregistry of the Domain Name System (DNS)
Parameters registry located at:

http://www.iana.org/assignments/dns-parameters

IANA has made a provisional assignment of Resource Record Type 257 for the CAA
Resource Record Type and added the line below to the registry. This
registration should not be made permanent and its reference updated to
[ RFC-to-be ]

TYPE Value and meaning Reference
----------- --------------------------------------------- -------------
CAA 257 Certification Authority Restriction [ RFC-to-be ]

IANA Question --> Is the line depicted above as described in the document
be added to or be replaced the existing assigned Resource Record Type 257:

CAA 257 Certification Authority Authorization [Hallam-Baker]

?

Second, IANA is requested to create a new registry. The new registry will be
called the Certification Authority Authorization Properties registry. New
registrations require public specification and expert review using the
methodology of Section 3.1.1 of RFC 6195. There are initial registrations in
this registry as follows:

Tag Meaning Reference
----------- ---------------------------------- ---------
issue Authorization Entry by Domain [ RFC-to-be ]
issuewild Authorization Entry by Domain [ RFC-to-be ]
iodef Report incident by IODEF report [ RFC-to-be ]
auth Reserved draft-hallambaker-donotissue-04
path Reserved draft-hallambaker-donotissue-04
policy Reserved draft-hallambaker-donotissue-04

IANA Question --> Should this be a standalone registry or should it be housed
along with other PKIX parameters at: Public Key Infrastructure using X.509
(PKIX) Parameters
(http://www.iana.org/assignments/pkix-parameters/pkix-parameters.xml)?

Third, IANA is requested to create another new registry. The new registry will
be called the Certification Authority Authorization Flags registry. New
registrations in this registry are done through RFC Required as specified in RFC
5226. There are initial registrations in this new registry as follows:

Flag Meaning Reference
----------- ---------------------------------- -------------
0 Issuer Critical Flag [ RFC-to-be ]
1-7 Reserved [ RFC-to-be ]

IANA Question --> Should this be a standalone registry or should it be housed
along with other PKIX parameters at: Public Key Infrastructure using X.509
(PKIX) Parameters
(http://www.iana.org/assignments/pkix-parameters/pkix-parameters.xml)?

IANA understands that these three actions are the only ones required to
be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

[Ballot comment]
[Updated for -15]
One non-blocking comment still remains in this version:
You have to move the Acknowledgments up a level in the sections: it's now Section 7.4, and I think you want it to be a top-level section (8), and not part of the IANA Considerations.  :-)

I returned this document to the PKX WG after Brian's DISCUSS (from DNS Directorate) resulted in changes to the CAA record location / tree climbing processing.  It passed through WGLC and I issued another IETF LC to make sure everybody else gets a chance to see the changes.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (DNS Certification Authority Authorization (CAA) Resource Record) to Proposed Standard


The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'DNS Certification Authority Authorization (CAA) Resource Record'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Certification Authority Authorization (CAA) DNS Resource Record
  allows a DNS domain name holder to specify one or more Certification
  Authorities (CAs) 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.  This document defines the syntax of the CAA
  record and rules for processing CAA records by certificate issuers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
(Damn. Updating my comment as *I* screwed up the ABNF I gave you the first time. Which is why I'd like to see an external reference to it. But let's try again.)

  label = 1* (ALPHA / DIGIT / "-" )

If you're trying to conform to host syntax, I wish you would reference it from another RFC. In any event, the above is not correct. Try:

  label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))

[Ballot comment]
[Updated for -13; cleared the DISCUSS]

Version -12: Thank you for adding instructions for the designated expert; that goes a long way toward resolving my issue.

Version -13: I'm happy with the clarification of "[RFC6195], Section 3.1.1." for the policy in Section 7.2; issue resolved, and thanks.


One thing I missed before, which I now notice from the addition of Section 7.3, is that you have to move the Acknowledgments up a level in the sections: it's now Section 7.4, and I think you want it to be a top-level section (8), and not part of the IANA Considerations.  :-)

[Ballot comment]
Thanks for addressing my DISCUSS points and comments.

There are a few editorial mistakes (concatenated words) in the RRSet definition that can be fixed with an RFC Editor's note.

[Ballot discuss]
Thanks for working through most of these issues.  I am updating based on the -12 version...

1. Resolved

2. The definition of "Resource Record" has several issues.  First, it does not incorporate the fact that RRs come in sets. Given that, this definition is stretching things to the point of being misleading. A proposed fix to the definition is :
"A particular entry in the DNS including the owner name, class, type, time to live, and data, as defined in [RFC1035] and [RFC2181].  Resource records come in sets identified by the owner name, class, and type.  The time to live on all RRs is always the same.  The data may be different among RRs in an RRset."

3. Section 2.1 gives this example for specifying additional information:

  $ORIGIN example.com
  .      CAA 0 issue "ca.example.net; account=230123"

And the text following it states : "The syntax of additional parameters is a sequence of tag-value pairs
  as defined in section [RFC5234].

The above appears to be trying to reference a specific section of 5234.  It is difficult to determine if the example is correct without knowing *which* section of RFC 5234 to reference.

4. Resolved

5. Resolved

[Ballot comment]
1. Resolved

2. The use of ASCII encoding for the tags is confusing.  It would appear that the tags could be a bit field given their usage.

3. Fixed

4. The definition of Domain is confusing given its use of the term "resources".  These resources cannot be resource records, so what are they?  Andrew also pointed out that this definition gets even more confusing given the use of the "domain" in the ABNF in section 4.2.

5. Fixed

6. Fixed

7. Fixed

8. Fixed

9. Does section 4.3 constrain iodef URLs to the mailto and http[s] schemes only?

10. Fixed

[Ballot discuss]
[Updated for -12; I'm just working from new I-Ds here, and have not received any discussion from the authors.]

In section 6.2:
  Addition of tag identifiers requires a public specification and
  expert review as set out in [RFC6195].

Thank you for adding instructions for the designated expert; that goes a long way toward resolving my issue.

RFC 6195 isn't the usual reference for IANA registration policies (we usually use RFC 5226).  Using another is fine if it's clear what you mean, so what section of 6195 defines the expert review policy you're talking about?  The phrase "Expert Review" (capitalized, as it turns out) appears twice in Section 3.1.1, in reference to DNS RRTYPE allocations, and it's quite specific to DNS RRTYPEs -- it requires posting a message with a specific template to dnsext@ietf.org, for example.

Do you mean to use that procedure, including posting to dnsext@ietf.org?  If that's right, it will probably help to change the reference to add the section number, like this:

NEW
  Addition of tag identifiers requires a public specification and
  Expert Review as set out in [RFC6195], Section 3.1.1.

That will make it clear that you intend to invoke that process.

[Ballot discuss]
[Updated for -12; I'm just working from new I-Ds here, and have no received any discussion from the authors.]

In section 6.2:
  Addition of tag identifiers requires a public specification and
  expert review as set out in [RFC6195].

Thank you for adding instructions for the designated expert; that goes a long way toward resolving my issue.

RFC 6195 isn't the usual reference for IANA registration policies (we usually use RFC 5226).  Using another is fine if it's clear what you mean, so what section of 6195 defines the expert review policy you're talking about?  The phrase "Expert Review" (capitalized, as it turns out) appears twice in Section 3.1.1, in reference to DNS RRTYPE allocations, and it's quite specific to DNS RRTYPEs -- it requires posting a message with a specific template to dnsext@ietf.org, for example.

Do you mean to use that procedure, including posting to dnsext@ietf.org?  If that's right, it will probably help to change the reference to add the section number, like this:

NEW
  Addition of tag identifiers requires a public specification and
  Expert Review as set out in [RFC6195], Section 3.1.1.

That will make it clear that you intend to invoke that process.

[Ballot comment]
I have no objection to the publication of this document and only a
couple of (well, four) trivial obeservations.

---

Would be nice to add just a couple of words to what is otherwise a good
Abstract to say what this document actually does.

---

The RFC editor will probably want to work with you to move the
Introduction to be the first section in the document.

---

I don't think Section 6.3 should be a subsection of Section 6!

---

Are you sure that you dn't want an IANA registry for the Flags field
defined in Section 4.1?

[Ballot comment]
  label = 1* (ALPHA / DIGIT / "-" )

If you're trying to conform to host syntax, I wish you would reference it from another RFC. In any event, the above is not correct. Try:

  label = (ALPHA / DIGIT) *(["-"] (ALPHA / DIGIT))

[Ballot discuss]
[Update: DNS Directorate review has arrived, and Brian is handling the issues from that. I'm removing that from my DISCUSS.]

One point remaining:

In section 6.2:
  Addition of tag identifiers requires a public specification and
  expert review as set out in [RFC6195]

RFC 6195 isn't the usual reference for IANA registration policies (we usually use RFC 5226).  Using another is fine if it's clear what you mean, but I don't see that it is: What section of 6195 defines the expert review policy you're talking about?  The phrase "Expert Review" (capitalized, as it turns out) appears twice in Section 3.1.1, in reference to DNS RRTYPE allocations, and it's quite specific to DNS RRTYPEs -- it requires posting a message with a specific template to dnsext@ietf.org, for example, and it gives guidelines to the expert (in Section 3.1.2) that don't seem to be applicable here (they're also specific to RRTYPEs).

Please clarify what the policy is, exactly where it's documented, and what the designated expert is supposed to consider in her review.

[Ballot discuss]
Many of these points come out of the DNS Directorate review performed by Andrew Sullivan...

1. The definition of "Public Delegation Point" is incomplete given previous definitions of the same thing, albeit by different names.  The suggestion to address this is to add something to the definition like : "Also known as public suffix, effective TLD, and public domain".  It would also be good to strike the term "suffix" from the definition.  More importantly, this definition does not seem to agree with the text in section 2.1.  In 2.1, the draft says "Since the policy is published at the Public Delegation Point, the policy applies to all subordinate domains..." The definition of Public Delegation Point means that "com" is the delegation point ("under which DNS names are delegated": "com" does the delegation).  Second, this seems to suggest that the policy flows top-down and constrains subordinate names, but that's not what's in section 3.

2. The definition of "Resource Record" has several issues.  First, it does not incorporate the fact that RRs come in sets. Given that, this definition is stretching things to the point of being misleading. A proposed fix to the definition is :
"A particular entry in the DNS including the owner name, class, type, time to live, and data, as defined in [RFC1035] and [RFC2181].  Resource records come in sets identified by the owner name, class, and type.  The time to live on all RRs is always the same.  The data may be different among RRs in an RRset."

3. Section 2.1 gives this example for specifying additional information:

  $ORIGIN example.com
  .      CAA 0 issue "ca.example.net; account=230123"

And the text following it states : "The syntax and semantics of such parameters is left to site policy and is outside the scope of this document."

If the above is true, how does a consumer of this information know that the ";" is a separation character?  If this document is defining the "issue" tag, shouldn't have to specify the syntax?

4. It appears that the Extended Issuer Authorization Set notation (section 3) needs some work.  The first issue is the one raised in the Gen-ART review about tree-climbing.  The other is the implicit constraint that this notation puts on subordinate names.  If I control a domain with a published CAA record and delegate a sub-domain to someone, they are stuck using the CA of my choice unless they publish their own CAA.

5. Section 3 also states the following:

  The DNS defines the CNAME and DNAME mechanisms for specifying domain
  name aliases.  The canonical name of a DNS name is the name that
  results from performing all DNS alias operations.  An issuer MUST
  perform CNAME and DNAME processing as defined in the DNS
  specifications [RFC1035] to resolve CAA records.

In combination with the tree-climbing issue, this is going to be problematic.  Suppose we have :

    example.net DNAME example.com
    example.net CAA [$x]
    foo.example.com CAA [$y]

If someone requests a certificate for bar.foo.example.net, does the CAA at example.net rule, or the CAA at foo.example.com?  It appears that the one at foo.example.com would be chosen because the alias resolution appears to be performed before anything else.  Is that the intent?

[Ballot comment]
1. The issue of tree-walking (mentioned in Russ' position) was also identified as an issue by Andrew Sullivan during his DNS Directorate review.  It would be good to get that issue resolved.

2. The use of ASCII encoding for the tags is confusing.  It would appear that the tags could be a bit field given their usage.

3. The terms "Canonical Domain Name" and "Canonical Domain Name Value" are not used anywhere in the draft even though they are defined.  I would suggest striking them from section 1.2.  If the definitions are kept, and properly used in the document, I would suggest expanding the definition of Canonical Domain Name to include discussion of DNAME aliases.

4. The definition of Domain is confusing given its use of the term "resources".  These resources cannot be resource records, so what are they?  Andrew also pointed out that this definition gets even more confusing given the use of the "domain" in the ABNF in section 4.2.

5. The definition of "Domain Name" should reference RFC 1034, rather than RFC 1035.

6. The definition of "Domain Name System" should reference STD13.  STD13 refers to both RFC 1034 and RFC 1035.

7. The definition of "DNS Security" should reference RFCs 4033, 4034, 4035, and 5155.

8. The ABNF in 4.2 constrains domains to the hostname/LDH syntax. The draft should make an explicit statement about that limitation since the draft suggests that you can use CAA for "domain names", but not for domain names made up entirely of LDH-labels.

9. Does section 4.3 constrain iodef URLs to the mailto and http[s] schemes only?

10. Section 5.3 suggests that complete failure to get an answer for CAA queries for a name results in the issuer refusing to issue a certificate.  This could be stated more directly.

[Ballot comment]
Should automata processing a record with the iodef property do any sort of validation of the URI it finds there before using it? (The examples point into the same domain, but that's not a restriction, right?).

The draft says "Web Service" a few times, sometimes capitalized that way, when pointing to RFC6546. This could lead to confusion with WSDL/SOAP which RFC6546 does not use.

[Ballot discuss]
Two items here:

(1) From the shepherd writeup:
> There has been relatively little on-list discussion of the more recent
> versions of this document. Conceptually it is simple, from a PKI
> perspective. If there are errors, they are likely to be in the DNS arena.
>
> A DNS expert should review the document to make sure that the DNS
> aspects are accurate.

As far as I can see (I've checked list archives), no review by DNS experts has happened, despite the shepherd's report that one is needed.  So let's get one.  I'm explicitly including  on this and asking for a DNS Directorate review before we move this document forward.
[Update: Sean had requested one already, and I'll keep this DISCUSS as a placeholder until it comes through.]

(2) In section 6.2:
  Addition of tag identifiers requires a public specification and
  expert review as set out in [RFC6195]

RFC 6195 isn't the usual reference for IANA registration policies (we usually use RFC 5226).  Using another is fine if it's clear what you mean, but I don't see that it is: What section of 6195 defines the expert review policy you're talking about?  The phrase "Expert Review" (capitalized, as it turns out) appears twice in Section 3.1.1, in reference to DNS RRTYPE allocations, and it's quite specific to DNS RRTYPEs -- it requires posting a message with a specific template to dnsext@ietf.org, for example, and it gives guidelines to the expert (in Section 3.1.2) that don't seem to be applicable here (they're also specific to RRTYPEs).

Please clarify what the policy is, exactly where it's documented, and what the designated expert is supposed to consider in her review.

[Ballot comment]
I agree with the points raised by Barry and Russ. 

Building on one of Stephen's comments: are the requirements
for archiving DNS transactions regarding CAA based on
actual audit requirements or are they speculative?  Why would
this document include those specific requirements instead of
a more general statement about "meeting audit requirements"
from whatever audit process is employed?

Minor editorial suggestion: in section 3, I think you should cite
more than just RFC 1035 as references for CNAME and DNAME
processing.

[Ballot discuss]
Two items here:

(1) From the shepherd writeup:
> There has been relatively little on-list discussion of the more recent
> versions of this document. Conceptually it is simple, from a PKI
> perspective. If there are errors, they are likely to be in the DNS arena.
>
> A DNS expert should review the document to make sure that the DNS
> aspects are accurate.

First, I find it distressing that the shepherd would send the document to the IESG without having arranged for that (and I guess I also have to beat up on Sean for accepting it).  One can easily ask the dnsop-chairs to arrange for a review, or contact the int-ads and ask for a DNS Directorate review -- and one should.

But this DISCUSS is because, as far as I can see (I've checked list archives), no review by DNS experts has happened, despite the shepherd's report that one is needed.  So let's get one.  I'm explicitly including  on this and asking for a DNS Directorate review before we move this document forward.

(2) In section 6.2:
  Addition of tag identifiers requires a public specification and
  expert review as set out in [RFC6195]

RFC 6195 isn't the usual reference for IANA registration policies (we usually use RFC 5226).  Using another is fine if it's clear what you mean, but I don't see that it is: What section of 6195 defines the expert review policy you're talking about?  The phrase "Expert Review" (capitalized, as it turns out) appears twice in Section 3.1.1, in reference to DNS RRTYPE allocations, and it's quite specific to DNS RRTYPEs -- it requires posting a message with a specific template to dnsext@ietf.org, for example, and it gives guidelines to the expert (in Section 3.1.2) that don't seem to be applicable here (they're also specific to RRTYPEs).

Please clarify what the policy is, exactly where it's documented, and what the designated expert is supposed to consider in her review.

IANA has reviewed draft-ietf-pkix-caa-10 and has the following comments:

IANA has a question about the IANA Actions requested in this document.

IANA understands that, upon approval of this document, there are two IANA
actions which must be completed.

First, in the Resource Record (RR) TYPEs subregistry of the Domain Name System
(DNS) Parameters located at:

http://www.iana.org/assignments/dns-parameters

the entry:

RR Name Value and meaning Reference
----------- --------------------------------------------- ---------
CAA 257 Certification Authority Restriction

has already been registered via early registration. Upon approval of this
document, the reference will be changed to [RFC-to-be].

Second, a new registry will be created called the "Certification Authority
Authorization Properties" registry. Maintenance of the new registry will be
done via public specification and expert review.

IANA Question --> Should this new registry be listed with other PKIX
parameters registries located at:

http://www.iana.org/protocols/

There are initial values for the new registry as follows:

Tag Meaning Reference
----------- ----------------------------------------------- ---------
issue Authorization Entry by Domain [RFC-to-be]
iodef Report incident by means of IODEF format report [RFC-to-be]
auth Reserved
path Reserved
policy Reserved

IANA Question --> where have the last three initial values been reserved?
Should the reference for those values also point to [RFC-to-be]?

IANA understands that these two actions are the only ones that need to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed until the
document has been approved for publication as an RFC. This message is only to
confirm what actions will be performed.

[Ballot comment]

- I agree with Russ' discuss - the "tree-walking vs. not"
disussion needs to be worked through before this is ready.  Is
the wildcard cert part of the gen-art review part of Russ'
discuss? I think the authors also said they'd fix that.

- Overall comment: I think this is a fine function to offer, but
this draft is IMO over complicated and could be a lot simpler.
Nonetheless, I think it can be used as-is, so going forward is
better than holding it up, modulo Russ' discuss.

- A suggested addition for the abstract: "CAA Resource Records
are intended for consumption by CAs and not by other entities
involved in public key infrastrucures." I think it'd help the
reader to get that from the abstract.  I don't care how that's
worded but the above might work.

- Section 1.2: (This was nearly a discuss but I expect it'll be
sorted as part of Russ' discuss.) The definition of Public
Delegation Point is imprecise.  I realise any precise definition
is controversial but you include it in the tree-walking
algorithm here and different interpretations could lead to
unexpected non-issuance without any attack. I think that at
least needs to be noted.

- Section 2: While you do define the term "Certificate
Evaluator" properly, I don't personally like the term, as I
think its too easily confused with RP. However, that's just me,
so this isn't discuss-worthy, but I nonetheless think it'd be
worth the following change in the last para before 2.1: s/CAA
Records MAY be used by Certificate Evaluators/CAA Records MAY be
used by Certificate Evaluators (who are, by definition, not
Relying Parties)/

- You probably should say that "1" means "set" for Issuer
Critical and "0" means unset.

- Using "MUST NOT" as part of an example seems wrong since 2119
language would be better avoided there.  I'd suggest s/The
following example informs CAs that certificates MUST NOT/The
following example informs CAs that certificates ought not/

- Be good to provide a reference so people can understand the
zone file syntax used in the examples.

- The first example in 2.1 refers to this being at the public
delegation point, but you've not said anything about that so
far, other than the definition.

- Section 3, 1st para, might be better to s/the CA/ a compliant
CA/ in the last sentence of this para.

- Last para before 3.1 says "unless the certificate conforms"
but I didn't think you were defining conformance for
certificates, maybe s/certificate/Issuer/ here?

- DNSSEC can demonstrate non-existence of a domain.  If an
Issuer receives a request for foo.bar.example.com and DNSSEC
shows there's no such domain then oughtn't that result in
non-issuance for a compliant CA? Worth a mention here? (I'd say
maybe.)

- I personally doubt that use of DNSSEC gives an issuer a
non-repudiable proof. I'd delete the phrase.

- Is the ABNF for 'parameter' correct? Looks wrong to me.

- I think this bit of 5.2 is badly stated: " A CA MUST mitigate
this risk by employing DNSSEC verification whenever possible and
rejecting certificate requests in any case where it is not
possible to verify the non-existence or contents of a relevant
CAA record." I think you want to say that "a compliant CA MUST
implement DNSSEC validation" but I'm not sure you can say
anything about rejecting requests really.

- 6.1, 1st para is missing a ")" before "deleted."

- 6.2, I don't get why "auth," "path" and "policy" are reserved
without any further mention.

- 6.2, the public CA business can be competitive. If you could
specify more about when the expert is supposed to say yes or no,
that'd be good, especially if (as is probably likely) the expert
is liable to end up being employed by some CA operator.

[Ballot discuss]

  The Gen-ART Review by Richard Barnes on 6-July-2012 started a
  discussion.  Some points have been resolved, and others have not.
  Looking in the entry associated with the public delegation point
  as opposed to tree walking has not reached closure.  When the
  discussion does reach closure, I believe the document should be
  updated to capture the agreed points from the discussion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (DNS Certification Authority Authorization (CAA) Resource Record) to Proposed Standard


The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'DNS Certification Authority Authorization (CAA) Resource Record'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Certification Authority Authorization (CAA) DNS Resource Record
  allows a DNS domain name holder to specify one or more Certification
  Authorities (CAs) 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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by_RFC 4858_, this is the current template for the Document
Shepherd Write-Up. This version is dated 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
*Standards track, since it specifies how to represent an X.509
certificate in a specific type of DNS record, for use in mitigating
attacks against the set of public trust anchors typically used by browsers.

*is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

*Yes.

*(2) The IESG approval announcement includes a Document Announcement

Write-Up. The approval announcement contains the following sections:


Technical Summary

*The Certification Authority Authorization (CAA) DNS Resource Record
allows a DNS domain name holder to specify one or more Certification
Authorities 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.


*Working Group Summary

*This document might have been pursued in other WGs, specifically
DNSEXT, since it specifies a new DNS record type. It also might have
been pursued in DANE, but the focus of DANE is sufficiently different
that it is probably not a good fit there. Because the document specifies
a DNS record type, for use with PKI technology, PKIX was reasonable
choice for the authors. There was some controversy initially, but that
went away over time.


*Document Quality

*I am not aware of any existing implementations of the protocol, but
both authors work for a company that is represented by a trust anchor in
browsers and operating systems, and thus it is likely that their
organization will support this proposal via an implementation.

*Personnel

*Steve Kent is the Document Shepherd, and Sean Turner the Responsible
Area Director.

*(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

*I read the document and suggested a number of edits to improve
readability. The authors complied and I am happy with the results.

*(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

*There has been relatively little on-list discussion of the more recent
versions of this document. Conceptually it is simple, from a PKI
perspective. If there are errors, they are likely to be in the DNS arena.

*(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

*A DNS expert should review the document to make sure that the DNS
aspects are accurate.

*(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

*As noted above, I am not confident in my ability to review the
DNS-specific aspects of the document.

*(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

*I contacted the authors and they confirmed that there are no relevant
IPR disclosures, to the best of their knowledge.

*(8) Has an IPR disclosure been filed that references this document?

*Not to the best of my knowledge, based on a check of the IETF IPR
disclosure database.

*(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

*Most PKIX members do not seem to care about this document. Folks who
care about the recent spate of trust anchor security breaches see this
as a possible mitigation strategy.

*(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

*I am aware of no threatened appeals.

*(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

*I have processed version 10 of this document with I-D nits (verbose
mode) and there re no errors, just a reference warning.

*(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

*There is no MIB, and no media types definitions in this document. Only
example URIs are employed, and they are simple types of URIs.

*(13) Have all references within this document been identified as either
normative or informative?

*Yes.

*(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

*No.

*(15) Are there downward normative references (see RFC 3967)?

*There are no down references.

*(16) Will publication of this document change the status of any
existing RFCs?

*No.

*(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.

*This document calls for creation of a new IANA registry. The name
seems to be reasonable, as per RFC 5226. Initial registry entry values
have been specified, and the format for registry entries seems to be
well-specified.

*(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

*There is one registry, called "Certification Authority Authorization
Properties." The document notes that creation of new entries requires
expert review.

*(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

*N/A.*