On Wednesday, May 15, 2019 at 10:36:00 AM UTC-7, Ryan Sleevi wrote: > On Wed, May 15, 2019 at 1:18 PM Ryan Hurst via dev-security-policy < \> > 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) As I stated above multiple times, this new change does clarify that the domain owner is authoritative for the local part and CAs can directly rely on them as such.
> 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. [rmh] It is a diagram that shows a delegated RA; it is not insecure, it is not allowed under the current policy but my point is that a delegated RA agreement that limited the RA to use cases where these federated authentication providers attest that the user controls an email they manage, given the nature of emails and authentication, seems desirable to accommodate if we believe client certificates should be used more. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
