On Tue, Apr 3, 2018 at 11:42 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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? > > Our policy covers this in section 2.2(1) : *All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.* > > > > > 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
