Gerv,

Do we need to add any clarification to this statement:

…CA must check for a CAA record for each dNSName in the subjectAltName 
extension of the certificate to be issued, according to the procedure in RFC 
6844.

As it stands, this means that CAs must support Issuer Critical, issue and 
issuewild today and then to support other Property Tags as they are added 
(without an indication of when the need to be supported).  The spec also says 
that you must check the specified CNAME or DNAME record if they exist.  Are all 
of these checks required and how do we handle new Property Tags?

Doug


From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Thursday, January 12, 2017 9:25 AM
To: CABFPub <public@cabforum.org>
Cc: Gervase Markham <g...@mozilla.org>
Subject: [cabfpub] Draft CAA motion (3)

Hi everyone,

As we are trying to get ballots ready for when the ballot reforms are done, 
here's a third version of the draft motion to make CAA mandatory. Changes over 
version 2 are:

* Add a further exception: "CAA checking is optional if the domain's DNS is 
operated by the CA or an Affiliate."

This is an attempt to help Jody with his request to not have to check 
Microsoft's domains, while recognising that one part of the CA asking another 
part of the CA to set some DNS records so it can check them isn't really 
pointful.

One change I am not making is that I am not persuaded that there are compelling 
technical or business reasons to provide carve-outs for enterprise or other 
accounts. Providing such carve-outs changes CAA from "site policy" to "CA 
policy", and opens up loopholes which could be used by CAs to not do CAA on 
occasions where it would be appropriate. I feel the big benefit of CAA for 
sites is that it allows them to control issuance by all CAs (especially those 
with which they do not have a relationship) in a way which has not been 
possible before, and I'm keen to preserve that benefit. While I admit I have 
limited control over this, I'm also keen to encourage CAs to implement CAA in 
way which is hard or impossible for CA issuance staff to override, and if there 
are reasons they regularly need to override it, CAs obviously won't do that.

There are lots of ways a site owner can totally break their site by changing 
their DNS. Adding "adds an adverse CAA record in a situation where they need 
quick issuance" to that list doesn't, to my mind, change the risk profile 
significantly. Of course, the motion requires CAs to document problems 
encountered so if this analysis proves wrong, they will be able to provide 
evidence.

I am now seeking endorsers for this motion.

Would anyone like to suggest the appropriate section of the BRs to which the 
first section of text should be added?

The proposal is that the effective date of this change (written into the new 
section 2.2) should be six months after the voting period ends. I am proposing 
six months rather than three because it requires a reasonable amount of 
development work within a CA's infrastructure.

Gerv

Ballot XXX - Make CAA Checking Mandatory

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by XXX of XXX and XXX of XXX:

Statement of Intent:
Certificate Authority Authorization (CAA) is a DNS Resource Record defined in 
RFC 6844 - https://datatracker.ietf.org/doc/rfc6844/ , published in January 
2013. It allows a DNS domain name holder to specify one or more Certification 
Authorities (CAs) authorized to issue certificates for that domain and, by 
consequence, that no other CAs are authorized.

The intent of this motion is to make it mandatory for CAs to check CAA records 
at issuance time for all certificates issued (except in one or two uncommon 
cases), and to prevent issuance if a CAA record is found which does not permit 
issuance by that CA. This therefore allows domain owners to set an issuance 
policy which will be respected by all publicly-trusted CAs, and allows them to 
mitigate the problem that the public CA trust system is only as strong as its 
weakest CA.

Note that CAA is already a defined term in the BRs and so does not need 
definitional text to be provided by this motion.

-- MOTION BEGINS --
Add the following text to section XXX ("XXX") of the Baseline Requirements:
As part of the issuance process, the CA must check for a CAA record for each 
dNSName in the subjectAltName extension of the certificate to be issued, 
according to the procedure in RFC 6844, following the processing instructions 
set down in RFC 6844 for any records found. If the CA issues, they must do so 
within the TTL of the CAA record, or 1 hour, whichever is greater.

This stipulation does not prevent the CA from checking CAA records at other 
points in the issuance process.

RFC 6844 requires that CAs "MUST NOT issue a certificate unless either (1) the 
certificate request is consistent with the applicable CAA Resource Record set 
or (2) an exception specified in the relevant Certificate Policy or 
Certification Practices Statement applies." For issuances conforming to these 
Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their 
CP or CPS unless they are one of the following:

  *   CAA checking is optional for certificates for which a Certificate 
Transparency pre-certificate was created and logged in at least two public 
logs, and for which CAA was checked.
  *   CAA checking is optional for certificates issued by an Technically 
Constrained Subordinate CA Certificate as set out in Baseline Requirements 
section 7.1.5, where the lack of CAA checking is an explicit contractual 
provision in the contract with the Applicant.
  *   CAA checking is optional if the domain's DNS is operated by the CA or an 
Affiliate of the CA.
CAs are permitted to treat a record lookup failure as permission to issue if:

  *   the failure is outside the CA's infrastructure;
  *   the lookup has been retried at least once; and
  *   the domain's zone does not have a DNSSEC validation chain to the ICANN 
root.
CAs MUST document issuances that were prevented by an adverse CAA record in 
sufficient detail to provide feedback to the CAB Forum on the circumstances, 
and SHOULD report such requests to the contact(s) stipulated in the CAA iodef 
record(s), if present. CAs are not expected to support URL schemes in the iodef 
record other than mailto: or https:.
Update section 2.2 ("Publication of Information") of the Baseline Requirements, 
to remove the following text:

    Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy 
and/or Certification

    Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL 
state whether

    the CA reviews CAA Records, and if so, the CA’s policy or practice on 
processing CAA Records

    for Fully Qualified Domain Names. The CA SHALL log all actions taken, if 
any, consistent with

    its processing practice.
and replace it with:

    Effective as of XXX, section 4.2 of a CA's Certificate Policy and/or 
Certification

    Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL 
state the CA’s policy or

    practice on processing CAA Records for Fully Qualified Domain Names; that 
policy shall be consistent

    with these Requirements. It shall clearly specify the set of Issuer Domain 
Names that the CA

    recognises in CAA "issue" or "issuewild" records as permitting it to issue. 
The CA SHALL log all actions

    taken, if any, consistent with its processing practice.



Add the following text to the appropriate place in section 1.6.3 ("References"):
RFC6844, Request for Comments: 6844, DNS Certification Authority Authorization 
(CAA) Resource Record, Hallam-Baker, Stradling, January 2013.
-- MOTION ENDS --

The review period for this ballot shall commence at 2200 UTC on XXX, and will 
close at 2200 UTC on XXX. Unless the motion is withdrawn during the review 
period, the voting period will start immediately thereafter and will close at 
XXX. Votes must be cast by posting an on-list reply to this thread.

A vote in favor of the motion must indicate a clear 'yes' in the response. A 
vote against must indicate a clear 'no' in the response. A vote to abstain must 
indicate a clear 'abstain' in the response. Unclear responses will not be 
counted. The latest vote received from any representative of a voting member 
before the close of the voting period will be counted. Voting members are 
listed here: https://cabforum.org/members/
In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor. Quorum is currently XXX members – at 
least that many members must participate in the ballot, either by voting in 
favor, voting against, or abstaining.
_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to