[cabfpub] Draft CAA motion (2)
Gervase Markham
gerv at mozilla.org
Thu Nov 10 17:39:52 UTC 2016
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
More information about the Public
mailing list