[cabfpub] Draft CAA motion

Wed Nov 9 22:09:50 UTC 2016

Couldn’t we include strict contract-originated validations along with strict CAA checking for non-relationship account transactions?

1.       Validate contract signer authority to EVG spec

2.       Validate enterprise RA admins as Certificate Approvers per EVG spec

3.       To not need to check CAA on every issuance, a CA MUST:

a.       Hold a verified contract that the customer can terminate for convenience

b.      Validate each domain requested to a post-169 3.2.2.4 method, whether by initial contract or subsequent request to add domains by a Certificate Approver

c.       Mark domains white listed in a specific account in their database that are exempt from CAA checking

d.      Check CAA at the slower interval of [x] on only those marked domains

3b would require the marketing person to collaborate with someone with WHOIS change authority, DNS server update authority, ability to demonstrate control of the web server in question, or to exist as either an explicit or constructed email contact on WHOIS.

We could further stipulate that only specific 3.2.2.4 methods can be used to gain authorization to bypass transactional CAA checking. We could add explicit waiver of CAA checking language to domain contact methods and/or to contracts.

The idea of not checking CAA on every issuance on a relationship account is not a weakening of initial domain validation or of the inclusion of enough interested stakeholders at the customer to detect rogue action. It means that when a relationship account wants to move to another CA, they have to execute the TFC clause with their current CA rather than editing their CAA.

The rogue person gets blocked either by CAA enforcement by the CA that does not have a contract or by lacking affiliation with the relationship account. The person in the large organization who didn’t realize they have a contract with a specific CA gets blocked, wrong portal.

The certificate requestors who submit requests in the proper domains to the proper portal bound to a contract have their requests accepted, and the Certificate Approvers authorized by the Contract Signer review and approve the requests. The requestor’s automation, with a proper two-factor credential, can submit millions of certificate requests to a contract-controlled portal that are auto-approved without per-transaction CAA check due to (1) initial validation, (2) 13/39 month revalidation, and (3) slower CAA spot checking at interval X.

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Wednesday, November 09, 2016 2:31 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>
Cc: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Draft CAA motion

On Wed, Nov 9, 2016 at 11:28 AM, Bruce Morton <Bruce.Morton at entrustdatacard.com <mailto:Bruce.Morton at entrustdatacard.com> > wrote:

I would prefer if we started CAA with minimum requirements and then make these requirements more strict over time, rather than creating a policy which is very strict with no back-out clause, when there has not been enough CAA records to gain any new experience.

Given that we've been debating this for five years, at what point do you feel confident there will be sufficient experience to make these requirements more strict over time? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161109/830e457c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5744 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161109/830e457c/attachment-0001.p7s>