[Technical Errata Reported] RFC6844 (4992)
RFC Errata System <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix