As currently required by the Forum, as specified in 6844. Held for document update means just that - a future version of CAA may adjust the processing rules, consistent with the IETF process. It was not rejected - that is, there was sufficient consensus that it wasn't an outright bad idea - but it's not formally adopted.
However, this does give the Forum something somewhat-stable and reflecting broad-consensus and public participation to consider requiring in the interim, through a subsequent ballot, which would have the effect of 'relaxing' certain provisions of CAA. That is, should a member propose such a ballot, and should the Forum adopt it, this could be integrated - much as we have things such as non-critical nameConstraints to work around since-resolved vendor issues. On Wed, Aug 23, 2017 at 5:31 AM, Mads Egil Henriksveen via Public < public@cabforum.org> wrote: > Hi > > What does this mean for us who are in the process of implementing support > for CAA? > > Do we implement the CAA processing rules according to this errata or do we > need to comply with the current version of RFC6844? > > Regards > Mads > > -----Original Message----- > From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Phillip > via Public > Sent: tirsdag 22. august 2017 22:15 > To: 'CA/Browser Forum Public Discussion List' <public@cabforum.org> > Subject: [cabfpub] FW: [Errata Held for Document Update] RFC6844 (5065) > > We have held for document update! > > > -----Original Message----- > From: RFC Errata System [mailto:rfc-edi...@rfc-editor.org] > Sent: Tuesday, August 22, 2017 12:58 PM > To: phill...@comodo.com; phill...@comodo.com; rob.stradl...@comodo.com > Cc: e...@rtfm.com; i...@ietf.org; p...@ietf.org; rfc-edi...@rfc-editor.org > Subject: [Errata Held for Document Update] RFC6844 (5065) > > The following errata report has been held for document update for RFC6844, > "DNS Certification Authority Authorization (CAA) Resource Record". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5065 > > -------------------------------------- > Status: Held for Document Update > Type: Technical > > Reported by: Phillip Hallam-Baker <phill...@comodo.com> Date Reported: > 2017-07-10 Held by: EKR (IESG) > > 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)) is not empty, 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 chain to its target. If the target label > contains a CAA record, it is returned. > > ?O?therwise, 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). > > To prevent resource exhaustion attacks, CAs SHOULD limit the length of > CNAME chains that are accepted. However CAs MUST process CNAME > chains that contain 8 or fewer CNAME records. > > Notes > ----- > This is the updated errata to replace the ones previously deleted. It has > been reviewed by all the parties concerned. Since this is a breaking > change, this will have to go to hold for document update. The LAMPS working > group is currently considering a more radical re-working of the CAA > discovery scheme as a work item for its new charter. > > I will be in Prague to discuss... > > -------------------------------------- > 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 > > _______________________________________________ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public >
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public