[cabfpub] Draft CAA motion (2)

[Steve Medin]

> -----Original Message-----
> From: Gervase Markham [mailto:gerv at mozilla.org]
> Sent: Friday, November 18, 2016 9:54 AM
> To: Steve Medin <Steve_Medin at symantec.com>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>; Doug Beattie
> <doug.beattie at globalsign.com>; Peter Bowen <pzb at amzn.com>
> Cc: Bruce Morton <Bruce.Morton at entrustdatacard.com>
> Subject: Re: [cabfpub] Draft CAA motion (2)
>
> On 17/11/16 21:18, Steve Medin wrote:
> > TCSCs, when the domain names aren't known, don't scale for customers
> > who add brandspace constantly.
>
> Yes, I understand that. If the list of domain names is changing constantly, 
> to
> my mind that's all the more reason to maintain CAA checks, because it's
> much easier for mistakes to be made - such as a domain not owned by the
> large customer in question making it on to the list, or them selling one and 
> it
> not getting taken off.

I agree with your point about selloffs. If the customer fails to inform a CA 
about of their sold business and its domains, they violate their service 
agreement and subscriber agreement, are in breach, and subject to suspension 
or termination of services.

Before and after that selloff, per-transaction CAA checking still occurs on 
all entry points to the CA except the service account. Service account access 
is authenticated, with two factors for those who can cause the issuance of a 
certificate given said white list. For less-often CAA checking to fail, the 
new domain owner has to assert CAA and the seller's TLS service admins who are 
deafeningly aware of the namespace transaction must be negligent or malicious.

The larger the organization, the more people do TLS as their day job. In my 
past life, the admins did TLS, full stop. They had ~400 authorized requestors 
who were the only people able to request certs. When the numerous divestitures 
occurred, those people traveled with the certificates.

I can't give much weight to the concern about getting names onto the list. 
There are no differences between that process and the BRs except we store them 
in one database table versus another. Any concerns about the management of 
such a list at any CA is a fundamental concern about that CA. Whether the 
customer has 15 domains or 15,000 the process is the same as issuing a single 
certificate.

>
> I think this is the fundamental disconnect. I think that CAA provides a 
> useful
> protection for arbitrary domain owners from CA process missteps, which are
> just as likely to happen when a big CA with an enterprise customer is 
> juggling
> a large and constantly-changing domain list, as they are in any other 
> issuance
> scenario. "Just trust us not to screw this up; we're big" is not good 
> enough.
>
> The only alternative I can see to the current ballot is to remove the 
> section
> about "permitted exceptions" entirely and allow CAs to write any exceptions
> they like into their CP/CPS, but for Mozilla policy to specify the 
> exceptions we
> allow (i.e. the existing list), and say that anything else is counted by us 
> as a
> serious misissuance. Then, if you want to trapeze without a safety net with
> your enterprise customers, you could go right ahead.
>

If your policy states otherwise, permissive language in a CPS is pointless and 
not at all anything I would entertain.

Now back to my snipped point about the customer who has had the same 2,000 
domains for the past 10 years, has CAA to protect from unauthorized CAs 
issuing for their domains, and submits 500 requests a day. What do they gain 
by having "their CA" check CAA?

-------------- 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/20161118/cf5ca5c8/attachment-0001.p7s>