[cabfpub] Draft CAA motion

[Bruce Morton]

Hi Ryan,

If Google Marketing wanted to open an account, signed the Subscriber agreement, and was verified, then they could request certificates. My assumption is the verification would fail as the Google CAA record does not authorize Entrust. So, I am not trying to use the enterprise argument to create new business. I just want to protect existing enterprise Subscribers. I also want to allow new enterprise Subscribers to be created if they are not blocked by CAA.

I do think that the random person executing a contract with a CA is out of scope of the CAA discussion. This issue can potentially already happen with or without a CAA policy. I do not think this is an issue with OV and EV certificates.

I think the primary CAA goal is to assure that a random unidentified person does not receive a certificate where the CAA record does not authorize the CA for issuing. This could also be extended to stopping an random person from creating an account where the data is pre-verified if the verification fails the CAA check. I also hope the goal is to allow a company to contract a CA to issue tens, hundreds or thousands of certificates per year without suddenly being blocked by a change to a CAA record.

There are minimum requirements for an enterprise to open a certificate management service, such as:

·        Accept the Subscriber agreement

·        All organization names would be pre-validated to OV or EV requirements

·        All Base Domain Names would have to be pre-validated

·        Enterprise RAs would be validated by contacting the enterprise using a Reliable Method of Communication

·        All certificate requests or API implementations would have to be approved by the Enterprise RA

I think that we should be able to come to an agreement to use CAA to block an unauthorized CA from issuing in over 99% of the cases. I’m also hoping we can find a way to allow a verified enterprise Subscriber to have successful certificate requests without suddenly being blocked by CAA.

Thanks, Bruce.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Wednesday, November 9, 2016 12:05 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Doug Beattie <doug.beattie at globalsign.com>; Bruce Morton <Bruce.Morton at entrustdatacard.com>
Subject: Re: [cabfpub] Draft CAA motion

Bruce,

What would prevent a random person in Google Marketing from executing a contract with Entrust? How would Entrust determine that person is or is not authorized? How would that be normalized across the industry? How would Google signal to Entrust that such a person was not authorized to sign contracts on Google's behalf?

These are all things for which your reply is, ultimately, based on how Entrust does its business, and other CAs may differ in practices or rigor - which is why it is very much the realm of CA policy in how it executes such agreements, and subscribers have no way to prevent CAs from being fooled or signalling that they're making a mistake.

On Wed, Nov 9, 2016 at 8:25 AM, Bruce Morton via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:
This doesn't make CAA in the realm of CA policy. This puts certificate issuance in the realm of certificate Subscriber policy, which I think we all respect through our BR and EV documents.

Bruce.

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>] On Behalf Of Gervase Markham via Public
Sent: Wednesday, November 9, 2016 10:12 AM
To: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; CA/Browser Forum Public Discussion List <public at cabforum.org<mailto:public at cabforum.org>>
Cc: Gervase Markham <gerv at mozilla.org<mailto:gerv at mozilla.org>>
Subject: Re: [cabfpub] Draft CAA motion


I'm sorry, but that moves CAA from the realm of enforced site policy to the realm of CA policy, which defeats much of the point. We have discussed this recently on this list, I believe.

_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161109/f03d925e/attachment-0003.html>