That’s actually false. The IETF is not mentioned anywhere in our Bylaws.
-Tim From: Public [mailto:[email protected]] On Behalf Of Phillip via Public Sent: Friday, January 26, 2018 11:25 AM To: 'Corey Bonnell' <[email protected]>; 'Ryan Sleevi' <[email protected]>; 'CA/Browser Forum Public Discussion List' <[email protected]> Subject: Re: [cabfpub] Draft ballot 219: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag Actually it is the opposite as getting the errata into that state is a defacto precondition to getting the BR modified. From: Corey Bonnell [mailto:[email protected]] Sent: Friday, January 26, 2018 12:23 PM To: [email protected] <mailto:[email protected]> ; Ryan Sleevi <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] Draft ballot 219: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag Hello Phillip and Ryan, IETF Erratum 5244 (https://www.rfc-editor.org/errata/eid5244) has been submitted to clarify the wording in the RFC. My original motivation for first proposing the Ballot was due to a (perhaps incorrect) impression that the process of getting an erratum into a state (such as “approved” or “held for document update”) where it is suitable for inclusion in the BRs is a lengthy process, so it would be more expedient to address the ambiguity first in the BRs. If that’s not the case, then I agree that it would be better to handle this in the same way Erratum 5065 was handled. Thanks, Corey Corey Bonnell Senior Software Engineer t: +1 412.395.2233 Trustwave | SMART SECURITY ON DEMAND www.trustwave.com 2017 Best Managed Security Service Winner – SC Media From: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Date: Thursday, January 25, 2018 at 10:42 AM To: Ryan Sleevi <[email protected] <mailto:[email protected]> >, CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Cc: Corey Bonnell <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] Draft ballot 219: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag +1 Unless the semantics are changed, an errata can be approved rather than held for document revision. Since we are not proposing to change the semantics, that would be the right approach. We did have a long discussion about this with the interaction of issue and issuewild if people recall. On Jan 25, 2018, at 9:09 AM, Ryan Sleevi via Public < <mailto:[email protected]> [email protected]> wrote: 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 < <mailto:[email protected]> [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: <tel:(412)%20395-2233> +1 412.395.2233 Trustwave | SMART SECURITY ON DEMAND www.trustwave.com 2017 Best Managed Security Service Winner – SC Media _______________________________________________ Public mailing list <mailto:[email protected]> [email protected] https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list <mailto:[email protected]> [email protected] https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
