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

[Ryan Sleevi]

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> 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
> 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/e5e5fee2/attachment-0003.html>