[cabfpub] FW: [Errata Held for Document Update] RFC6844 (5065)
Jacob Hoffman-Andrews
jsha at letsencrypt.org
Fri Aug 25 19:50:23 UTC 2017
This looks good to me.
On Fri, Aug 25, 2017 at 9:00 AM, Phillip <philliph at comodo.com> wrote:
>
>
> I will endorse for Comodo but I don’t think we are quite there yet :)
>
>
> Some further wordsmithing:
>
> > As part of the issuance process, the CA MUST check for a CAA record for
> each dNSName in the subjectAltName extension of the certificate to be
> issued, according to the procedure in RFC 6844 as amended by Errata 5065
> (Appendix A), following the processing instructions set down in RFC 6844
> for any records found. If the CA issues, they MUST do so within the TTL of
> the CAA record, or 8 hours, whichever is greater.
>
>
> As part of the issuance process, the CA MUST check for CAA records and
> follow the processing instructions for any records found, for each dNSName
> in the subjectAltName extension of the certificate to be issued, as
> specified in RFC 6844 as amended by Errata 5065 (Appendix A). If the CA
> issues, they MUST do so within the TTL of the CAA record, or 8 hours,
> whichever is greater.
>
>
> Basically, this is just taking the original text and moving the reference
> to the end for the instructions to which it applies.
>
>
>
> Any further changes?
>
>
>
> *From:* Mads Egil Henriksveen [mailto:Mads.Henriksveen at buypass.no]
> *Sent:* Friday, August 25, 2017 12:44 AM
> *To:* Jacob Hoffman-Andrews <jsha at letsencrypt.org>; Phillip <
> philliph at comodo.com>; CA/Browser Forum Public Discussion List <
> public at cabforum.org>
> *Cc:* Ryan Sleevi <sleevi at google.com>
> *Subject:* RE: [cabfpub] FW: [Errata Held for Document Update] RFC6844
> (5065)
>
>
>
>
>
> I will endorse for Buypass.
>
>
>
> Regards
>
> Mads
>
>
>
> *From:* Jacob Hoffman-Andrews [mailto:jsha at letsencrypt.org
> <jsha at letsencrypt.org>]
> *Sent:* fredag 25. august 2017 00:01
> *To:* Phillip <philliph at comodo.com>; CA/Browser Forum Public Discussion
> List <public at cabforum.org>
> *Cc:* Ryan Sleevi <sleevi at google.com>; Mads Egil Henriksveen <
> Mads.Henriksveen at buypass.no>
> *Subject:* Re: [cabfpub] FW: [Errata Held for Document Update] RFC6844
> (5065)
>
>
>
> This looks good, and I will endorse for Let's Encrypt. Do we have another
> endorser present? I'd like to get this to a ballot quickly to minimize any
> end-user confusion over the specifics.
>
>
>
> One small tweak to the new text:
>
>
>
> > As part of the issuance process, the CA MUST check for a CAA record for
> each dNSName in the subjectAltName extension of the certificate to be
> issued, according to the procedure in RFC 6844 as amended by Errata 5065
> (Appendix A), following the processing instructions set down in RFC 6844
> for any records found. If the CA issues, they MUST do so within the TTL of
> the CAA record, or 8 hours, whichever is greater.
>
>
>
> Since this references 6844 twice, it's slightly ambiguous. I would instead
> just reference it once:
>
>
>
> > As part of the issuance process, the CA MUST check for a CAA record for
> each dNSName in the subjectAltName extension of the certificate to be
> issued, according to the procedure in RFC 6844 as amended by Errata 5065
> (Appendix A). If the CA issues, they MUST do so within the TTL of the CAA
> record, or 8 hours, whichever is greater.
>
>
>
>
>
> On Wed, Aug 23, 2017 at 10:12 AM, Phillip via Public <public at cabforum.org>
> wrote:
>
> I am just working on wording for a proposal.
>
>
>
>
>
> Proposal: Modify the Baseline Requirements v1.4.9 as follows:
>
>
>
> 3.2.2.8. CAA Records
>
>
>
> Change:
>
>
>
> As part of the issuance process, the CA MUST check for a CAA record for
> each dNSName in the subjectAltName extension of the certificate to be
> issued, according to the procedure in RFC 6844, following the processing
> instructions set down in RFC 6844 for any records found. If the CA issues,
> they MUST do so within the TTL of the CAA record, or 8 hours, whichever is
> greater.
>
>
>
> To:
>
>
>
> As part of the issuance process, the CA MUST check for a CAA record for
> each dNSName in the subjectAltName extension of the certificate to be
> issued, according to the procedure in RFC 6844 as amended by Errata 5065
> (Appendix A), following the processing instructions set down in RFC 6844
> for any records found. If the CA issues, they MUST do so within the TTL of
> the CAA record, or 8 hours, whichever is greater.
>
>
>
>
>
> Add the following
>
>
>
> Appendix A:
>
>
>
> 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 <philliph at 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.
>
> 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).
>
> 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.
>
>
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Wednesday, August 23, 2017 10:04 AM
> *To:* Mads Egil Henriksveen <Mads.Henriksveen at buypass.no>; CA/Browser
> Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] FW: [Errata Held for Document Update] RFC6844
> (5065)
>
>
>
> 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 at 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-bounces at cabforum.org] On Behalf Of Phillip
> via Public
> Sent: tirsdag 22. august 2017 22:15
> To: 'CA/Browser Forum Public Discussion List' <public at 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-editor at rfc-editor.org]
> Sent: Tuesday, August 22, 2017 12:58 PM
> To: philliph at comodo.com; philliph at comodo.com; rob.stradling at comodo.com
> Cc: ekr at rtfm.com; iesg at ietf.org; pkix at ietf.org; rfc-editor at 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 <philliph at 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.
>
> 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).
>
> 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 at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170825/22d4c989/attachment-0003.html>
More information about the Public
mailing list