[cabfpub] Draft CAA motion (2)

[Doug Beattie]

Hi Gerv,

I agree that trying to quantity which type of contract is acceptable is problematic.  

We'd like to avoid a requirement to check every FQDN (and especially at the time of issuance)  and check only a higher level FQDN (or Domain Name) on a "regular" basis by following an approved, documented process.  This will help move failure cases earlier in the ordering/validation flow instead of right at time of issuance and also allow high volume issuance without needing to insert a CAA check into the issuance process.

Example 1: Assume we issue a lot of certificates to serialnumber.us.example.com, I'd like to check us.example.com every few of days to cover this vs. every fqdn at the time of issuance.  If that means a special CAA directive (no-check subdomain or something, what was this called?), then that's OK because we can work with the small number of customers that need this type of service. I'd like to avoid name constrained CAs, special extensions and complicated "contractual" requirements.

I'm a bit concerned that not all DNS systems will allow the creation of CAA records, so the proposed solution above might need an alternative approach in those cases to allow high volume issuance.  Rick reported on DNS capabilities a while ago, but I don’t know what the current status is.

Example 2: Retail/reseller ordering process: Check CAA for the FQDN(s) when the order data is collected and be able to use that for up to 5 days.  If it takes more than 5 days to complete the vetting process, then it needs to be checked again prior to issuance.

Example 3: Enterprise account: 
I'd like to propose less restrictive checks on enterprise accounts when domain ownership or control is performed when the domain is added to the enterprise account, but I don’t think anything I would propose here would be accepted.  I'll try anyway: If domain ownership is verified by vetting agents and added manually (vs. one of the other domain validation methods), would it be possible to do CAA checks at the time that domain is added and then annually thereafter and skip CAA checks for the FQDNs?

I'd propose CAA checking at a minimum every 5 days, but in reality we'd probably check every day or two and have that data useable for 5 days to cover error cases when attempting to re-validate it.

I'd propose soft fail for the first 6 months of this requirement then move to hard fail.  That 6-month period of mandatory CAA will surface remaining CAA issues and then those can be addressed before hard fail is a requirement.  While CAA has been talked about for 5 years, it needs some time for heavier use in a permissive mode vs. jumping right to hard fail to shake out operational issues.



-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Thursday, November 17, 2016 6:31 AM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>; Peter Bowen <pzb at amzn.com>
Subject: Re: [cabfpub] Draft CAA motion (2)

Hi Doug,

On 14/11/16 21:09, Doug Beattie wrote:
> We're getting closer - is the only remaining discussion topic for 
> allowing CAs to skip CAA "at time of  issuance" in certain cases when 
> certain criteria are met?

So, having considered it, I will add an additional bullet to the list of permitted exceptions:

* the domain's DNS is operated by the CA or an Affiliate

Today it is true that you shouldn't host your DNS with your CA unless you're OK with that CA issuing certificates for you (see recent discussion about Cloudflare in m.d.s.policy), and that's not going to change, so I am comfortable with this exception. There is no point in one part of a CA asking another part for permission. This should solve Jody's problem, I hope, although it might not solve yours and Steve's, unless you want to get into the DNS hosting business.

So we now need to talk about the idea of a contractual opt-out for CAA checking, with an OID in the cert to indicate that this is what has happened. My concern is that because most CAs have some sort of contract, often click-through, with those who buy their certs, what's to prevent them all sticking a "no need for CAA" clause into it, and then not bothering to implement CAA at all?

Also, what if the contract is executed not with the domain holder, but with an attacker? How can a domain holder prevent that happening?

I'm fairly sure CAs would not like the browsers or the BRs to start making regulations about the strength of contracts they must have, or the level of awareness by the contracting party they must prove exists.

I'd also be concerned that putting requirements on the type of contract that must exist would be tantamount to saying "CAs with business model X don't have to do this check, but CAs with business model Y do".

Gerv