[pkix] [Technical Errata Reported] RFC6844 (4992)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC6844,
"DNS Certification Authority Authorization (CAA) Resource Record".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4992

--------------------------------------
Type: Technical
Reported by: Phillip Hallam-Baker <[e-mail]>

Section: 4

Original Text
-------------
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

Corrected Text
--------------
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME 
   alias record chain specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)), then R(X) =
      CAA(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

  Thus, when a search at node X returns a CNAME record, the CA will 
  follow the CNAME record to its target. If the target label contains a 
  CAA record, it is returned. otherwise, the CA continues the search at 
  the parent of node X. 

  Note that the search does not include the parent of a target of a 
  CNAME record (except when the CNAME points back to its own path).

  If the target of a CNAME record is itself a CNAME record, the CA MAY 
  follow it or MAY ignore it. In either case, the search continues at 
  the parent of the label containing the initial CNAME.

  Processing for DNAME is exactly the same as for CNAME. Note that since
  DNAME records are implemented by creating the corresponding CNAME 
  records on the fly, it is only necessary for DNAME records to appear 
  on the wire for purposes of DNSSEC.

Notes
-----
This is a correction to Errata 4998 which is withdrawn.

This is a fuller response to the issue raised in 4515. Note that the algorithm stated in RFC6844 was the algorithm intended at the time it was written. Subsequent implementation has shown that the approach described here is preferable.

This is a breaking change and thus the intended disposition is Hold for Document Update. The principle purpose of this errata is to provide a stable reference for the benefit of CABForum which publishes certificate validation guidelines that mandate CAA. This in turn will avoid the need for work being proposed to provide a full solution to the problem to have to address backwards compatibility with an approach now seen as undesirable.

The issue arises because CNAME records are commonly used for the purpose of host delegation and name delegation and no distinction is made between the two. Nor does the use of DNAME records allow such distinction be made in practice. Further, the limitation that CNAME be the only record in a zone is a liability. The original algorithm was designed to provide an administrative convenience for the name delegation case. Subsequent discussion with CDNs has shown that the host delegation use is sufficiently widespread for this approach to be unsatisfactory.

After discussion in the LAMPS working group, a new approach is being considered which allows both sets of requirements to be met using an extended search algorithm. Until this is done, it is best that implementations do not perform the recursive portion.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6844 (draft-ietf-pkix-caa-15)
--------------------------------------
Title               : DNS Certification Authority Authorization (CAA) Resource Record
Publication Date    : January 2013
Author(s)           : P. Hallam-Baker, R. Stradling
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG