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

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

Re: [FORGED] Re: Firefox removes UI for site identity

[Phillip Hallam-Baker via dev-security-policy]

On Fri, Oct 25, 2019 at 4:21 AM James Burton  wrote:

> Extended validation was introduced at a time when mostly everyone browsed
> the internet using low/medium resolution large screen devices that provided
> the room for an extended validation style visual security indicator .
> Everything has moved on and purchases are made on small screen devices that
> has no room to support an extended validation style visual security
> indicator. Apple supported  extended validation style visual security
> indicator in iOS browser and it failed [1] [2].
>
> It's right that we are removing the extended validation style visual
> security indicator from browsers because of a) the above statement b)
> normal users don't understand extended validation style visual security
> indicators c) the inconsistencies of extended validation style visual
> security indicator between browsers d) users can't tell who is real or not
> based on extended validation style visual security indicators as company
> names sometimes don't match the actual site name.
>
> [1]  https://www.typewritten.net/writer/ev-phishing
> [2]  https://stripe.ian.sh
>

The original proposal that led to EV was actually to validate the company
logos and present them as logotype.
There was a ballot proposed here to bar any attempt to even experiment with
logotype. This was withdrawn after I pointed out to Mozilla staff that
there was an obvious anti-Trust concern in using the threat of withdrawing
roots from a browser with 5% market share to suppress deployment of any
feature.

Now for the record, that is what a threat looks like: we will destroy your
company if you do not comply with our demands. Asking to contact the
Mozilla or Google lawyers because they really need to know what one of
their employees is doing is not.

Again, the brief here is to provide security signals that allow the user to
protect themselves.


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

Re: [FORGED] Re: Firefox removes UI for site identity

[James Burton via dev-security-policy]

Extended validation was introduced at a time when mostly everyone browsed
the internet using low/medium resolution large screen devices that provided
the room for an extended validation style visual security indicator .
Everything has moved on and purchases are made on small screen devices that
has no room to support an extended validation style visual security
indicator. Apple supported  extended validation style visual security
indicator in iOS browser and it failed [1] [2].

It's right that we are removing the extended validation style visual
security indicator from browsers because of a) the above statement b)
normal users don't understand extended validation style visual security
indicators c) the inconsistencies of extended validation style visual
security indicator between browsers d) users can't tell who is real or not
based on extended validation style visual security indicators as company
names sometimes don't match the actual site name.

[1]  https://www.typewritten.net/writer/ev-phishing
[2]  https://stripe.ian.sh

Thank you

Burton

On Fri, Oct 25, 2019 at 5:35 AM Phillip Hallam-Baker via
dev-security-policy  wrote:

> On Thu, Oct 24, 2019 at 9:54 PM Peter Gutmann via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Paul Walsh via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> > writes:
> >
> > >we conducted the same research with 85,000 active users over a period of
> > >12 months
> >
> > As I've already pointed out weeks ago when you first raised this, your
> > marketing department conducted a survey of EV marketing effectiveness.
> If
> > you have a refereed, peer-reviewed study published at a conference or in
> > an academic journal, please reference it, not a marketing survey
> > masquerading as a "study".
>
>
> There are certainly problems with doing usability research. But right now
> there is very little funding for academic studies that are worth reading.
>
> You didn't criticize the paper with 27 subjects split into three groups
> from 2007. Nor did you criticize the fact that the conclusions were totally
> misrepresented.
>
> So it doesn't appear to be spurious research that you have a problem with
> or the misrepresentation of the results. What you seem to have a problem
> with is the conclusions.
>
> At least with 85,000 subjects there is some chance that Paul himself has
> found out something of interest. That doesn't mean that we have to accept
> his conclusions as correct, or incontrovertible but I think it does mean
> that he deserves to be treated with respect.
> I am not at all happy with the way this discussion has gone. It seems that
> contrary to the claims of openness, Mozilla has a group think problem. For
> some reason it is entirely acceptable to attack CAs for any reason and with
> the flimsiest of evidence.
> ___
> 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