[cabfpub] Discussion Period to End/Voting to Begin on Ballot 219 v2: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag

Dimitris Zacharopoulos jimmy at it.auth.gr
Mon Apr 2 15:05:58 UTC 2018

Tim also mentioned 
(https://cabforum.org/pipermail/public/2018-March/013076.html) that you 
would need to post a new version, even with no changes (this was a bit 
odd but it's the rules :). Your e-mail on March 14th clearly indicates a 
v2 but I'm having a little trouble following the discussion dates 
mentioned in your previous posts. On March 14th, you indicate that the 
discussion period ends on March 23rd. In today's message, you indicate 
that the discussion period ends tomorrow (April 3rd) and then we vote. 
It seems a bit strange to what we've seen in the past :)


On 2/4/2018 5:31 μμ, Corey Bonnell wrote:
> Hi Dimitris,
> From v1.8 of the Bylaws, section 2.3.c: “The ballot automatically 
> fails if 21 calendar days elapse since the proposer last posted a 
> version of the ballot and the voting period has not been started.”
> I last posted a version of the ballot on March 14th 
> (https://cabforum.org/pipermail/public/2018-March/013086.html), which 
> is less than 21 calendar days ago. Given that, I do not believe this 
> ballot has expired.
> Thanks,
> Corey^
> *From: *Dimitris Zacharopoulos <jimmy at it.auth.gr>
> *Date: *Monday, April 2, 2018 at 10:23 AM
> *To: *Corey Bonnell <CBonnell at trustwave.com>, CA/Browser Forum Public 
> Discussion List <public at cabforum.org>
> *Subject: *Re: [cabfpub] Discussion Period to End/Voting to Begin on 
> Ballot 219 v2: Clarify handling of CAA Record Sets with no 
> "issue"/"issuewild" property tag
> Hello Corey,
> I'm afraid you've passed the 21 days from first introduction and 
> according to the Bylaws (section 2.3 c) the ballot automatically 
> fails. I think this is actually the first time we have this situation 
> so I would like at least another member to confirm or correct my 
> interpretation.
> If I am correct, you should pick a new ballot number and send a new 
> ballot to start the 7-day (minimum) discussion period. If you are 
> certain that you will not need more than 7 days for discussion, you 
> could indicate that the voting period begins exactly after the 7-days 
> discussion.
> Best Regards,
> Dimitris.
> On 2/4/2018 4:52 μμ, Corey Bonnell via Public wrote:
>     Hello,
>     IETF 101 has transpired two weeks ago and erratum 5244
>     (https://www.rfc-editor.org/errata/eid5244<https://scanmail.trustwave.com/?c=4062&d=-7zC2mLoCEj_NneVHp-V3QEqSUXMX5Za_nt1gdSZOA&s=5&u=https%3a%2f%2fwww%2erfc-editor%2eorg%2ferrata%2feid5244>)
>     was discussed. There is acknowledgement by the RFC 6844-bis author
>     that the wording will be clarified in the next version of the RFC
>     (see Jacob Hoffman-Andrews’s acknowledgement at
>     https://www.ietf.org/mail-archive/web/spasm/current/msg01203.html<https://scanmail.trustwave.com/?c=4062&d=-7zC2mLoCEj_NneVHp-V3QEqSUXMX5Za_nkii4fEOg&s=5&u=https%3a%2f%2fclicktime%2esymantec%2ecom%2fa%2f1%2fuUwicKB8-pbHUWekhZLLnL1-iQ4iv8xW0naYU8AFGIw%3d%3fd%3dq3oyNowL2aeaPqmICQ6FILMGQnUfIOKUv5cXNx7atOigOD%5fQT40kd5gytm1HYEMEC5lPaH7h2Z8%5frmod645WTM4RcJ0f2NjDMvKUaPdN%5fNMSYIvaHstwmn7QNVmPT8lyOMUi--ogk2eOrlGGaWrMS9A6FiBImZuZ3OPHhoEWrCgKUUWTwngjo-SM%5fS3gSUr8NNNN2zTX2c2EHeYXnHvU5FgDJofsezIeuOxr2iYXJMYqQCCKHEq-m5mX66RT-wjoereyGuNb5VjIn9QGZuB-ds1QFnrLQKdMRrxIaIiDLgSqSlkfUqIU1BzVD-AaoO8sTJlufu3%5f0hW6KIgY5aKiDcHcgZZQSZwNjiazIwVkAGQeel0RrA%3d%3d%26u%3dhttps%3a%2f%2fwww%2eietf%2eorg%2fmail-archive%2fweb%2fspasm%2fcurrent%2fmsg01203%2ehtml> and
>     my response at
>     https://www.ietf.org/mail-archive/web/spasm/current/msg01206.html<https://scanmail.trustwave.com/?c=4062&d=-7zC2mLoCEj_NneVHp-V3QEqSUXMX5Za_n1w0YWfYQ&s=5&u=https%3a%2f%2fclicktime%2esymantec%2ecom%2fa%2f1%2f8ZBAp3FOCf908ne78Zhxwn40HD9hrc0H9QE-w1fF6oI%3d%3fd%3dq3oyNowL2aeaPqmICQ6FILMGQnUfIOKUv5cXNx7atOigOD%5fQT40kd5gytm1HYEMEC5lPaH7h2Z8%5frmod645WTM4RcJ0f2NjDMvKUaPdN%5fNMSYIvaHstwmn7QNVmPT8lyOMUi--ogk2eOrlGGaWrMS9A6FiBImZuZ3OPHhoEWrCgKUUWTwngjo-SM%5fS3gSUr8NNNN2zTX2c2EHeYXnHvU5FgDJofsezIeuOxr2iYXJMYqQCCKHEq-m5mX66RT-wjoereyGuNb5VjIn9QGZuB-ds1QFnrLQKdMRrxIaIiDLgSqSlkfUqIU1BzVD-AaoO8sTJlufu3%5f0hW6KIgY5aKiDcHcgZZQSZwNjiazIwVkAGQeel0RrA%3d%3d%26u%3dhttps%3a%2f%2fwww%2eietf%2eorg%2fmail-archive%2fweb%2fspasm%2fcurrent%2fmsg01206%2ehtml>).
>     However, there is still no indication that the erratum state will
>     change to “Held for Document Update” or “Approved” anytime soon.
>     We believe that the acknowledgement from the RFC author to fix
>     this in the next version of the RFC is a sufficient surrogate to
>     getting the erratum state changed. Waiting for the erratum state
>     to change is merely red-tape in the process. As such, we intend to
>     proceed with the ballot in its current form by closing the
>     Discussion Period on Ballot 219 and begin voting tomorrow evening
>     (UTC time).
>     Thanks,
>     Corey
>     Ballot 219 v2: 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, 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: 2018-04-03 19:00:00 UTC
>     Vote for approval (7 days)
>       Start Time: 2018-04-03 19:00:00 UTC
>       End Time: 2018-04-10 19:00:00 UTC
>     *Corey Bonnell*
>     Senior Software Engineer
>     t: +1 412.395.2233
>     *Trustwave***| SMART SECURITY ON DEMAND
>     www.trustwave.com<http://www.trustwave.com/>
>     _______________________________________________
>     Public mailing list
>     Public at cabforum.org<mailto:Public at cabforum.org>
>     https://cabforum.org/mailman/listinfo/public<https://scanmail.trustwave.com/?c=4062&d=-7zC2mLoCEj_NneVHp-V3QEqSUXMX5Za_ihz19TKaQ&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>

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

More information about the Public mailing list