[cabfpub] Draft CAA motion (2)

[Jeremy Rowley]

I think this is an important ballot to get right on the IP issue considering it'll be mandatory for all CAs and there is a clear author of the RFC. If this passes, I'd like an implementation date that is far enough out we can effectively hold a PAG to consider any IP disclosures made.

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham via Public
Sent: Thursday, November 10, 2016 10:40 AM
To: Steve Medin <Steve_Medin at symantec.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Gervase Markham <gerv at mozilla.org>
Subject: Re: [cabfpub] Draft CAA motion (2)

On 10/11/16 17:10, Steve Medin wrote:
> Given the dynamic name space of large organizations that all consume 
> TLS certificates via relationship accounts, portals, and contracts, 
> creating a name-constrained subordinate CA for each customer then 
> keeping up with their domain realty is not a concession to my request.

It will not be suitable for all customers, but it will be suitable for the sort of high-volume issuance that Jeremy was talking about, where you are issuing millions of certs an hour under a single domain and a single misplaced CAA record could bring the whole enterprise to a shuddering halt.

In circumstances where the list of domains is large and regularly changing, the impact of this "mis-applied CAA record on one of the domains" scenario you continue to invoke would be much less.

> For several CAs, contracts and software-constrained portals that 
> routinely pass audits are the vast majority of their issuance. If 
> we’re going to allow CAA bypass with technical constraints, then we 
> should leave 7.1.5 as is but in the context of CAA expand to include 
> software-enforced explicit permit domain lists resulting from 
> adherence to the BR domain validation rules and successful audit review.

It seems your argument boils down to "trust us, our software and our audits - we'll make sure we don't screw up". Given many recent events (e.g. a short discussion you and I had at CAB Forum about the inaccuracy of certain spreadsheets) I feel disinclined to produce a ballot which requires this sort of trust. It again takes control of issuance out of the hands of the domain owner and puts it in the hands of CA policy.

Having heard both your argument and Bruce's, I see no technical reason why CAA checks cannot be done in the circumstances you talk about. The fact that you and BigCorp have a contract doesn't, to me, make it a good idea to allow you to build a system which permits CAA-less issuance.


But here's another suggestion. Instead of mandating CAA in Mozilla policy, we'll just say that issuing in the face of an adverse CAA record is a serious misissuance. Then, you'd be free to not check it as often as you liked, relying on your systems and contracts to save you - and the first time they went wrong, we'd untrust your intermediate or remove your EV indicator or some other sanction. How would that be? :-)

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161110/4d621379/attachment-0001.p7s>