[cabfpub] Draft CAA motion (3)

Gervase Markham gerv at mozilla.org
Mon Jan 16 16:56:06 UTC 2017

On 13/01/17 22:32, Steve Medin wrote:
> Pending questions handled by an explanatory new angle. Since EV
> Certificate Approvers and their non-EV counterparts are implemented
> in Enterprise RA accounts as 2FA-credentialed issuance portal
> administrators with access to a pre-vetted collection of domains,
> would you think that if we discover a CAA record in conflict of a
> pre-vetted domain, we should then immediately revoke the portal
> access certificate and second factor of every Certificate Approver so
> authorized by the Contract Signer?

No. Why would you do that?

> So an organization can hold a contract with a CA for a managed
> service and have the rights, within aforementioned technical
> constraints, to produce certificates, but if someone who happens to
> have access to DNS drops in an I choose you, Pikachu for another CA,
> that whole contractual relationship, portal account, and course of
> doing business for a decade plus is all swept to the recycle bin?

Well, it might have been - I would expect that if the CA had not been
notified of the end of the relationship, the CA would quickly get in
contact with the company to find out what was going on, and either get
the DNS fixed, or discover the relationship had indeed been terminated.

> So even though the certificate request came in to the same portal as
> always, and a credentialed Certificate Approver among a team of 30
> reviewing certificate requests in an enterprise RA account globally
> reviewed it, who has been a member of that team for some time, the
> CAA change takes precedence? The DNS admin (or the bind 0day) rules
> over them all?

Yes. Because all of your internal controls and systems are entirely
opaque both to the public and to the person whose domain you misissued
for due to some bug in domain handling. This is the same argument all
over again. I am not going to change this proposal to allow you to
exempt certain domains from CAA checks for contractual reasons.

I think this feature is an important part of the value CAA provides for
the ecosystem, protecting everyone - both protecting _your_ customers
from other CAs (which, if I think you ask them, they will want), as well
as protecting other people's customers from you. The two go together -
you can't have one without the other.

The question you should be asking your customers is: "The CA industry is
considering requiring the implementation of a system which makes it
significantly harder for any CA in the world other than us to issue
certs for your domain. The downside of this is that it would become
possible for you to misconfigure your DNS in a way that stops _us_
issuing for your domain until you fix it. Is that a good trade-off for you?"

If you ask them that question, I suspect they will agree that CAA is a
good idea. But if not, I would expect you to vote against. What would be
disappointing is if you voted against without asking your customers that

> If so, then I suggest specific wording that the amendment takes
> precedence over the granted rights to Certificate Approvers in EV
> 11.8.4 and over the contemplation of multiple certificates issued as
> a result of a single request in BR 4.1.2. For the latter, this
> tightly correlates with the BR data reuse provisions which are muted
> by precedence of the amendment and CAA changes.

I don't see this as a precedence thing. In order for you to issue a
certificate, a number of things must be correct, in place, true, or
whatever. This just adds another one to the list.

> I suggest consensus about requirements to terminate such
> relationships, as they dominate the landscape and highly intersect
> with the consumer of CAA.

See above; the proposed change does not require the termination of any


More information about the Public mailing list