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

[philliph at comodo.com]

+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 <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 <public at cabforum.org <mailto: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 <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 <tel:(412)%20395-2233>
>  
> 
> Trustwave | SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
>  
> 
> 2017 Best Managed Security Service Winner – SC Media
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public <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/20180125/03f12617/attachment-0003.html>