On Wed, May 15, 2019 at 1:18 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > > I think this bears expansion because I don't think it's been clearly > > documented what flow you believe is currently permitted today that will > be > > prevented tomorrow with this change. > > To be clear, In that statement was referring to that scenario being > allowed under the proposed change where the mail provider who is > authoritative for a domain can get certificates for its users. > > Specifically where Wayne suggested: > "CAs MUST NOT delegate validation of the domain name part of an email > address to a 3rd party." > > Are you suggesting with that change mail providers cannot get certificates > for their users without the CA validating the local party? > As Wayne noted in his existing message, there is an existing restriction Forbidden Practices: Delegation of email address validation is already addressed by Mozilla's > Forbidden Practices [1] state: > "Domain and Email validation are core requirements of the Mozilla's Root > Store Policy and should always be incorporated into the issuing CA's > procedures. Delegating this function to 3rd parties is not permitted." [1] > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties So I'm stating that the proposed change is functionally more liberal than the existing requirement. I'm suggesting that, as it stands today, CAs cannot be issuing S/MIME certificates to end users without first performing the validation of the domain name portion themselves (new policy), and potentially the local part as well (existing policy) > > The level of abstraction here doesn't > > help, because understanding the state diagram of what the SAAS is > > requesting, and who it's requesting it of, is vital to understanding the > > security properties. > > I put together a quick diagram to try to visually explain the flow: > > https://www.dropbox.com/s/ocfow995aluowyl/auth%20redirect%20cert%20flow.png?dl=0 Thanks. I think this is desirable to forbid, as it is insecure, and I believe it's already forbidden, because the process of step (4) is relying on GMAIL to act as a Delegated Third Party for the validation of the e-mail address. There are a host of security issues here in the described flow. As demonstrated, Step (6) and (7) entirely absent any validation by the CA of the e-mail address, which should be a dead-ringer for why it's problematic. If you replace "SAAS" with "Attacker", this should be clear and obvious. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
