[cabfpub] Draft CAA motion (4)

Ryan Sleevi sleevi at google.com
Wed Jan 25 10:15:05 MST 2017


On Wed, Jan 25, 2017 at 9:04 AM, Bruce Morton via Public <
public at cabforum.org> wrote:

> Current contractual obligations may be a prepaid service to perform
> certificate management services and license a Subscriber to issue X number
> of certificates (say 5, 10, 100, 500, 1000, ...) over a specific period of
> time (say 1, 2, 3 years ...). Creation or a change to the CAA record with a
> hard-fail could stop the CA from fulfilling their obligation.
>

Using this line of argument, so could changes to Ballot 169 with
validation. Or is the point being that y'all don't revalidate domain
ownership, so you're already not concerned about potential misissuance?


> Anti-competitive behavior is an error case which I think should be planned
> for in the policy design. I am not sure how we can provide evidence to
> strongly prove a future error case. I don't believe that we are allowed to
> discuss possible incentives or benefits which a Subscriber could be
> provided by restricting the CAA record to a specific CA.
>

This again sounds like "Uncertainty" part of FUD. In the four+ years we've
been discussing CAA, not a single CA member has been able to advance this
argument to any meaningful scenario beyond what you've described, other
than the possible "CA may request that their customer put a CAA record in".
And that's not anti-competitive - that's helping customers be more secure.
If HTTP Public Key Pinning had been subject to the CA/Browser Forum, I have
no doubt CAs would have equally been opposed to helping their customers
prevent misissuance for the same grounds, but the reality is that HPKP is a
thing, it exists, and CAA is functionally no different in this regard,
other than preventing the certificates from being issued in the first
place. Which is by design.


> I am not looking for CA processes to decide whether to check a CAA record.
> I am looking to use the current methods which we have defined in the BRs
> and EV guidelines to permit a CA to issue a certificate. I am also looking
> for escalation processes using defined terms and requirements from the BRs
> and EV guidelines to allow an Applicant or Subscriber to request and
> authenticate the issuance of a certificate.
>

That is a misleading statement. The "defined terms" refer to CA-specific
processes. You're not using objective policies and practices - you're again
resorting to undefined and underspecified aspects of the BRs that allow a
CA to do whatever it wants, which the entire point of CAA is to say that if
we're going to allow the BRs to have these undefined practices, we need
some way to limit their risk.

The alternative to CAA that accomplishes browsers' goals is removing those
allowances - things like allowing the reuse of previously validated
information, and of Enterprise RA contracts, and of methods of validation
other than DNS validation - and since I have no doubt that would be far
more impactful and objectionable to CAs such as yourself, CAA offers a more
measured path to get the damage prevention from insecure CA practices -
such as those seen recently. It's a question about one or the other -
either CAA to indicate which CA's discretion is acceptable from a business
risk perspective, or the removal of any ability for CA discretion or
contractual agreements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170125/e81b6abf/attachment-0001.html>


More information about the Public mailing list