Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

I've opened issue #196 [1] to track Rufus' suggested clarification for a
future policy update. I'll consider this issue (#175) resolved unless
further comments are received.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/196

On Mon, Oct 28, 2019 at 4:41 PM Wayne Thayer  wrote:

> On Sun, Oct 27, 2019 at 3:46 PM Buschart, Rufus <
> rufus.busch...@siemens.com> wrote:
>
>> Maybe the following could be a reasonable rewording of the paragraph that
>> makes the intention of the discussion clear, but isn't to 'clunky':
>>
>> For a certificate capable of being used for digitally signing or
>> encrypting email messages, the CA SHALL validate that the Applicant
>> Representative (as defined in the BRGs) of the request controls the email
>> account associated with the email address referenced in the certificate,
>> except when the CA and the owner of the domain are Affiliates (as defined
>> in the BRGs). The CA SHALL NOT delegate the validation of an email address.
>> The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
>> to perform this validation.
>>
>>
> Thank you for the proposal. Proposals are always helpful! However, this
> seems significantly less clear to me.
>
> With this wording we would reach:
>>
>> 1) The request can be initiated by the Applicant or Applicant
>> Representative - due to the definition of Applicant Representative in the
>> BRGs
>>
>
> The existing language does the same without adding more BR references.
>
> 2) Every CA can continue to issue S/MIME certificates as long as they
>> perform a validation of the control of the email address
>> 3) The CA cannot delegate the validation process
>>
>
> Did you intentionally omit the language that allows the CA to delegate
> validation of the local portion of the email address?
>
> 4) If the operator of the mail server operates its own CA, he doesn't have
>> to perform error prone email address validations
>>
>
> The existing language already permits this via "*or* has been authorized
> by the email account holder to act on the account holder's behalf."
>
> Do you believe that this is forbidden by the current version of Mozilla
> policy?
>
>
>> 5) We don't mix the words validation and verification for the same
>> activity
>>
>>
> I have no issue with changing "verification" to "validation", but this is
> also unchanged from the current version of the policy.
>
> In other words, these proposed changes address what might be another
> potential issue with the existing policy, but don't appear to be essential
> to the issue being discussed in this thread.
>
> > As to which is it - is it the MX admin/domain admin or the individual
>> meat person - it seems that the answer is
>> > either/or/both, at least from the perspective of RFC 822. The
>> meat-person may control the account, or the admin
>> > of the account may themselves control the account, or the admin of the
>> domain may control the MX that controls
>> > the account. In all cases, they control the email account associated.
>>
>> In the upcoming S/MIME WG I see a lot of discussions around this topic
>> arising.
>>
>> With best regards,
>> Rufus Buschart
>>
>> Siemens AG
>> Siemens Operations
>> Information Technology
>> Value Center Core Services
>> SOP IT IN COR
>> Freyeslebenstr. 1
>> 91058 Erlangen, Germany
>> Tel.: +49 1522 2894134
>> mailto:rufus.busch...@siemens.com
>> http://www.twitter.com/siemens
>> https://siemens.com/ingenuityforlife
>>
>> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
>> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief
>> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel,
>> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and
>> Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300,
>> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Sun, Oct 27, 2019 at 3:46 PM Buschart, Rufus 
wrote:

> Maybe the following could be a reasonable rewording of the paragraph that
> makes the intention of the discussion clear, but isn't to 'clunky':
>
> For a certificate capable of being used for digitally signing or
> encrypting email messages, the CA SHALL validate that the Applicant
> Representative (as defined in the BRGs) of the request controls the email
> account associated with the email address referenced in the certificate,
> except when the CA and the owner of the domain are Affiliates (as defined
> in the BRGs). The CA SHALL NOT delegate the validation of an email address.
> The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
> to perform this validation.
>
>
Thank you for the proposal. Proposals are always helpful! However, this
seems significantly less clear to me.

With this wording we would reach:
>
> 1) The request can be initiated by the Applicant or Applicant
> Representative - due to the definition of Applicant Representative in the
> BRGs
>

The existing language does the same without adding more BR references.

2) Every CA can continue to issue S/MIME certificates as long as they
> perform a validation of the control of the email address
> 3) The CA cannot delegate the validation process
>

Did you intentionally omit the language that allows the CA to delegate
validation of the local portion of the email address?

4) If the operator of the mail server operates its own CA, he doesn't have
> to perform error prone email address validations
>

The existing language already permits this via "*or* has been authorized by
the email account holder to act on the account holder's behalf."

Do you believe that this is forbidden by the current version of Mozilla
policy?


> 5) We don't mix the words validation and verification for the same activity
>
>
I have no issue with changing "verification" to "validation", but this is
also unchanged from the current version of the policy.

In other words, these proposed changes address what might be another
potential issue with the existing policy, but don't appear to be essential
to the issue being discussed in this thread.

> As to which is it - is it the MX admin/domain admin or the individual
> meat person - it seems that the answer is
> > either/or/both, at least from the perspective of RFC 822. The
> meat-person may control the account, or the admin
> > of the account may themselves control the account, or the admin of the
> domain may control the MX that controls
> > the account. In all cases, they control the email account associated.
>
> In the upcoming S/MIME WG I see a lot of discussions around this topic
> arising.
>
> With best regards,
> Rufus Buschart
>
> Siemens AG
> Siemens Operations
> Information Technology
> Value Center Core Services
> SOP IT IN COR
> Freyeslebenstr. 1
> 91058 Erlangen, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> http://www.twitter.com/siemens
> https://siemens.com/ingenuityforlife
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief
> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel,
> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and
> Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300,
> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Fri, Oct 25, 2019 at 6:44 PM Buschart, Rufus 
wrote:

> Your statement is, in my opinion, totally correct for external CAs. But
> the scenario I have in my mind is a little bit different: In my scenario,
> there is
> a Root CA that is included in the Root stores serving the general public
> and an internal issuing CA only serving "mycompany". In this scenario, Root
> CA issues a name-constrained S/MIME-issuing CA certificate to the internal
> CA of "mycompany" after this CA has proven control over the DNS records for
> "mycompany.example". This proof of control should be based on the methods
> from BRG 3.2.2.4. (taking Ryans remark about the problems of http-
> validation for this scenario into account). The internal CA issues only
> S/MIME end-entity-certificates for mailboxes under @mycompany.example.
> Now we have (a) and (b) as totally separated sets of verifications. In
> this scenario, I would expect, that the root CA describes (a) and the
> internal
> issuing CA describes (b) in their CP/CPS.
>

Sure, this seems to be permitted under the most recent commit (
https://github.com/mozilla/pkipolicy/commit/0a63f457c059365103e48ad3eb409cd376903e51
)?
Provided that both entities disclose the reasonable measures, and that root
CA doesn't delegate the domain portion, the policy is met?


> And while writing this email, I think I found one more problem: You are
> using the term "email account holder" which isn't defined anywhere. Who
> is the "email account holder" for john.doe@mycompany.example? Is it John
> Doe or is it "mycompany"? And in the case of
> john.doe@public-mail-provider.example? Is it John Doe or the "public mail
> provider"? I think we need a definition, ideally based on the terms
> "Subject" and "Subscriber". Or we replace "email account holder" with one
> of the two terms?


Isn't it handled within that same sentence?

"the entity submitting the request controls the email account associated
with the email address referenced in the certificate" seems like it should
be clear that the "email account holder" (the following clause) is "the
entity that controls the email account associated with the email address"
(since it's handling the situation where the applicant is not that entity)

The clunkier reword (not a fan, but seeing how you feel about this, Rufus)
would be
"the entity submitting the request is *either* the entity that controls the
email account associated with the email address referenced in the
certificate *or* has been authorized by the entity that controls the email
address referenced within the certificate"

That avoids introducing the backreference term, but is a mouthful. I'm
assuming you meant Applicant and not Subscriber, since we're talking
pre-issuance validation ;)

As to which is it - is it the MX admin/domain admin or the individual meat
person - it seems that the answer is either/or/both, at least from the
perspective of RFC 822. The meat-person may control the account, or the
admin of the account may themselves control the account, or the admin of
the domain may control the MX that controls the account. In all cases, they
control the email account associated.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Thu, Oct 24, 2019 at 10:33 AM Buschart, Rufus 
wrote:

> On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi 
> wrote:
> > On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy
>  wrote:
> >> Thanks Dimitris and Rufus. Would it satisfy your concern if the
> requirement
> >> was changed to:
> >>
> >> The CA SHALL NOT delegate validation of the Base Domain Name (as
> defined in
> >> the Baseline Requirements) portion of an email address.
>
> Thanks Wayne, I like the new wording.
>
> > If the CA has validated "mycompany.example", associated with account
> "mycompany", what is the expectation for 'localpart'?
> >
> > Interpretation 1) The CA MAY delegate validation of the localpart to
> 'mycompany'. However, 'mycompany' MUST take reasonable measure ...
> > Interpretation 2) By validating 'mycompany' as to have control over
> 'mycompany.example', the CA has taken reasonable measure. No further
> validation requirements
> > exist for the localpart, provided it is directed by the 'mycompany'
> account, as 'mycompany' is seen to implicitly have control over the MX
> records.
> >
> > I'm not sure Interpretation #2 fully holds (e.g. if the CA were using
> something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was
> trying to get at whether
> > (CA || mycompany) needs to perform some validation step for 'localpart'
> once the validation for the domain part is done.
>
> I simply want to avoid to come into the situation, that I as the operator
> of an internal Enterprise PKI have to do some additional email validation
> on our own mailboxes. We do have 350 k users, if the validation process
> fails only at 1% of them, we have 3500 help desk tickets.
>
> One last remark: I might be the only one, but I'm not 100% sure what the
> "this verification" at the end of the last sentence refers to. Is "this
> verification" (a) the verification of the Authorization Domain Name, (b)
> the verification of the email address or (c) both together? If it is (b),
> as I believe, I would move the whole sentence, starting from "The CA's
> CP/CPS...", after the first sentence (ending with "the account holder's
> behalf").
>
>
I would argue that (a) is a subset of (b) and there is no difference
between (b) and (c), but the intent is (c). If a CA issues both TLS and
S/MIME certificates, their CPS could simply state that the domain component
is validated using the same methods as used for TLS. For a CA that only
issues S/MIME certificates, I want to see the methods used to validate the
domain part documented - especially given that they aren't subject to the
BRs - along with the methods used to validate the local part or the entire
address.

Would changing "this" to "email address" but leaving that sentence after
the domain part requirements make it clear? That would read:

"The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
to perform email address verification."

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi  wrote:

>
> On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> > I'm also not sure if I understand the wording correctly. Let's assume,
>> an
>> > internal CA of company "mycompany" gets successfully validated for
>> > mycompany.example and receives a (possibly name constrained) certificate
>> > for its issuing CA from one of the root CAs. Can this internal CA issue
>> > certificates for every email address under @mycompany.example without
>> > further validation or is an internal validation process required? My
>> > opinion is, that such an internal validation process doesn't increase
>> > security, since mycompany controls the mailservers of mycompany and can
>> > anyhow validate everything.
>> >
>> >
>> Thanks Dimitris and Rufus. Would it satisfy your concern if the
>> requirement
>> was changed to:
>>
>> The CA SHALL NOT delegate validation of the Base Domain Name (as defined
>> in
>> the Baseline Requirements) portion of an email address.
>>
>
> I may be misunderstanding Rufus' concern, but it seemed slightly different?
>
> That is, taken in the whole of 2.2, the expectation is "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 *or* has been authorized by the email account holder to act
> on the account holder's behalf".
>
> If the CA has validated "mycompany.example", associated with account
> "mycompany", what is the expectation for 'localpart'?
>
> Interpretation 1) The CA MAY delegate validation of the localpart to
> 'mycompany'. However, 'mycompany' MUST take reasonable measure ...
> Interpretation 2) By validating 'mycompany' as to have control over
> 'mycompany.example', the CA has taken reasonable measure. No further
> validation requirements exist for the localpart, provided it is directed by
> the 'mycompany' account, as 'mycompany' is seen to implicitly have control
> over the MX records.
>
> I'm not sure Interpretation #2 fully holds (e.g. if the CA were using
> something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was
> trying to get at whether (CA || mycompany) needs to perform some validation
> step for 'localpart' once the validation for the domain part is done.
>
>
The "new" (it was already a Forbidden Practice) restriction on delegating
domain validation doesn't change the language that applies here, which is
that "...the CA takes reasonable measures..." and that "The CA's CP/CPS
must clearly specify the procedure(s)...". Until there are BRs for S/MIME,
CAs must define and document their email validation practices.

  As to Dimitris' case, I think you're spot on in understanding the problem.
>
>
>> Alternately, would this create an unacceptable loophole in the requirement
>> and if so, can you suggest a more secure alternative?
>
>
> My worry is that CAs will read this believing it permits more than
> intended. If the CA doesn't use "Base Domain Name" / "Authorization Domain
> Name", and only validates at the FQDN (i.e. the entire @domain), they may
> see this as being permitted to delegate. After all, they are not delegating
> validation of a Base Domain Name, they're delegating validation of an FQDN.
>
> """The CA SHALL NOT delegate validation of the domain portion of an email
> address. The CA MAY rely on validation the CA has performed for an
> Authorization Domain Name (as specified in the Baseline Requirements) as
> being valid for subdomains of that Authorization Domain Name."""
>
>
This is much better, thanks. The proposed change is:
https://github.com/mozilla/pkipolicy/commit/0a63f457c059365103e48ad3eb409cd376903e51

The point here is to make it explicit SHALL NOT. The following sentence
> does not conflict or limit that scope, but gives the CA limited additional
> permission to address the case Dimitris raised.
>
> The choice of "Authorization Domain Name" versus "Base Domain Name" is
> that a given FQDN may have multiple "Base Domain Names", due to how the
> Public Suffix List works. The Authorization Domain Name process was
> designed to find the most specific Base Domain Name, by pruning labels
> left-to-right. Rather than recreate that algorithm, I reused it here.
>
> The downside is that such a definition picks up CNAME chasing, which
> (similar to the remarks to Rufus), can be distinct from MX validation in
> some situations. However, it's a trade-off, and seems strictly improved
> over the status quo, and regardless, the documentation requirement that 2.2
> places would cover those situations (hopefully).
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > I'm also not sure if I understand the wording correctly. Let's assume, an
> > internal CA of company "mycompany" gets successfully validated for
> > mycompany.example and receives a (possibly name constrained) certificate
> > for its issuing CA from one of the root CAs. Can this internal CA issue
> > certificates for every email address under @mycompany.example without
> > further validation or is an internal validation process required? My
> > opinion is, that such an internal validation process doesn't increase
> > security, since mycompany controls the mailservers of mycompany and can
> > anyhow validate everything.
> >
> >
> Thanks Dimitris and Rufus. Would it satisfy your concern if the requirement
> was changed to:
>
> The CA SHALL NOT delegate validation of the Base Domain Name (as defined in
> the Baseline Requirements) portion of an email address.
>

I may be misunderstanding Rufus' concern, but it seemed slightly different?

That is, taken in the whole of 2.2, the expectation is "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 *or* has been authorized by the email account holder to act
on the account holder's behalf".

If the CA has validated "mycompany.example", associated with account
"mycompany", what is the expectation for 'localpart'?

Interpretation 1) The CA MAY delegate validation of the localpart to
'mycompany'. However, 'mycompany' MUST take reasonable measure ...
Interpretation 2) By validating 'mycompany' as to have control over
'mycompany.example', the CA has taken reasonable measure. No further
validation requirements exist for the localpart, provided it is directed by
the 'mycompany' account, as 'mycompany' is seen to implicitly have control
over the MX records.

I'm not sure Interpretation #2 fully holds (e.g. if the CA were using
something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was
trying to get at whether (CA || mycompany) needs to perform some validation
step for 'localpart' once the validation for the domain part is done.

  As to Dimitris' case, I think you're spot on in understanding the problem.


> Alternately, would this create an unacceptable loophole in the requirement
> and if so, can you suggest a more secure alternative?


My worry is that CAs will read this believing it permits more than
intended. If the CA doesn't use "Base Domain Name" / "Authorization Domain
Name", and only validates at the FQDN (i.e. the entire @domain), they may
see this as being permitted to delegate. After all, they are not delegating
validation of a Base Domain Name, they're delegating validation of an FQDN.

"""The CA SHALL NOT delegate validation of the domain portion of an email
address. The CA MAY rely on validation the CA has performed for an
Authorization Domain Name (as specified in the Baseline Requirements) as
being valid for subdomains of that Authorization Domain Name."""

The point here is to make it explicit SHALL NOT. The following sentence
does not conflict or limit that scope, but gives the CA limited additional
permission to address the case Dimitris raised.

The choice of "Authorization Domain Name" versus "Base Domain Name" is that
a given FQDN may have multiple "Base Domain Names", due to how the Public
Suffix List works. The Authorization Domain Name process was designed to
find the most specific Base Domain Name, by pruning labels left-to-right.
Rather than recreate that algorithm, I reused it here.

The downside is that such a definition picks up CNAME chasing, which
(similar to the remarks to Rufus), can be distinct from MX validation in
some situations. However, it's a trade-off, and seems strictly improved
over the status quo, and regardless, the documentation requirement that 2.2
places would cover those situations (hopefully).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 10:59 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > > Sounds good. This was your proposed response to solving this issue
> > > back on May 13, so it's full circle :)
> > >
> > >
> > > I'm going to consider this issue resolved unless there are further
> > > comments.
> >
> > Just checking whether the following is acceptable.
> >
> > If a CA validates the domain mycompany.example being owned/controlled by
> "mycompany", can this company delegate the issuance of
> > S/MIME certificates for subsection1.mycompany.example to an internal
> department or a subsidiary? Does the proposed language allow
> > this?
>
> I'm also not sure if I understand the wording correctly. Let's assume, an
> internal CA of company "mycompany" gets successfully validated for
> mycompany.example and receives a (possibly name constrained) certificate
> for its issuing CA from one of the root CAs. Can this internal CA issue
> certificates for every email address under @mycompany.example without
> further validation or is an internal validation process required? My
> opinion is, that such an internal validation process doesn't increase
> security, since mycompany controls the mailservers of mycompany and can
> anyhow validate everything.
>
>
Thanks Dimitris and Rufus. Would it satisfy your concern if the requirement
was changed to:

The CA SHALL NOT delegate validation of the Base Domain Name (as defined in
the Baseline Requirements) portion of an email address.

Alternately, would this create an unacceptable loophole in the requirement
and if so, can you suggest a more secure alternative?

By the way: How are CAA records to be treated in the scope of S/MIME? Since
> gmail.com has a CAA record that prevents every CA except of Google to
> issue certificates for gmail.com, does this also forbid every CA to issue
> certificates for rufus.busch...@gmail.com?
>
>
I'm not aware of any current policy that requires CAs to perform CAA checks
on S/MIME certificates.

With best regards,
> Rufus Buschart
>
> Siemens AG
> Siemens Operations
> Information Technology
> Value Center Core Services
> SOP IT IN COR
> Freyeslebenstr. 1
> 91058 Erlangen, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> www.twitter.com/siemens
>
> www.siemens.com/ingenuityforlife
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief
> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel,
> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and
> Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300,
> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Dimitris Zacharopoulos via dev-security-policy]

On 2019-10-22 7:28 μ.μ., Wayne Thayer wrote:


The CA SHALL NOT delegate validation of the domain part of
an e-mail
address.


This is

https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a


Sounds good. This was your proposed response to solving this issue
back on May 13, so it's full circle :)


I'm going to consider this issue resolved unless there are further 
comments.


Just checking whether the following is acceptable.

If a CA validates the domain mycompany.example being owned/controlled by 
"mycompany", can this company delegate the issuance of S/MIME 
certificates for subsection1.mycompany.example to an internal department 
or a subsidiary? Does the proposed language allow this?



Thanks,
Dimitris.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Mon, Oct 21, 2019 at 7:01 PM Ryan Sleevi  wrote:

>
> On Mon, Oct 21, 2019 at 7:58 PM Wayne Thayer  wrote:
>
>> The CA MUST verify all e-mail addresses using a process that is
>>> substantially similar to the process used to verify domain names, as
>>> described in the Baseline Requirements.
>>>
>>
>> This seems problematic because it could be interpreted as forbidding an
>> email challenge-response validation, not to mention that "substantially"
>> leaves a lot of room for interpretation.
>>
>
> Yeah, this was more about short-hand matching the existing 2.2
> requirements for validation, which leave "reasonable measures" as the
> validation requirement (i.e. even more room for interpretation ;D)
>
>
>> The CA SHALL NOT delegate validation of the domain part of an e-mail
>>> address.
>>>
>>
>> This is
>> https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a
>>
>
> Sounds good. This was your proposed response to solving this issue back on
> May 13, so it's full circle :)
>
>

I'm going to consider this issue resolved unless there are further comments.


>> The CA SHALL NOT delegate validation of the local part of an e-mail
>>> address
>>> except when delegating to an Enteprise RA, provided that the domain part
>>> of
>>> the e-mail address is within the Enteprise RA's verified Domain
>>> Namespace.
>>>
>>>
>> This seems to go beyond the original intent of this issue and the
>> discussion to-date, and Enterprise RAs are not defined in the context of
>> S/MIME certificates. Why is the existing language in section 2.2(2)
>> insufficient to cover this requirement?
>>
>
> Your original proposal seemed to entirely do away with this ("Delegating
> this function to 3rd parties is not permitted."). I was trying to capture
> the subset for the use case folks identified (including my initial reply to
> your proposal, back on May 13), while still being more prescriptive.
>
> The issue/concern would be a CA reads that they shall not delegate the
> domain portion, but don't realize it /also/ means they can't delegate
> 'total' validation, since the full e-mail also contains a domain part. i.e.
> that I can't delegate validating sleevi.example, but I can totally delegate
> validating ryan@sleevi.example since that's not delegating "just" a
> domain part, but delegating validation a "total" email.
>
> It's contrived, I agree, but it was trying to match your original, much
> more restrictive language, of not allowing any delegation of e-mail.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Mon, Oct 21, 2019 at 7:58 PM Wayne Thayer  wrote:

> The CA MUST verify all e-mail addresses using a process that is
>> substantially similar to the process used to verify domain names, as
>> described in the Baseline Requirements.
>>
>
> This seems problematic because it could be interpreted as forbidding an
> email challenge-response validation, not to mention that "substantially"
> leaves a lot of room for interpretation.
>

Yeah, this was more about short-hand matching the existing 2.2 requirements
for validation, which leave "reasonable measures" as the validation
requirement (i.e. even more room for interpretation ;D)


> The CA SHALL NOT delegate validation of the domain part of an e-mail
>> address.
>>
>
> This is
> https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a
>

Sounds good. This was your proposed response to solving this issue back on
May 13, so it's full circle :)


>
> The CA SHALL NOT delegate validation of the local part of an e-mail address
>> except when delegating to an Enteprise RA, provided that the domain part
>> of
>> the e-mail address is within the Enteprise RA's verified Domain Namespace.
>>
>>
> This seems to go beyond the original intent of this issue and the
> discussion to-date, and Enterprise RAs are not defined in the context of
> S/MIME certificates. Why is the existing language in section 2.2(2)
> insufficient to cover this requirement?
>

Your original proposal seemed to entirely do away with this ("Delegating
this function to 3rd parties is not permitted."). I was trying to capture
the subset for the use case folks identified (including my initial reply to
your proposal, back on May 13), while still being more prescriptive.

The issue/concern would be a CA reads that they shall not delegate the
domain portion, but don't realize it /also/ means they can't delegate
'total' validation, since the full e-mail also contains a domain part. i.e.
that I can't delegate validating sleevi.example, but I can totally delegate
validating ryan@sleevi.example since that's not delegating "just" a domain
part, but delegating validation a "total" email.

It's contrived, I agree, but it was trying to match your original, much
more restrictive language, of not allowing any delegation of e-mail.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Sat, Oct 5, 2019 at 6:32 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks Jeremy, Dimitris,
>
> It does help clarify. I think we're all on the same page: namely, in all
> cases, the CA does the validation of (at minimum) the domain portion.
>
> I think it might be useful to think of this like the split between
> Authorization Domain Name and Fully Qualified Domain Name. A CA isn't
> /required/ to only use the ADN, they could validate just the FQDN and
> always at the FQDN level. But, in both cases, they have to at least
> validate (a portion of) the domain name.
>
> For S/MIME, the idea here is:
> - If the CA had validated the domain portion, they could delegate the
> validation of the local part to the RA. This is the same as the concept of
> Enterprise RA, which allows the RA to handle the O/OU and other attributes,
> as long as the CA validated the domain.
> - Alternatively, the CA could validate the entire e-mail address (e.g.
> using a random value)
>
> But in both cases, the CA is involved in any domain-part validation.
>
> Perhaps said differently:
>

It's not clear if you intended the following to be a concrete policy
proposal, but I'll treat it as such.

The CA MUST verify all e-mail addresses using a process that is
> substantially similar to the process used to verify domain names, as
> described in the Baseline Requirements.
>

This seems problematic because it could be interpreted as forbidding an
email challenge-response validation, not to mention that "substantially"
leaves a lot of room for interpretation.

The CA SHALL NOT delegate validation of the domain part of an e-mail
> address.
>

This is
https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a

The CA SHALL NOT delegate validation of the local part of an e-mail address
> except when delegating to an Enteprise RA, provided that the domain part of
> the e-mail address is within the Enteprise RA's verified Domain Namespace.
>
>
This seems to go beyond the original intent of this issue and the
discussion to-date, and Enterprise RAs are not defined in the context of
S/MIME certificates. Why is the existing language in section 2.2(2)
insufficient to cover this requirement?

I tried a couple variations of this (e.g. MAY delegate), but that could be
> read as a loophole of allowing other forms of local-part delegation (i.e.
> the "MAY" reads as "MAY use an Enterprise RA, or MAY use whatever else you
> want", instead of "MAY" only if Enterprise RA)
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

Thanks Jeremy, Dimitris,

It does help clarify. I think we're all on the same page: namely, in all
cases, the CA does the validation of (at minimum) the domain portion.

I think it might be useful to think of this like the split between
Authorization Domain Name and Fully Qualified Domain Name. A CA isn't
/required/ to only use the ADN, they could validate just the FQDN and
always at the FQDN level. But, in both cases, they have to at least
validate (a portion of) the domain name.

For S/MIME, the idea here is:
- If the CA had validated the domain portion, they could delegate the
validation of the local part to the RA. This is the same as the concept of
Enterprise RA, which allows the RA to handle the O/OU and other attributes,
as long as the CA validated the domain.
- Alternatively, the CA could validate the entire e-mail address (e.g.
using a random value)

But in both cases, the CA is involved in any domain-part validation.

Perhaps said differently:
The CA MUST verify all e-mail addresses using a process that is
substantially similar to the process used to verify domain names, as
described in the Baseline Requirements.
The CA SHALL NOT delegate validation of the domain part of an e-mail
address.
The CA SHALL NOT delegate validation of the local part of an e-mail address
except when delegating to an Enteprise RA, provided that the domain part of
the e-mail address is within the Enteprise RA's verified Domain Namespace.

I tried a couple variations of this (e.g. MAY delegate), but that could be
read as a loophole of allowing other forms of local-part delegation (i.e.
the "MAY" reads as "MAY use an Enterprise RA, or MAY use whatever else you
want", instead of "MAY" only if Enterprise RA)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Dimitris Zacharopoulos via dev-security-policy]

Jeremy,

As I'm sure you know, there are several federated services, at least in 
the Education and Research area, where schemes like https://edugain.org/ 
are used. In that scenario, Identity Providers under a certain policy 
(https://technical.edugain.org/documents) provide signed assertions that 
contain the full name and email address of the Subject, along with other 
signed attributes. Identity providers under this scheme usually have 
even stricter policies. Unfortunately these entities are not under a 
strict audit scheme but has been working pretty well for decades.


If any of these Identity Providers want to enable their users to get an 
S/MIME Certificate trusted by NSS, I think it would be acceptable for 
the CA to validate control of the Domain part and then let the federated 
login take care of the local part. Does that seem reasonable?



Dimitris.

On 2019-10-05 9:45 π.μ., Jeremy Rowley via dev-security-policy wrote:

I’m thinking more in terms of the potential rule in the Mozilla policy. If the 
rule is “the CA MUST verify the domain component of the email address” then the 
rule potentially prohibits the scenario where the CA verifies the entire email 
address, not the domain component, by sending a random value to each email 
address and requiring the email address holder to approve issuance. I actually 
liked the previous requirement prohibiting delegation of email address 
verification, although the rule lacked clarity on what email address 
verification entailed. I figure that will be defined in the s/MIME working 
group.

Describing the actors is a good way to look at it though. Besides those three 
buckets of issuers, you have the RAs, the email holders, and the organization 
controlling the domain portion of the email address. These entities may not be 
the same as the CA. More often than not, the RA ends up being the organization 
contracting with the CA for the s/MIME services. The RAs are the risky party 
that I think should be restricted on what they can verify since that’s where 
the lack of transparency starts to come in. With the prohibition against 
delegation of email control eliminated, we’re again placing domain/email 
control responsibilities on a party that has some incentive to misuse it (to 
read email of a third party) without audit, technical, or policy controls that 
limit their authority.  Because there are a lack of controls over the RAs, they 
become a hidden layer in the process that can issue certificates without anyone 
looking at how they are verifying the email address or domain name and whether 
these processes are equivalent to the controls found int eh BR.  Similar to 
TLS, the unaudited party should not be the one providing or verifying 
acceptance of the tokens used to approve issuance.

In short, I’m agreeing with the “at least” verifying the domain control 
portion. However, I know we verify a lot of email addresses directly with the 
email owner that doesn’t have control over the domain name. So the rule should 
be something that permits verification by the root CA of either the full email 
address or the domain name but at least eliminates delegation to non-audited 
third parties. For phrasing, “the CA MUST verify either the domain component of 
the email address or the entire email address using a process that is 
substantially similar to the process used to verify domain names as described 
in the Baseline Requirements”, with the understanding that we will rip out the 
language and replace it with the s/MIME requirements once those are complete at 
the CAB Forum.

Jeremy

From: Ryan Sleevi 
Sent: Friday, October 4, 2019 10:56 PM
To: Jeremy Rowley 
Cc: Kathleen Wilson ; Wayne Thayer ; 
mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for 
S/MIME Certificates

Jeremy:

Could you describe a bit more who the actors are?

Basically, it seems that the actual issuance is going to fall into one of 
several buckets:
1) Root CA controls Issuing CAs key
2) Issuing CA controls its own key, but is technically constrained
3) Issuing CA controls its own key, and is not technically constrained

We know #1 is covered by Root CA’s audit, and we know #3 is covered by Issuing 
CA’s audit, and #2 is technically constrained and thus the domain part is 
apriori validated.

So when you say “some organizations”, I’m trying to understand which of the three cases 
here they fall under. If I understand correctly, the idea is that Customer Foo approaches 
Root CA (Case #1). Root CA knows Foo’s namespace is foo.example through prior verification, 
and Root CA allows Foo to issue to *@foo.example<mailto:*@foo.example>. Then Foo says 
“oh, hey, we have a contractor at user@bar.example<mailto:user@bar.example>, we’d 
like a cert for them too”.

Why can’t Root CA verify themselves? Why would or should Root CA trust Foo to 
do it correctly? I can imagine plenty of verification protocols where Foo can 

RE: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Jeremy Rowley via dev-security-policy]

I’m thinking more in terms of the potential rule in the Mozilla policy. If the 
rule is “the CA MUST verify the domain component of the email address” then the 
rule potentially prohibits the scenario where the CA verifies the entire email 
address, not the domain component, by sending a random value to each email 
address and requiring the email address holder to approve issuance. I actually 
liked the previous requirement prohibiting delegation of email address 
verification, although the rule lacked clarity on what email address 
verification entailed. I figure that will be defined in the s/MIME working 
group.

Describing the actors is a good way to look at it though. Besides those three 
buckets of issuers, you have the RAs, the email holders, and the organization 
controlling the domain portion of the email address. These entities may not be 
the same as the CA. More often than not, the RA ends up being the organization 
contracting with the CA for the s/MIME services. The RAs are the risky party 
that I think should be restricted on what they can verify since that’s where 
the lack of transparency starts to come in. With the prohibition against 
delegation of email control eliminated, we’re again placing domain/email 
control responsibilities on a party that has some incentive to misuse it (to 
read email of a third party) without audit, technical, or policy controls that 
limit their authority.  Because there are a lack of controls over the RAs, they 
become a hidden layer in the process that can issue certificates without anyone 
looking at how they are verifying the email address or domain name and whether 
these processes are equivalent to the controls found int eh BR.  Similar to 
TLS, the unaudited party should not be the one providing or verifying 
acceptance of the tokens used to approve issuance.

In short, I’m agreeing with the “at least” verifying the domain control 
portion. However, I know we verify a lot of email addresses directly with the 
email owner that doesn’t have control over the domain name. So the rule should 
be something that permits verification by the root CA of either the full email 
address or the domain name but at least eliminates delegation to non-audited 
third parties. For phrasing, “the CA MUST verify either the domain component of 
the email address or the entire email address using a process that is 
substantially similar to the process used to verify domain names as described 
in the Baseline Requirements”, with the understanding that we will rip out the 
language and replace it with the s/MIME requirements once those are complete at 
the CAB Forum.

Jeremy

From: Ryan Sleevi 
Sent: Friday, October 4, 2019 10:56 PM
To: Jeremy Rowley 
Cc: Kathleen Wilson ; Wayne Thayer ; 
mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for 
S/MIME Certificates

Jeremy:

Could you describe a bit more who the actors are?

Basically, it seems that the actual issuance is going to fall into one of 
several buckets:
1) Root CA controls Issuing CAs key
2) Issuing CA controls its own key, but is technically constrained
3) Issuing CA controls its own key, and is not technically constrained

We know #1 is covered by Root CA’s audit, and we know #3 is covered by Issuing 
CA’s audit, and #2 is technically constrained and thus the domain part is 
apriori validated.

So when you say “some organizations”, I’m trying to understand which of the 
three cases here they fall under. If I understand correctly, the idea is that 
Customer Foo approaches Root CA (Case #1). Root CA knows Foo’s namespace is 
foo.example through prior verification, and Root CA allows Foo to issue to 
*@foo.example<mailto:*@foo.example>. Then Foo says “oh, hey, we have a 
contractor at user@bar.example<mailto:user@bar.example>, we’d like a cert for 
them too”.

Why can’t Root CA verify themselves? Why would or should Root CA trust Foo to 
do it correctly? I can imagine plenty of verification protocols where Foo can 
be the “face” of the verification, but that it uses Root CAs APIs and systems 
under the hood. I‘m fairly certain DigiCert has experience doing this for their 
customers, such as for white label CAs.

So that’s why I’m struggling to understand the use case, or the challenges, 
with at least requiring domain-part validation by the CA.

On Fri, Oct 4, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Will this permit either verification of the email address or the domain part? 
For example, some organizations may verify their entire domain space and then 
confirm contractors using a random value sent to the email address itself. They 
don't  need the entire domain space in those cases, but they do need to issue 
certificates for a few email addresses outside of their domain control. 
Verification of email control using a random value seems like it affords 
controls that are equivalen

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

Jeremy:

Could you describe a bit more who the actors are?

Basically, it seems that the actual issuance is going to fall into one of
several buckets:
1) Root CA controls Issuing CAs key
2) Issuing CA controls its own key, but is technically constrained
3) Issuing CA controls its own key, and is not technically constrained

We know #1 is covered by Root CA’s audit, and we know #3 is covered by
Issuing CA’s audit, and #2 is technically constrained and thus the domain
part is apriori validated.

So when you say “some organizations”, I’m trying to understand which of the
three cases here they fall under. If I understand correctly, the idea is
that Customer Foo approaches Root CA (Case #1). Root CA knows Foo’s
namespace is foo.example through prior verification, and Root CA allows Foo
to issue to *@foo.example. Then Foo says “oh, hey, we have a contractor at
user@bar.example, we’d like a cert for them too”.

Why can’t Root CA verify themselves? Why would or should Root CA trust Foo
to do it correctly? I can imagine plenty of verification protocols where
Foo can be the “face” of the verification, but that it uses Root CAs APIs
and systems under the hood. I‘m fairly certain DigiCert has experience
doing this for their customers, such as for white label CAs.

So that’s why I’m struggling to understand the use case, or the challenges,
with at least requiring domain-part validation by the CA.

On Fri, Oct 4, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Will this permit either verification of the email address or the domain
> part? For example, some organizations may verify their entire domain space
> and then confirm contractors using a random value sent to the email address
> itself. They don't  need the entire domain space in those cases, but they
> do need to issue certificates for a few email addresses outside of their
> domain control. Verification of email control using a random value seems
> like it affords controls that are equivalent to the challenge-response
> mechanisms in the BRs.
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Friday, October 4, 2019 2:38 PM
> To: Kathleen Wilson 
> Cc: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation
> for S/MIME Certificates
>
> I'd like to revive this discussion. So far we've established that the
> existing "required practice" [1] is too stringent for email address
> validation and needs to be changed. We can do that by removing email
> addresses from the scope of the requirement as Kathleen proposed, or by
> exempting the local part of the email address as I proposed earlier:
>
> "CAs MUST NOT delegate validation of the domain name part of an email
> address to a 3rd party."
>
> We have a fairly detailed explanation from Ryan Hurst of why and how
> removing the requirement entirely is beneficial, but no one else has spoken
> in favor of this need. Kathleen did however point out that this requirement
> doesn't appear to be the result of a thorough analysis. We have Ryan Sleevi
> arguing that the process described by Ryan Hurst is insecure and thus a
> reason to forbid delegation of validation of the domain name part. Pedro
> Fuentes also wrote in favor of this outcome.
>
> One thing that might help to resolve this is a more detailed description
> of the weaknesses that are present in the process described by Ryan Hurst.
> If we can all agree that the process is vulnerable, then it seems that we'd
> have a strong argument for banning it.
>
> - Wayne
>
> [1]
>
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
>
>
> On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > > The BRs forbid delegation of domain and IP address validation to
> > > third parties. However, the BRs don't forbid delegation of email
> > > address validation nor do they apply to S/MIME certificates.
> > >
> > > 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."
> > >
> > > I propose that we move this statement (changing "the Mozilla's Root
> > >

RE: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Jeremy Rowley via dev-security-policy]

Will this permit either verification of the email address or the domain part? 
For example, some organizations may verify their entire domain space and then 
confirm contractors using a random value sent to the email address itself. They 
don't  need the entire domain space in those cases, but they do need to issue 
certificates for a few email addresses outside of their domain control. 
Verification of email control using a random value seems like it affords 
controls that are equivalent to the challenge-response mechanisms in the BRs.  

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Friday, October 4, 2019 2:38 PM
To: Kathleen Wilson 
Cc: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for 
S/MIME Certificates

I'd like to revive this discussion. So far we've established that the existing 
"required practice" [1] is too stringent for email address validation and needs 
to be changed. We can do that by removing email addresses from the scope of the 
requirement as Kathleen proposed, or by exempting the local part of the email 
address as I proposed earlier:

"CAs MUST NOT delegate validation of the domain name part of an email address 
to a 3rd party."

We have a fairly detailed explanation from Ryan Hurst of why and how removing 
the requirement entirely is beneficial, but no one else has spoken in favor of 
this need. Kathleen did however point out that this requirement doesn't appear 
to be the result of a thorough analysis. We have Ryan Sleevi arguing that the 
process described by Ryan Hurst is insecure and thus a reason to forbid 
delegation of validation of the domain name part. Pedro Fuentes also wrote in 
favor of this outcome.

One thing that might help to resolve this is a more detailed description of the 
weaknesses that are present in the process described by Ryan Hurst. If we can 
all agree that the process is vulnerable, then it seems that we'd have a strong 
argument for banning it.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties


On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > The BRs forbid delegation of domain and IP address validation to 
> > third parties. However, the BRs don't forbid delegation of email 
> > address validation nor do they apply to S/MIME certificates.
> >
> > 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."
> >
> > I propose that we move this statement (changing "the Mozilla's Root 
> > Store Policy" to "this policy") into policy section 2.2 "Validation 
> > Practices".
> >
> > This is https://github.com/mozilla/pkipolicy/issues/175
> >
> > I will appreciate everyone's input on this proposal.
> >
> > - Wayne
> >
> > [1]
> >
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegat
> ion_of_Domain_.2F_Email_Validation_to_Third_Parties
> >
>
>
> All,
>
> As the person who filed the Github issue for this, I would like to 
> provide some background and my opinion.
>
> Currently the 'Delegation of Domain / Email Validation to Third Parties'
> section of the 'Forbidden Practices' page says:
> "This is forbidden by the Baseline Requirements, section 1.3.2.
> 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."
>
> Based on the way that section is written, it appears that domain 
> validation (and the BRs) was the primary consideration, and that the 
> Email part of it was an afterthought, or added later. Historically, my 
> attention has been focused on TLS certs, so it is possible that the 
> ramifications of adding Email validation to this section was not fully 
> thought through.
>
> I don't remember who added this email validation text or when, but I 
> can tell you that when I review root inclusion requests I have only 
> been concerned about making sure that domain validation is not being 
> delegated to 3rd parties. It wasn't until a representative of a CA 
> brought this to my attention that I realized that there has been a 
> difference in text on this wiki page versus th

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Fri, Oct 4, 2019 at 4:37 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> One thing that might help to resolve this is a more detailed description of
> the weaknesses that are present in the process described by Ryan Hurst. If
> we can all agree that the process is vulnerable, then it seems that we'd
> have a strong argument for banning it.


The issue is that Ryan Hurst hasn't really described a reliable, verifiable
way to have assurance that the RA actually performs this verification. It's
functionally akin to the "any other method", without any meaningful
supervision. This is the same issue that Gerv had with delegated third
parties performing the domain validation.

Ryan's described algorithm basically means that any service you click "sign
in to Google" (i.e. OAuth) with could potentially obtain an S/MIME
certificate for you, on your behalf, without any authorization or
interaction with the CA by you the user, or by GMail as the domain holder.
That's quite literally the design captured in the diagram (
https://www.dropbox.com/s/ocfow995aluowyl/auth%20redirect%20cert%20flow.png?dl=0
),
at least from the perspective of an external party.

However, on a technical level, it's even worse. It relies on pinky swears
(aka contracts) between the RA and the CA. The RA is quite literally
allowed to request certificates for any domain and user, but pinky-swears
to the CA that it will only request certificates for users who click "sign
in with Google", and (hopefully, but not specified) if they agree to that.
In this scenario, the operator of the domain name (e.g. "gmail.com") has no
control over this - not even CAA. The end-user has no awareness of this
issuance either - any OAuth login could be used to cause issuance of an
S/MIME certificate.

The "benefit" of this scenario is that it just works with OAuth, and the
user never has to know which CA is dealing certs out in their name. They
may never even see the cert - the RA (service provider) may be the only one
with the keys, acting in the user's name, simply because they signed in.

All of this is under the /best/ case scenario. You could just forgo the
OAuth dance entirely - the RA could just tell the CA "Yo, give me a cert
for that Sleevi guy", and that would be that.

This is why I think it's crucial to require the CA perform the domain
validation portion. It requires that, in this case, the email provider
authorize the CA (if the CA is going to have a blank check for that
domain), or that the user authorize the CA (if the CA is only going to be
able to issue for that user). This does make it hard to just issue certs to
whomever you want. That's a feature, not a bug, and would be key to any
future improvements we might want to see in this space (e.g. CAA)

Is there a path with OAuth to allow delegation? Well, yes, there's a whole
host of concepts in signed assertions and JWT where you might allow Service
Provider to obtain a signed assertion from Mail Provider to act on behalf
of the user, and that Service Provider could in turn hand that signed
assertion to any CA, and the CA could verify that assertion back with Mail
Provider that the Service Provider was authorized. But that's not what is
described in the diagram, because that requires changes to Mail Provider,
and the 'desired benefit' of omitting this requirement from policy is to
allow issuing arbitrary certificates without the explicit, quantifiable
consent of the user or the mail provider. I think that's insecure.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

I'd like to revive this discussion. So far we've established that the
existing "required practice" [1] is too stringent for email address
validation and needs to be changed. We can do that by removing email
addresses from the scope of the requirement as Kathleen proposed, or by
exempting the local part of the email address as I proposed earlier:

"CAs MUST NOT delegate validation of the domain name part of an email
address to a 3rd party."

We have a fairly detailed explanation from Ryan Hurst of why and how
removing the requirement entirely is beneficial, but no one else has spoken
in favor of this need. Kathleen did however point out that this requirement
doesn't appear to be the result of a thorough analysis. We have Ryan Sleevi
arguing that the process described by Ryan Hurst is insecure and thus a
reason to forbid delegation of validation of the domain name part. Pedro
Fuentes also wrote in favor of this outcome.

One thing that might help to resolve this is a more detailed description of
the weaknesses that are present in the process described by Ryan Hurst. If
we can all agree that the process is vulnerable, then it seems that we'd
have a strong argument for banning it.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties


On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > The BRs forbid delegation of domain and IP address validation to third
> > parties. However, the BRs don't forbid delegation of email address
> > validation nor do they apply to S/MIME certificates.
> >
> > 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."
> >
> > I propose that we move this statement (changing "the Mozilla's Root Store
> > Policy" to "this policy") into policy section 2.2 "Validation Practices".
> >
> > This is https://github.com/mozilla/pkipolicy/issues/175
> >
> > I will appreciate everyone's input on this proposal.
> >
> > - Wayne
> >
> > [1]
> >
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
> >
>
>
> All,
>
> As the person who filed the Github issue for this, I would like to
> provide some background and my opinion.
>
> Currently the 'Delegation of Domain / Email Validation to Third Parties'
> section of the 'Forbidden Practices' page says:
> "This is forbidden by the Baseline Requirements, section 1.3.2.
> 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."
>
> Based on the way that section is written, it appears that domain
> validation (and the BRs) was the primary consideration, and that the
> Email part of it was an afterthought, or added later. Historically, my
> attention has been focused on TLS certs, so it is possible that the
> ramifications of adding Email validation to this section was not fully
> thought through.
>
> I don't remember who added this email validation text or when, but I can
> tell you that when I review root inclusion requests I have only been
> concerned about making sure that domain validation is not being
> delegated to 3rd parties. It wasn't until a representative of a CA
> brought this to my attention that I realized that there has been a
> difference in text on this wiki page versus the rules I have been trying
> to enforce. That is when I filed the github issue.
>
> I propose that we can resolve this discrepancy for now by removing "/
> Email Validation" from the title of the section and removing "and Email"
> from the contents of the section.
>
> Unless we believe there are significant security reasons to add our own
> S/MIME required/forbidden practices at this time, my preference is to
> wait for the CA/Browser Forum to create the S/MIME Working Group, and
> for that group to identify the S/MIME baseline requirements. Then we can
> add policy and required/forbidden practices based on the S/MIME BRs
> provided by that group.
>
> I do realize that my proposal is unfair to CAs who have been diligently
> following this section of this wiki page. Your diligence is appreciated,
> and your contributions to this discussion will also be appreciated.
>
> Thanks,
> Kathleen
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Kathleen Wilson via dev-security-policy]

On 5/13/19 10:24 AM, Wayne Thayer wrote:

The BRs forbid delegation of domain and IP address validation to third
parties. However, the BRs don't forbid delegation of email address
validation nor do they apply to S/MIME certificates.

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

I propose that we move this statement (changing "the Mozilla's Root Store
Policy" to "this policy") into policy section 2.2 "Validation Practices".

This is https://github.com/mozilla/pkipolicy/issues/175

I will appreciate everyone's input on this proposal.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties




All,

As the person who filed the Github issue for this, I would like to 
provide some background and my opinion.


Currently the 'Delegation of Domain / Email Validation to Third Parties' 
section of the 'Forbidden Practices' page says:

"This is forbidden by the Baseline Requirements, section 1.3.2.
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."


Based on the way that section is written, it appears that domain 
validation (and the BRs) was the primary consideration, and that the 
Email part of it was an afterthought, or added later. Historically, my 
attention has been focused on TLS certs, so it is possible that the 
ramifications of adding Email validation to this section was not fully 
thought through.


I don't remember who added this email validation text or when, but I can 
tell you that when I review root inclusion requests I have only been 
concerned about making sure that domain validation is not being 
delegated to 3rd parties. It wasn't until a representative of a CA 
brought this to my attention that I realized that there has been a 
difference in text on this wiki page versus the rules I have been trying 
to enforce. That is when I filed the github issue.


I propose that we can resolve this discrepancy for now by removing "/ 
Email Validation" from the title of the section and removing "and Email" 
from the contents of the section.


Unless we believe there are significant security reasons to add our own 
S/MIME required/forbidden practices at this time, my preference is to 
wait for the CA/Browser Forum to create the S/MIME Working Group, and 
for that group to identify the S/MIME baseline requirements. Then we can 
add policy and required/forbidden practices based on the S/MIME BRs 
provided by that group.


I do realize that my proposal is unfair to CAs who have been diligently 
following this section of this wiki page. Your diligence is appreciated, 
and your contributions to this discussion will also be appreciated.


Thanks,
Kathleen
















___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Wed, May 15, 2019 at 2:10 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > 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 doesn't, though. It doesn't describe the scope of the delegation, and
appears to allow attesting based solely on something like OpenID
Connect/OAuth, which isn't itself safe or secure to do so.

Now, yes, you're eliding a number of details from this description, but the
fact that we can't fit a one paragraph description of what or how the CA is
validating the e-mail address, let alone the supposed RA, is a great reason
to be concerned.


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


Who said they should be used more? ;)

I'm concerned that we're conflating somewhat separate pieces - the
localpart and the domain-part - and this is adding to the confusion. I'm
concerned as well about the description of SAAS here and the role it plays
- because it seems to be used interchangably in the discussion between the
provider of the email services (e.g. GMail), a reseller/vendor, and the
customer of such services (e.g. a customer of a GSuite instance). All of
these make it problematic to understand your concerns, goals, and how to
provide positive language to improve this.

What I also want to separate is a specific implementation of an approach to
validation, which it seems to be your focus, and the generalized principle
that the policy is trying to capture. I agree that they're related, in as
much as policy might prevent specific implementations, but I don't think we
want to propose specific changes to policy to enumerate all the acceptable
methods (... yet. Hopefully for an S/MIME WG)

To save the rest of the list from Ryan-on-Ryan disagreement, let's try and
follow-up offlist to see if we can come up with some clearer documentation
about what you want to be allowed (which I think we're in agreement isn't
now, at least as described), and then we can look at either how to achieve
that under the current policy, or how the proposed policy would impact that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Hurst via dev-security-policy]

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

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

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

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Hurst via dev-security-policy]

> 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?

> 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


> I'm still at an absolute loss for understanding your flow and what you
> believe is validated, so I do not feel able to evaluate these alternatives,
> other than to note that I find problems with all of them. I'm hoping you
> can, focusing solely on the CA validation process, describe who is
> validating what, and when.

Hopefully, the diagram helps to clarify if not let me know.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Wed, May 15, 2019 at 11:52 AM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I believe the case where Google requests a certificate from the CA is
> accommodated but not the case where SAAS requests a certificate from the CA
> based on the authentication of the user it did with Google.
>

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. 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 also believe that the nature of how email addresses are used, and how
> many there are (billions) suggests that delegation should be allowed if
> scoped very narrowly.
>

I don't believe so, based on the description, that this aligns with how
they're used or that this is desirable to allow. But I _suspect_ that it's
merely based on the information presented, and by not having a clearer
picture of your proposed flow.


> > Hopefully, this analysis avoids the emotive aspects of the previous
> posts,
> > and focuses purely on what technical steps are being provided.
>
> I was not trying to be emotive, I was trying to make sure the consequences
> of the proposed wording is clear.
>

It's an appeal to impact, but it's missing the substantive part: the
demonstration of how this is a functional change from the already Forbidden
Practice, and while it lays out the "desired end result", doesn't describe
it in terms of who is validating what, and when, which is the key thing to
assess for this discussion.


> It is true that ping mails could be replaced with users logging being
> redirected from the application they use to a CA where they authenticate to
> the CA via one of these federated authentication schemes and then be
> federated back. This has all the same issues and is not materially
> different than a ping mail though when looking at usability which is why I
> omitted it but as you point out it is still possible.


> It is also possible for a mail service provider to become a CA, or provide
> certificates through a CA by proving control of the base domain and then
> being authoritative for the local part of the address but this limits the
> use of certificates in this case to email providers that have built this.
>
> These options leave SAAS providers with the following choices:
> a) use private trust certificates
> d) use public trust certificates and accept it makes your user experience
> non-competitive
> c) do not use certificates because it makes your user experience
> non-competitive
>

I'm still at an absolute loss for understanding your flow and what you
believe is validated, so I do not feel able to evaluate these alternatives,
other than to note that I find problems with all of them. I'm hoping you
can, focusing solely on the CA validation process, describe who is
validating what, and when.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Hurst via dev-security-policy]

> I must admit, I'm confused. Based on your concerns as I understand them,
> either the scenario you're describing is already prohibited today (and thus
> no change from existing policy), or its already permitted today and would
> continue to be permitted with this change. I'm hoping you can succinctly
> explain where we might disagree.

Given the inconsistent interpretation, I have heard from many in this area of 
what is allowed and is not I will abstain from inserting my own opinion on that 
matter.

Instead, I just want to make sure that whatever changes are made make it clear 
what is allowed and is not. 

I also want to make sure that while that is done that the whole problem is 
looked at.


> However, I don't think the new or old language prohibits this. The flow
> you've described is functionally a relationship between Google (as the
> GMail operator) and the CA. Google requests certificates on the users'
> behalf - much like a reseller does - and provides them to the user. The CA
> validates that Google is authorized for the gmail.com domain for each of
> these requests, potentially relying on previously completed domain
> validations (e.g. the reuse of data), and then lets Google validate the
> local-part as appropriate.

I believe the case where Google requests a certificate from the CA is 
accommodated but not the case where SAAS requests a certificate from the CA 
based on the authentication of the user it did with Google.

I believe this is an important case to support as it allows the development of 
scenarios where seamless use of certificates happen. 

I also believe that the nature of how email addresses are used, and how many 
there are (billions) suggests that delegation should be allowed if scoped very 
narrowly.

> Hopefully, this analysis avoids the emotive aspects of the previous posts,
> and focuses purely on what technical steps are being provided.

I was not trying to be emotive, I was trying to make sure the consequences of 
the proposed wording is clear.

> Perhaps I overlooked something, but I don't see the requirement for 'ping' 
> emails or
> the like, so I do not understand why it's relevant to the policy
> discussion. If I'm missing something, though, hopefully, you'll be able to
> point it out :)

It is true that ping mails could be replaced with users logging being 
redirected from the application they use to a CA where they authenticate to the 
CA via one of these federated authentication schemes and then be federated 
back. This has all the same issues and is not materially different than a ping 
mail though when looking at usability which is why I omitted it but as you 
point out it is still possible.

It is also possible for a mail service provider to become a CA, or provide 
certificates through a CA by proving control of the base domain and then being 
authoritative for the local part of the address but this limits the use of 
certificates in this case to email providers that have built this.

These options leave SAAS providers with the following choices:
a) use private trust certificates
d) use public trust certificates and accept it makes your user experience 
non-competitive
c) do not use certificates because it makes your user experience non-competitive
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Wed, May 15, 2019 at 9:28 AM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Pedro,
>
> That scenario is addressed by Wayne proposed change.
>
> That same change does not allow for applications that use GMail or there
> federated authentication providers to use client certificates without
> sending each user to the CA.
>

Ryan,

I must admit, I'm confused. Based on your concerns as I understand them,
either the scenario you're describing is already prohibited today (and thus
no change from existing policy), or its already permitted today and would
continue to be permitted with this change. I'm hoping you can succinctly
explain where we might disagree.

As Wayne mentioned, it's already covered in CA forbidden practices, so I do
not see how moving that existing language would meaningfully change things.
If the new language prohibits it, then so to does the old language.

However, I don't think the new or old language prohibits this. The flow
you've described is functionally a relationship between Google (as the
GMail operator) and the CA. Google requests certificates on the users'
behalf - much like a reseller does - and provides them to the user. The CA
validates that Google is authorized for the gmail.com domain for each of
these requests, potentially relying on previously completed domain
validations (e.g. the reuse of data), and then lets Google validate the
local-part as appropriate.

To be clear: I have serious and extensive reservations about the suggested
reliance on OAuth/OIDC in the context of validation, and the scenario
presented is one that I see incredible danger and harm in, if left at that
level. I do, however, agree there are secure deployments that can exist,
and likely does in the case you're describing - but I don't think we should
muddy those waters yet, because I think trying to capture explicitly what
you're proposing will require considerably more details. Hopefully, my
analysis above, of the principles of the validation process, demonstrate a
more reasonable and reliable level of assurance in the validation process.

Hopefully, this analysis avoids the emotive aspects of the previous posts,
and focuses purely on what technical steps are being provided. Perhaps I
overlooked something, but I don't see the requirement for 'ping' emails or
the like, so I do not understand why it's relevant to the policy
discussion. If I'm missing something, though, hopefully you'll be able to
point it out :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Hurst via dev-security-policy]

Pedro,

That scenario is addressed by Wayne proposed change.

That same change does not allow for applications that use GMail or there 
federated authentication providers to use client certificates without sending 
each user to the CA.

Ryan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Pedro Fuentes via dev-security-policy]

I have the feeling that this going to something over-complicated...

Let's think in a simple case, which is, I think, the most common scenario where 
there's some delegation:

1. A company needs MPKI service for its employees, who use email addresses in 
one or more domains owned by the company
2. The CA validates that the company has control on the domain and grants a 
MPKI access with domain constraints
3. The company, that has already its own controls on the people before 
assigning an email address to an individual (e.g. HR dept does a vetting and 
asks to the IT dept to create the account), is autonomous to enroll new users 
and provide them certificates. The CA is not providing any value nor security 
by doing additional validations on each individual

This is what we do for corporate MPKI services with domain constraints. I can't 
talk in behalf of all CAs, but I think this is the use case that we'd want to 
be able to keep.

Best,
Pedro
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Hurst via dev-security-policy]

> Does replacing the existing "require practice" language by adding the
> following sentence to the Root Store Policy achieve the clarity you're
> seeking and avoid the problems you've pointed out?
> 
> "CAs MUST NOT delegate validation of the domain name part of an email
> address to a 3rd party."


If Mozilla wishes to preclude modern web applications from using digital 
certificates that contain their email address without :
a) having to know that a certificate is in use, 
b) having to know that the certificate is coming from a specific CA,
c) and stopping the associated transaction to enroll for a certificate or 
require pre-enrollment of a certificate.

Then this does make things better. I say this because by my read if that text 
is that it allows the CA to:
1) Delegate the local part of the validation to the mail providers via 
mechanisms like DNS or MX records,
2) Do their own OAUTH based email validation workflows,
3) To continue to do ping mail based validation.

With that said, I do not think that this goes far enough.

Let me provide some background.

The two most common cloud email providers represent around 1.5billion users and 
OAUTH based authentication into third-party services has become the norm. 
Basically, nearly every email provider on the planet likely supports OAUTH (or 
similar) federation at this point.

To put this in perspective, there are less than 340 million domains.

I bring this up because using these federated authentication flows like this 
are really the best way to validate a user in control of an email address. This 
is the case because it happens silently on every authentication and is asserted 
by the entity that knows the best, the mail operator.

So, if we wanted to allow a SAAS service to enroll a client for a certificate 
at login, or transaction time, via a federated login, what would such an RA 
agreement look like? 

In my mind it would say:

"if the mail operator, via an approved mechanism, which includes ONLY the use 
of OAUTH based federated authentication to a mail provider (MS, Google, Yahoo, 
etc) says the user controls that address then you can get the certificate, 
under no other circumstances can you".

The value the CA provides here is that:
a) they are trusted, 
b) they enforce this contract.


> > This is because out of context ping emails to individual users (what many
> > CAs offer today) is essentially a deal breaker.
> >
> >
> A deal breaker due to the poor usability involved in interrupting a task
> while the user retrieves an email and confirms receipt?
Yes, I think so.

As an example, in the EU document signing solutions have used certificates 
since their inception, in the US, on the other-hand we insert a picture of a 
signature derived from a font.

When we look at the solutions that were in the EU, up until very recently, 
these solutions forced people through the path of interacting with the CA to 
get a certificate.

As a result (at least in part) we saw was signing was not adopted anywhere near 
as much as it was the US where you could just "click" and move on with your 
life despite extensive marketing.

As a user, the reality is if you are using a signing service you have no need 
to know:
a) a CA is involved, 
b) or which CA is involved.

I also believe all signing certificates need to have either an email or a phone 
number and all SHOULD have an email address. This means that a decision to not 
allow RA agreements precludes any Mozilla CA from offering certificates to a 
SAAS that use certs like this, even if other root programs allow for it.

I should note, I have created such a service prior to joining Google so I say 
this with a bias, but I do think that having solutions where:
a) the user is the only one in control of their signing key,
b) the user doesn't have to know certificates are in use at all,
c) there is no unnecessary third-party interacting with the user.

If your interested here is a quick video of the signing experience in that 
solution.
https://www.dropbox.com/s/z5omfzew15g5bb7/Hancock%20for%20Wayne.mov?dl=0

While I talked about the document signing use case above, this is not limited 
to those use cases.

There are lots of use cases where SAAS applications could make their offerings 
more secure with end-user certificates if doing so did not ruin the user 
experience.

Ryan
(personal hat)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Mon, May 13, 2019 at 9:13 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Though it seems the thread has largely expressed my concerns I do want to
> chime in and stress that I believe that it is important that this text gets
> clarified.
>
>
Does replacing the existing "require practice" language by adding the
following sentence to the Root Store Policy achieve the clarity you're
seeking and avoid the problems you've pointed out?

"CAs MUST NOT delegate validation of the domain name part of an email
address to a 3rd party."


Email addresses are, as has been pointed out, tricky.
>
> Today it is common practice for CAs to send "ping mails" for every
> certificate that is sent, this has been a common interpretation for what
> "email certificate" validation has to look like.
>
> This, however, excludes things like:
> > Using MX records, as a means to look at which mail service is
> authoritative for that domain and delegating the local part to the entity
> operating the mail service.
> > Using DNS records as a means to determine who is authoritative for that
> domain and delegating the local part to that entity.
> > Relying on OAUTH based redirection flows from mail service providers
> such as Google, Microsoft, and others.
>
> These options all offer strong and friction-free user experiences for the
> associated use cases.
>
> I also think that since emails have become the most common account
> identifier excluding the ability for a CA to enter into an RA agreement
> essentially precludes the use of email certificates by anyone other than a)
> the CA or b) the mail service provider.
>
> This means, as an example, one could not use Mozilla trusted certificates
> at scale for mail or document signing unless it was provided by one of
> those two entities.
>
> This is because out of context ping emails to individual users (what many
> CAs offer today) is essentially a deal breaker.
>
>
A deal breaker due to the poor usability involved in interrupting a task
while the user retrieves an email and confirms receipt?

The scale and nature of email validation are such that RA style agreements
> should, in my personal opinion, be within reason to accommodate.
>
>
It's not clear to me if you are arguing for the policy I proposed above, or
the ability for a CA to also delegate the validation of the domain name
part to a 3rd party RA?


> This is particularly problematic in that even if other root stores allowed
> the use of RA agreements for email certificates it would no longer be
> allowed; in essence, precluding the adoption of publicly trusted client
> certificates for mainstream SASS applications.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Hurst via dev-security-policy]

On Monday, May 13, 2019 at 10:25:18 AM UTC-7, Wayne Thayer wrote:
> The BRs forbid delegation of domain and IP address validation to third
> parties. However, the BRs don't forbid delegation of email address
> validation nor do they apply to S/MIME certificates.
> 
> 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."
> 
> I propose that we move this statement (changing "the Mozilla's Root Store
> Policy" to "this policy") into policy section 2.2 "Validation Practices".
> 
> This is https://github.com/mozilla/pkipolicy/issues/175
> 
> I will appreciate everyone's input on this proposal.
> 
> - Wayne
> 
> [1]
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties

Though it seems the thread has largely expressed my concerns I do want to chime 
in and stress that I believe that it is important that this text gets clarified.

Email addresses are, as has been pointed out, tricky. 

Today it is common practice for CAs to send "ping mails" for every certificate 
that is sent, this has been a common interpretation for what "email 
certificate" validation has to look like.

This, however, excludes things like:
> Using MX records, as a means to look at which mail service is authoritative 
> for that domain and delegating the local part to the entity operating the 
> mail service.
> Using DNS records as a means to determine who is authoritative for that 
> domain and delegating the local part to that entity.
> Relying on OAUTH based redirection flows from mail service providers such as 
> Google, Microsoft, and others.

These options all offer strong and friction-free user experiences for the 
associated use cases.

I also think that since emails have become the most common account identifier 
excluding the ability for a CA to enter into an RA agreement essentially 
precludes the use of email certificates by anyone other than a) the CA or b) 
the mail service provider.

This means, as an example, one could not use Mozilla trusted certificates at 
scale for mail or document signing unless it was provided by one of those two 
entities.

This is because out of context ping emails to individual users (what many CAs 
offer today) is essentially a deal breaker.

The scale and nature of email validation are such that RA style agreements 
should, in my personal opinion, be within reason to accommodate.

This is particularly problematic in that even if other root stores allowed the 
use of RA agreements for email certificates it would no longer be allowed; in 
essence, precluding the adoption of publicly trusted client certificates for 
mainstream SASS applications.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Mon, May 13, 2019 at 2:09 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Piggybacking to Ryan's message and putting into my mundane words, I'd say
> that is reasonable to say that a CA must not delegate the validation of
> what is after the @ in the email address, but I think it's totally
> admissible to let the domain owner (and typically email service provider)
> to assume the task to issue certificates to its users without further
> intervention of the CA once the domain part has been validated.
>
> Just my two cents...
>
> Pedro
>
> El lunes, 13 de mayo de 2019, 19:58:46 (UTC+2), Ryan Sleevi  escribió:
> > On Mon, May 13, 2019 at 1:25 PM Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > The BRs forbid delegation of domain and IP address validation to third
> > > parties. However, the BRs don't forbid delegation of email address
> > > validation nor do they apply to S/MIME certificates.
> > >
> > > 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."
> > >
> > > I propose that we move this statement (changing "the Mozilla's Root
> Store
> > > Policy" to "this policy") into policy section 2.2 "Validation
> Practices".
> > >
> > > This is https://github.com/mozilla/pkipolicy/issues/175
> > >
> > > I will appreciate everyone's input on this proposal.
> > >
> > > - Wayne
> > >
> >
> > This strikes me as tricky to get right, because an e-mail contains both a
> > local-part and a domain (to use the terminology from RFC 5322, 3.4.1) [1]
> >
> > Under the SSL/TLS model, we do allow partial (conceptual) delegation of
> > domain validation, with respect to Section 1.3.2 of the BRs [2] ("The CA
> > SHALL confirm that the requested Fully-Qualified Domain Name(s) are
> within
> > the Enterprise RA's verified Domain Namespace") and the use of
> > "Authorization Domain Names". I say it's partial, because the CA still
> has
> > certain obligations (such as CAA checking), but otherwise can allow an
> > external entity to represent subdomains as authorized, without requiring
> > additional control validation.
> >
> > I highlight this, because in the context of S/MIME, the question is
> whether
> > or not the CA is responsible for validating the local-part, or whether it
> > may delegate validation of that to the operator of the domain. The
> > semantics of the local-part are entirely at the responsibility of the
> > holder - they can, for example, dictate that local-parts are equivalent
> > based on the presence of full-stop (".") characters, or they might even
> > designate equivalence based on the presence of some token (for example,
> the
> > use of "+label"), both examples taken from Gmail/GSuite, but which have
> > since expanded among industry.
> >
> > I think it's fairly reasonable to designate an organization as an
> > Enterprise RA, in the S/MIME sense, allowing them to control issuance for
> > arbitrary local-parts if they've demonstrated control over the domain
> (and
> > thus, correspondingly, the primary MX records). Is this something you
> think
> > is reasonable to continue supporting, or is this something you'd like to
> > prohibit? Understanding your/Mozilla's goals would help figure out
> > productive next steps - whether to convince you otherwise ;) or to
> provide
> > draft language accounting for it.
> >
>

The goal of this issue is to move a currently "required practice" into the
formal policy so that we don't have requirements that aren't explicitly
called out in policy. However, everyone has made it clear that the current
statement is too vague to add to our policy.

I think we can rely on the BRs to set forth the requirements for TLS
certificates.

If we are going to craft a policy for S/MIME, I agree that we should permit
delegation of the local-part. The resulting language could be:

CAs MUST NOT delegate validation of the domain name part of an email
address to a 3rd party.

Thoughts?

> [1] https://tools.ietf.org/html/rfc5322#section-3.4.1
> > [2]
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Pedro Fuentes via dev-security-policy]

Piggybacking to Ryan's message and putting into my mundane words, I'd say that 
is reasonable to say that a CA must not delegate the validation of what is 
after the @ in the email address, but I think it's totally admissible to let 
the domain owner (and typically email service provider) to assume the task to 
issue certificates to its users without further intervention of the CA once the 
domain part has been validated.

Just my two cents...

Pedro

El lunes, 13 de mayo de 2019, 19:58:46 (UTC+2), Ryan Sleevi  escribió:
> On Mon, May 13, 2019 at 1:25 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > The BRs forbid delegation of domain and IP address validation to third
> > parties. However, the BRs don't forbid delegation of email address
> > validation nor do they apply to S/MIME certificates.
> >
> > 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."
> >
> > I propose that we move this statement (changing "the Mozilla's Root Store
> > Policy" to "this policy") into policy section 2.2 "Validation Practices".
> >
> > This is https://github.com/mozilla/pkipolicy/issues/175
> >
> > I will appreciate everyone's input on this proposal.
> >
> > - Wayne
> >
> 
> This strikes me as tricky to get right, because an e-mail contains both a
> local-part and a domain (to use the terminology from RFC 5322, 3.4.1) [1]
> 
> Under the SSL/TLS model, we do allow partial (conceptual) delegation of
> domain validation, with respect to Section 1.3.2 of the BRs [2] ("The CA
> SHALL confirm that the requested Fully-Qualified Domain Name(s) are within
> the Enterprise RA's verified Domain Namespace") and the use of
> "Authorization Domain Names". I say it's partial, because the CA still has
> certain obligations (such as CAA checking), but otherwise can allow an
> external entity to represent subdomains as authorized, without requiring
> additional control validation.
> 
> I highlight this, because in the context of S/MIME, the question is whether
> or not the CA is responsible for validating the local-part, or whether it
> may delegate validation of that to the operator of the domain. The
> semantics of the local-part are entirely at the responsibility of the
> holder - they can, for example, dictate that local-parts are equivalent
> based on the presence of full-stop (".") characters, or they might even
> designate equivalence based on the presence of some token (for example, the
> use of "+label"), both examples taken from Gmail/GSuite, but which have
> since expanded among industry.
> 
> I think it's fairly reasonable to designate an organization as an
> Enterprise RA, in the S/MIME sense, allowing them to control issuance for
> arbitrary local-parts if they've demonstrated control over the domain (and
> thus, correspondingly, the primary MX records). Is this something you think
> is reasonable to continue supporting, or is this something you'd like to
> prohibit? Understanding your/Mozilla's goals would help figure out
> productive next steps - whether to convince you otherwise ;) or to provide
> draft language accounting for it.
> 
> [1] https://tools.ietf.org/html/rfc5322#section-3.4.1
> [2] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Stephen Davidson via dev-security-policy]

Hello Wayne:



The current wording in section 2.2 "Validation Practices" of the Mozilla Root 
Store Policy says:



2.  For a certificate capable of being used for digitally signing or encrypting 
email messages, 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 or has been authorized by the email 
account holder to act on the account holder's behalf. The CA's CP/CPS must 
clearly specify the procedure(s) that the CA employs to perform this 
verification.



Does the proposed change seek to replace that text - or to clarify that only 
the CA may perform the verifications?  Something like this ...



2.  For a certificate capable of being used for digitally signing or encrypting 
email messages, the CA takes reasonable measures, which must not be delegated 
to a third party, to verify that the entity submitting the request controls the 
email account associated with the email address referenced in the certificate 
or has been authorized by the email account holder to act on the account 
holder's behalf. The CA's CP/CPS must clearly specify the procedure(s) that the 
CA employs to perform this verification.



Regards, Stephen





-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Monday, May 13, 2019 2:25 PM
To: Mozilla 
Subject: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME 
Certificates



The BRs forbid delegation of domain and IP address validation to third parties. 
However, the BRs don't forbid delegation of email address validation nor do 
they apply to S/MIME certificates.



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



I propose that we move this statement (changing "the Mozilla's Root Store 
Policy" to "this policy") into policy section 2.2 "Validation Practices".



This is https://github.com/mozilla/pkipolicy/issues/175



I will appreciate everyone's input on this proposal.



- Wayne



[1]

https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties

___

dev-security-policy mailing list

dev-security-policy@lists.mozilla.org

https://lists.mozilla.org/listinfo/dev-security-policy



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

On Mon, May 13, 2019 at 1:25 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The BRs forbid delegation of domain and IP address validation to third
> parties. However, the BRs don't forbid delegation of email address
> validation nor do they apply to S/MIME certificates.
>
> 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."
>
> I propose that we move this statement (changing "the Mozilla's Root Store
> Policy" to "this policy") into policy section 2.2 "Validation Practices".
>
> This is https://github.com/mozilla/pkipolicy/issues/175
>
> I will appreciate everyone's input on this proposal.
>
> - Wayne
>

This strikes me as tricky to get right, because an e-mail contains both a
local-part and a domain (to use the terminology from RFC 5322, 3.4.1) [1]

Under the SSL/TLS model, we do allow partial (conceptual) delegation of
domain validation, with respect to Section 1.3.2 of the BRs [2] ("The CA
SHALL confirm that the requested Fully-Qualified Domain Name(s) are within
the Enterprise RA's verified Domain Namespace") and the use of
"Authorization Domain Names". I say it's partial, because the CA still has
certain obligations (such as CAA checking), but otherwise can allow an
external entity to represent subdomains as authorized, without requiring
additional control validation.

I highlight this, because in the context of S/MIME, the question is whether
or not the CA is responsible for validating the local-part, or whether it
may delegate validation of that to the operator of the domain. The
semantics of the local-part are entirely at the responsibility of the
holder - they can, for example, dictate that local-parts are equivalent
based on the presence of full-stop (".") characters, or they might even
designate equivalence based on the presence of some token (for example, the
use of "+label"), both examples taken from Gmail/GSuite, but which have
since expanded among industry.

I think it's fairly reasonable to designate an organization as an
Enterprise RA, in the S/MIME sense, allowing them to control issuance for
arbitrary local-parts if they've demonstrated control over the domain (and
thus, correspondingly, the primary MX records). Is this something you think
is reasonable to continue supporting, or is this something you'd like to
prohibit? Understanding your/Mozilla's goals would help figure out
productive next steps - whether to convince you otherwise ;) or to provide
draft language accounting for it.

[1] https://tools.ietf.org/html/rfc5322#section-3.4.1
[2] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy