[cabfpub] Draft CAA motion (2)

[Steve Medin]

Right, but it wasn't my intent to suggest that CAs check CAA after issuing, I offered that up for third parties who wish to monitor CA behavior as a programmatic method to document that a written exception from the customer was asserted by the CA at the time of issuance through placement of a signaling CP OID. Sure, CAA will change over time and such monitoring can trigger false positives.

I should also add that I don't include clickthrough agreements such as subscriber agreements and the like when I talk about contracts. I'm referring to negotiated service agreements that state a commitment over a period of a year or more including facts like the number and type of certificate licenses being prepaid, the appointed Certificate Approvers, and several paragraphs about the vendor/client responsibilities, indemnification, confidentiality of information, and limits of liability in the relationship rather than the CA/subscriber document talking about a specific certificate and the typically one-sided application of policy from the CA upon the subscriber with no right to redline.

These are documents that involve a sales organization, customer legal staff, redline volleys, a credit check, and a binding commitment to pay. Once executed, individual identity vetting occurs on the proposed Certificate Approvers. I suggested that apprehension with contract handling could be addressed by validating Contract Signers and Certificate Approvers to EV spec.

Ryan asks why we would go through this work. It's because this is a normal part of doing business we can leverage. Ryan asks why again, and all I can say further is carbon footprint. These are bytes that don't need to travel.

Once we implement per-transaction CAA checking for one-off, touch and go enrollment processes, applicants coming to the wrong CA get blocked whether they are being malicious or unaware of a standard corporate portal and related service agreement. Once we implement CAA checking on every domain named in a contract, we perform the check before any issuance occurs. After initial vetting, subsequent domains can be waived from per-transaction CAA by an amendment signed by the verified Contract Signer.

I propose to mark certs issued with per-contract CAA checking while fully supporting the need for per-transaction CAA checking.

Bruce, Doug, since you both had some comments earlier in the discussion it might help to share some high level commonality across CAs and service agreement handling while reciting the anti-trust clause.

> -----Original Message-----
> From: Gervase Markham [mailto:gerv at mozilla.org]
> Sent: Friday, November 11, 2016 6:21 AM
> To: Steve Medin <Steve_Medin at symantec.com>; Ryan Sleevi
> <sleevi at google.com>
> Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
> Subject: Re: [cabfpub] Draft CAA motion (2)
> 
> On 10/11/16 20:28, Steve Medin wrote:
> > Sorry, I’m not citing existing BR content, I’m proposing new to give
> > weight to a vendor/client relationship. Add a clause to Gerv’s motion
> > that recognizes that a customer can opt out of a CA checking CAA by
> > contract. Require that the CA indicate this choice through presence of
> > a CABF arc CP OID at EE tier, allowing programmatic checking of CAA
> > violation.
> 
> Except that's not possible, because post-issuance checking of CAA is not a
> good idea, according to the RFC.
> 
> Gerv
-------------- 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/20161114/542280bb/attachment-0001.p7s>