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 ( https://www.dropbox.com/s/ocfow995aluowyl/auth%20redirect%20cert%20flow.png?dl=0 ), 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
