[cabfpub] How do you handle mass revocation requests?

Ryan Sleevi sleevi at google.com
Wed Feb 28 14:00:36 MST 2018


On Wed, Feb 28, 2018 at 3:46 PM, Geoff Keating <geoffk at apple.com> wrote:

>
>
> > On 28 Feb 2018, at 11:08 am, Ryan Sleevi <sleevi at google.com> wrote:
> >
> >
> >
> > On Wed, Feb 28, 2018 at 1:59 PM, Geoff Keating via Public <
> public at cabforum.org> wrote:
> >> This raises a question about the MDSP policy and CAB Forum
> requirements. Who is the subscriber in the reseller relation?  We believe
> this to be the key holder. However, the language is unclear.
> >
> > ‘Subscriber’ is a defined term in the BRs:
> > Subscriber: A natural person or Legal Entity to whom a Certificate is
> issued and who is legally bound by a Subscriber Agreement or Terms of Use.
> >
> > That’s pretty clear and can’t be stretched to cover a reseller—a
> reseller won’t be able to comply with a Subscriber Agreement.
> >
> > At the risk of stretching things, I want to point out that taking this
> interpretation requires determining whether or not the Reseller is acting
> as an Applicant Representative during the process.
> >
> > In this case, is the Reseller legally binding the "user" (for lack of
> better word) to a Subscriber Agreement? If so, how does the CA determine
> that the Reseller is an authorized Applicant Representative, and thus
> entitled to legally bind the "user" to the Subscriber Agreement?
>
> There are several ways this could be done.  However there is no question
> about the result, because that’s covered by 4.1.2:
> Prior to the issuance of a Certificate, the CA SHALL obtain the following
> documentation from the Applicant:
>
>         • A certificate request, which may be electronic; and
>
>         • An executed Subscriber Agreement or Terms of Use, which may be
> electronic
>
> So after a CA issues the certificate, it’s easy to find out who the
> Subscriber was (for some definition of ‘who’): you get the CA’s copy of the
> Subscriber Agreement and look for the bit where it says “This is an
> agreement between ______ and <the CA>.” and see what was written in the
> blank.  (and yes, it does have to be between the Subscriber and the CA, not
> between the Subscriber and anyone else, see the definition of ’Subscriber
> Agreement’.)
>

Right, we're in violent agreement here :)


>
> In addition under 9.6.1 item 6, the CA ‘represents and warrants’ that “the
> Subscriber and CA are parties to a legally valid and enforceable Subscriber
> Agreement that satisfies these Requirements…” and under 9.6.3, "The CA
> SHALL implement a process to ensure that each Subscriber Agreement or Terms
> of Use is legally enforceable against the Applicant."
>

Here's where I'm saying I've seen fuzziness, with respect to the Reseller
being nominated as an Applicant Representative (effectively), thus binding
the Agreement between the user (who is now the Subscriber) and <the CA>.
We've left under-specified how the Applicant Representative is authorized
(under than 'express authority') - other than the 3.2.5 case.

To be clear: I don't think this is a defensible position, but I'm saying
that based on how some of the issuance practices (or, more aptly, based on
complaints we've heard re: various API integrations, including those of
former CAs no longer members), this does seem an interpretation that some
have advanced. The CA has defined a process (the Applicant Representative
agreed), but it's not a very ... good... process. The CA would be at fault,
but this is where the messiness is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180228/2bb5d5c1/attachment-0001.html>


More information about the Public mailing list