[cabfpub] Revocation as a domain owner

[Ryan Sleevi]

So we discussed #2 in the context of 213, and prior to that, had similar
discussions relating to the context of redaction (and unredaction).

I am not sure it's as cut and dry, in part, because of the challenges they
present to subscribers. Imagine an entity like Google, which tries to very
strictly control who and how validation is performed. By design, support
for automated issuance systems on critical properties simply doesn't exist
- there's no way you can complete an ACME HTTP-01 challenge on a Google
domain, and would literally require new code to be written and globally
deployed to be able to do so (with multiple checks and balances along the
way).

Now assume someone performs a DNS hijack through a registrar compromise,
temporarily obtains a certificate from one or more automated CAs that only
support ACME HTTP-01, and then control of DNS is restored back to Google.
How should revocation be authorized?

That is, the question that remained open in past conversations, and which
is as of yet unresolved, is what methods a CA MUST support to authenticate
revocation? Should CAs be required to support all of the validation methods
in 3.2.2.4 for revocation (if so, then it's all the more reason to quickly
get rid of the insecure methods, like .1 and .5, and work to strengthen the
presently-weak methods, .6, .8, .9, .10, and 3.2.2.5)? Is it only that some
MUST be supported? How does that work for the CAs that claim they only
issue certificates based on proof of government identity documents in
person - do they now also need to support these automated methods?

While I can understand your apprehension about the liability, isn't that
liability fundamentally introduced by allowing CAs to issue the
certificates in the first place? And should we err more on the side of
presuming victimhood - and thus proactive revocation (to be mitigated with
improved automation, presumably) - or should we adopt a stance that I
believe you may be suggesting, which is to presume revocation is highly
disruptive?

One way to remedy many of these concerns is to *only* allow certificates be
issued via automated means. Revocation would be able to utilize those same
means, and should there be an 'unauthorized' revocation, automation can
recover from it. Of all the solutions from the discussions to date, it
seems like that is the only one with clear winners on all sides of the
equation - users, site operators, browsers, and CAs. This only works if all
the automated methods are interoperable, though, but I think the IETF is
making good progress there.

On Mon, Jan 22, 2018 at 9:03 PM, Josh Aas via Public <public at cabforum.org>
wrote:

> It can be very difficult for a CA to determine who is the legal owner
> of a domain, thus taking action (e.g. revoking) on that basis creates
> significant liability. The BRs should not introduce additional rules
> requiring such determinations.
>
> A couple of ideas that don't depend on determining legal ownership:
>
> 1) Let anyone revoke a certificate if they can demonstrate control of
> the certificate's private key. Let's Encrypt does this, it has worked
> out well.
>
> 2) Allow people to revoke certificates if they can re-validate for all
> of the domains in the cert. The Let's Encrypt API also allows this.
>
> Both of these methods are clearly defined and can be fully automated.
>
> On Wed, Jan 3, 2018 at 10:59 AM, Wayne Thayer via Public
> <public at cabforum.org> wrote:
> > Matthias,
> >
> > I think you've raised a valid point. I'm working on ballot 213
> "Revocation
> > Timeline Extension" that makes changes to this section of the BRs, and I
> > will draft some language to attempt to address this. If you have any
> ideas
> > on how this requirement should be stated, please let me know.
> >
> > Thanks,
> >
> > Wayne
> >>
> >>
> >> I can't propose a ballot as I'm not a CAB member but adding the
> >> requirement of having to revoke certificates on the domain owner's
> request
> >> should probably be considered.
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> >
>
>
>
> --
> Josh Aas
> Executive Director
> Internet Security Research Group
> Let's Encrypt: A Free, Automated, and Open CA
> _______________________________________________
> Public mailing list
> 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/20180122/306aca94/attachment-0003.html>