On Wed, Apr 4, 2018 at 3:44 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, April 4, 2018 at 3:39:46 PM UTC-7, Wayne Thayer wrote:
> > On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy <
> > > My opinion on this method and on Adrian's comments is that the
> CA/Browser
> > Forum, with it's new-found ability to create an S/MIME Working Group, is
> a
> > better venue for formulating secure email validation methods. Does it
> make
> > sense for us to define more specific email validation methods in this
> forum
> > when it's likely the CA/Browser Forum will do the same in the next year
> or
> > two?
> I understand that position, and maybe this is acceptable, but I believe
> the removal of "business controls" (which to be clear I like) prohibits
> this practice when it is reasonable and even desirable.
> The "business controls" language has always been scoped to technically
constrained subordinate CAs, so nothing has changed.

I was thinking until an S/MIME policy is established some accommodation of
> federated login in the mozilla policy accompanying the removal of "business
> controls" would address that.
> I think the existing language in section 2.2(2) also supports the
federated authentication system use case you described. It says that the CA
"takes reasonable measures to verify that the entity submitting the request
controls the email account associated with the email address referenced in
the certificate". If a CA first confirms that it is a condition of a
particular federated authentication system that a user must have proven
control over the email account that constitutes their username to activate
their account, then requires that user to prove they can authenticate in to
the account, I think that meets the "reasonable" standard, even though a
threat analysis might determine that the method is insufficient for various

If the problem is that the user is not the "entity submitting the request",
could that be changed?

Alternately, maybe you can suggest a change to 2.2(2) that achieves your
goals without going so far as permitting "business controls" for validation?
dev-security-policy mailing list

Reply via email to