On Tue, Apr 3, 2018 at 12:19 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > > For example, if we consider a CA supporting a large mail provider in > providing S/MIME certificates to all of its customers. In this model, the > mail provider is the authoritative namespace owner. > There may be interest in some of the other twists such a concept helps to illuminate. MV (mail validated) versus IV (individual validated). I'm aware that the BRs don't contemplate email certificates and standards pertaining to these, but one of the BR concepts is that Subject party data of an unvalidated nature not be included in the certificate. For example, no O= component on certificates which were solely domain validated. Similarly, does or should Mozilla policy consider Subject parameters other than E= in the email program? A third party domain delegating via MX record email addresses of that domain does seem both point-in-time auditable and would generally prove that a party at the target MX server does or could choose to receive email to any address at that domain. But even the domain serving the email address doesn't get us to CN=Real Name. So, my question is whether the policy should incorporate standards similar to the BRs which require that those personal-level details be validated if included? > > In the context of mail, you can imagine gmail.com or peculiarventures.com > as examples, both are gmail (as determined by MX records). It seems > reasonable to me (Speaking as Ryan and not Google here) to allow a CA to > leverage this internet reality (expressed via MX records) to work with a CA > to get S/MIME certificates for all of its customers without forcing them > through an email challenge. > > In this scenario, you could not rely on name constraints because the > onboarding of custom domains (like peculiarventures.com) happens real > time as part of account creation. The prior business controls text seemed > to allow this case but it seems the interpretation discussed here would > prohibit it. > > > Another case I think is interesting is that of a delegation of email > verification to a third-party. For example, when you do a OAUTH > authentication to Facebook it will return the user’s email address if it > has been verified. The same is true for a number of related scenarios, for > example, you can tell via Live Authentication and Google Authentication if > the user's email was verified. > Among other questions that raises, how do you determine and audit the trustworthiness of the third party to speak as to the email validation? It seems the trend in the BR world of the WebPKI is to reduce reliance on third party validations and assertions. > > The business controls text plausibly would have allowed this use case also. > > I think a policy that does not allow a CA to support these use cases would > severly limit the use cases in which S/MIME could be used and I would like > to see them considered. > > Ryan Hurst > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
