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

Mon Mar 12 16:07:09 UTC 2018

On 12/3/2018 5:28 μμ, Tim Hollebeek wrote:
>
> Well, the clock can be extended by posting a new version (with version
> number).  And there is no requirement that the new version have any
> differences.  So you can keep a ballot alive indefinitely if the
> proposer is paying attention.  The 21 days is just to kill abandoned
> ballots.
>
>  
>
> IETF is March 17-23^rd .  If Ryan and I can’t get IETF to approve some
> version of the errata in a timely manner, I suggest we go forward
> without them.  It’s been long enough.  I’ll let everyone know how the
> discussion in London goes.
>
>  
>
> Also there appears to be some bad math on the end time of the
> discussion period in the original version of the ballot.  That alone
> might be a good reason for posting a new version 😊
>
>  
>
> -Tim
>

With the new rules, you can trigger the voting period with the final
text even at March 28th (at the latest). I don't think the "Discussion
end time" makes a difference since the Bylaws are very clear on the 7+
days for discussion :)

Thanks,
Dimitris.

>  
>
> *From:*Public [mailto:public-bounces at cabforum.org] *On Behalf Of
> *Dimitris Zacharopoulos via Public
> *Sent:* Monday, March 12, 2018 3:26 AM
> *To:* public at cabforum.org
> *Subject:* Re: [cabfpub] Ballot 219: Clarify handling of CAA Record
> Sets with no "issue"/"issuewild" property tag
>
>  
>
> On 7/3/2018 9:02 μμ, Corey Bonnell via Public wrote:
>
>     Hello,
>
>     Several weeks ago, after receiving feedback from several Forum
>     members, I submitted an IETF erratum
>     (https://www.rfc-editor.org/errata_search.php?eid=5244
>     <https://clicktime.symantec.com/a/1/_dfjzFBLFWWu3TtSSb258nrvIo9PjiZ6EINdAY3hg5U=?d=gJpjg_n3FbpDyP_Ng3Qhe1LcnmYhQB4WE5LK78ISpw3j19Wq2r4pzz1Q_JpCK1TW3j64DgExJBMOH6mDAYlvmPTcGAuyf5Y8waQuHacRiIEs2uhKFS_1IJveDOA4uuQP03rNr54M8lHPxgXVfbCoyC7tbhs1wODAPB4oElC0yD7Y1sOTUyWU8_az0Q39LNkkzA_4nn4M8oGDMafbkF91UfOKWMneObWs2ieTRV5EWFQY2rkfVFWjjOHEhDvwUXNn9HujUGGYwoz7zh43EI9_11FmTcPdzdDsgZprK0jRWiCSoy0Clm2vQO9xO1eNz89LEACC-I7NqQ3PbWj9oDXxuPq7D1GRsDS-GS_xqdNAhPRwsCEsgAL9bz3lVIrn1_Kj_oCKDupWFBvkU2Hy_PTtNaP5rvZmjpr1FVUhrQddRr7fNo8dDXcqOLDO8LgrCi5SpAsTkHOoj5rIrp1CjBfFkzMqJIpxgMGzC0c%3D&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata_search.php%3Feid%3D5244>)
>     for this clarification so that we may potentially be able to
>     directly include the erratum text in the Baseline Requirements as
>     was done for erratum 5065. However, there has been no response
>     from the IETF in regard to getting this erratum approved, so we
>     would like to proceed with Ballot 219 to clarify this in the
>     Baseline Requirements in the short term. We will continue to
>     pursue getting the RFC language clarified, but that appears that
>     it will take quite some time.
>
>      
>
>     The wording of the ballot below is the same as the version sent in
>     late January with the exception of a slight change to
>     “future-proof” the language based on a suggestion by Gerv and the
>     BR version has been bumped up to the latest version.
>
>      
>
>     We would like to begin the discussion period for this ballot. We
>     would highly appreciate any feedback and comments that anyone has
>     before bringing this ballot to a vote.
>
>      
>
>     I’d be happy to create a redline, but I’m unsure of our current
>     preferred process for doing so. If Github
>     (https://github.com/cabforum/documents
>     <https://clicktime.symantec.com/a/1/4cnBDQ-JMP2wxqhzMSjmi4KjTQs01n3y_Yi08QrgHwc=?d=gJpjg_n3FbpDyP_Ng3Qhe1LcnmYhQB4WE5LK78ISpw3j19Wq2r4pzz1Q_JpCK1TW3j64DgExJBMOH6mDAYlvmPTcGAuyf5Y8waQuHacRiIEs2uhKFS_1IJveDOA4uuQP03rNr54M8lHPxgXVfbCoyC7tbhs1wODAPB4oElC0yD7Y1sOTUyWU8_az0Q39LNkkzA_4nn4M8oGDMafbkF91UfOKWMneObWs2ieTRV5EWFQY2rkfVFWjjOHEhDvwUXNn9HujUGGYwoz7zh43EI9_11FmTcPdzdDsgZprK0jRWiCSoy0Clm2vQO9xO1eNz89LEACC-I7NqQ3PbWj9oDXxuPq7D1GRsDS-GS_xqdNAhPRwsCEsgAL9bz3lVIrn1_Kj_oCKDupWFBvkU2Hy_PTtNaP5rvZmjpr1FVUhrQddRr7fNo8dDXcqOLDO8LgrCi5SpAsTkHOoj5rIrp1CjBfFkzMqJIpxgMGzC0c%3D&u=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments>)
>     is the current preferred method, I’d like to point out that the
>     “master” branch is currently out of date (it’s currently 1.5.4,
>     whereas the current adopted version is 1.5.6).
>
>      
>
>     Ballot 219: Clarify handling of CAA Record Sets with no
>     "issue"/"issuewild" property tag
>
>      
>
>     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.
>
>      
>
>     The following motion has been proposed by Corey Bonnell of
>     Trustwave and endorsed by Tim Hollebeek of Digicert and Mads Egil
>     Henriksveen of Buypass.
>
>      
>
>     -- MOTION BEGINS --
>
>     This ballot modifies the “Baseline Requirements for the Issuance
>     and Management of Publicly-Trusted Certificates” as follows, based
>     upon Version 1.5.6:
>
>      
>
>     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 no
>     records in the CAA Resource Record Set otherwise prohibit issuance.
>
>      
>
>     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 –
>
>      
>
>     The procedure for approval of this ballot is as follows:
>
>     Discussion (7+ days)
>
>       Start Time: 2018-03-07 19:00:00 UTC 
>
>       End Time: Not Before 2017-03-10 19:00:00 UTC
>
>      
>
>     Vote for approval (7 days)
>
>       Start Time: TBD
>
>       End Time: TBD
>
>      
>
>      
>
>     *Corey Bonnell*
>
>     Senior Software Engineer
>
>     t: +1 412.395.2233
>
>      
>
>     *Trustwave** *| SMART SECURITY ON DEMAND
>     www.trustwave.com
>     <https://clicktime.symantec.com/a/1/esxpAFsW4yzcLvuyiRSGLU5XqPMaJtsgbNP3BtI0wzo=?d=gJpjg_n3FbpDyP_Ng3Qhe1LcnmYhQB4WE5LK78ISpw3j19Wq2r4pzz1Q_JpCK1TW3j64DgExJBMOH6mDAYlvmPTcGAuyf5Y8waQuHacRiIEs2uhKFS_1IJveDOA4uuQP03rNr54M8lHPxgXVfbCoyC7tbhs1wODAPB4oElC0yD7Y1sOTUyWU8_az0Q39LNkkzA_4nn4M8oGDMafbkF91UfOKWMneObWs2ieTRV5EWFQY2rkfVFWjjOHEhDvwUXNn9HujUGGYwoz7zh43EI9_11FmTcPdzdDsgZprK0jRWiCSoy0Clm2vQO9xO1eNz89LEACC-I7NqQ3PbWj9oDXxuPq7D1GRsDS-GS_xqdNAhPRwsCEsgAL9bz3lVIrn1_Kj_oCKDupWFBvkU2Hy_PTtNaP5rvZmjpr1FVUhrQddRr7fNo8dDXcqOLDO8LgrCi5SpAsTkHOoj5rIrp1CjBfFkzMqJIpxgMGzC0c%3D&u=http%3A%2F%2Fwww.trustwave.com%2F>
>
>
>
>
>     _______________________________________________
>
>     Public mailing list
>
>     Public at cabforum.org <mailto:Public at cabforum.org>
>
>     https://cabforum.org/mailman/listinfo/public
>     <https://clicktime.symantec.com/a/1/h9_RPGffXzOThunxElSFYzMNZr0CZoId1LZqkKjybKs=?d=gJpjg_n3FbpDyP_Ng3Qhe1LcnmYhQB4WE5LK78ISpw3j19Wq2r4pzz1Q_JpCK1TW3j64DgExJBMOH6mDAYlvmPTcGAuyf5Y8waQuHacRiIEs2uhKFS_1IJveDOA4uuQP03rNr54M8lHPxgXVfbCoyC7tbhs1wODAPB4oElC0yD7Y1sOTUyWU8_az0Q39LNkkzA_4nn4M8oGDMafbkF91UfOKWMneObWs2ieTRV5EWFQY2rkfVFWjjOHEhDvwUXNn9HujUGGYwoz7zh43EI9_11FmTcPdzdDsgZprK0jRWiCSoy0Clm2vQO9xO1eNz89LEACC-I7NqQ3PbWj9oDXxuPq7D1GRsDS-GS_xqdNAhPRwsCEsgAL9bz3lVIrn1_Kj_oCKDupWFBvkU2Hy_PTtNaP5rvZmjpr1FVUhrQddRr7fNo8dDXcqOLDO8LgrCi5SpAsTkHOoj5rIrp1CjBfFkzMqJIpxgMGzC0c%3D&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic>
>
>
> I would like to note that according to section 2.3 (c) of the Bylaws,
> the proposers of this ballot have 21 calendar days (starting on March
> 7th 2018) to start the voting period, otherwise the ballot
> automatically fails. If my calculations are correct, the final day to
> start the voting is March 28th.
>
>
> Thank you,
> Dimitris.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180312/f0198042/attachment-0003.html>