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
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to