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

[Buschart, Rufus via dev-security-policy]

Von: Ryan Sleevi  
> On Fri, Oct 25, 2019 at 6:44 PM Buschart, Rufus 
>  wrote:
>> 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 ;)

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.

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
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
4) If the operator of the mail server operates its own CA, he doesn't have to 
perform error prone email address validations
5) We don't mix the words validation and verification for the same activity

> 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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Buschart, Rufus via dev-security-policy]

Von: Wayne Thayer 
On Thu, Oct 24, 2019 at 10:33 AM Buschart, Rufus 
 wrote:
>> 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).

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.

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

If you think, that the scenario described above is covered by the proposed 
sentence I'd happy with it, but I'm not totally sure if it is covered.

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?


/Rufus



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

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

[Buschart, Rufus 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 
>  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").


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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Buschart, Rufus via dev-security-policy]

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

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? 

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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy