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."

> 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

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

Reply via email to