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) 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) 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 <http://www.trustwave.com/>
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
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.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
