[cabfpub] Draft ballot 219: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag

Mon Jan 29 16:26:38 UTC 2018

That’s actually false.  The IETF is not mentioned anywhere in our Bylaws.

-Tim

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Phillip via Public
Sent: Friday, January 26, 2018 11:25 AM
To: 'Corey Bonnell' <CBonnell at trustwave.com>; 'Ryan Sleevi' <sleevi at google.com>; 'CA/Browser Forum Public Discussion List' <public at cabforum.org>
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:CBonnell at trustwave.com] 
Sent: Friday, January 26, 2018 12:23 PM
To: philliph at comodo.com <mailto:philliph at comodo.com> ; Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >; CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >
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: "philliph at comodo.com <mailto:philliph at comodo.com> " <philliph at comodo.com <mailto:philliph at comodo.com> >
Date: Thursday, January 25, 2018 at 10:42 AM
To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >, CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >
Cc: Corey Bonnell <CBonnell at trustwave.com <mailto:CBonnell at trustwave.com> >
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:public at cabforum.org> public at cabforum.org> 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:public at cabforum.org> public at cabforum.org> 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:Public at cabforum.org> Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
 <mailto:Public at cabforum.org> 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/20180129/06f8c161/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180129/06f8c161/attachment-0003.p7s>