I think the order of proposed operations is inverted - we should resolve this in IETF first, and then the CA/Browser Forum, much like the other Erratum.
On Wed, Jan 24, 2018 at 4:45 PM, Corey Bonnell via Public < [email protected]> wrote: > Hello, > > I reported an ambiguity in the CAA RFC (RFC 6844) two weeks ago on the > IETF LAMPS WG mailing list: https://www.ietf.org/mail- > archive/web/spasm/current/msg01104.html. Tim and Quirin responded to the > initial email (links to their responses are at the bottom of that page) > with excellent feedback and comments. > > > > This issue was further discussed on last week’s Validation WG call, where > it was decided that this ambiguity be resolved with a “two-pronged” > approach. Specifically, to address the ambiguity in the short term, we are > proposing some clarification in the wording of BR section 3.2.2.8 to allow > for CAA processing consistent with the intent of the RFC. To address this > ambiguity in the long term, a IETF erratum will be filed to clarify the > wording in RFC 6844-bis. > > > > I am looking for two endorsers for this Draft ballot. > > > > The following motion has been proposed by Corey Bonnell of Trustwave and > endorsed by the following CA/B Forum member representatives: XXXX and YYYY > to clarify handling of CAA Record Sets with no "issue"/"issuewild" property > tag as described in the Ballot. > > > > Purpose of this ballot: > > > > RFC 6844 contains an ambiguity in regard to the correct processing of a > non-empty CAA Resource Record Set that does not contain any issue property > tag (and also does not contain any issuewild property tag in the case of a > Wildcard Domain Name). It is ambiguous if a CA must not issue when such a > CAA Resource Record Set is encountered, or if such a Resource Record Set is > implicit permission to issue. > > > > Given that the intent of the RFC is clear (such a CAA Resource Record Set > is implicit permission to issue), we are proposing the following change to > allow for CAA processing consistent with the intent of the RFC. > > > > -- MOTION BEGINS -- > > This ballot modifies the “Baseline Requirements for the Issuance and > Management of Publicly-Trusted Certificates” as follows, based upon Version > 1.5.4: > > > > In section 3.2.2.8, add this sentence: > > CAs MAY treat a non-empty CAA Resource Record Set that does not contain > any issue property tags (and also does not contain any issuewild property > tags when performing CAA processing for a Wildcard Domain Name) as > permission to issue, provided that the CAA Resource Record Set does not > contain any unrecognized property with the critical flag set. > > > > to the end of this paragraph: > > When processing CAA records, CAs MUST process the issue, issuewild, and > iodef property tags as specified in RFC 6844, although they are not > required to act on the contents of the iodef property tag. Additional > property tags MAY be supported, but MUST NOT conflict with or supersede the > mandatory property tags set out in this document. CAs MUST respect the > critical flag and not issue a certificate if they encounter an unrecognized > property with this flag set. > > > > -- MOTION ENDS -- > > > > Thanks, > > Corey > > > > > > *Corey Bonnell* > > Senior Software Engineer > > t: +1 412.395.2233 <(412)%20395-2233> > > > > *Trustwave* | SMART SECURITY ON DEMAND > www.trustwave.com > > > > *2017 Best Managed Security Service Winner – SC Media* > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
