On Fri, Oct 4, 2019 at 4:37 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> One thing that might help to resolve this is a more detailed description of
> the weaknesses that are present in the process described by Ryan Hurst. If
> we can all agree that the process is vulnerable, then it seems that we'd
> have a strong argument for banning it.

The issue is that Ryan Hurst hasn't really described a reliable, verifiable
way to have assurance that the RA actually performs this verification. It's
functionally akin to the "any other method", without any meaningful
supervision. This is the same issue that Gerv had with delegated third
parties performing the domain validation.

Ryan's described algorithm basically means that any service you click "sign
in to Google" (i.e. OAuth) with could potentially obtain an S/MIME
certificate for you, on your behalf, without any authorization or
interaction with the CA by you the user, or by GMail as the domain holder.
That's quite literally the design captured in the diagram (
at least from the perspective of an external party.

However, on a technical level, it's even worse. It relies on pinky swears
(aka contracts) between the RA and the CA. The RA is quite literally
allowed to request certificates for any domain and user, but pinky-swears
to the CA that it will only request certificates for users who click "sign
in with Google", and (hopefully, but not specified) if they agree to that.
In this scenario, the operator of the domain name (e.g. "gmail.com") has no
control over this - not even CAA. The end-user has no awareness of this
issuance either - any OAuth login could be used to cause issuance of an
S/MIME certificate.

The "benefit" of this scenario is that it just works with OAuth, and the
user never has to know which CA is dealing certs out in their name. They
may never even see the cert - the RA (service provider) may be the only one
with the keys, acting in the user's name, simply because they signed in.

All of this is under the /best/ case scenario. You could just forgo the
OAuth dance entirely - the RA could just tell the CA "Yo, give me a cert
for that Sleevi guy", and that would be that.

This is why I think it's crucial to require the CA perform the domain
validation portion. It requires that, in this case, the email provider
authorize the CA (if the CA is going to have a blank check for that
domain), or that the user authorize the CA (if the CA is only going to be
able to issue for that user). This does make it hard to just issue certs to
whomever you want. That's a feature, not a bug, and would be key to any
future improvements we might want to see in this space (e.g. CAA)

Is there a path with OAuth to allow delegation? Well, yes, there's a whole
host of concepts in signed assertions and JWT where you might allow Service
Provider to obtain a signed assertion from Mail Provider to act on behalf
of the user, and that Service Provider could in turn hand that signed
assertion to any CA, and the CA could verify that assertion back with Mail
Provider that the Service Provider was authorized. But that's not what is
described in the diagram, because that requires changes to Mail Provider,
and the 'desired benefit' of omitting this requirement from policy is to
allow issuing arbitrary certificates without the explicit, quantifiable
consent of the user or the mail provider. I think that's insecure.
dev-security-policy mailing list

Reply via email to