[cabfpub] Continuing the discussion on CAA

Ryan Sleevi sleevi at google.com
Mon Oct 24 18:44:36 UTC 2016

On Mon, Oct 24, 2016 at 11:32 AM, Kirk Hall <Kirk.Hall at entrustdatacard.com>

> Ryan, I have to admit I have not always understood your response on
> Jeremy’s question (which I have asked myself).  You have said at times “we
> already answered that”, but I think many of us can’t recall what your exact
> answer was.

I do hope that the minutes from the F2F will show that Andrew and I
responded to this, in person. I believe Jeremy was present, but you were
certainly present.

In the F2F, we discussed cases where Amazon could have benefited from CAA
(due to unauthorized issuance), and cases where Google has benefited from
CAA - preventing letsencrypt certificates for domains where we allow
customer-controlled content.

You, specifically, have raised this several calls, and I've responded both
on list and in person, so I'm really not sure how I can more productively
and clearly communicate the value of CAA, as perceived by Google. It is
precisely because of this repeated question - and the ability to
conveniently forget answers - that it increasingly becomes harder to see
this as a benign question born of genuine curiouisity, but rather an active
attempt to disrupt a valuable security improvement by feigning ignorance or
conveniently forgetting.

To assist in the future, I'll just link you this message in the archives.

> However, as I understand it Google wants to prevent a genuine Google
> employee from buying a cert from a CA that is not on a corporate-approved
> list of CAs shown in a CAA record, and so Google is supporting CAA as a way
> of preventing genuine Google employees from ordering a cert from a CA not
> on Google’s CAA list.  I can see why an enterprise like Google might want
> that, but to my mind a cert issued with the approval of a genuine Google
> employee from a CA not on the corporate CAA list of approved CAs is *not*
> “misissuance” in the sense that we normally use the term – instead, it is
> non-compliance by a Google employee with an internal corporate policy,
> which is normally handled internally by the corporation, and not pushed out
> to CAs to help in enforcing internal corporate policies.

While I appreciate your attempt to educate me on terminology, please
re-read that I communicated: unauthorized issuance.

We discussed this at the F2F as well - the challenges provided in the
current BRs for the language provided, which allows restricting authorized
cert requestors, but only to CAs for which the company has a pre-existing
relationship. The specific nature of this conversation was with your
employers' other representative, Bruce Morton, and in the context of
discussing how, in the absence of a strict enforcement of CAA, it would be
necessary to address this loophole (which some members present expressed as
'unintentional') via policy.

If it appears that I'm frustrated with you, it is the case, because you in
particular have asked this question. If you recall, you asked the same
question Jeremy did, during the F2F not even a week ago, and I responded to
you, in person, immediately following your asking it.

So please don't position it that I haven't answered this before - on the
list, on calls, and less than a week ago in person.

> So – *excluding* cases where a genuine Google employee has ordered or
> obtained a cert for a Google domain from a CA not on Google’s CAA list of
> approved CAs (not considered “misissuance” for the purpose of this
> question) – can you provide any details as to other cases where CAA would
> have prevented true “misissuance” of a cert to a fraudster not connected to
> the organization that owns the domain in question?  Those examples would be
> very helpful to this discussion.

The examples I provided you, in person, at Meeting 39, were specifically
about third-parties, not Google employees. The same examples I've provided
you every time you've asked, but for which I'll link to this thread from
now on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161024/484d0723/attachment-0003.html>

More information about the Public mailing list