Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Wed, 28 Aug 2019 11:51:37 -0700 (PDT)
Josef Schneider via dev-security-policy
 wrote:

> Not legally probably and this also depends on the jurisdiction. Since
> an EV cert shows the jurisdiction, a user can draw conclusions from
> that.

Yes it is true that crimes are illegal. This has not previously stopped
criminals, and I think your certainty that it will now is misplaced.

What conclusions would you draw from the fact that the jurisdiction is
the United Kingdom of Great Britain and Northern Ireland? Or the US
state of Delaware ?

Those sound fine right? Lots of reputable businesses?

Yes, because those are great places to register a business,
tremendously convenient. They have little if any regulation on
registering businesses, light touch enforcement and they attract a
modest fee for each one.

This is of course also exactly the right environment for crooks.


> But removing the bar is also not the correct solution. If you find
> out that the back door to your house is not secured properly, will
> you remove the front door because it doesn't matter anyway or do you
> strengthen the back door?

Certainly if crooks are seen to walk in through the back door and none
has ever even attempted to come through the upstairs windows, it is
strange to insist that removing the bars from your upstairs windows to
let in more light makes the house easier to burgle.

> The current
> EV validation information in the URL works and is helpful to some
> users (maybe only a small percentage of users, but still...)

Is it helpful, or is it misleading? If you are sure it's helpful, and
yet as we saw above you don't really understand the nuances of what
you're looking at (governments are quite happy to collect business
registration fees from crooks) then I'd say that means it's misleading.

> EV certificates do make more assurances about the certificate owner
> than DV certificates. This is a fact. This information can be very
> useful for someone that understands what it means. Probably most
> users don't understand what it means. But why not improve the display
> of this valuable information instead of hiding it?

The information is valuable to my employer, which does with it
something that is useless to Mozilla's users and probably not in line
with what EV certificate purchasers were intending, but I'm not on
m.d.s.policy to speak for my employer, and they understood that
perfectly well when they hired me.

In my opinion almost any conceivable display of this information is
likely to mislead users in some circumstances and bad guys are ideally
placed to create those circumstances. So downgrading the display is a
reasonable choice especially when screen real estate is limited.

> Certificates cannot magically bring security. Certificates are about
> identity. But the fact that the owner of the website somebank.eu is
> the owner of the domain somebank.eu is not that helpful in
> determining the credibility.

If I process a link (as browsers do many times in constructing even
trivial web pages these days) then this assures me it actually links to
what was intended.

This is enough to bootstrap WebAuthn (unphishable second factor
credentials) and similar technologies, to safeguard authentication
cookies and sandbox active code inside an eTLD+1 or narrower. All very
useful even though the user isn't aware of them directly.

For end users it means bookmarks they keep and links they follow from
outside actually lead where they should, and not somewhere else as
would trivially happen without this verification.

> But the information that the owner of
> somebank.eu is a incorporated company from Germany officially called
> "Somebank AG" is more valuable. Maybe some people don't care and
> enter their account data happily at s0m1b4nk.xyz, maybe most people
> do. We don't know and we probably can't know how many people stopped
> and thought if they are actually at the correct website because the
> green bar was missing. But I am certain that it was more than zero. 

Why are you certain of this? Just gut feeling?

> Why not for example always open a small overlay with information when
> someone starts entering data in a password field? Something like "You
> are entering a password at web.page. You visited this page 5 times
> before, first on August 4th 2019. We don't know anything about the
> owner" or for EV "You are entering a password at web.page. You
> visited this page 5 times before, first on August 4th 2019. This
> server is run by "WebPage GmbH" from Vienna, Austria [fancy flag
> picture]".

This server is run by "Authorised Web Site" from London, UK [Union
flag].

Sounds legitimate.

Remember, the British government doesn't care that Authorised Web Site
is a stupid name for a company, that its named officers are the
characters in Toy Story, that its claimed offices are a building site,
nor even that it has never filed (and never will file) any business
accounts. They collected their registration fee and that's all they

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jakob Bohm via dev-security-policy]

On 29/08/2019 10:58, Nick Lamb wrote:
> On Wed, 28 Aug 2019 11:51:37 -0700 (PDT)
> Josef Schneider via dev-security-policy
>  wrote:
> 
>> Not legally probably and this also depends on the jurisdiction. Since
>> an EV cert shows the jurisdiction, a user can draw conclusions from
>> that.
> 
> Yes it is true that crimes are illegal. This has not previously stopped
> criminals, and I think your certainty that it will now is misplaced.
> 
> What conclusions would you draw from the fact that the jurisdiction is
> the United Kingdom of Great Britain and Northern Ireland? Or the US
> state of Delaware ?
> 
> Those sound fine right? Lots of reputable businesses?
> 
> Yes, because those are great places to register a business,
> tremendously convenient. They have little if any regulation on
> registering businesses, light touch enforcement and they attract a
> modest fee for each one.
> 
> This is of course also exactly the right environment for crooks.
> 

The example given a few messages above was a different jurisdiction than 
those two easily duped company registries.

You keep making the logic error of concluding from a few example to the 
general.

A user can draw conclusions from their knowledge of the legal climate in 
a jurisdiction, such as how easy it is to register fraudulent 
untraceable business names there, and how quickly such fraudulent 
business registrations are shut down by the legal teams of high profile 
companies such as MasterCard Inc.

Such knowledge can be expected to be greater among residents of said 
jurisdiction, who may also be in a much better position to recognize 
that an address is a building site, the city stadium etc.

> 
>> But removing the bar is also not the correct solution. If you find
>> out that the back door to your house is not secured properly, will
>> you remove the front door because it doesn't matter anyway or do you
>> strengthen the back door?
> 
> Certainly if crooks are seen to walk in through the back door and none
> has ever even attempted to come through the upstairs windows, it is
> strange to insist that removing the bars from your upstairs windows to
> let in more light makes the house easier to burgle.
> 

None attempting to enter through the visibly barred window says nothing 
about how many turned away when seeing the bars.  Nor does it say 
anything about which other measures have been taken to deal with the 
known problems of the back door (Maybe they make a habit of blocking the 
door between the back entrance and the stairwell whenever leaving the 
house).

>> The current
>> EV validation information in the URL works and is helpful to some
>> users (maybe only a small percentage of users, but still...)
> 
> Is it helpful, or is it misleading? If you are sure it's helpful, and
> yet as we saw above you don't really understand the nuances of what
> you're looking at (governments are quite happy to collect business
> registration fees from crooks) then I'd say that means it's misleading.
> 

You presume government failures in some jurisdictions imply such 
failures everywhere.  Some jurisdictions require various economic 
assurances of registered companies, often tiered by the desired level of 
incorporation.  Some require a known arrestable citizen or liability 
insured public accountant to securely sign off on the registration.

>> EV certificates do make more assurances about the certificate owner
>> than DV certificates. This is a fact. This information can be very
>> useful for someone that understands what it means. Probably most
>> users don't understand what it means. But why not improve the display
>> of this valuable information instead of hiding it?
> 
> The information is valuable to my employer, which does with it
> something that is useless to Mozilla's users and probably not in line
> with what EV certificate purchasers were intending, but I'm not on
> m.d.s.policy to speak for my employer, and they understood that
> perfectly well when they hired me.
> 
> In my opinion almost any conceivable display of this information is
> likely to mislead users in some circumstances and bad guys are ideally
> placed to create those circumstances. So downgrading the display is a
> reasonable choice especially when screen real estate is limited.
> 

That opinion still is lacking in strong evidence of anything but spot 
failures under specific, detectable circumstances.


>> Certificates cannot magically bring security. Certificates are about
>> identity. But the fact that the owner of the website somebank.eu is
>> the owner of the domain somebank.eu is not that helpful in
>> determining the credibility.
> 
> If I process a link (as browsers do many times in constructing even
> trivial web pages these days) then this assures me it actually links to
> what was intended.
> 
> This is enough to bootstrap WebAuthn (unphishable second factor
> credentials) and similar technologies, to safeguard authentication
> cookies and sandbox active code inside an 

Re: DigiCert OCSP services returns 1 byte

[Peter Bowen via dev-security-policy]

On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Thanks for posting this Curt.  We investigated and posted an incident
> > report on Bugzilla. The root cause was related to pre-certs and an error
> in
> > generating certificates for them. We're fixing the issue (should be done
> > shortly).  I figured it'd be good to document here why pre-certs fall
> under
> > the requirement so there's no confusion for other CAs.
> >
>
> Oh, Jeremy, you were going so well on the bug, but now you've activated my
> trap card (since you love the memes :) )
>
> It's been repeatedly documented every time a CA tries to make this
> argument.
>
> Would you suggest we remove that from the BRs? I'm wholly supportive of
> this, since it's known I was not a fan of adding it to the BRs for
> precisely this sort of creative interpretation. I believe you're now the
> ... fourth... CA that's tried to skate on this?
>
> Multiple root programs have clarified: The existence of a pre-certificate
> is seen as a binding committment, for purposes of policy, by that CA, that
> it will or has issued an equivalent certificate.


Is there a requirement that a CA return a valid OCSP response for a
pre-cert if they have not yet issued the equivalent certificate?

Is there a requirement that a CA return a valid OCSP response for a serial
number that has never been assigned?  I know of several OCSP responders
that return a HTTP error in this case.

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

RE: Symantec migration update

[Jeremy Rowley via dev-security-policy]

Yeah - these types of weird continuity requirements  are all over the place and 
the reason the consolidation has taken this long. A lot of the effort has been 
trying to figure out how to replace things tied to old hardware with updated 
systems, essentially rebuilding things (like the timestamp service) so it can 
scale better and use more current technology. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, August 29, 2019 8:26 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec migration update

Note that while not used by Mozilla, the Time Stamping Authority services 
formerly owned by Symantec have some unique business continuity
requirements:

1. Time stamp signatures, by their very purpose, need to remain valid
   and trusted for decades after signing, even if no more signatures
   are generated.  This means keeping up private key protection and
   revocation checking.

2. The specific Symantec time stamping URLs are baked into thousands of
   scripts, as they have remained the same since before Symantec acquired
   VeriSign's CA business.  But nothing prevents pointing them to
   equivalent DigiCert servers, as Symantec had already pointed them to
   Thawte servers.

3. The unique protocol for generated Microsoft-compatible SHA-1 time
   stamp signatures remain important as long as there are still Vista,
   Windows 7, Server 2008 and older machines around (even though
   Microsoft support for those is going away, that hasn't historically
   stopped users from keeping stuff running and asking 4th party vendors
   for fresh application updates, thus causing those 4th party vendors to
   need old form signatures trusted by those old systems).  CAs would
   instead need to take additional precautions to guard against SHA-1
   weaknesses.


On 29/08/2019 00:58, Jeremy Rowley wrote:
> Hey – I realized it’s been a long time since I posted an update about where 
> we are at on shutting down the legacy Symantec systems. I thought the 
> community might find it interesting on what we’re doing to consolidate all 
> the system.
> 
> 
> When we bought the Symantec CA business, we promised to bring the systems up 
> to modern compliance standards and deprecate systems or improve the customer 
> experience by consolidating storefronts. We soon realized that we may have 
> underestimate the  scope of this promise as the systems were a bit old. As 
> soon as we gained access to the legacy Symantec systems, we audited the 
> systems for features use and functionality and the legal business agreements 
> requiring certain things. From this list, we created a migration roadmap that 
> ensured we could support customer needs and maintain their certificate 
> landscapes without extensive interference, prioritizing systems based on 
> complexity and risk.
> 
> 
> 
> Once we had a preliminary list, engineering started developing solutions to 
> to migrate customers to our primary certificate management system, 
> CertCentral. This was a necessary foundational step to moving customers off 
> legacy Symantec storefronts and APIs, so that we can shut down the old 
> Symantec systems.  As everyone knows, we did the migration of all validation 
> first (per the browser requirements), followed by the migration of org 
> details, and other information. We are still working on some  migration tools.
> 
> 
> 
> Migration to a new system is complicated for customers, and we’ve tried to 
> take an approach that would accommodate their needs. To do this, we’re 
> migrating customers in a staged approach that allows us to target groups as 
> soon as we have system readiness for different customer subsets. We began 
> migration efforts with small accounts and accounts who had outgrown the 
> performance of their old Symantec console. Moving these customers first 
> allowed us to learn and adapt our migration plan. Next, we began targeting 
> larger enterprise customers and partners with more complicated, business 
> integrations. Finally, we have begun targeting API integrated customers with 
> the most difficult migration plans. We’re working with these customers to 
> provide them the resources they need to update integrations as soon as 
> possible.
> 
> 
> 
> Of course, on the backend, we already migrated all legacy Symantec customers 
> to the DigiCert validation and issuance systems for TLS and most code 
> signing. We’re still working on it for SMIME.
> 
> 
> 
> To date, we’ve migrated a total of about 50,000 legacy accounts. This is 
> important progress towards our goal of system consolidation since we need to 
> move customers off legacy systems before we turn them off.   This isn’t the 
> half-way point, but we’ve been ramping up migration as new portions of the 
> code come into completion. Most of the migration has completed since June.
> 
> 
> 
> Now that we’re nearly product ready for all customer types to migrate, we 
> have 

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Thanks for posting this Curt.  We investigated and posted an incident report on 
Bugzilla. The root cause was related to pre-certs and an error in generating 
certificates for them. We're fixing the issue (should be done shortly).  I 
figured it'd be good to document here why pre-certs fall under the requirement 
so there's no confusion for other CAs.   

It can get confusing because the BRs section 7.1.2.7 a pre-cert is "not 
considered a certificate subject to the requirements of RFC 5280". The scope of 
the BRs is also questionable since it's still only applicable to "certificates 
intended to bused for authenticating servers"  (BRs 1.1) . By virtue of the 
poison extension, precerts can never be applicable to authenticating servers. 
Initially, it's easy to think that pre-certs may not require OCSP or the same 
strict compliance

I reviewed the CT log policy and, unless I missed something, the policy there 
is silent on pre-certs and OCSP.

I think the requirement for pre-certs comes from two places. The requirements 
around revocation information originates from Mozilla policy 5.2 "CAs MUST NOT 
issue certificates that have: cRLDistributionPoints or OCSP 
authorityInfoAccess extensions for which no operational CRL or OCSP service 
exists." Then in Section 6 "For end-entity certificates, if the CA provides 
revocation information via an Online Certificate Status Protocol (OCSP) 
service:"

What this means that a CA including a crl distribution point or OCSP service in 
the pre-cert must provide the OCPS/CRL service for the pre-cert, even if 
there's no possible way the pre-cert can be used by Mozilla on a server. The 
idea we had is simply drop the revocation information from the precert. 
Unfortunately, this doesn't work either because the pre-cert must be identical 
to the certificate plus the poison extension.  This was probably obvious to 
anyone following CT over the years, but the discussion comes up every once in a 
while internally so I thought I'd document it externally so others can also 
chime in. 

Feel free to substitute SCT for pre-cert if you want to use correct terminology.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Curt Spann via dev-security-policy
Sent: Tuesday, August 27, 2019 2:05 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: DigiCert OCSP services returns 1 byte

Hello,

I created the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014
___
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: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks for posting this Curt.  We investigated and posted an incident
> report on Bugzilla. The root cause was related to pre-certs and an error in
> generating certificates for them. We're fixing the issue (should be done
> shortly).  I figured it'd be good to document here why pre-certs fall under
> the requirement so there's no confusion for other CAs.
>

Oh, Jeremy, you were going so well on the bug, but now you've activated my
trap card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this
argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of
this, since it's known I was not a fan of adding it to the BRs for
precisely this sort of creative interpretation. I believe you're now the
... fourth... CA that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

1) Has DigiCert reviewed the existing incident reports from other CAs?
2) What process does DigiCert have to review all compliance issues,
regardless of the CA, so that it can examine its own systems for similar
issues or be aware of relevant discussions and/or ambiguities?

(And, yes, it's a trap)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Thu, 29 Aug 2019 17:05:43 +0200
Jakob Bohm via dev-security-policy
 wrote:

> The example given a few messages above was a different jurisdiction
> than those two easily duped company registries.

I see. Perhaps Vienna, Austria has a truly exemplary registry when it
comes to such things. Do you have evidence of that? I probably can't
read it even if you do.

But Firefox isn't a Viennese product, it's available all over the
world. If only some handful of exemplary registries contain trustworthy
information, you're going to either need to persuade the CAs to stop
issuing for all other jurisdictions, or accept that it isn't actually
helpful in general.

> You keep making the logic error of concluding from a few example to
> the general.

The IRA's threat to Margaret Thatcher applies:

We only have to be lucky once. You will have to be lucky always.

Crooks don't need to care about whether their crime is "generally"
possible, they don't intend to commit a "general" crime, they're going
to commit a specific crime.

> A user can draw conclusions from their knowledge of the legal climate
> in a jurisdiction, such as how easy it is to register fraudulent 
> untraceable business names there, and how quickly such fraudulent 
> business registrations are shut down by the legal teams of high
> profile companies such as MasterCard Inc.

Do you mean knowledge here, or beliefs? Because it seems to me users
would rely on their beliefs, that may have no relationship whatsoever
to the facts.

> That opinion still is lacking in strong evidence of anything but spot 
> failures under specific, detectable circumstances.

We only have to be lucky once.

> Except that any event allowing a crook to hijack http urls to a
> domain is generally sufficient for that crook to instantly get and
> use a corresponding DV certificate.

If the crook hijacks the actual servers, game is over anyway,
regardless of what type of certificate is used.

Domain owners can set CAA (now that it's actually enforced) to deny
crooks the opportunity from an IP hijack. More sophisticated owners can
use CAA and DNSSEC to deny crooks the opportunity to use this even
against a DNS hijack, so that crooks need to attack a registrar or
registry.

If the crook only does some sort of IP hijack they need to control the
IP from the perspective of the issuer as well as from the perspective
of their target in order to obtain and use a DV certificate with methods
like 3.2.2.4.6

This means small hijacks (e.g. of a single ISP or public access point)
are unlikely to be effective for obtaining a certificate.

You are correct that a large hijack (e.g. BGP hijack to move an
entire /24 for most of the Internet to some system you control) would
work on most domains, BUT this is relatively difficult for an attacker,
cannot be done silently and is already being addressed by numerous
initiatives by people over in that community rather than m.d.s.policy

> Yes, I think you have repeatedly used the failures of UK and US
> company registries as reason to dismiss all other governments.

I don't have examples from other countries either way. I assure you if
I could say "Oh, in New Zealand it works great" based on solid
information like a track record of actually prosecuting people who
make bogus registrations - I'd do that.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

This string is about Mozilla’s announced plan to remove the EV UI from Firefox 
in October.  Over time, this will tend to eliminate confirmed identity 
information about websites from the security ecosystem, as EV website owners 
may decide it’s not worth using a n EV certificate if browsers decide to hide 
the data from users.  As noted in my last message, this will be a tragedy for 
users, as browser phishing filters and other anti-phishing services currently 
rely on website EV data in their algorithms for protecting users.

It’s interesting to note that others in the security ecosystem, such as 
Facebook, are going exactly the opposite direction from Mozilla to deal with 
fraudsters operating under false names or posting anonymously (like phishers 
do), and are now actually *requiring* the use of third-party confirmed identity 
information before they are allowed to use Facebook’s platform.  I include a 
link to today’s New York Times article on Facebook’s policy changes [1], and 
also Facebook’s actual announcement of the new rules requiring identity 
confirmation before posting. [2]

I hope Mozilla will reconsider its plan to remove the EV UI and instead work on 
a better, more streamlined design for a new Firefox UI that tells users when 
confirmed identity is present, and when it is not.  Apple seems to be handling 
this UI challenge well – just compare the UI on an iPhone for apple.com (green 
lock symbol, green URL for EV identity) to the UI for mozilla.org (black lock 
symbol, black URL for DV).  Easy for users to see the difference, no need for 
users to scrutinize the actual EV identity information (unless they want to), 
tells users in a simple, binary way whether or not the website has confirmed 
identity behind it or is anonymous.  And it fits nicely on mobile devices like 
iPhones – I assume Firefox is going to continue to show users at least what URL 
they’re at (like now), so that copying the Apple UI instead of the Chrome UI 
seems like it would be a relatively easy engineering task.  By making the 
Mozilla and Apple UIs the same, we would also be taking a step forward in 
standardization of browser UIs, which makes it easier to educate users on how 
to understand what the UI means – something we should all support.

@Mozilla – please give Facebook’s announcement on the importance of identity 
some consideration before you make a final decision on changing the Firefox UI.

***

Facebook Announcement: Updates to Ads About Social Issues, Elections or 
Politics in the US

People should know who is trying to influence their vote and advertisers 
shouldn’t be able to  cover up who is paying for ads. That’s why over the past 
few years, we’ve made important changes to help ensure more transparency and 
authenticity in ads about social issues, elections or politics.

Today, we’re sharing additional steps we’re taking to protect elections and 
prepare for the US 2020 election. Those steps include strengthening the 
authorization process for US advertisers, showing people more information about 
each advertiser and updating our list of social issues in the US to better 
reflect the public discourse on and off Facebook. 

New Disclaimer Requirements

In 2018, we started requiring advertisers to get authorized before running ads 
about social issues, elections or politics. We also save those ads in an Ad 
Library so they’re publicly available for seven years.

The authorization process already requires advertisers in the US to provide 
identification to confirm who they are and where they are located. Advertisers 
must also place a “Paid for by” disclaimer on their ads to communicate who is 
responsible for them. Despite these requirements, there are a number of cases 
where advertisers have attempted to put misleading “Paid for by” disclaimers on 
their ads. That’s why, starting mid-September, advertisers will need to provide 
more information about their organization before we review and approve their 
disclaimer. If they do not provide this information by mid-October, we will 
pause their ads. While the authorization process won’t be perfect, it will help 
us confirm the legitimacy of an organization and provide people with more 
details about who’s behind the ads they are seeing. 

Advertisers will have five options for providing more information, three of 
which demonstrate they are registered with the US government. If they choose 
one of the three government resource options, they will be allowed to use their 
registered organization name in disclaimers and the “i” icon that appears in 
the upper right-hand corner of their ads will read “Confirmed Organization.”
In addition to providing their US street address, phone number, business email 
and a business website matching the email, they must provide one of the 
following: 

1. Tax-registered organization identification number (i.e. EIN)

2. A government website domain that matches an email ending in .gov or .mil

3. Federal Election 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > In this case, the use of EV certificates, and the presumption of
> > reputation, would lead to actively worse security.
> >
> > Did I misunderstand the scenario?
>
> Don't argue with me, argue with the browser phishing filters and
> anti-phishing services who do, in fact, use EV website information to
> protect users as I described.  Presumably they know what they are doing.


Sorry that it sounded like I'm arguing. I'm just trying to understand the
premise, since it so obviously has security holes that would make EV
certificates more dangerous for any user who relied on such services.

Could you point to the browsing phishing filters and anti-phishing services
that do? It might be an opportunity for you to find out how they deal with
this, and report back, so we don't have to presume anything.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 3:10:49 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > > In this case, the use of EV certificates, and the presumption of
> > > reputation, would lead to actively worse security.
> > >
> > > Did I misunderstand the scenario?
> >
> > Don't argue with me, argue with the browser phishing filters and
> > anti-phishing services who do, in fact, use EV website information to
> > protect users as I described.  Presumably they know what they are doing.
> 
> 
> Sorry that it sounded like I'm arguing. I'm just trying to understand the
> premise, since it so obviously has security holes that would make EV
> certificates more dangerous for any user who relied on such services.
> 
> Could you point to the browsing phishing filters and anti-phishing services
> that do? It might be an opportunity for you to find out how they deal with
> this, and report back, so we don't have to presume anything.

Let's hear directly from the experts - can you get someone from Google Safe 
Browsing to post to this list, and then we can all ask him or her our questions 
and get the definitive answers.  Thanks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Josef Schneider via dev-security-policy]

Am Donnerstag, 29. August 2019 10:59:40 UTC+2 schrieb Nick Lamb:
> On Wed, 28 Aug 2019 11:51:37 -0700 (PDT)
> Josef Schneider via dev-security-policy
>  wrote:
> 
> > Not legally probably and this also depends on the jurisdiction. Since
> > an EV cert shows the jurisdiction, a user can draw conclusions from
> > that.
> 
> Yes it is true that crimes are illegal. This has not previously stopped
> criminals, and I think your certainty that it will now is misplaced.
> 
> What conclusions would you draw from the fact that the jurisdiction is
> the United Kingdom of Great Britain and Northern Ireland? Or the US
> state of Delaware ?

If I expect to be on the website of my German bank, I would conclude that I am 
not at the correct website!

If they would use just a DV certificate, I wouldn't be able to come to that 
conclusion easily!

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 12:17:22 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Sure, I’m happy to explain, using Bank of America as an example.
> 
> 
> Kirk,
> 
> Thanks for providing this example. Could you help me understand how it
> helps determine that things are safe? For example, the reputation system
> you described, which is more akin to code signing than what is generally
> practiced an anti-phishing, seems like if it was implemented, it would
> leave users at significant risk from compromise on EV sites. That is, if an
> EV-using site was compromised and displayed a phishing form, the fact that
> it had "good" reputation would actually be actively harmful to users
> security, because it would make it harder to provide timely responsiveness.
> That is, it would be a false negative.
> 
> In this case, the use of EV certificates, and the presumption of
> reputation, would lead to actively worse security.
> 
> Did I misunderstand the scenario?

Don't argue with me, argue with the browser phishing filters and anti-phishing 
services who do, in fact, use EV website information to protect users as I 
described.  Presumably they know what they are doing.

And go argue with Facebook, which has just decided that binding confirmed 
identity information to Facebook posts will help in combating fraud, fake 
identities, foreign powers, etc.  Presumably they also know what they are doing.

There's also a difference between EV code signing and EV websites.  For EV code 
signing, this creates a permanent artifact associated  with the signed code 
that helps applications decide whether or not to trust the code - and it has 
become a de facto requirement in some environments.  

For EV certificates, the appeal for website owners over the past 10 years has 
been that they get a distinctive EV UI that they believe protects their 
consumers and their brands (again, don't argue with me but argue with them - 
but these website owners include many of the top enterprises and brands, so 
presumably they are smart people too with significant technical skills and have 
made their own EV decisions on a rational basis, even if you disagree with them 
or have a different commercial interest in supporting or not supporting website 
identity).  

EV identity information as used by phishing filters and anti-phishing services 
is an *incidental* benefit (but a huge one), and is not a benefit that most EV 
website owners are focused on - and website owners may not be willing to 
continue using EV certs for their websites for this incidental anti-phishing 
benefit alone if the EV UI goes away.

So again - why don't Mozilla and Chrome move to the simple, binary Apple UI 
which tells users at a glance whether or not the site has been identified 
(green URL and lock symbol, yes / black URL and lock symbol, no) so users can 
be informed and make their own decisions, instead of making the EV and DV UIs 
the same and hiding EV information from users.  

And please conduct one more Google research paper - but this time, don't just 
ask users what they *know* about the Chrome UI (and then show them websites 
without any training or other information - the Chrome UI has changed so often 
in recent years that no one knows what it means anymore - from green "Secure" 
for DV phishing sites until last year, to turning the EV UI gray).  Instead, 
research what users *can* know with 30 seconds of training.  I'll bet the Apple 
binary UI (identity / no identity) will be easy for users to understand.  Now 
that would be research worth using.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ian Carroll via dev-security-policy]

On Thursday, August 29, 2019 at 11:49:16 AM UTC-7, Kirk Hall wrote:
> On Thursday, August 29, 2019 at 11:01:27 AM UTC-7, Jonathan Rudenberg wrote:
> > On Thu, Aug 29, 2019, at 13:39, Kirk Hall via dev-security-policy wrote:
> > > This string is about Mozilla’s announced plan to remove the EV UI from 
> > > Firefox in October.  Over time, this will tend to eliminate confirmed 
> > > identity information about websites from the security ecosystem, as EV 
> > > website owners may decide it’s not worth using a n EV certificate if 
> > > browsers decide to hide the data from users.  As noted in my last 
> > > message, this will be a tragedy for users, as browser phishing filters 
> > > and other anti-phishing services currently rely on website EV data in 
> > > their algorithms for protecting users.
> > 
> > Can you provide more detail (preferably with citations) about how browser 
> > phishing filters, and specifically Google Safe Browsing (used by Firefox), 
> > rely on EV data?
> > 
> > It's not clear to me how this could possibly be useful in detecting 
> > phishing given the data that you've previously published[1] showing that an 
> > extremely small number sites with EV certificates were detected as phishing.
> > 
> > Jonathan
> > 
> > [1] 
> > https://casecurity.org/wp-content/uploads/2018/06/Summary-Report-Incidence-of-Phishing-04-16-2018.pdf
> 
> 
> Sure, I’m happy to explain, using Bank of America as an example.
> 
> The EV data securing the domain www.bankofamerica.com is as follows:
> 
> CN = www.bankofamerica.com
> SERIALNUMBER = 2927442
> OU = eComm Network Infrastructure
> 2.5.4.15 = Private Organization
> O = Bank of America Corporation
> 1.3.6.1.4.1.311.60.2.1.2 = Delaware
> 1.3.6.1.4.1.311.60.2.1.3 = US
> L = Chicago
> S = Illinois
> C = US
> 
> This data uniquely and unambiguously identifies the owner of the domain as 
> “Bank of America Corporation”, a Delaware, US corporation with the Delaware 
> registry serial number 2927442 – no other corporation in the world can get 
> that place of incorporation and serial number.  There’s no “Stripe” problem 
> here – even if a phisher or academic could create a new corporation in 
> another state (e.g., Kentucky) in the name of “Bank of America Corporation” 
> and then get an EV cert, it would show state of incorporation as Kentucky and 
> show a different serial number –it’s easy for phishing algorithms to notice 
> the difference and know these are not the same organization who own the 
> websites.
> 
> Phishing services tend to capture and retain this kind of website identity 
> information and use it in their algorithms to create a “reputation” for 
> specific domains and for specific organizations named in EV certificates that 
> they re-use later.  
> 
> Now, suppose a new website appears, “bankofamerica-alerts.com” and suppose 
> it’s only secured by a DV certificate.  In that case, this is the only 
> certificate information available to the anti-phishing service:
> 
> CN = bankofamerica-alerts.com
> 
> That could be a site owned by the real Bank of America, or owned by a phisher 
> – who knows, as there is no identity information available about the site.  
> So a phishing service would be very cautious.
> 
> Now suppose the new website “bankofamerica-alerts.com” is instead secured by 
> an EV certificate.  The certificate identity information for that site would 
> be as follows:
> 
> CN = bankofamerica-alerts.com
> SERIALNUMBER = 2927442
> OU = eComm Network Infrastructure
> 2.5.4.15 = Private Organization
> O = Bank of America Corporation
> 1.3.6.1.4.1.311.60.2.1.2 = Delaware
> 1.3.6.1.4.1.311.60.2.1.3 = US
> L = Chicago
> S = Illinois
> C = US
> 
> Only the CN field would be different from the EV certificate securing 
> www.bankofamerica.com.  Anti-phishing services will notice this similarity, 
> and will likely rely on the “reputation” already established for the site 
> www.bankofamerica.com (and for the organization “Bank  of America 
> Corporation, Delaware serial number 2927442”) and so feel confident based on 
> that good reputation that the new EV website “bankofamerica-alerts.com” is 
> unlikely to be a phishing site.  This helps speed up decisions on which sites 
> are likely safe for users and which should be flagged for phishing.
> 
> Anti-phishing algorithms like lots of data, particularly strongly confirmed 
> data like EV data.  Website owners who use EV certificates today do so 
> because they believe EV certs protect their customers and their brands, 
> chiefly through the EV UI.  If the browsers eliminate the EV UI and hide 
> identity data from users, over time website owners may stop using EV 
> certificates, and the EV identity data will disappear from the security 
> ecosystem – a real loss.

EV code signing certificates do not display any trusted UI -- their chief 
purpose is to inform Smartscreen and other relying parties of identity 
information, similar to the anti-phishing services you mention. UAC/etc will 

RE: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Let me try that again since I didn't explain my original post very well. 
Totally worth it since I got a sweet Yu-gi-oh reference out of fit. 

What happened at DigiCert is that the OCSP service failed to return a signed 
response for a certificate where a pre-certificate existed by a certificate had 
not issued for whatever reason. The question asked was what type of OCSP 
services are required for a pre-cert if there is no other certificate. The 
answer we came up with is it should respond "GOOD" based on the Mozilla policy, 
not Unknown or any other response. Note that this was a bug in the DigiCert 
system but it lead to a fun internal discussion. What I'm sharing is the 
outcome of the internal discussion - it's only tangentially related to the bug, 
not the cause or remediation of it.

Summary: Pre-certs require a standard OCSP response as if the pre-cert was a 
normal cert. In fact, it's a mistake to ever think of pre-certs as anything 
other than TLS certs, even if the poison extension exists.

The question comes up because the BRs don't cover pre-certs. However, as Ryan 
points out, the browsers sort-of cover this as does the Mozilla policy. The 
browser say this is a promise to issue the cert and mis-issuance of a pre-cert 
is the same as mis-issuance of a cert. Although this isn't mis-issuance in the 
traditional profile sense, the lack of OCSP services for the pre-cert is a 
violation of the Mozilla policy. I couldn't figure out if it's a violation of 
the Chrome policy since Chrome says it's a promise to issue a cert. If the cert 
hasn't issued, then I'm not sure where that puts the OCSP service for Chrome. 
Regardless, according to Mozilla's policy, the requirement is that regardless 
of how long the cert takes to issue, the CA must provide OCSP services for the 
pre-cert. The reason is Mozilla requires an OCSP for each end-entity 
certificate listing an AIA in the certificate. Pre-certs are end-entity 
certificates.
 
Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, August 29, 2019 11:55 AM
To: Peter Bowen ; Ryan Sleevi 
Cc: Curt Spann ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte

Yes. That was the point of my post. There is a requirement fo return an ocsp 
repsonse for a pre cert where the cert hasn't issued because of the Mozilla 
policy. Hence our failure was a Mozilla policy violation even if no practical 
system can use the response because no actual cert (without a posion extension) 
exists.

From: Peter Bowen 
Sent: Thursday, August 29, 2019 11:44:11 AM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; Curt Spann ; 
mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: DigiCert OCSP services returns 1 byte



On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy < 
dev-security-policy@lists.mozilla.org>
 wrote:

> Thanks for posting this Curt.  We investigated and posted an incident 
> report on Bugzilla. The root cause was related to pre-certs and an 
> error in generating certificates for them. We're fixing the issue 
> (should be done shortly).  I figured it'd be good to document here why 
> pre-certs fall under the requirement so there's no confusion for other CAs.
>

Oh, Jeremy, you were going so well on the bug, but now you've activated my trap 
card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of this, 
since it's known I was not a fan of adding it to the BRs for precisely this 
sort of creative interpretation. I believe you're now the ... fourth... CA 
that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate is 
seen as a binding committment, for purposes of policy, by that CA, that it will 
or has issued an equivalent certificate.

Is there a requirement that a CA return a valid OCSP response for a pre-cert if 
they have not yet issued the equivalent certificate?

Is there a requirement that a CA return a valid OCSP response for a serial 
number that has never been assigned?  I know of several OCSP responders that 
return a HTTP error in this case.

Thanks,
Peter
___
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: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Oh, I wasnt arguing that this isnt an issue. The opposite in fact.  I was 
documenting why it is an issue  ie, that a ca can't argue this isnt a 
compliance concern.  It comes up a lot but I dont remember seeing it here.

From: Ryan Sleevi
Sent: Thursday, August 29, 11:38 AM
Subject: Re: DigiCert OCSP services returns 1 byte
To: Jeremy Rowley
Cc: Curt Spann, mozilla-dev-security-pol...@lists.mozilla.org




On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Thanks for posting this Curt.  We investigated and posted an incident report on 
Bugzilla. The root cause was related to pre-certs and an error in generating 
certificates for them. We're fixing the issue (should be done shortly).  I 
figured it'd be good to document here why pre-certs fall under the requirement 
so there's no confusion for other CAs.

Oh, Jeremy, you were going so well on the bug, but now you've activated my trap 
card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of this, 
since it's known I was not a fan of adding it to the BRs for precisely this 
sort of creative interpretation. I believe you're now the ... fourth... CA 
that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate is 
seen as a binding committment, for purposes of policy, by that CA, that it will 
or has issued an equivalent certificate.

1) Has DigiCert reviewed the existing incident reports from other CAs?
2) What process does DigiCert have to review all compliance issues, regardless 
of the CA, so that it can examine its own systems for similar issues or be 
aware of relevant discussions and/or ambiguities?

(And, yes, it's a trap)


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jakob Bohm via dev-security-policy]

On 29/08/2019 19:47, Nick Lamb wrote:
> On Thu, 29 Aug 2019 17:05:43 +0200
> Jakob Bohm via dev-security-policy
>  wrote:
> 
>> The example given a few messages above was a different jurisdiction
>> than those two easily duped company registries.
> 
> I see. Perhaps Vienna, Austria has a truly exemplary registry when it
> comes to such things. Do you have evidence of that? I probably can't
> read it even if you do.
> 

I have no specific knowledge, but Austrians probably do, using empirical 
data from their life experience and press coverage of all kinds of 
business and fraud related mischief: Did fraudsters get away with 
registering misleading company names? were the registrations revoked by 
authorities soon after discovery?  Was there a serious police effort to 
prosecute?

Same for any other country as known by its citizens.

> But Firefox isn't a Viennese product, it's available all over the
> world. If only some handful of exemplary registries contain trustworthy
> information, you're going to either need to persuade the CAs to stop
> issuing for all other jurisdictions, or accept that it isn't actually
> helpful in general.
> 

The point is you keep bringing up examples from exactly two countries in 
a world with more than 100 countries.

The usefulness of knowing that a Mozilla-accepted and regularly audited 
CA has confirmed the connection to match a government record in a 
country ties directly to the trust that people can reasonably attribute 
to that part of that government.  This in turn is approximately the same 
trust applicable to those government records being reflected in other 
parts of official life, such as phone books, building permits, business 
certificates posted in offices, etc. etc.

In either case there is some residual risk of fraud, as always.


>> You keep making the logic error of concluding from a few example to
>> the general.
> 
> The IRA's threat to Margaret Thatcher applies:
> 
> We only have to be lucky once. You will have to be lucky always.
> 
> Crooks don't need to care about whether their crime is "generally"
> possible, they don't intend to commit a "general" crime, they're going
> to commit a specific crime.
> 

Almost any anti-crime effort has some probability of success and 
failure.  If a measure would stop the IRA's attacks on Thatcher 99.5% of 
the time, they would, on average, have to try 100 times to get a 50/50 
chance of getting lucky.  If another measure takes away another 80% of 
their chance, she would get 99.9% and so on.  At some point her chances 
became good enough to actually retire and die of old age having 
accumulated even more enemies.

One of the measures known to have saved her at least once was a number 
of barriers forcing an IRA rocket attack to fly just far enough to miss.  
Certainly not a perfect measure, but clearly better than nothing.


>> A user can draw conclusions from their knowledge of the legal climate
>> in a jurisdiction, such as how easy it is to register fraudulent
>> untraceable business names there, and how quickly such fraudulent
>> business registrations are shut down by the legal teams of high
>> profile companies such as MasterCard Inc.
> 
> Do you mean knowledge here, or beliefs? Because it seems to me users
> would rely on their beliefs, that may have no relationship whatsoever
> to the facts.
> 

Of cause they would use their imperfect knowledge (beliefs) about the 
country they live and survive in.  Knowing what kind of official 
paperwork to trust is a basic life skill in any society with common 
literacy (illiterates wouldn't be able to read what it says on an 
official document, nor read the words in a browser UI).

>> That opinion still is lacking in strong evidence of anything but spot
>> failures under specific, detectable circumstances.
> 
> We only have to be lucky once.
> 

When fighting a wave of similar crimes committed many times, reducing 
the number of times the criminals get lucky is a win, even if that crime 
is murder instead of theft.

>> Except that any event allowing a crook to hijack http urls to a
>> domain is generally sufficient for that crook to instantly get and
>> use a corresponding DV certificate.
> 
> If the crook hijacks the actual servers, game is over anyway,
> regardless of what type of certificate is used.
> 

Hijacking the authorized server is obviously game over.

Hijacking DNS or IP routing in any repeatable manner can be used to get 
a DV cert, then a bit later presenting that to victim browsers.  Of 
cause if the hijack ability happens to not include the view from any of 
the DV issuing CAs, then that one-two punch fails.

> Domain owners can set CAA (now that it's actually enforced) to deny
> crooks the opportunity from an IP hijack. More sophisticated owners can
> use CAA and DNSSEC to deny crooks the opportunity to use this even
> against a DNS hijack, so that crooks need to attack a registrar or
> registry.
> 

DNSSEC, like certificate pinning, is unfortunately 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Thu, 29 Aug 2019 13:33:26 -0400
Lee via dev-security-policy 
wrote:

> That it isn't my financial institution.  Hopefully I'd have the
> presence of mind to save the fraud site cert, but I'd either find the
> business card of the person I've been dealing with there or find an
> old statement, call and ask to be transferred to the fraud dept.

I commend this presence of mind.

> Same deal if the displayed info ends with (US) but doesn't match what
> I'm expecting, except I'd be asking the fraud dept about the name
> change instead of telling them.

Perhaps American banks are much better about this than those I've
handled but certainly here in the UK "expecting" is tricky for ordinary
customers. As a domain expert I know why my good bank says:

first direct (HSBC Bank plc) (GB)

... but I won't be surprised if many of their customers didn't know
they're technically part of the enormous HSBC

NS's certificate spells their name out. Unfortunately their name is
quite long, which is why they prefer the abbreviation, so my browser
shows:

National Savings and Investme... (GB)

... but it would be perfectly legal to set up businesses with different
names that truncate exactly the same as this.

My mother banks with Halifax. Again I understand why, but I suspect
she'd be astonished if she stopped to read that it says:

Lloyd Banking Group PLC (GB)

... in fact her bank is part of a larger group under a different name
and they didn't bother to get certificates that mention Halifax at all.


> I understand that ev certs aren't a panacea, but for the very few web
> sites that I really care about I like having the company name
> displayed automatically.  I think they're helpful and, since I use
> bookmarks instead of email links or search results, provide an
> adequate assurance that I've actually ended up on the web site I want.
> Is that an incorrect assumption?  What more should I be doing?

The implication of the UI change is that you needn't bother trying to
guess whether the Company Name is what you expected, if you are
visiting the bookmark for your bank (credit union, card issuer,
whatever), that will be your bank. As you have seen in this thread,
some people don't agree, but I endorse this view.

In a broader picture, there isn't much you should bother trying to do,
the onus is largely on the bank. You could try to use countermeasures
they provide e.g. per account images to re-assure you that they know
who you are before you complete login, but they're pretty likely to get
rid of them or change to new ones on a whim so it's scarcely worth it.

If you _work_ for such an institution, the best thing you could do to
protect your customers against Phishing, a very popular attack that
TLS is often expected to mitigate, is offer WebAuthn. Unfortunately the
FIDO tokens to enable WebAuthn are not cheap, making the idea of just
mailing one to every customer prohibitive. But certainly it could make
sense to offer this to High Net Worth Individuals or just let customers
use their own tokens if they want to.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 11:01:27 AM UTC-7, Jonathan Rudenberg wrote:
> On Thu, Aug 29, 2019, at 13:39, Kirk Hall via dev-security-policy wrote:
> > This string is about Mozilla’s announced plan to remove the EV UI from 
> > Firefox in October.  Over time, this will tend to eliminate confirmed 
> > identity information about websites from the security ecosystem, as EV 
> > website owners may decide it’s not worth using a n EV certificate if 
> > browsers decide to hide the data from users.  As noted in my last 
> > message, this will be a tragedy for users, as browser phishing filters 
> > and other anti-phishing services currently rely on website EV data in 
> > their algorithms for protecting users.
> 
> Can you provide more detail (preferably with citations) about how browser 
> phishing filters, and specifically Google Safe Browsing (used by Firefox), 
> rely on EV data?
> 
> It's not clear to me how this could possibly be useful in detecting phishing 
> given the data that you've previously published[1] showing that an extremely 
> small number sites with EV certificates were detected as phishing.
> 
> Jonathan
> 
> [1] 
> https://casecurity.org/wp-content/uploads/2018/06/Summary-Report-Incidence-of-Phishing-04-16-2018.pdf


Sure, I’m happy to explain, using Bank of America as an example.

The EV data securing the domain www.bankofamerica.com is as follows:

CN = www.bankofamerica.com
SERIALNUMBER = 2927442
OU = eComm Network Infrastructure
2.5.4.15 = Private Organization
O = Bank of America Corporation
1.3.6.1.4.1.311.60.2.1.2 = Delaware
1.3.6.1.4.1.311.60.2.1.3 = US
L = Chicago
S = Illinois
C = US

This data uniquely and unambiguously identifies the owner of the domain as 
“Bank of America Corporation”, a Delaware, US corporation with the Delaware 
registry serial number 2927442 – no other corporation in the world can get that 
place of incorporation and serial number.  There’s no “Stripe” problem here – 
even if a phisher or academic could create a new corporation in another state 
(e.g., Kentucky) in the name of “Bank of America Corporation” and then get an 
EV cert, it would show state of incorporation as Kentucky and show a different 
serial number –it’s easy for phishing algorithms to notice the difference and 
know these are not the same organization who own the websites.

Phishing services tend to capture and retain this kind of website identity 
information and use it in their algorithms to create a “reputation” for 
specific domains and for specific organizations named in EV certificates that 
they re-use later.  

Now, suppose a new website appears, “bankofamerica-alerts.com” and suppose it’s 
only secured by a DV certificate.  In that case, this is the only certificate 
information available to the anti-phishing service:

CN = bankofamerica-alerts.com

That could be a site owned by the real Bank of America, or owned by a phisher – 
who knows, as there is no identity information available about the site.  So a 
phishing service would be very cautious.

Now suppose the new website “bankofamerica-alerts.com” is instead secured by an 
EV certificate.  The certificate identity information for that site would be as 
follows:

CN = bankofamerica-alerts.com
SERIALNUMBER = 2927442
OU = eComm Network Infrastructure
2.5.4.15 = Private Organization
O = Bank of America Corporation
1.3.6.1.4.1.311.60.2.1.2 = Delaware
1.3.6.1.4.1.311.60.2.1.3 = US
L = Chicago
S = Illinois
C = US

Only the CN field would be different from the EV certificate securing 
www.bankofamerica.com.  Anti-phishing services will notice this similarity, and 
will likely rely on the “reputation” already established for the site 
www.bankofamerica.com (and for the organization “Bank  of America Corporation, 
Delaware serial number 2927442”) and so feel confident based on that good 
reputation that the new EV website “bankofamerica-alerts.com” is unlikely to be 
a phishing site.  This helps speed up decisions on which sites are likely safe 
for users and which should be flagged for phishing.

Anti-phishing algorithms like lots of data, particularly strongly confirmed 
data like EV data.  Website owners who use EV certificates today do so because 
they believe EV certs protect their customers and their brands, chiefly through 
the EV UI.  If the browsers eliminate the EV UI and hide identity data from 
users, over time website owners may stop using EV certificates, and the EV 
identity data will disappear from the security ecosystem – a real loss. 

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Sure, I’m happy to explain, using Bank of America as an example.


Kirk,

Thanks for providing this example. Could you help me understand how it
helps determine that things are safe? For example, the reputation system
you described, which is more akin to code signing than what is generally
practiced an anti-phishing, seems like if it was implemented, it would
leave users at significant risk from compromise on EV sites. That is, if an
EV-using site was compromised and displayed a phishing form, the fact that
it had "good" reputation would actually be actively harmful to users
security, because it would make it harder to provide timely responsiveness.
That is, it would be a false negative.

In this case, the use of EV certificates, and the presumption of
reputation, would lead to actively worse security.

Did I misunderstand the scenario?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[James Burton via dev-security-policy]

These so called "extended" validation vetting checks on companies for
extended validation certificates are supposed to provide the consumer
on the website with an high level of assurance that the company has
been properly validated but the fact is that these so called
"extended" validation vetting checks are nothing more than basic
checks. The Disclosure and Barring Service (DBS) in the United Kingdom
conducts more vetting checks on an individual applying for an basic
DBS check than CAs do for an so called "extended" validation
certificates for companies.

I serious doubts over the methods used by CAs to conduct these so
called "extended" validation vetting checks. This is from personal
experience of going through dozens of dozens of validation checks of
all types of certificates with different CAs.

These so called "extended" validation certificates should be removed
forthwith because it is not performing the intended job it was
supposed to be made for and given that these so called "extended"
validation certificates are nothing more than basic checks it is in a
way falsely advertising to consumers on these websites that uses these
so called "extended" validation certificates that they have been
validated to an "extended" level of vetting which they have not.

Burton

On Thu, Aug 29, 2019 at 8:17 PM Ryan Sleevi via dev-security-policy
 wrote:
>
> On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Sure, I’m happy to explain, using Bank of America as an example.
>
>
> Kirk,
>
> Thanks for providing this example. Could you help me understand how it
> helps determine that things are safe? For example, the reputation system
> you described, which is more akin to code signing than what is generally
> practiced an anti-phishing, seems like if it was implemented, it would
> leave users at significant risk from compromise on EV sites. That is, if an
> EV-using site was compromised and displayed a phishing form, the fact that
> it had "good" reputation would actually be actively harmful to users
> security, because it would make it harder to provide timely responsiveness.
> That is, it would be a false negative.
>
> In this case, the use of EV certificates, and the presumption of
> reputation, would lead to actively worse security.
>
> Did I misunderstand the scenario?
> ___
> 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: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

On 8/29/2019 11:07 AM, Nick Lamb via dev-security-policy wrote:

...
If you _work_ for such an institution [e.g.,a bank], the best thing 
you could do to

protect your customers against Phishing, a very popular attack that
TLS is often expected to mitigate, is offer WebAuthn


You also could (1) use only one domain for everything (including email), 
and tell your customers on every login that that is the only legitimate 
domain; (2) use only one customer service number for everything, and 
ditto the customer notices.


The contrary (badly-insecure) practices are very common. I receive 
several such calls each year purporting to be from financial 
institutions at which I have accounts. So far, none have been phishes, 
but I always call back the customer service number that I originally 
obtained from the institution's website, and always submit a security 
ticket about this issue. It never gets fixed.


-R


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

Re: DigiCert OCSP services returns 1 byte

[Jeremy Rowley via dev-security-policy]

Yes. That was the point of my post. There is a requirement fo return an ocsp 
repsonse for a pre cert where the cert hasn't issued because of the Mozilla 
policy. Hence our failure was a Mozilla policy violation even if no practical 
system can use the response because no actual cert (without a posion extension) 
exists.

From: Peter Bowen 
Sent: Thursday, August 29, 2019 11:44:11 AM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; Curt Spann ; 
mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: DigiCert OCSP services returns 1 byte



On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org>
 wrote:

> Thanks for posting this Curt.  We investigated and posted an incident
> report on Bugzilla. The root cause was related to pre-certs and an error in
> generating certificates for them. We're fixing the issue (should be done
> shortly).  I figured it'd be good to document here why pre-certs fall under
> the requirement so there's no confusion for other CAs.
>

Oh, Jeremy, you were going so well on the bug, but now you've activated my
trap card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this
argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of
this, since it's known I was not a fan of adding it to the BRs for
precisely this sort of creative interpretation. I believe you're now the
... fourth... CA that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

Is there a requirement that a CA return a valid OCSP response for a pre-cert if 
they have not yet issued the equivalent certificate?

Is there a requirement that a CA return a valid OCSP response for a serial 
number that has never been assigned?  I know of several OCSP responders that 
return a HTTP error in this case.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 8:54 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> What the heck does it mean when sometimes you say you are posting "in a
> personal capacity" and sometimes you don't?


It sounds like you were very prescient in your inability to remember
things, as you mentioned at
https://groups.google.com/d/msg/mozilla.dev.security.policy/cCeLZuxAOvQ/iM1cbmxjDgAJ

Hope that helps explain how things work. I sometimes include it to help jog
the memory of folk who tend to forget, so sorry that the extra reminder
sounds like it might have confused you.


> does GSB use any EV certificate identity data in its phishing algorithms.
> My understanding is that the answer is yes,
>

That's a good question, but I'm not sure where your understanding came
from! I was hoping you could share more, since that would definitely be the
easiest way to confirm it. It sounds like you're not sure, and you don't
have any evidence handy. If you can find out more information, can you
report back? It seems like you have some contacts or some information that
led you to your conclusion, I'm sure there is no one more effective or
efficient at finding an answer than you.

I've never heard of that, so of course, I wouldn't know where to start. On
the other hand, if you're not sure, it might be clearer not to definitively
state that's how things work, or presume they work? That might make it a
bit clearer about what's real and what's imagined, in case you're just
misremembering things. After all, if you don't know, and I don't know, and
no one else here knows, maybe it's worth focusing on the things we do know
instead of speculating?

The information I have about use of EV identity data for anti-phishing
> algorithms was all provided in private communications, so I would not be
> able to name any names without permission.  I have already emailed two
> people about this,
>

Great! Then it sounds like we're on track to having you report back once
you know more. I look forward to hearing how they've solved this, as it
sounds like EV might have be valuable even when the UI isn't shown. That
would be great validation that you don't need to show prominent UI to get
user benefit.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > Could you point to the browsing phishing filters and anti-phishing
> services
> > that do? It might be an opportunity for you to find out how they deal
> with
> > this, and report back, so we don't have to presume anything.
>
> Let's hear directly from the experts - can you get someone from Google
> Safe Browsing to post to this list, and then we can all ask him or her our
> questions and get the definitive answers.  Thanks.


I think it’s a great idea to hear from the experts!

So far, it’s hard to tell who they are, because you haven’t been able to
provide any details about who does what you describe. It sounded initially
like a hypothetical, but now that you’ve stated it’s factual, perhaps you
could provide sources? And then ask folks at those organizations and report
back? It seems that you’re passionate about this, and I can’t think of
anyone better suited to demonstrate whether or not this actually happens
than someone as passionate for the truth as you. I’m sure you’ll be able to
find out whether or not the world works like you described and report back
to us all.

Look forward to hearing more about who actually does this, and how they
solve the very obvious security risks. I’m assuming that if we don’t hear
back, it might mean no one actually does this, or that perhaps no one has
solved this obvious security issues.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > > Could you point to the browsing phishing filters and anti-phishing
> > services
> > > that do? It might be an opportunity for you to find out how they deal
> > with
> > > this, and report back, so we don't have to presume anything.
> >
> > Let's hear directly from the experts - can you get someone from Google
> > Safe Browsing to post to this list, and then we can all ask him or her our
> > questions and get the definitive answers.  Thanks.
> 
> 
> I think it’s a great idea to hear from the experts!
> 
> So far, it’s hard to tell who they are, because you haven’t been able to
> provide any details about who does what you describe. It sounded initially
> like a hypothetical, but now that you’ve stated it’s factual, perhaps you
> could provide sources? And then ask folks at those organizations and report
> back? It seems that you’re passionate about this, and I can’t think of
> anyone better suited to demonstrate whether or not this actually happens
> than someone as passionate for the truth as you. I’m sure you’ll be able to
> find out whether or not the world works like you described and report back
> to us all.
> 
> Look forward to hearing more about who actually does this, and how they
> solve the very obvious security risks. I’m assuming that if we don’t hear
> back, it might mean no one actually does this, or that perhaps no one has
> solved this obvious security issues.

Uh... Ryan...  some of the experts work down the hall from you.  Google Safe 
Browsing.  This was the question I posed to you:

"Can you get someone from Google Safe Browsing to post to this list, and then 
we can all ask him or her our questions and get the definitive answers."

What is your response?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 5:28:29 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 8:23 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote:
> > > On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > > Could you point to the browsing phishing filters and anti-phishing
> > > > services
> > > > > that do? It might be an opportunity for you to find out how they deal
> > > > with
> > > > > this, and report back, so we don't have to presume anything.
> > > >
> > > > Let's hear directly from the experts - can you get someone from Google
> > > > Safe Browsing to post to this list, and then we can all ask him or her
> > our
> > > > questions and get the definitive answers.  Thanks.
> > >
> > >
> > > I think it’s a great idea to hear from the experts!
> > >
> > > So far, it’s hard to tell who they are, because you haven’t been able to
> > > provide any details about who does what you describe. It sounded
> > initially
> > > like a hypothetical, but now that you’ve stated it’s factual, perhaps you
> > > could provide sources? And then ask folks at those organizations and
> > report
> > > back? It seems that you’re passionate about this, and I can’t think of
> > > anyone better suited to demonstrate whether or not this actually happens
> > > than someone as passionate for the truth as you. I’m sure you’ll be able
> > to
> > > find out whether or not the world works like you described and report
> > back
> > > to us all.
> > >
> > > Look forward to hearing more about who actually does this, and how they
> > > solve the very obvious security risks. I’m assuming that if we don’t hear
> > > back, it might mean no one actually does this, or that perhaps no one has
> > > solved this obvious security issues.
> >
> > Uh... Ryan...  some of the experts work down the hall from you.  Google
> > Safe Browsing.  This was the question I posed to you:
> >
> > "Can you get someone from Google Safe Browsing to post to this list, and
> > then we can all ask him or her our questions and get the definitive
> > answers."
> >
> > What is your response?
> >
> 
> Oh, I thought I made it clear, I'm posting in a personal capacity.
> 
> As you're the one making the claim, I was hoping you might demonstrate
> whether there's any truth. I certainly wouldn't want to bother anyone just
> because someone on the Internet said something. I'm sure no one would get
> any work done if they had to respond to everyone who had a half-baked idea
> about how things might work.
> 
> Of course, that also wouldn't help answer the question I asked of you, in
> the context of what you claimed:
> "Could you point to the browsing phishing filters and anti-phishing
> services that do? It might be an opportunity for you to find out how they
> deal with this, and report back, so we don't have to presume anything."
> 
> What is your response?

What the heck does it mean when sometimes you say you are posting "in a 
personal capacity" and sometimes you don't?  To me, it always appears that your 
postings on the Mozilla list are always the same as your postings on the 
CA/Browser Forum list and are always for the purpose of promoting Google's 
policies and objectives.  Is there really a difference?

Ryan, seriously - please (acting in a personal capacity, or in an official 
capacity, you choose) pull in a Google Safe Browsing expert so we can all get 
some answers on this fairly important question - does GSB use any EV 
certificate identity data in its phishing algorithms.  My understanding is that 
the answer is yes, but there is an easy way to confirm that (or change that) by 
talking to a Google Safe Browsing expert, and it's in your hands.

The information I have about use of EV identity data for anti-phishing 
algorithms was all provided in private communications, so I would not be able 
to name any names without permission.  I have already emailed two people about 
this, but if you're not even willing to put this group in contact with GSB or 
provide any information from GSB (either yes or no on whether GSB uses EV cert 
identity information), then I'm not going to bother any further.  Your 
unwillingness to help the group on this list get that information from GSB 
speaks volumes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jacob Hoffman-Andrews via dev-security-policy]

Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652

On 2019.08.28 we read Apple’s bug report at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
responder returning incorrect results for a precertificate. This prompted us to 
run our own investigation. We found in an initial review that for 35 of our 
precertificates, we were serving incorrect OCSP results (“unauthorized” instead 
of “good”). Like DigiCert, this happened when a precertificate was issued, but 
the corresponding certificate was not issued due to an error.

We’re taking these additional steps to ensure a robust fix:
  - For each precertificate issued according to our audit logs, verify that we 
are serving a corresponding OCSP response (if the precertificate is currently 
valid).
  - Configure alerting for the conditions that create this problem, so we can 
fix any instances that arise in the short term.
  - Deploy a code change to Boulder to ensure that we serve OCSP even if an 
error occurs after precertificate issuance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 8:23 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote:
> > On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > > Could you point to the browsing phishing filters and anti-phishing
> > > services
> > > > that do? It might be an opportunity for you to find out how they deal
> > > with
> > > > this, and report back, so we don't have to presume anything.
> > >
> > > Let's hear directly from the experts - can you get someone from Google
> > > Safe Browsing to post to this list, and then we can all ask him or her
> our
> > > questions and get the definitive answers.  Thanks.
> >
> >
> > I think it’s a great idea to hear from the experts!
> >
> > So far, it’s hard to tell who they are, because you haven’t been able to
> > provide any details about who does what you describe. It sounded
> initially
> > like a hypothetical, but now that you’ve stated it’s factual, perhaps you
> > could provide sources? And then ask folks at those organizations and
> report
> > back? It seems that you’re passionate about this, and I can’t think of
> > anyone better suited to demonstrate whether or not this actually happens
> > than someone as passionate for the truth as you. I’m sure you’ll be able
> to
> > find out whether or not the world works like you described and report
> back
> > to us all.
> >
> > Look forward to hearing more about who actually does this, and how they
> > solve the very obvious security risks. I’m assuming that if we don’t hear
> > back, it might mean no one actually does this, or that perhaps no one has
> > solved this obvious security issues.
>
> Uh... Ryan...  some of the experts work down the hall from you.  Google
> Safe Browsing.  This was the question I posed to you:
>
> "Can you get someone from Google Safe Browsing to post to this list, and
> then we can all ask him or her our questions and get the definitive
> answers."
>
> What is your response?
>

Oh, I thought I made it clear, I'm posting in a personal capacity.

As you're the one making the claim, I was hoping you might demonstrate
whether there's any truth. I certainly wouldn't want to bother anyone just
because someone on the Internet said something. I'm sure no one would get
any work done if they had to respond to everyone who had a half-baked idea
about how things might work.

Of course, that also wouldn't help answer the question I asked of you, in
the context of what you claimed:
"Could you point to the browsing phishing filters and anti-phishing
services that do? It might be an opportunity for you to find out how they
deal with this, and report back, so we don't have to presume anything."

What is your response?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Thu, Aug 29, 2019 at 02:14:10PM -0700, Kirk Hall via dev-security-policy 
wrote:
> For EV certificates, the appeal for website owners over the past 10 years
> has been that they get a distinctive EV UI that they believe protects
> their consumers and their brands (again, don't argue with me but argue
> with them - but these website owners include many of the top enterprises
> and brands, so presumably they are smart people too with significant
> technical skills and have made their own EV decisions on a rational basis,
> even if you disagree with them or have a different commercial interest in
> supporting or not supporting website identity).

On the contrary, I think it's perfectly reasonable to discuss this stance
with representatives of CAs, as it is, in my estimation, primarily the
marketing activities of CAs which has created this belief in website owners.

- Matt

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

Representing one's employer

[Peter Bowen via dev-security-policy]

(forking this to a new subject)

On Thu, Aug 29, 2019 at 5:54 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> What the heck does it mean when sometimes you say you are posting "in a
> personal capacity" and sometimes you don't?  To me, it always appears that
> your postings on the Mozilla list are always the same as your postings on
> the CA/Browser Forum list and are always for the purpose of promoting [your
> employer's] policies and objectives.  Is there really a difference?
>

Kirk,

You ask a very important question that deserves a clear answer.  Yes, there
is a difference.  If I'm posting on behalf of my employer, the post can be
attributed to my employer and could be quoted as $EMPLOYER says ... while
if I'm posting as an individual, this is not true.

Many people, including myself and many others who participate in this
group, work for companies they do not control.  These companies frequently
have specific policies for their employees about who can speak on behalf of
the company and under what circumstances they can speak on behalf of the
company.  See, for example, https://www.ibm.com/blogs/zz/en/guidelines.html

The concept of authority to represent a legal entity and the fact not
everyone who works for an entity has authority to commit the entity to
agreements is fairly well known.  The CA/Browser Forum EV Guidelines
recognize this when require that the "CA MUST verify that the Contract
Signer is authorized by the Applicant to enter into the Subscriber
Agreement (and any other relevant contractual obligations) on behalf of the
Applicant".  I expect that many questions would come up if someone
indicated they are employed as a summer intern yet authorized to obligate
their employer to an agreement.

You point out that frequently personal opinions and the opinions of one's
employer align.  This is not all that surprising to me.  What it tells me
is that the poster is probably influential in their organization and has
convinced those who determine the position of the legal entity to align the
position with their thinking.  IBM says in their guidelines "the following
standard disclaimer should be prominently displayed: 'The postings on this
site are my own and don't necessarily represent IBM's positions, strategies
or opinions'" when posting.  Note that it doesn't say "do not represent",
rather "do not necessarily represent".  There are cases were an employee's
personal opinions will be aligned with their employer and vice-versa; this
does not mean they always will align.

Another way to think about this is that participation in Mozilla may easily
exceed the duration of one's employment with a given employer.  Looking
back, my first bug filed with Mozilla was 21 years and several employers
ago (https://bugzilla.mozilla.org/show_bug.cgi?id=7368) and my first
certificate related bug was filed before I worked for any part of Amazon (
https://bugzilla.mozilla.org/show_bug.cgi?id=546176).  I can assure you I
wasn't speaking on behalf of those employers then and I'm not speaking for
my current employer in this post.

I've tried to make clear for whom I'm speaking by using different email
addresses; @gmail.com for personal posts and @.com for the rare
times I'm speaking on behalf of my employer.  As you have pointed out,
identity is important in order to know to whom you are interacting.

Thanks,
Peter

(not speaking for my employer)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy