SSL Certs for Malicious Websites

[Kathleen Wilson]

All,

I have been receiving questions about the following items in the CA/Browser Forum Baseline Requirements, and I would appreciate your input on what the answers are or should be.

== In the Baseline Requirements ==

Definitions:

Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.

High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk‐mitigation criteria.

Section 4.2.1:
The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.

Section 4.9.1.1:
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
… 4. The CA obtains evidence that the Certificate was misused;

Section 4.9.2:
Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.

Section 4.9.5:
The CA SHALL begin investigation of a Certificate Problem Report within twenty-four hours of receipt, and decide whether revocation or other appropriate action is warranted based on at least the following criteria:
1. The nature of the alleged problem;
2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
3. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that she didn’t receive the goods she ordered); and
4. Relevant legislation.

Section 4.10.2:
The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.

== Questions ==
1) What does "Certificate misuse, or other types of fraud" in the definition of Certificate Problem Report actually mean?
2) What does "misused" mean in Section 4.9.1.1?
3) If a website is using its SSL certificate to mask injection of malware and evidence of that is presented to the issuing CA, is that sufficient misuse for the CA to be required to revoke the certificate?
4) Does a website who is known to an issuing CA to inject malware count as high risk?
5) Are CAs required to maintain a list/database to prevent issuance of SSL certificates for websites that are known to them to inject malware?
==

As always, I will appreciate your thoughtful and constructive input on these questions.

Thanks,
Kathleen

[Peter Bowen]

(Top posting to bring the questions to the top)

> 1) What does "Certificate misuse, or other types of fraud" in the definition of Certificate Problem Report actually mean?
> 2) What does "misused" mean in Section 4.9.1.1?

I think there are a several of different things that could fall within
"misuse or fraud". For example:

- The certificate is being used for a purpose outside of that
contained in the certificate, for example taking advantage of a bug in
a certificate validation library to use a server authentication
certificate for code signing

- The Applicant for the certificate provided fraudulent information in
order to receive the certificate, for example claiming to be an
employee or authorized agent of a company with whom they have no
relationship

> 3) If a website is using its SSL certificate to mask injection of malware and evidence of that is presented to the issuing CA, is that sufficient misuse for the CA to be required to revoke the certificate?
> 4) Does a website who is known to an issuing CA to inject malware count as high risk?
> 5) Are CAs required to maintain a list/database to prevent issuance of SSL certificates for websites that are known to them to inject malware?

Some CAs may choose to not issue to sites known to inject malware, but
this outside the scope of the SSL requirements. The EV Guidelines it
very clear that the reputation and actions of the Subject are not in
scope:

"EV Certificates focus only on the identity of the Subject named in
the Certificate, and not on the behavior of the Subject. As such, an
EV Certificate is not intended to provide any assurances, or otherwise
represent or warrant:
(1) That the Subject named in the EV Certificate is actively engaged
in doing business;
(2) That the Subject named in the EV Certificate complies with applicable laws;
(3) That the Subject named in the EV Certificate is trustworthy,
honest, or reputable in its business dealings;
(4) That it is “safe” to do business with the Subject named in the EV
Certificate."

The definition of "High Risk" explicitly leaves it up to the CA to
determine what criteria are used. A CA might, for example, consider
requests for popular websites to be high risk due to frequent requests
from unauthorized Applicants for their domains. Alternatively a CA
might consider hostnames that appear to be algorithmically generated
from IP addresses.

The EV Guidelines themselves explain why it is valuable to encourage
all sites to use certificates issued by a third party:

"By providing more reliable third-party verified identity and address
information regarding the business, EV Certificates may help to [...]
Assist law enforcement organizations in their investigations of
phishing and other online identity fraud, including where appropriate,
contacting, investigating, or taking legal action against the
Subject."

This makes is clear it is highly valuable to have CAs issue
certificates to websites irrespective of content.

Thanks,
Peter

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Richard Wang]

There are a good malware test site that WoSign used: https://www.virustotal.com/en/.
If WoSign receive report for malware, we test this URL in this site, if the test result is negative, then we will revoke the SSL or code signing that signed malware.


Best Regards,

Richard

[Richard Z]

On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:

> Some CAs may choose to not issue to sites known to inject malware, but
> this outside the scope of the SSL requirements. The EV Guidelines it
> very clear that the reputation and actions of the Subject are not in
> scope:

knowingly issuing/tolerating certificates for sites known to inject
malware is
* contrary to user expectaions
* possible case of criminal felony and a liablility issue

So irrespective of what EV Guidelines say there may be other common
sense reasons to require revocation of such certificates and I would
not want Mozilla to underbid the already minimalistic security
promise of TLS.

Having an identity established by EV is nice but in most cases of
malware attacks the user has no chance to examine this identity if
the attack comes in an injected iframe.

Richard

--
Name and OpenPGP keys available from pgp key servers

[Kurt Roeckx]

On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:

> "By providing more reliable third-party verified identity and address
> information regarding the business, EV Certificates may help to [...]
> Assist law enforcement organizations in their investigations of
> phishing and other online identity fraud, including where appropriate,
> contacting, investigating, or taking legal action against the
> Subject."
>
> This makes is clear it is highly valuable to have CAs issue
> certificates to websites irrespective of content.

This makes perfect sense to me for EV certificates. What about
DV?


Kurt

[Rob Stradling]

On 16/05/16 01:43, Peter Bowen wrote:
<snip>

> Some CAs may choose to not issue to sites known to inject malware, but
> this outside the scope of the SSL requirements. The EV Guidelines it
> very clear that the reputation and actions of the Subject are not in
> scope:

Peter, I'd just like to point out that the EVGs also say (emphasis mine):
"The Guidelines describe an integrated set of technologies, protocols,
identity proofing, lifecycle management, and auditing practices
specifying the *minimum requirements* that must be met in order to issue
and maintain Extended Validation Certificates (“EV Certificates”)
concerning an organization."

This discussion should consider what's best for Mozilla's users.
Perhaps that aligns precisely with the minimum requirements in the EVGs,
or perhaps it doesn't. Mozilla are free to specify additional
requirements if they feel the need to do so, just as Microsoft did
recently...

https://aka.ms/rootcert
"If Microsoft, it its sole discretion, identifies a DV Server
Authentication certificate is being used to promote malware or unwanted
software, Microsoft will contact the responsible CA and request that it
revoke the certificate. The CA must either revoke the certificate within
a commercially-reasonable timeframe, or it must request an exception
from Microsoft within two (2) business days of receiving Microsoft’s
request. Microsoft may either grant or deny the exception at its sole
discretion. In the event that Microsoft does not grant the exception,
the CA must revoke the certificate within a commercially-reasonable
timeframe not to exceed two (2) business days."

[Please note: In this post I have not actually offered any opinions,
either my own or those of my employer, on the questions that Kathleen
asked at the beginning of this thread]

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Peter Bowen]

On Mon, May 16, 2016 at 6:06 AM, Rob Stradling <rob.st...@comodo.com> wrote:
> On 16/05/16 01:43, Peter Bowen wrote:
>
> This discussion should consider what's best for Mozilla's users. Perhaps
> that aligns precisely with the minimum requirements in the EVGs, or perhaps
> it doesn't. Mozilla are free to specify additional requirements if they
> feel the need to do so, just as Microsoft did recently...

Maybe I misunderstood the original email from Kathleen, but my
impression was that she was looking purely for clarification of what
is already required by the CA/Browser Forum Baseline Requirements. As
you point out Mozilla can adopt additional requirements as part of the
Mozilla CA Certificate Policy, but I think that is a different
discussion. In order to have that discussion, one needs to understand
what is already required by the Policy, and that is what I was
addressing.

Thanks,
Peter

[Gervase Markham]

On 16/05/16 01:13, Kathleen Wilson wrote:
> 3) If a website is using its SSL certificate to mask injection of malware and evidence of that is presented to the issuing CA, is that sufficient misuse for the CA to be required to revoke the certificate?

Counter-question to many of these: who defines what is malware, and who
made them king?

> 4) Does a website who is known to an issuing CA to inject malware count as high risk?

Well, the definition of High Risk has a clause which basically says that
the CA can define High Risk, so you'd have to ask the CA :-) But I'd say
no, because the fact that they do this doesn't make them at greater risk
for someone impersonating _them_.

Gerv

[Kathleen Wilson]

> > This discussion should consider what's best for Mozilla's users. Perhaps
> > that aligns precisely with the minimum requirements in the EVGs, or perhaps
> > it doesn't. Mozilla are free to specify additional requirements if they
> > feel the need to do so, just as Microsoft did recently...
>
> Maybe I misunderstood the original email from Kathleen, but my
> impression was that she was looking purely for clarification of what
> is already required by the CA/Browser Forum Baseline Requirements. As
> you point out Mozilla can adopt additional requirements as part of the
> Mozilla CA Certificate Policy, but I think that is a different
> discussion. In order to have that discussion, one needs to understand
> what is already required by the Policy, and that is what I was
> addressing.
>

My original email was regarding the current state of the BRs, and I would like to clarify what current requirements are. However, I think it is reasonable for this discussion to progress into whether or not the BRs and/or Mozilla policy need to be updated to address the questions.

I am wondering if the BRs need to be updated to:
+ Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
+ Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.

In regards to Mozilla policy, maybe we should consider adding text about Mozilla's expectations for CAs when they find out that a TLS/SSL certificate that they issued is being used to do bad things. I've added a link to this discussion to
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_Currently_in_Discussion

Thanks,
Kathleen

[Rob Stradling]

On 16/05/16 17:20, Kathleen Wilson wrote:
>>> This discussion should consider what's best for Mozilla's users. Perhaps
>>> that aligns precisely with the minimum requirements in the EVGs, or perhaps
>>> it doesn't. Mozilla are free to specify additional requirements if they
>>> feel the need to do so, just as Microsoft did recently...
>>
>> Maybe I misunderstood the original email from Kathleen, but my
>> impression was that she was looking purely for clarification of what
>> is already required by the CA/Browser Forum Baseline Requirements. As
>> you point out Mozilla can adopt additional requirements as part of the
>> Mozilla CA Certificate Policy, but I think that is a different
>> discussion. In order to have that discussion, one needs to understand
>> what is already required by the Policy, and that is what I was
>> addressing.
>

> My original email was regarding the current state of the BRs, and I would like to clarify what current requirements are.

ISTM that the current state of the BRs is that "misuse" is inadequately
defined.

Some groups of people will tell you that CAs MUST revoke certs for sites
that are deemed to have served malware, whilst other groups of people
will tell you that this absolutely isn't a requirement.

> However, I think it is reasonable for this discussion to progress into whether or not the BRs and/or Mozilla policy need to be updated to address the questions.

I think the discussion must progress in that manner, or else we'll be
arguing this point forever. Good luck trying to achieve consensus though!

> I am wondering if the BRs need to be updated to:
> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.
>
> In regards to Mozilla policy, maybe we should consider adding text about Mozilla's expectations for CAs when they find out that a TLS/SSL certificate that they issued is being used to do bad things. I've added a link to this discussion to
> https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_Currently_in_Discussion
>
> Thanks,
> Kathleen

[Matt Palmer]

On Mon, May 16, 2016 at 09:20:40AM -0700, Kathleen Wilson wrote:
> In regards to Mozilla policy, maybe we should consider adding text about
> Mozilla's expectations for CAs when they find out that a TLS/SSL
> certificate that they issued is being used to do bad things.

Mozilla should expect that CAs will do nothing when they find out that a
TLS/SSL certificate that they issued is being used to do "bad things" (for
values of "bad things" that do not subvert the PKI ecosystem itself). The
purpose of a CA is to attest as to *identity*, not *activity*. We have
other, more effective, mechanisms for dealing with bad actors.

- Matt

[Matt Palmer]

On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote:
> On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:
>

> > Some CAs may choose to not issue to sites known to inject malware, but
> > this outside the scope of the SSL requirements. The EV Guidelines it
> > very clear that the reputation and actions of the Subject are not in
> > scope:
>

> knowingly issuing/tolerating certificates for sites known to inject
> malware is
> * contrary to user expectaions

[Citation needed]

> * possible case of criminal felony and a liablility issue

[Citation needed]

- Matt

[Charles Reiss]

Do you think revoking certificate from malware-injecting sites would
have or has had meaningful effects on the security received by users?

I'd note that, even with OCSP hard-fail (not default), revocation takes
at least the duration of OCSP response validity to reliably take effect,
often 1 week.

Even if it did not, CAs seem to be in a very poor position to evaluate
whether sites are serving malware (compared to, say, browser vendors who
run programs like the Google Safe Browsing list) or to have nuanced
responses to tricky cases, like shared web hosts or advertising networks
who have some customers which are serving malware.

[Peter Gutmann]

Matt Palmer <mpa...@hezmatt.org> writes:
>On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote:

>> knowingly issuing/tolerating certificates for sites known to inject
>> malware is
>> * contrary to user expectaions
>

>[Citation needed]

So you're saying users expect CAs to certify malware sites?

(There have been plenty of user studies showing that users expect the padlock
to protect them from malware, hackers, and all sorts of other stuff. Please
produce a study showing that users expect CAs to certify malware sites and
virus authors).

Peter.

[Hubert Kario]

then users expect impossible

Go to Firefox and check what the connection information dialog says.
Does it say that the party you're communicating with is trustworthy?

CAs certify identity, always had, and unless they themselves start
hosting those websites, they have no way to certify trustworthiness of
the data served.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[Peter Gutmann]

Hubert Kario <hka...@redhat.com> writes:

>then users expect impossible

Users expect CAs to be something other than certificate vending machines. The
fact that CAs fail to do this is a problem with browser PKI and CAs, not with
users.

(There have been numerous cases of security people reporting CA-certified
phishing and malware sites to the CAs that did it. The general response has
been "not our problem, they paid their money and we gave them a cert". So
even if you tell the CA, they're likely not going to fix it).

Peter.

[Hubert Kario]

problem is, that this is a slippery slope. What's malware for one person
is a research subject for another. What's inflammatory or misleading
information for one person is parody and joke material to other. What's
illegal in one jurisdiction is completely legal and normal or at least
socially acceptable behaviour in another.

Remember, the web audience spans continents and vastly different
cultures.

Asking CAs to police such space is asking for trouble.

[Jernej Simončič]

On Tue, 17 May 2016 12:51:53 +0200, Hubert Kario wrote:

> problem is, that this is a slippery slope. What's malware for one person
> is a research subject for another. What's inflammatory or misleading
> information for one person is parody and joke material to other. What's
> illegal in one jurisdiction is completely legal and normal or at least
> socially acceptable behaviour in another.

I've had problems in the past because files that I host consistently
trigger antivirus warnings, despite being harmless (examples: GIMP
installer for Windows, debug data for GIMP and wget, netcat for Windows).
Luckily, the worst that came from it were some e-mail exchanges and a
lengthy phonecall with my ISP, but I know of people who lost their hosting
thanks to having files that were similarly triggering false antivirus
alerts.

--
begin .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end

[Nick Lamb]

On Tuesday, 17 May 2016 04:19:57 UTC+1, Peter Gutmann wrote:
> So you're saying users expect CAs to certify malware sites?

I'm a user, and that's what I expect, so trivially yes.

[Kathleen Wilson]

On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote:
> I am wondering if the BRs need to be updated to:
> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.
>

Would someone please volunteer to take this up with the CA/Browser Forum?


I also see a couple places in Mozilla's CA Certificate Policy where the words 'fraudulent' and 'misused' appear without having been defined...

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
"4. We reserve the right to not include a particular CA certificate in our software products. This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) would cause undue risks to users’ security, for example, with CAs that
- knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or
- knowingly issue certificates that appear to be intended for fraudulent use."

What is meant by "fraudulent use"?
Is the second bullet point essentially a restatement of the first bullet point?
Should the second bullet point be deleted?


https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
"2. CAs must revoke Certificates that they have issued upon the occurrence of any of the following events:
... the CA obtains reasonable evidence that the subscriber’s private key (corresponding to the public key in the certificate) has been compromised or is suspected of compromise (e.g. Debian weak keys), or that the certificate has otherwise been misused;"

Proposal:
Change
"or that the certificate has otherwise been misused;"
to
"or that the certificate has been used for a purpose outside of that indicated in the certificate or in the CA's subscriber agreement;"


Thanks,
Kathleen

[Eric Mill]

On Mon, May 16, 2016 at 8:24 AM, Ben Wilson <ben.w...@digicert.com> wrote:

> Gerv wrote,

> "Counter-question to many of these: who defines what is malware, and who
> made them king?"
>

> The contract that the CA enters into with the subscriber should have done
> that.
>
> Subscriber Agreements should have language in them that says something to
> the effect, "We can revoke your certificate if you are [insert bad
> behavior]
> as we determine [insert evidentiary standard or threshold]." (The
> evidentiary standard might be "as we reasonably believe", "as we determine
> in our sole discretion", etc.)
>

Individual CA terms of service are a much more reasonable place for these
kinds of requirements. That's something CAs can put in their marketing as a
feature to audiences that want that. It doesn't stop malware actors from
getting certificates from CAs that don't police malware, but given that
certificates today are being automatically dispensed for free based sheerly
on technical validation, preventing malware from *obtaining* a certificate
seems like a losing battle.

Putting malware policing into root program requirements is significantly
more dangerous, because that root program has what amounts to unchecked
policing power over any HTTPS domain. And since revocation isn't even
enforced except in limited circumstances by the most popular browser
(Chrome), the positive impact of revoking a malware site's certificate is
quite limited.

So using revocation to block malware is the worst of both worlds: revoking
a "bad guy" certificate fails to save everyone from the bad guy, yet
revoking a "good guy" certificate prevents the good guy from serving a
significant chunk of the global population. And while the folks on this
list might have a similar and narrow shared mental conception of malware,
in the long run and at global scale, "misuse" can get a lot more
subjective.

Will this also be how IP holders might pursue relief if they don't like how
the DMCA safe harbor is working out? Or how a government blocks the release
of material it believes to be classified or societally harmful? It could be
a lot easier and cheaper to convince a root program to tell a CA to revoke
a certificate than it is to convince a judge or go through ICANN's UDRP. It
would also come with zero oversight or defined public process, or the
opportunity for the public interest to be represented.

The absolute last place it should be is in CA/B Forum requirements. Peter
already pointed to some helpful language in the EV Guidelines that suggests
that the Baseline Requirements are explicitly not trying to be in this
business. If there's still ambiguity, maybe Mozilla can be helpful in
resolving it.

More generally, the IANA transition has brought a ton of scrutiny to
internet governance and the role of US governments and corporations in
managing the internet's name system. That scrutiny will only increase,
especially as other large countries clamor for more control and
sovereignty. If HTTPS should be the default on the internet, and the CA
system is the only thing we have right now that can guarantee it, then root
programs and the CA/B Forum start to look a lot like a new internet
governance body.

Being an internet governance body comes with real obligations to the
public, and the real potential to see involuntary regulation if
self-regulation fails. Since only CAs can issue certificates, while other
layers can defend users against malware, the CA system at large should be
very careful about how it weighs malware defense alongside its other
responsibilities.

-- Eric

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

--
konklone.com | @konklone <https://twitter.com/konklone>

[Roland Shoemaker]

In the case of a DV certificate it's exactly what it says, validating
the ownership of a domain, and nothing more. While users _may believe_
that TLS is supposed to protect them from malware, hackers, or
'untrustworthy' sites in general _it is not_. TLS exists to encrypt the
connection between a client and a server.

What users expect, because of poor wording by people conveying the use
of TLS in the past (I think we are all probably a bit guilty of
perpetuating this error), should not dictate how CAs actually operate.

On 05/17/2016 12:36 PM, Peter Gutmann wrote:
> Hubert Kario <hka...@redhat.com> writes:
>
>> then users expect impossible
>
> Users expect CAs to be something other than certificate vending machines. The
> fact that CAs fail to do this is a problem with browser PKI and CAs, not with
> users.
>
> (There have been numerous cases of security people reporting CA-certified
> phishing and malware sites to the CAs that did it. The general response has
> been "not our problem, they paid their money and we gave them a cert". So
> even if you tell the CA, they're likely not going to fix it).
>

> Peter.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--

Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

[Gervase Markham]

On 17/05/16 22:41, Kathleen Wilson wrote:
> On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote:
>> I am wondering if the BRs need to be updated to:
>> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
>> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.
>
> Would someone please volunteer to take this up with the CA/Browser Forum?

To be clear: you would like the CA/Browser Forum to define more
explicitly what is meant by "Certificate misuse, or other types of
fraud" in the definition of "Certificate Problem Report"? And your
initial proposal for a definition is "being used for a purpose outside
of that contained in the cert, or applicant provided false information"?

If we can be clear by the end of the week what we are asking, I can
bring this up in the CAB Forum face-to-face meeting next week.

> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> "4. We reserve the right to not include a particular CA certificate in our software products. This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) would cause undue risks to users’ security, for example, with CAs that
> - knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or
> - knowingly issue certificates that appear to be intended for fraudulent use."
>
> What is meant by "fraudulent use"?

I think the bullet as a whole could mean that we reserve the right to
not include CAs who happily issue certs to "www.paypalpayments.com" to
just anyone without any checks or High Risk string list or anything.
Such a cert, unless issued to Paypal, Inc., is clearly to be used for
fraud, IMO, and a CA is negligent in issuing it given that it's not hard
to flag for manual review any cert containing the names of major banks
and payment companies.

Gerv

[Peter Bowen]

On Wed, May 18, 2016 at 7:16 AM, Gervase Markham <ge...@mozilla.org> wrote:
> I think the bullet as a whole could mean that we reserve the right to
> not include CAs who happily issue certs to "www.paypalpayments.com" to
> just anyone without any checks or High Risk string list or anything.
> Such a cert, unless issued to Paypal, Inc., is clearly to be used for
> fraud, IMO, and a CA is negligent in issuing it given that it's not hard
> to flag for manual review any cert containing the names of major banks
> and payment companies.

Playing Devil's Advocate for a moment, if paypalpayments.com is a
valid registered domain and is owned by A Better World LLC (a Delaware
Corporation), why should they not be able to get a certificate for
their domain?

How far do you take it? According to
http://brandirectory.com/league_tables/table/banking-500-2014, top
bank brands include "TD", "UBS", and "ING", should CAs block on
"outdoor.sh", "nightclubs.io", and "exceeding.ly"?

Why should Hong Kong and Shanghai Banking Corporation be considered to
have claim to HSBC than the Humane Society of Broward County, the
House Small Business Committee, or Hobe Sound Bible College?

Given that there is already the ICANN UDRP, shouldn't that be the
venue to decide who is authorized to have what domain names? Should
CAs be responsible for making calls on who is authorized for a domain
name?

Thanks,
Peter

[Nick Lamb]

On Wednesday, 18 May 2016 16:22:39 UTC+1, Peter Bowen wrote:
> Given that there is already the ICANN UDRP, shouldn't that be the
> venue to decide who is authorized to have what domain names? Should
> CAs be responsible for making calls on who is authorized for a domain
> name?

The UDRP and the registrars only get to see the 2LD, whereas a CA is making an assertion about the entire name certified.

I would be a lot more comfortable just saying "No" here if Mozilla had mandated CT logging. With CT logging you can argue that figuring out if hsbc.customerhelp.example is "legitimate" is left as a problem for HSBC via log monitoring (either with their own monitor or more likely a service provider), as they please.

However with the current level of voluntary logging you have the same situation as CAA. The most scrupulous CAs log everything, some others selectively opt out for paying customers, and some log nothing whatsoever. A policy change, and in the longer term a commitment to require SCTs would alter that landscape. But until then it's easy to have some sympathy for the idea of "high risk" names as a check for CAs to perform to protect the ecosystem. More sympathy than for the idea of them inspecting a site's contents.

Also, FWIW I believe that even though I sometimes insist on expanding it to Hong Kong and Shanghai Banking Corporation that isn't legally correct. HSBC today doesn't stand for anything at all, the name of the globally famous bank is literally just HSBC.

[Eric Mill]

On Wed, May 18, 2016 at 9:35 AM, Ben Wilson <ben.w...@digicert.com> wrote:

> Looking at the threat from a defense-in-depth/orthogonal perspective,
> doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does
> something to combat malicious websites for the public?
>

It certainly could, and so far no one's argued that individual CAs should
be forbidden from revoking certificates used for malware. The issue is
whether CAs should be universally required, via CA/B or Mozilla rules, to
do so.

-- Eric

> Given that there is already the ICANN UDRP, shouldn't that be the
> venue to decide who is authorized to have what domain names? Should
> CAs be responsible for making calls on who is authorized for a domain name?
>

> Thanks,
> Peter

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>


--

konklone.com | @konklone <https://twitter.com/konklone>

[jo...@letsencrypt.org]

I would simply like to state that my views, and the views of Let's Encrypt, are closely aligned with those already expressed here by Peter Bowen and Eric Mill.

I will add, since I don't think it has been made clear enough here already, that violations of a CA's subscriber agreement can and should be considered fraud and abuse, in addition to the other general definitions given here.

[Matt Palmer]

On Wed, May 18, 2016 at 04:35:49PM +0000, Ben Wilson wrote:
> Looking at the threat from a defense-in-depth/orthogonal perspective,
> doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does
> something to combat malicious websites for the public?

Because the next steps after "we must do something!" is invariably "this is
something" and "we must do this", regardless of efficacy. We can't get CAs
to do what they *have* to do (attest as to identity) in a reliable manner;
how is heaping more nuanced decision-making on them going to help?

As far as browsers doing "something" to combat malicious websites, they are
doing plenty already, with things like the Google Safe Browsing list. Not
everything needs to be hit with the CA stick.

- Matt

[Matt Palmer]

On Wed, May 18, 2016 at 03:16:59PM +0100, Gervase Markham wrote:
> > What is meant by "fraudulent use"?
>

> I think the bullet as a whole could mean that we reserve the right to
> not include CAs who happily issue certs to "www.paypalpayments.com" to
> just anyone without any checks or High Risk string list or anything.
> Such a cert, unless issued to Paypal, Inc., is clearly to be used for
> fraud, IMO

How so? It could be a site providing information from a third party on how
to make and receive payments via PayPal. It could also be a site operated
by a third party on behalf of PayPal. Inferring nefarious intent from a
domain name seems like a really great way to make some fairly spectacular
mistakes.

- Matt

--
My favourite was some time ago, and involved a female customer thanking "Mr.
Daemon" for his effort trying to deliver her mail, and offering him a "good
time" if he ever visited Sydney.
-- Matt McLeod

[Richard Z]

On Tue, May 17, 2016 at 01:04:28AM +0000, Charles Reiss wrote:
> On 05/16/16 12:22, Richard Z wrote:
> >On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:
> >
> >>Some CAs may choose to not issue to sites known to inject malware, but
> >>this outside the scope of the SSL requirements. The EV Guidelines it
> >>very clear that the reputation and actions of the Subject are not in
> >>scope:
> >

> >knowingly issuing/tolerating certificates for sites known to inject
> >malware is
> >* contrary to user expectaions

> >* possible case of criminal felony and a liablility issue
> >
> >So irrespective of what EV Guidelines say there may be other common
> >sense reasons to require revocation of such certificates and I would
> >not want Mozilla to underbid the already minimalistic security
> >promise of TLS.
> >
> >Having an identity established by EV is nice but in most cases of
> >malware attacks the user has no chance to examine this identity if
> >the attack comes in an injected iframe.
>
> Do you think revoking certificate from malware-injecting sites would have or
> has had meaningful effects on the security received by users?
>
> I'd note that, even with OCSP hard-fail (not default), revocation takes at
> least the duration of OCSP response validity to reliably take effect, often
> 1 week.
>
> Even if it did not, CAs seem to be in a very poor position to evaluate
> whether sites are serving malware (compared to, say, browser vendors who run
> programs like the Google Safe Browsing list) or to have nuanced responses to
> tricky cases, like shared web hosts or advertising networks who have some
> customers which are serving malware.

the point is if mozilla would say "we don't care the least if certificates are
used for illegal or malicious purposes as long as the identity is established"
it might actually encourage some CAs to search for new business models.
There are crime friendly providers already and having crime friendly CAs is
something that users would definitely notice.

Richard

--
Name and OpenPGP keys available from pgp key servers

[Matt Palmer]

On Tue, May 17, 2016 at 11:14:21PM +0200, Richard Z wrote:
> There are crime friendly providers already and having crime friendly CAs is
> something that users would definitely notice.

Why? Do users typically notice the crime friendly hosting providers?

- Matt

[Peter Kurrasch]

Hi Gerv,

I would recommend against asking CA's to necessarily judge "malicious intent" on their own. Many CA's have enough to worry about just making sure they issue certs properly that I would question their ability to take on this extra work and perform it sufficiently well.

That said, it may be worthwhile bringing up for discussion the idea of malicious intent and what roles or responsibilities are reasonable for a CA. There are undoubtedly parallels here to how anti-spam and IP address blacklisting services go about their functions as well as Microsoft's response to malicious code that is signed with a cert that is recognized by their code signing program. Perhaps there are lessons learned there or good practices that could be adopted.

Possible talking points:

* In simplest terms I imagine most all CA's would agree that "we have the right to refuse service to anyone for any reason, up to and including revocation of already-issued certs". Certainly, something that can be seen as harmful to the reputation of a CA would qualify as one such reason?

* ‎If a CA is notified that a cert under their purview is being used for malicious intent, what will their response be and what should it be? Can a CA individually specify what they might consider malicious, how a judgment might be reached, any notifications made? Certainly each case and situation will have its own considerations but maybe some general guidelines could still be documented.

Even if the best a CA can do is revoke the cert, that still has value. At least we might have some assurance that future encounters with the malicious activity will have limited effect.

Thanks.

From: Gervase Markham Sent: Wednesday, May 18, 2016 9:17 AM To: Kathleen Wilson; mozilla-dev-s...@lists.mozilla.org Subject: Re: SSL Certs for Malicious Websites

On 17/05/16 22:41, Kathleen Wilson wrote:

> On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote:
>> I am wondering if the BRs need to be updated to:
>> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
>> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.
>
> Would someone please volunteer to take this up with the CA/Browser Forum?

To be clear: you would like the CA/Browser Forum to define more

explicitly what is meant by "Certificate misuse, or other types of

fraud" in the definition of "Certificate Problem Report"? And your

initial proposal for a definition is "being used for a purpose outside

of that contained in the cert, or applicant provided false information"?

If we can be clear by the end of the week what we are asking, I can
bring this up in the CAB Forum face-to-face meeting next week.

> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> "4. We reserve the right to not include a particular CA certificate in our software products. This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) would cause undue risks to users’ security, for example, with CAs that
> - knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or
> - knowingly issue certificates that appear to be intended for fraudulent use."
>
> What is meant by "fraudulent use"?

I think the bullet as a whole could mean that we reserve the right to

not include CAs who happily issue certs to "www.paypalpayments.com" to
just anyone without any checks or High Risk string list or anything.
Such a cert, unless issued to Paypal, Inc., is clearly to be used for

fraud, IMO, and a CA is negligent in issuing it given that it's not hard
to flag for manual review any cert containing the names of major banks
and payment companies.

Gerv

[kirkh...@gmail.com]

This has been a very surprising discussion to me. If most CAs were asked “Do you think CAs are supposed to investigate and revoke one of your certificates that is reported to you for injecting malware on Relying Parties clients?” their answer would be “Yes, of course – that’s required under the Baseline Requirements (BRs) and related WebTrust audit requirements.” So I’m very surprised to see some on this list say CAs have no duties at all to protect Relying Parties, or that their duties are somehow limited to “identity” issue.

Kathleen’s list of applicable BR sections should also include BR 4.9.3:

4.9.3. Procedure for Revocation Request

"*** The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means."

1. Breakdown of BR Requirements

This is a long post, but the subject is very important.

Looking at the BR requirements quoted in Kathleen’s initial message, it’s clear they deal with two separate processes and requirements for CAs: (a) CA’s must follow a process to revoke certificates already issued (and perhaps do other things, like report the subscriber to law enforcement), and (b) CAs must follow a process for refusing to issue new certificates to a subscriber.

2. Provisions requiring a CA to revoke a certificate

Looking at (a) first as a logical workflow, here is what the BRs require a CA to do concerning revocation of certificates already issued.

(A) Provide Relying Parties and other third parties “with clear [online] instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.” BR 4.9.3. This is a separate requirement from the provisions using the term “Certificate Problem Reports”.

[Why would the BRs require this unless the CA is supposed to do something about reported misuse, fraud, inappropriate conduct, or “any other matter related to Certificates”?]

(B) This is supplemented by new BR 4.9.2, added just three months ago, in February 2016:

“4.9.2 Who Can Request Revocation. *** Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.”

Note that this is pretty wide open – a relying party can request revocation of a certificate issued to a subscriber upon any “reasonable cause.”

(C) The CA shall maintain a “continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.” BR 4.10.2 on Service Availability.

Note that CAs “shall” revoke a certificate and/or report to law enforcement where appropriate.

This section uses the term Certificate Problem Report, which is defined as “Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.” That is pretty broad, and ties fairly closely to the reporting language in BR 4.9.3.

(D) The process that the CA “shall” follow after receiving a “Complaint of Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates” is laid out with some specificity in BR 4.9.5. This is not optional, but mandatory:

"The CA SHALL begin investigation of a Certificate Problem Report within twenty-four hours of receipt, and decide whether revocation or other appropriate action is warranted based on at least the following criteria:

1. The nature of the alleged problem;
2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
3. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that she didn’t receive the goods she ordered); and
4. Relevant legislation. ***"

Clearly the CA must investigate, make judgments, and take action (for example, if the Web site is “engaged in illegal activities” the CA should probably act and revoke the certificate, while if a consumer complains about missing goods the CA probably doesn’t need to act or revoke). Once the CA has completed the process of investigation and analysis, the CA must “decide whether revocation or other appropriate action is warranted.”

Those who say that CAs have no duty to investigate and act after receiving complaints covering “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates“ are not correct.

(E) There’s another independent requirement for revocation (BR 4.9.1.1), but this does not limit or override the stronger provisions quoted above:

"The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: ***

4. The CA obtains evidence that the Certificate was misused;"

It’s not very useful to play the dictionary game, but here is the first definition I found for the word misused: “to treat badly or abusively; maltreat.” That seems pretty close to the string “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates” used in other sections on revocation of a certificate, and it certainly would encompass things like a website that engages in illegal activities or injects malware on relying parties’ clients.

2. Provisions requiring a CA to follow checking procedures before issuing a certificate

The other provisions quoted by Katherine do not relate to revocation of issued certificates, but instead list checks that CAs must do before issuing a new certificate and which may result in refusal to issue the new certificate. These are separate and independent CA requirements from certificate revocation (note that the decision whether to issue a new certificate to a subscriber depends in part on whether the CA has previously revoked a subscriber’s certificate).

Here are those relevant provisions:

“The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.” BR 4.2.1

So what are High Risk Certificate Requests? Here is the definition, broken down by individual criteria for easier reading:

“High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include
[a] names at higher risk for phishing or other fraudulent usage,
[b] names contained in previously rejected certificate requests or revoked Certificates,
[c] names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or
[d] names that the CA identifies using its own risk‐mitigation criteria.”

All certificate requests received by a CA are potentially “high risk certificate requests” at the start – the CA will only know after running each and every certificate request through the types of tests listed at [a] through [d] above. Note that under BR 4.2.1 the CA is required to perform “additional verification activity” once a high risk certificate has been identified – the CA can’t just close its eyes and issue the certificate.

Note also that criteria [b] includes names (presumably both identity names and domain names) contained in previously rejected requests or revoked certificates – so certificate revocation is very important under BR 4.2.1 to the later decision on whether to issue a new certificate to the same subscriber (or in the same name).

3. Is “misuse” limited to “identity”?

Some postings have suggested that revocation is only required for “misuse,” and that misuse is limited to cases where the CA made a vetting mistake and issued a certificate to the wrong party (and/or with the wrong identity information inside).

Clearly this is not the case – many sections of the BRs go way beyond “misuse” and require revocation for “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates”. Note that the word “identity” never shows up in any of the applicable BR sections, although errors by the CA in issuing to the wrong party or with the wrong information inside could clearly be one form of misuse justifying or even requiring revocation. (I would say that revocation for improper authentication is required by other BR sections instead, including the CA warranties section.)

4. Response to Kathleen’s questions

So here are my responses to Kathleen’s questions (representing my personal opinion only, not those of my company).

1) What does "Certificate misuse, or other types of fraud" in the definition of Certificate Problem Report actually mean?

[KH] See discussion above. It includes “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates”, and could potentially involve “illegal activities,” “phishing or other fraudulent usage,” and other types of bad activity that puts a subscriber on the “Miller Smiles phishing list or the Google Safe Browsing list.” (Please forgive all the quotation marks, but these are all mentioned in the relevant BRs quoted above – they must mean something.)

Note that these provisions do not make CAs the Internet Police – instead, the BRs require CAs to set up and follow procedures and make reasonable judgments about revocation and refusal to issue. It’s not that hard to do, and most CAs are doing it today – and their WebTrust auditors want to see that they have a process in place and are following it.

In the past, fraudsters didn’t need to use SSL to do their work – but with the move to “https everywhere,” soon the fraudster websites won’t work without a certificate as the browsers require SSL to render a “normal” UI instead of a warning. Internet security works best when everyone helps fight the fraudsters – starting with the CAs (who can revoke or refuse to issue, thereby making it hard or impossible for fraudsters to maintain their malware sites), and continuing with browsers (through such features as Microsoft SmartScreen and Google Safe Browsing - although not all users will be protected by these features, and some bad sites may never be reported) and security software companies. No one line of defense can block every fraudster, so it’s important to have many lines of defense, including CAs.

2) What does "misused" mean in Section 4.9.1.1?

[KH] See my comments at (5) above – Section 4.9.1.1 is a relatively unimportant provision, as certificate misuse is just one of 15 listed “Reasons for Revoking a Subscriber Certificate.” Section 4.9.1.1 may function mainly to fill in that part of RFC 3647, which lists the provisions that should be in a CA’s CPS. The more important BR provisions on required revocation are as described at 2(A) through (D) above, which go far beyond the word “misused”.

However, as discussed at 2(E) above, I think “misused” at 4.9.1.1 should be interpreted as the same as “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates” used in the other applicable BR sections on revocation of a certificate. There’s no reason to limit misuse to something narrower, such as identity only.

3) If a website is using its SSL certificate to mask injection of malware and evidence of that is presented to the issuing CA, is that sufficient misuse for the CA to be required to revoke the certificate?

[KH] Absolutely yes. It falls within “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates” as well as “illegal activities”.

How can CAs know if a subscriber site is injecting malware? In most cases they can’t know independently (although if the subscriber website is listed with the Anti-Phishing Working Group, Microsoft SmartScreen, Google Safe Browsing, etc. that’s a pretty conclusive reason for refusing to issue the certificate – in the past, CAs I have been associated with have required a subscriber to get its name off a blacklist before we would issue a certificate).

In addition, security software companies are constantly looking for bad sites (such as those injecting malware) and are notifying the CAs who issued the certificate to request revocation. See, for example, the following report from Trend Micro:

http://blog.trendmicro.com/trendlabs-security-intelligence/lets-encrypt-now-being-abused-by-malvertisers/

The TrendLabs group found two websites (later five) apparently compromised by bad actors using a technique called “domain shadowing” who obtained certificates for legitimate websites. The bad actors then placed their encrypted ads on the websites that led to sites hosting the Angler Exploit Kit, which would download a banking Trojan onto the affected user machines.

One point of the TrendLabs report is that with the increasing availability of DV certs from many CAs, and the difficulty that security software can have in scanning encrypted web content for malware, these types of exploits are likely to increase. This is especially true as browsers start to require https everywhere, which pushes fraudsters to encrypt their malware. So revocation by CAs of certificates used to hide malware has become even more important. Why wouldn’t a CA want to help protect users??

In cases such as this, I think the CA could confidently rely on a security company’s research, and after requesting a response from the subscriber (that’s basic due process), must proceed and revoke the certificate under the BRs and add the name to its High Risk Certificate Request database so it will never issue a certificate to the subscriber in the future.

4) Does a website who is known to an issuing CA to inject malware count as high risk?

Yes. See discussion at Section 2 above concerning procedures that CAs must follow for High Risk Certificate Requests and refusal to issue a certificate to a subscriber. These requirements include checking the following types of criteria and databases, and refusal to issue if appropriate based on the information found by the issuing CA:

"[a] names at higher risk for phishing or other fraudulent usage,
[b] names contained in previously rejected certificate requests or revoked Certificates,
[c] names listed on the Miller Smiles phishing list or the Google Safe Browsing list, ***"

What can put a “name” (domain name or identity name) on one of these blacklists? Certainly for being a website known to an issuing CA to inject malware. Such malicious activity is very much “high risk” and should prevent a subscriber from receiving a certificate from the CA.

5) Are CAs required to maintain a list/database to prevent issuance of SSL certificates for websites that are known to them to inject malware?

Yes. See discussion in prior paragraph. Websites that are known for injecting malware will end up on one or more of the blacklists listed above, which the CA must consult before issuing a certificate to a subscriber. In addition, once a CA revokes a certificate for a site it knows has injected malware, it must add that subscriber to its own blacklist and refuse to issue any more certificates in the future.

5. Conclusion

Looking at some of the prior postings on this string, I think some people are not actually reading the BRs and WebTrust/ETSI requirements on certificate revocation, but instead are just stating their personal opinion of what the rules *should* be – namely, that a CA should do nothing, just issue certificates when requested, and never revoke anything. That’s just not what the BRs and related audit requirements say – and CAs will be tested on that by their auditors.

While the language of the BRs could have been written better the intent is very clear, and I don’t think the BRs need any clarification as to the necessity of revoking a certificate known to be used for injecting malware – it must be done. I can say this as a person who has worked with several CAs on compliance and WebTrust audit issues over many years – this is the common interpretation and the common practice among CAs.

If people want to remove the current BR revocation requirements for certificates used to hide malware, they can ask to amend the BRs to strip out the current revocation provisions, but the proposal is unlikely to pass – most CAs think they have an important role to play in fighting malware injection and other types of certificate misuse.

[Andrew Ayer]

Kathleen,

I believe that certificate authorities should be content-neutral. They
should not be required to assess "misuse" or "fraud," nor be required
to revoke certificates except upon request of the owner of a domain
listed in the certificate.

Requiring CAs to police website content is incompatible with Mozilla's
goal of deprecating non-secure HTTP. Requiring HTTPS for all sites is
only attainable if all sites can easily obtain certificates, and
content policing by CAs undermines that. As the operator of an
automated certificate reseller, I have witnessed countless cases of
certificate authorities flagging certificate requests as "High Risk"
due to the DNS name being supposedly similar to a popular brand name.
Without exception, every time has been a false positive. The best
outcome is a multi-hour delay as a human reviews the website, and the
worst outcome is an outright rejection of the request. Either way, it
creates uncertainty: you don't know if or when you can get a
certificate, which makes it hard to automate certificate deployment,
which makes it hard to deploy HTTPS. Given that CAs have only the
DNS name on which to base their decision, a high false positive rate
seems inevitable.

Requiring CAs to revoke certificates based on website content creates
another way for websites to be taken offline. What recourse does a
site operator have when their certificate is erroneously revoked by a
CA? How can websites that host user-uploaded content operate? These
are difficult questions which will need adequate answers if HTTPS is to
become mandatory for all websites. It would be much better if CAs
weren't required to police content and instead focused solely on what
certificates are meant to do: certify that a public key belongs to a
particular entity.

Protecting users from malicious content should be left to the
software processing the content (e.g. Firefox), which can do a better
job than a CA ever could. Firefox already uses Google Safe Browsing to
protect users from phishing and malware. It works for content
delivered over both HTTPS and HTTP, doesn't suffer from the multi-day
delay inherent with certificate revocation, and can operate on a
per-file level, using the URL or the hash of the file. Thus, a known
malware file can be blocked even when it appears on a brand new domain,
and if only a single file on a domain is malicious, only that file is
blocked instead of the entire site, which would cause collateral damage
in the case of a site like GitHub which serves user-uploaded content.

Regards,
Andrew

[Matt Palmer]

On Thu, May 19, 2016 at 09:15:00AM -0700, kirkh...@gmail.com wrote:
> “Yes, of course – that’s required under the Baseline Requirements (BRs)
> and related WebTrust audit requirements.”

That's an issue to be taken up with the CA/B Forum and the progenitors of
the audit requirements. It's irrelevant for a discussion of Mozilla policy.

> So I’m very surprised to see some on this list say CAs have no duties at
> all to protect Relying Parties, or that their duties are somehow limited
> to “identity” issue.

CAs have an absolute duty to protect Relying Parties from misidentification.
Everything else is marketing.

> http://blog.trendmicro.com/trendlabs-security-intelligence/lets-encrypt-now-being-abused-by-malvertisers/

Aaaaand here's the real motivation. You're out to protect the DV revenue
stream of legacy CAs by loading more and more irrelevant bureaucracy on top
of the *necessary* activities required to issue DV certificates.

I find it rather disingenuous (and disappointing) that you didn't disclose
your affiliation with Trend Micro when citing their marketing material in
support of your arguments. You're hardly a disinterested observer in these
discussions.

> The TrendLabs group found two websites (later five) apparently compromised
> by bad actors using a technique called “domain shadowing” who obtained
> certificates for legitimate websites. The bad actors then placed their
> encrypted ads on the websites that led to sites hosting the Angler Exploit
> Kit, which would download a banking Trojan onto the affected user
> machines.

If you believe that Lets Encrypt failed in their duties under the BRs, then
I'd recommend presenting that evidence in the relevant Mozilla inclusion
discussion, and to the organization(s) which have cross-signed their certs.
On the other hand, if they *haven't* contravened the BRs, then as
demonstrated by your own research, the controls in the BRs are insufficient
to meaningfully protect users from malware, and they shouldn't be considered
a valuable contribution to a Mozilla policy discussion.

Which way are you going to go?

> One point of the TrendLabs report is that with the increasing availability
> of DV certs from many CAs, and the difficulty that security software can
> have in scanning encrypted web content for malware, these types of
> exploits are likely to increase. This is especially true as browsers
> start to require https everywhere, which pushes fraudsters to encrypt
> their malware. So revocation by CAs of certificates used to hide malware
> has become even more important.


> Why wouldn’t a CA want to help protect users??

Why, indeed? I wonder that every time another report of misissuance from a
CA comes out, whether that's certificates mistakenly issued for well-known
sites, or collusion between CAs and unspecified organisations attempts to
subvert the strenuous efforts of browsers parties to improve the security of
*all* users by removing known weak algorithms from the web PKI.

> Looking at some of the prior postings on this string, I think some people
> are not actually reading the BRs and WebTrust/ETSI requirements on
> certificate revocation, but instead are just stating their personal
> opinion of what the rules *should* be – namely, that a CA should do
> nothing, just issue certificates when requested, and never revoke
> anything. That’s just not what the BRs and related audit requirements say
> – and CAs will be tested on that by their auditors.

What's that got to do with Mozilla policy?

> If people want to remove the current BR revocation requirements for
> certificates used to hide malware, they can ask to amend the BRs to strip
> out the current revocation provisions,

Except we can't in any meaningful fashion, because the CA/B Forum isn't open
to public participation, but instead only pre-approved voices are allowed to
meaningfully participate in the debate.

But that's irrelevant for a discussion of *Mozilla* policy.

- Matt

[Andrew Ayer]

On Tue, 17 May 2016 03:19:22 +0000
Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:

> Matt Palmer <mpa...@hezmatt.org> writes:
> >On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote:

> >> knowingly issuing/tolerating certificates for sites known to
> >> inject malware is
> >> * contrary to user expectaions
> >

> >[Citation needed]

>
> So you're saying users expect CAs to certify malware sites?

I suspect that the vast majority of users have no idea what a CA is and
thus have no expectations for what they should do.

> There have been plenty of user studies showing that users expect the
> padlock to protect them from malware, hackers, and all sorts of other
> stuff.

This may be the case, but this would be an argument for changing the UI
to avoid giving this misleading impression. For instance, HTTPS could
be displayed with a neutral indication, and HTTP with an insecure
indication.

(Note that the padlock is misleading *today*, because even with CAs'
current efforts to police content, it's easy to serve malware over
HTTPS. Even if the CA revokes the cert, the attacker can circumvent
the revocation for days by stapling a valid OCSP response.)

Regards,
Andrew

[Matt Palmer]

Well said, Andrew. You've summarised the issue excellently.

- Matt

> --

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

--
If someone tells you to forward an e-mail to all your friends, please -
forget that I'm your friend. If you don't, I will.

[tech...@gmail.com]

Andrew - As I outlined in my message above, the BRs cover two distinct situations: (1) when must CAs revoke certs that have already been issued for “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates,” and (2) when CAs must refuse to issue because their High Risk Certificate Request checking algorithms indicate the subscriber should not receive a new certificate.

Kathleen’s questions cover both situations (1) and (2):

== Questions ==

1) What does "Certificate misuse, or other types of fraud" in the definition of Certificate Problem Report actually mean? [KH - This relates to revocation of an issued certificate]

2) What does "misused" mean in Section 4.9.1.1? [KH - This relates to revocation of an issued certificate]

3) If a website is using its SSL certificate to mask injection of malware and evidence of that is presented to the issuing CA, is that sufficient misuse for the CA to be required to revoke the certificate? [KH - This relates to revocation of an issued certificate]

4) Does a website who is known to an issuing CA to inject malware count as high risk? [This relates to refusal to issue a new certificate to a subscriber based on known bad acts, not possible identity confusion in a name like “yourfacebookpage123.net” that is properly registered to a hacker.]

5) Are CAs required to maintain a list/database to prevent issuance of SSL certificates for websites that are known to them to inject malware? [This relates to refusal to issue a new certificate to a subscriber based on known bad acts, not possible identity confusion in a name like “yourfacebookpage123.net” that is properly registered to a hacker.]

Your main concern – unjustified delay in issuing a certificate to your customer while a human looks at the domain to decide if there is a problem - is not really related to any of Kathleen’s questions. Your other comments express what you think the role of a CA *should* be, but don’t address what the current BRs actually require CAs to do (which is what Kathleen was asking).

I think it’s a huge mistake to leave all user protection solely o software processing features like Microsoft SmartScreen and Google Safe Browsing. First, there are millions of users around the world who will not be protected by such features. Second, who knows what really goes in to these software processing features – and who knows if a malware site known to the CA who issued a cert for the site will ever be reported by the CA to all the possible software applications used around the world.

When a certificate is used to hide malware from users and prevent their security software from detecting the malware, that certificate should be revoked by the issuing CA once it receives credible information that the certificate is being used by a malware site (after the CA receives no timely or adequate response from the subscriber when asked about the report). That’s the first line of defense for users.

[tech...@gmail.com]

Matt, that's a bit harsh, and you are all over the map. I was only responding to Kathleen's questions, which asked what do the current BRs require CAs to do when they receive reports of SSL certificates issued to malware injection sites. I was not proposing any new rules or any new interpretations of the existing rules -- I was explaining what the existing rules say, and how CAs (including the ones I have worked for) have applied them for many years (I believe these rules were first adopted, with the concurrence of all the browsers, in 2008 as part of the EV Guidelines). I was also pointing out that with the commendable adoption of ssl-everywhere, we all face new challenges as fraudsters are forced to use SSL, and use it to hide malware from user security software.

If you don't like the current BR rules, you are free to argue for change.

[Peter Bowen]

On Thu, May 19, 2016 at 9:15 AM, <kirkh...@gmail.com> wrote:
> This has been a very surprising discussion to me. If most CAs were asked “Do you think CAs are supposed to investigate and revoke one of your certificates that is reported to you for injecting malware on Relying Parties clients?” their answer would be “Yes, of course – that’s required under the Baseline Requirements (BRs) and related WebTrust audit requirements.” So I’m very surprised to see some on this list say CAs have no duties at all to protect Relying Parties, or that their duties are somehow limited to “identity” issue.

Kirk,

I think you misinterpreted the responses, at least if that is the take
away you have. Kathleen asked specific questions and I think the
responses were to those specific questions. The question "MUST CAs
investigate and revoke certificates for websites that are reported to
them for injecting malware on Relying Parties clients?" was not one of
the questions.

As a few example of where the specific questions are important:

[KW Question] What does "misused" mean in Section 4.9.1.1?

You correctly point out there are 15 different things in 4.9.1.1.
This is specifically asking about #4. I would suggest that items #5,
#9, #10, and #14 all could cover the "injecting malware" case you
propose.

[KW Question] If a website is using its SSL certificate to mask

injection of malware and evidence of that is presented to the issuing
CA, is that sufficient misuse for the CA to be required to revoke the
certificate?

I think that there should be an option for the website to show they
had cleaned up their website (e.g. if they had a breach) and keep
their certificate rather than requiring revocation.

[KW Question] Does a website who is known to an issuing CA to inject

malware count as high risk?

The BRs only reference High Risk in the section called "Performing
Identification and Authentication Functions" and say "The CA SHALL

develop, maintain, and implement documented procedures that identify
and require additional verification activity for High Risk Certificate
Requests prior to the Certificate’s approval, as reasonably necessary
to ensure that such requests are properly verified under these

Requirements." This explicitly attaches High Risk to verification of
subject identity and domain control validation.

I don't think the concept of whether a CA chooses to issue a
certificate should be commingled with the identity validation -- I
think it is clear that a site serving malware might pass all
identification and authentication steps.

[KW Question] Are CAs required to maintain a list/database to prevent

issuance of SSL certificates for websites that are known to them to
inject malware?

This is clearly about the CA maintaining a list/database. As you
point out there are external databases that are frequently used by CAs
to determine if they want to issue a certificate, so I don't see value
in requiring the CA to maintain another database themselves.

Overall you bring up many good points, but I think most of the
responses were trying to directly address the questions asked. Given
they are about interpretations of specific audit criteria, it is
important that the responses are correctly scoped. If this had been
about the question you asked, the more generic one about how to handle
malware-distributing sites, that would have been different.

Thanks,
Peter

[tech...@gmail.com]

On Thursday, May 19, 2016 at 5:21:05 PM UTC-7, Peter Bowen wrote:

> I think you misinterpreted the responses, at least if that is the take
> away you have. Kathleen asked specific questions and I think the
> responses were to those specific questions. The question "MUST CAs
> investigate and revoke certificates for websites that are reported to
> them for injecting malware on Relying Parties clients?" was not one of
> the questions.
>
> As a few example of where the specific questions are important:
>
> [KW Question] What does "misused" mean in Section 4.9.1.1?
>
> You correctly point out there are 15 different things in 4.9.1.1.
> This is specifically asking about #4. I would suggest that items #5,
> #9, #10, and #14 all could cover the "injecting malware" case you
> propose.

[KH] Peter - the term "misuse" is used in multiple places, and I think you need to look at all uses to understand what it is intended to mean at Sec. 4.9.1.1. In any event, it appears we agree that certs used for malware injection should be revoked by the CA, unless the subscriber gives an adequate explanation and/or cleans up the website after the CA asks. But the CA is supposed to ask under the existing BRs.

>
> [KW Question] If a website is using its SSL certificate to mask
> injection of malware and evidence of that is presented to the issuing
> CA, is that sufficient misuse for the CA to be required to revoke the
> certificate?
>
> I think that there should be an option for the website to show they
> had cleaned up their website (e.g. if they had a breach) and keep
> their certificate rather than requiring revocation.

[KH] Agreed. The CA should ask the subscriber for an explanation and/or cleanup, and then does not need to revoke if the response is adequate. But under the BRs, the CA must revoke if there is no adequate response from a site using the cert to inject malware.

>
> [KW Question] Does a website who is known to an issuing CA to inject
> malware count as high risk?
>
> The BRs only reference High Risk in the section called "Performing
> Identification and Authentication Functions" and say "The CA SHALL
> develop, maintain, and implement documented procedures that identify
> and require additional verification activity for High Risk Certificate
> Requests prior to the Certificate’s approval, as reasonably necessary
> to ensure that such requests are properly verified under these
> Requirements." This explicitly attaches High Risk to verification of
> subject identity and domain control validation.
>
> I don't think the concept of whether a CA chooses to issue a
> certificate should be commingled with the identity validation -- I
> think it is clear that a site serving malware might pass all
> identification and authentication steps.

[KH] But Peter, how do you explain the provisions of the High Risk Certificate Definition, which suggests CAs should look at the following when processing a new certificate request?

“BR 4.2.1 The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.”

"High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include
[a] names at higher risk for phishing or other fraudulent usage,
[b] names contained in previously rejected certificate requests or revoked Certificates,
[c] names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or
[d] names that the CA identifies using its own risk‐mitigation criteria.”

Under this BR and related definition, the CA is supposed to look for much more than just possible name/identity confusion. Plus it's never safe to use a general section title to try to limit the meaning of a specific subsection - BR 4.2.1 has four paragraphs which covers lots of requirements, and the requirement as to High Risk Certificate Requests stands on its own and is very specific. (Plus I think the Section title you reference came from RFC 3647, the template for CPSs, and was not created by the Forum -- the Forum just stuffed a lot of requirements under that specific pre-determined heading).

>
> [KW Question] Are CAs required to maintain a list/database to prevent
> issuance of SSL certificates for websites that are known to them to
> inject malware?
>
> This is clearly about the CA maintaining a list/database. As you
> point out there are external databases that are frequently used by CAs
> to determine if they want to issue a certificate, so I don't see value
> in requiring the CA to maintain another database themselves.

[KH] See response above - yes, CAs can and should use multiple outside databases of bad actors. The High Risk Certificate Request defininition also suggests the following two databases, which the CA necessarily must establish and maintain for itself:

[b] names contained in previously rejected certificate requests or revoked Certificates, ***

[d] names that the CA identifies using its own risk‐mitigation criteria

>

[Ben Laurie]

On 19 May 2016 at 17:15, <kirkh...@gmail.com> wrote:
> 4.9.3. Procedure for Revocation Request
>
> "*** The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means."

I've tried a few times to find these readily accessible instructions
for any CA whatsoever. Do they exist? Where are Trend Micro's, for
example?

[Rob Stradling]

Kathleen,

"The CA SHALL publicly disclose the instructions through a readily

accessible online means" immediately makes me think of the Mozilla CA
Community in Salesforce.

Is there a field in the Salesforce system (per CA Owner, I'd have
thought) that indicates where the CA publishes these "clear instructions"?

Also, is it your intent to make the Salesforce system publicly readable?
(IINM, it's only readable by representatives of CAs at the moment).

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[tech...@gmail.com]

http://www.trendmicro.com/us/enterprise/cloud-solutions/deep-security/ssl-certificates/#support

PROBLEM REPORTING

If you need to revoke a certificate issued by Trend Micro SSL or if you want to report a problem with a site secured by a Trend Micro SSL certificate, please send details about the problem to ssl_s...@trendmicro.com.

By the way, I no longer work for Trend Micro

[Gervase Markham]

On 18/05/16 17:35, Ben Wilson wrote:
> Looking at the threat from a defense-in-depth/orthogonal perspective,
> doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does
> something to combat malicious websites for the public?

Not necessarily, if what they do ends up damaging innocent parties due
to lack of sufficient information.

Gerv

[Gervase Markham]

On 19/05/16 00:45, Matt Palmer wrote:
> How so? It could be a site providing information from a third party on how
> to make and receive payments via PayPal. It could also be a site operated
> by a third party on behalf of PayPal. Inferring nefarious intent from a
> domain name seems like a really great way to make some fairly spectacular
> mistakes.

Consider my comment withdrawn :-) Don't know what I was thinking.

Gerv

[Andrew Ayer]

On Thu, 19 May 2016 16:52:26 -0700 (PDT)
tech...@gmail.com wrote:

> Your main concern – unjustified delay in issuing a certificate to
> your customer while a human looks at the domain to decide if there is
> a problem - is not really related to any of Kathleen’s questions.
> Your other comments express what you think the role of a CA *should*
> be, but don’t address what the current BRs actually require CAs to do
> (which is what Kathleen was asking).

In fact, Kathleen asked explicitly for what the answers "should be" in
addition to what they are, so my email was not unrelated. To be more
explicit, I think the answers to questions 3-5 should be no. The
reason why is explained in my email: requiring CAs to be responsible
for content has unintended negative effects on HTTPS adoption. I
think that causes more harm than good to Internet security.

Regards,
Andrew

[Peter Bowen]

[ Disclaimer: This message is my personal view and does not
necessarily represent that of my employer. ]

On Thu, May 19, 2016 at 9:15 AM, <kirkh...@gmail.com> wrote:
> This has been a very surprising discussion to me. If most CAs were asked “Do you think CAs are supposed to investigate and revoke one of your certificates that is reported to you for injecting malware on Relying Parties clients?” their answer would be “Yes, of course – that’s required under the Baseline Requirements (BRs) and related WebTrust audit requirements.”

Kirk,

Addressing your question directly, the _Trust Service Principles and
Criteria for Certification Authorities, Version 2.0_ (better know as
WebTrust for Certification Authorities 2.0) very much does not require
such. This WebTrust audit is designed to provide assurance that the
CA does what it says it does when it comes to Subscriber Registration
and Certificate Issuance. It is up to the CA to determine the rules
about when it issues a certificate and document those in its CPS.

When it comes to public certificates, which is what the Mozilla CA
program covers and are the subject of the BRs and EV Guidelines
(EVGs), there is assurance that certificates do the the following:

Provide global identification by certifying:
1) A binding between the identity of a natural person or institution
and a cryptographic key
2) Confirmation that the identified named entity authorized issuance
of the certificate
Alternatively they explicitly may not provide identity.

Provide assurance that the subscriber either had control of the hosts,
control of the domain namespace, or was a contact for the domain
namespace for all DNS names or the equivalent for all alternative
names in the certificate at the time the certificate was issued. In
some cases, such as an electronic identity certificate, there may be
no alternative name.

This is all that they do. Now some CAs may choose to make further
assurances, for example they may assert that the person named in the
certificate is a citizen of a certain country or assert that the
company is a member of an organization or has been licensed for
certain activities However this is outside the scope of the BRs and
EVGs.

Just like state, province, territory, or district issued identity
cards in the US and Canada, Certificates do not directly assert
anything about the character of the individual identified. Someone
with multiple felony convictions can get an identity card. However,
what the identity card or certificate does so it help provide a
consistent identity that can be looked up in systems to find out about
the character of the person.

Certificates for a critical part of securing communication. They
solve the a priori knowledge problem when initiating a conversation
with a previously unknown party. The certificate allows the one party
to say to the other "I'm Bob and you can be assured of that because
our mutual friend Charlie confirmed a much". This avoids a
switcheroo taking place where someone else claims to be Bob.

If CAs want to add additional assertions to certificates, that should
be their prerogative. If this is included in a manner that allows
automatic extraction, then it is something that firewall or end point
security vendors might be able use to help classify websites. For
example, a certificate can declare it is a website operated by a
national government which might cause the security software to make
certain decisions. However this is out of scope for the BRs, EVGs,
and Mozilla CA program.

Thanks,
Peter

[tech...@gmail.com]

On Friday, May 20, 2016 at 12:22:07 PM UTC-7, Peter Bowen wrote:
> [ Disclaimer: This message is my personal view and does not
> necessarily represent that of my employer. ]
>

Now you have really stumped me, Peter. Are you saying the BR provisions of 4.2.1 through 4.9.10 quoted by Kathleen in her first message above are optional? I don't think that's correct.

I was not proposing that CAs go beyond what is spelled out in the BRs as to revocation (and blocking new cert issuance), although they can if they want to. I was only responding to Kathleen's questions about what the quoted BR provisions mean -- and to me, they are mandatory, not optional. I know we and other CAs have been following these rules for some years.

Also, you are only looking at basic WebTrust for CAs (with its new name). Take a look at BR WebTrust Sec. 5.

[Peter Bowen]

[ Disclaimer: This message is my personal view and does not
necessarily represent that of my employer. ]

On Fri, May 20, 2016 at 3:19 PM, <tech...@gmail.com> wrote:
> On Friday, May 20, 2016 at 12:22:07 PM UTC-7, Peter Bowen wrote:
>>

>> When it comes to public certificates, which is what the Mozilla CA
>> program covers and are the subject of the BRs and EV Guidelines
>> (EVGs), there is assurance that certificates do the the following:
>>
>> Provide global identification by certifying:
>> 1) A binding between the identity of a natural person or institution
>> and a cryptographic key
>> 2) Confirmation that the identified named entity authorized issuance
>> of the certificate
>> Alternatively they explicitly may not provide identity.
>>
>> Provide assurance that the subscriber either had control of the hosts,
>> control of the domain namespace, or was a contact for the domain
>> namespace for all DNS names or the equivalent for all alternative
>> names in the certificate at the time the certificate was issued. In
>> some cases, such as an electronic identity certificate, there may be
>> no alternative name.
>>
>> This is all that they do. Now some CAs may choose to make further
>> assurances, for example they may assert that the person named in the
>> certificate is a citizen of a certain country or assert that the
>> company is a member of an organization or has been licensed for
>> certain activities However this is outside the scope of the BRs and
>> EVGs.
>

> Now you have really stumped me, Peter. Are you saying the BR provisions of 4.2.1 through 4.9.10 quoted by Kathleen in her first message above are optional? I don't think that's correct.
>
> I was not proposing that CAs go beyond what is spelled out in the BRs as to revocation (and blocking new cert issuance), although they can if they want to. I was only responding to Kathleen's questions about what the quoted BR provisions mean -- and to me, they are mandatory, not optional. I know we and other CAs have been following these rules for some years.

The only places where the BRs uses the word "malware" are:
Section 5, about protecting the CA's own system from malware and
9.6.3 (8) which says CA must confirm that the Subscriber has
acknowledged the CA is "entitled" to revoke a certificate immediately
if the Certificate is used to enable the distribution of malware.

If you compare this to the recent Microsoft program requirement, you
will see there is no requirement that a CA do so, rather the
subscriber has simply acknowledged they are entitled to do so.

Kathleen has pointed out that terms like "misuse" is undefined and
suggested that the CA/Browser Forum update the BRs to define this
term. If you feel strongly that publicly trusted certificates should
certify more than identity, I would suggest you propose a ballot to
update the BRs state such.

Thanks,
Peter

[tech...@gmail.com]

On Friday, May 20, 2016 at 5:29:43 PM UTC-7, Peter Bowen wrote:
> [ Disclaimer: This message is my personal view and does not
> necessarily represent that of my employer. ]
>

Peter -- the reference to BR 9.6.8(8) is interesting, but is not really relevant to discussion of the requirements of BR 4.2.1 through 4.9.10 quoted by Kathleen in her first message above (and which are enforced by Section 5 of the Baseline Requirments WebTrust audit - see http://www.webtrust.org/homepage-documents/item76002.pdf) What about those sections? Look again at the first analysis I posted.

I don't understand the resistance to complying with these provisions -- it's not that hard.

If you think the requirements of BR 4.2.1 through 4.9.10 should be softened or deleted, then I suggest you are the one who needs to propose a ballot! CAs have been following these rules for about eight years now, so there is a pretty solid history and precedence.

[Peter Bowen]

[ Disclaimer: This message is my personal view and does not
necessarily represent that of my employer. ]

On Fri, May 20, 2016 at 5:41 PM, <tech...@gmail.com> wrote:
> Peter -- the reference to BR 9.6.8(8) is interesting, but is not really relevant to discussion of the requirements of BR 4.2.1 through 4.9.10 quoted by Kathleen in her first message above (and which are enforced by Section 5 of the Baseline Requirments WebTrust audit - see http://www.webtrust.org/homepage-documents/item76002.pdf) What about those sections? Look again at the first analysis I posted.
>
> I don't understand the resistance to complying with these provisions -- it's not that hard.
>
> If you think the requirements of BR 4.2.1 through 4.9.10 should be softened or deleted, then I suggest you are the one who needs to propose a ballot! CAs have been following these rules for about eight years now, so there is a pretty solid history and precedence.

You are right, it is not hard to comply with 4.2.1 to 4.9.10. However
they say absolutely nothing about malware. The do discuss "misuse"
but it is up to the CA to define misuse.

>From the sections you explicitly called out in your original email:

4.9.3: Requires CAs provide ability for anyone to report things. No
action is required of the CA other than accepting the report.

4.9.2: Says what must be in a certificate problem report, does not
address processing the report.

4.9.5: CA must decide _if_ revocation is warranted. However does not
state conditions under which revocation must be warranted.

4.10.2: CA must be able to respond to problem reports 24x7.
_Where_appropriate_ the CA can either forward the complaint to law
enforcement and/or revoke the certificate. Again does not specify any
conditions where the CA must do so.

4.9.1.1(4): Requires the CA to revoke if the Certificate was misused.
CA is free to define misuse as they see fit.

4.2.1: Requires "additional verification activity for High Risk

Certificate Requests prior to the Certificate’s approval, as
reasonably necessary to ensure that such requests are properly

verified under these Requirements." Simply requires CAs to be sure
they are properly identifying the subject authorization and DNS name
control, as that is what is verified.

High Risk Certificate Request: ": A Request that the CA flags for
additional scrutiny by reference to internal criteria and databases

maintained by the CA". Does not define any specific mandatory
requirements for the criteria or database contents. It does have "may
include", but that means it is up to the CA.

I think one of the things that frequently is missed by people not used
to technical specifications is the meaning of section 1.6.4 of the
BRs. It says that the 'words “MUST”, “MUST NOT”, "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in these Requirements shall be interpreted in accordance
with RFC 2119.' This basically means that anything labeled "should",
"may", "recommended", or "optional" can be ignored. The BRs become
much clearer if you simply remove all the text that uses these words.
This is why I recommended that they be amended if there is a desire
that CAs be required to do something currently allowed to be ignored.

Thanks,
Peter

[tech...@gmail.com]

On Friday, May 20, 2016 at 6:22:21 PM UTC-7, Peter Bowen wrote:
> [ Disclaimer: This message is my personal view and does not
> necessarily represent that of my employer. ]
>

Peter, once again you are ignoring the full language of BR 4.9.2 to 4.10.2. These CA requirements are not limited to reports of "misuse" submitted to a CA, but apply to reports of "suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates."

So please don't try to limit this conversation to what is "misuse" -- that's just inaccurate for defining a CA's obligations. We as CAs need to be protecting users once we receive Certificate Problem Reports of certs being used for malware injection.

4.9.2: Anyone can submit “Certificate Problem Reports” to the issuing CA. That includes “Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.”

4.9.3: “Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates”

4.9.5: “The CA SHALL begin investigation of a Certificate Problem Report within twenty-four hours of receipt, and decide whether revocation or other appropriate action is warranted based on at least the following criteria:

1. The nature of the alleged problem;
2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
3. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that she didn’t receive the goods she ordered); and

4. Relevant legislation.”

Section 4.10.2: "The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint."

[Richard Z]

they do. You can argue that in absence of crime friendly providers the
criminals have other methods but having rogue providers certainly
makes their business easier.

There should be some reasonable middle ground. CAs can not be responsible
for the contents served by their clients servers. However, CAs also must
not knowingly or by gross negligence support malicious operations.

[Eric Mill]

On Sat, May 21, 2016 at 12:04 PM, <tech...@gmail.com> wrote:
>
> Peter, once again you are ignoring the full language of BR 4.9.2 to
> 4.10.2. These CA requirements are not limited to reports of "misuse"
> submitted to a CA, but apply to reports of "suspected Key Compromise,
> Certificate misuse, or other types of fraud, compromise, misuse, or
> inappropriate conduct related to Certificates."
>
> So please don't try to limit this conversation to what is "misuse" --
> that's just inaccurate for defining a CA's obligations.

No one's limiting the conversation. This is the conversation that was
requested. Here are Kathleen's 5 questions:

> 1) What does "Certificate misuse, or other types of fraud" in the
definition of Certificate Problem Report actually mean?

Your citing of language that says "suspected Key Compromise, Certificate

misuse, or other types of fraud, compromise, misuse, or inappropriate

conduct related to Certificates." doesn't answer this question. It just
brings the question up again.

You clearly feel it necessarily includes malware injection, and believe
that this is the general consensus among CAs. Peter is telling you he
doesn't read it that way, and Kathleen is asking for clarification from the
community because it's not obvious to Mozilla.

In 4.9.2 to 4.10.2, every provision you list includes room for CA
discretion and independent judgment.

That discretion and independent judgment is also free to be fully encoded
in software, rather than requiring a human on the line per-request. That
software could encode a definition of "certificate misuse, or other types
of fraud" that is different than yours.

> 2) What does "misused" mean in Section 4.9.1.1?
> 3) If a website is using its SSL certificate to mask injection of malware

and evidence of that is presented to the issuing CA, is that sufficient
misuse for the CA to be required to revoke the certificate?

Everything I said above also applies to these two questions. It is up to
the CA

> 4) Does a website who is known to an issuing CA to inject malware count
as high risk?

As written, completely up to the CA. General consensus among the leaders of
some large CAs about how to interpret this question does not make a binding
definition.

> 5) Are CAs required to maintain a list/database to prevent issuance of

SSL certificates for websites that are known to them to inject malware?

Even were policing malware a requirement of the BRs or EVG, implementation
details of how to do that seem out of scope.

On Sat, May 21, 2016 at 12:04 PM, <tech...@gmail.com> wrote:

> We as CAs need to be protecting users once we receive Certificate Problem
> Reports of certs being used for malware injection.
>

And CAs who wish to do that are completely free to. Whether all CAs are
required to be malware police is, clearly, a matter of debate created by
vague wording in the BRs.

The language was probably intentionally vague, so as to give CAs some
flexibility in explaining to auditors how their controls meet the Baseline
Requirements. That's okay -- laws (the better ones, anyway) are generally
intentionally written to be vague, to futureproof the text and to allow
some level of private sector and federal agency implementation and
discretion.

And do you really want a maximalist reading of the BR text?

The BR language as written includes the phrase "inappropriate conduct". Do
you really think individual certificate authorities should be required to
police a broad definition of "inappropriate conduct" online? In my opinion,
that phrase should be stricken from the BRs immediately, but while it's in
there, I would hope it would be interpreted as narrowly as possible.

People should really heed Andrew Ayer's post about the practical
difficulties of operating a commercial certificate business with the way
many CAs currently design their review processes to hold on "risky"
certificates: "Without exception, every time has been a false positive."

In my work capacity, I actually had such an experience with Andrew's
business myself, documented on a public thread:
https://github.com/SSLMate/sslmate/issues/7

Andrew patiently worked with our team through delays from one CA because
our certificate had ".gov" in it, and a second CA that flagged the word
"treasury". Apparently no domain that uses the lower-case English word
"treasury" should enjoy the cost, security, and operational benefits of
inexpensive automatic issuance premised entirely on technical controls, and
nor should any office in US federal, state, or local government.

That's just my own little parochial issue -- again, at global scale, a
broad interpretation of "misuse" and "inappropriate conduct" are so much
more harmful than any single experience one of us is likely to have as a
customer.

CAs can always exercise judgment and vigorously watch for malware use among
their certificates -- it can even be something they compete on. But Mozilla
and the web PKI community should avoid, wherever possible, placing
requirements on CAs to be gatekeepers.

-- Eric

[Jason -]

On Wednesday, May 18, 2016 at 6:22:39 PM UTC+3, Peter Bowen wrote:

> On Wed, May 18, 2016 at 7:16 AM, Gervase Markham <ge...@mozilla.org> wrote:
> > I think the bullet as a whole could mean that we reserve the right to
> > not include CAs who happily issue certs to "www.paypalpayments.com" to
> > just anyone without any checks or High Risk string list or anything.
> > Such a cert, unless issued to Paypal, Inc., is clearly to be used for
> > fraud, IMO, and a CA is negligent in issuing it given that it's not hard
> > to flag for manual review any cert containing the names of major banks
> > and payment companies.
>

> Playing Devil's Advocate for a moment, if paypalpayments.com is a
> valid registered domain and is owned by A Better World LLC (a Delaware
> Corporation), why should they not be able to get a certificate for
> their domain?
>
> How far do you take it? According to
> http://brandirectory.com/league_tables/table/banking-500-2014, top
> bank brands include "TD", "UBS", and "ING", should CAs block on
> "outdoor.sh", "nightclubs.io", and "exceeding.ly"?
>
> Why should Hong Kong and Shanghai Banking Corporation be considered to
> have claim to HSBC than the Humane Society of Broward County, the
> House Small Business Committee, or Hobe Sound Bible College?
>
> Given that there is already the ICANN UDRP, shouldn't that be the
> venue to decide who is authorized to have what domain names? Should
> CAs be responsible for making calls on who is authorized for a domain
> name?
>
> Thanks,
> Peter

I will also add a classical example that used to exist there: gmail.de

[Ryan Sleevi]

On Friday, May 20, 2016 at 10:24:56 AM UTC-7, Andrew Ayer wrote:
> In fact, Kathleen asked explicitly for what the answers "should be" in
> addition to what they are, so my email was not unrelated. To be more
> explicit, I think the answers to questions 3-5 should be no. The
> reason why is explained in my email: requiring CAs to be responsible
> for content has unintended negative effects on HTTPS adoption. I
> think that causes more harm than good to Internet security.

At the risk of "me too," I think Andrew and Eric have properly captured the concerns, and agree with their conclusions.

I do not believe the "should" answers should encompass or include "malware," a phrase which is necessarily subjective and subject to interpretation. For example, if a piece of software may be illegal within a local jurisdiction, does it constitute malware? If the issuing CA is in an independent jurisdiction that disagrees with that local jurisdiction, is the CA obligated to revoke such a certificate?

The dangers to policing content are well known and well understood. In the promotion of more encrypted communications, we should not let the ambitions of some CAs to be Internet judges get in the way.

[tech...@gmail.com]

Ryan, here is a related question (a serious inquiry, not argument). A number of people on this discussion have said "responding to Certificate Problem Reports should not be the job of a CA. Instead, the public (or the CA?) should just report a site to Google Safe Browsing and Microsoft SmartScreen and be done with it."

Here's my question -- what do Google and Microsoft do with such reports? Do they investigate and then put a site on the "bad" list, eg, for injecting malware? If not, then no one will stop the malware site. If yes -- what criteria does Google (and Microsoft, etc.) use to put the site on your bad list?

It seems the problem of "what is malware, what is phishing, what is abuse" must be decided by someone. My opinion is that CAs at least have to try (set up a meaningful process, and respond to complaints by following the process, and in some cases revoking), and not just defer all action to browsers.

So speaking generally (not asking for trade secrets), what criteria does Google use to put a site on its Safe Browsing list? And how does Google deal with the issue of what are bad sites (as you know, Google's decisions feed back into the CA loop - many CAs will use a listing on Google Safe Browsing as a reason to refuse to issue any more certs to a user). And does Safe Browsing have a method by which a site can appeal and get off the list?

[Ryan Sleevi]

On Tue, May 24, 2016 at 10:25 AM, <tech...@gmail.com> wrote:
> Here's my question -- what do Google and Microsoft do with such reports? Do they investigate and then put a site on the "bad" list, eg, for injecting malware? If not, then no one will stop the malware site. If yes -- what criteria does Google (and Microsoft, etc.) use to put the site on your bad list?

https://www.microsoft.com/security/portal/mmpc/shared/objectivecriteria.aspx
https://www.google.com/transparencyreport/safebrowsing/faq/?hl=en#how-do-you-determine-that-a-site-is-unsafe

> It seems the problem of "what is malware, what is phishing, what is abuse" must be decided by someone. My opinion is that CAs at least have to try (set up a meaningful process, and respond to complaints by following the process, and in some cases revoking), and not just defer all action to browsers.

Unsurprisingly, I disagree. We're debating whether the ability to have
encryption - which provides an incredibly value service against
network level attackers - should be coupled with trust. Coupling
certificates to this can do greater HARM than good - imagine a
download site that provides general purpose file hosting from users,
and one user happens to upload malware. If you revoke that
certificate, you introduce active harm to all the good files being
downloaded.

Further, the distinction between "Why is it different from browsers"
is the ability for the end user to have choice. The end user can't
change the site's certificate.

> And does Safe Browsing have a method by which a site can appeal and get off the list?

While I'm sure your curiosity is real, it remains unclear how or why
that relates. The information can also be obtained independently, so
perhaps you could clarify how/why it relates to this topic? Otherwise,
I might suggest you read the above links.

[Richard Z]

On Wed, May 25, 2016 at 01:09:53AM -0700, Ryan Sleevi wrote:
> On Tue, May 24, 2016 at 10:25 AM, <tech...@gmail.com> wrote:
> > Here's my question -- what do Google and Microsoft do with such reports? Do they investigate and then put a site on the "bad" list, eg, for injecting malware? If not, then no one will stop the malware site. If yes -- what criteria does Google (and Microsoft, etc.) use to put the site on your bad list?
>
> https://www.microsoft.com/security/portal/mmpc/shared/objectivecriteria.aspx
> https://www.google.com/transparencyreport/safebrowsing/faq/?hl=en#how-do-you-determine-that-a-site-is-unsafe
>
> > It seems the problem of "what is malware, what is phishing, what is abuse" must be decided by someone. My opinion is that CAs at least have to try (set up a meaningful process, and respond to complaints by following the process, and in some cases revoking), and not just defer all action to browsers.
>
> Unsurprisingly, I disagree. We're debating whether the ability to have
> encryption - which provides an incredibly value service against
> network level attackers - should be coupled with trust.

imho it is debattable whether https-everywhere is worth any tradeoffs
in CA requirements. If any criminal can easily get EV certificates what
is the point of https?

> .... Coupling

> certificates to this can do greater HARM than good - imagine a
> download site that provides general purpose file hosting from users,
> and one user happens to upload malware. If you revoke that
> certificate, you introduce active harm to all the good files being
> downloaded.

How is any harm done here - with or without certificate you have not
the slightest assurance that any of the files is "good"?

However, when visiting my home-banking site I indeed want the assurance
that the site owning the EV certificate takes full responsibility
for all content.

> Further, the distinction between "Why is it different from browsers"
> is the ability for the end user to have choice. The end user can't
> change the site's certificate.

You can choose to accept any certificate of any site if you think
you want to trust the site whether or not it has been issued by a CA.
One of my banks did deliberately provide a self signed certificate
(without any CA validation) and asked customers to verify the certificate
by comparing the fingerprint with a hardcopy sent by surface mail.

[tech...@gmail.com]

On Wednesday, May 25, 2016 at 10:10:35 AM UTC+2, Ryan Sleevi wrote:

Ryan, I was only responding to your prior comments as follows:

"I do not believe the "should" answers should encompass or include "malware," a phrase which is necessarily subjective and subject to interpretation. For example, if a piece of software may be illegal within a local jurisdiction, does it constitute malware? If the issuing CA is in an independent jurisdiction that disagrees with that local jurisdiction, is the CA obligated to revoke such a certificate"

"The dangers to policing content are well known and well understood. In the promotion of more encrypted communications, we should not let the ambitions of some CAs to be Internet judges get in the way"

If I understand you correctly, you are saying that CAs should not be doing any "internet policing" or "content policing" when they receive credible reports their certs are being used by phishers, malware providers, etc. -- but that browsers can and should do "internet policing" or "content policing" when they blacklist sites on such applications as Google Safe Browsing and Microsoft Smart Screen -- am I stating that correctly? If so, I was not the one to introduce the topic to this string.

Plus -- I don't agree this string is about promoting encryption only. Kathleen started by asking for interpretation of existing BR language that requires CAs to revoke and/or non-issue for things like "Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates."

Why should CAs delegate to or rely on browsers for this type of user protection? Isn't it better for CAs to remain involved by revoking certs / refusing to issue certs to known bad sites, like CAs have done for at least the past 8 years - why change that now? Why can't both CAs and browsers work together for maximum user protection?

[Eric Mill]

On Wed, May 25, 2016 at 9:50 AM, <tech...@gmail.com> wrote:

>
> Why should CAs delegate to or rely on browsers for this type of user
> protection? Isn't it better for CAs to remain involved by revoking certs /
> refusing to issue certs to known bad sites, like CAs have done for at least
> the past 8 years - why change that now? Why can't both CAs and browsers
> work together for maximum user protection?
>

Because users use browsers (and choose them). Users don't choose what
certificates or CAs sites use. So users have no recourse if the CA is
taking an inappropriate action, and no strong market signal gets sent to
CAs about the appropriateness of their actions.

In any case, the question here isn't whether CAs should be *forbidden* from
revoking certificates for malware, it's whether they should be *required*
to. Requiring every CA to become content/malware police is extreme. The
only reasons it hasn't felt extreme to CAs until recently is because the
customer base was much smaller and more homogeneous than it's becoming
today, and certificates were not yet becoming required to use the full
featureset of the web.

-- Eric


> _______________________________________________

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



--

konklone.com | @konklone <https://twitter.com/konklone>

[Richard Z]

On Wed, May 25, 2016 at 11:54:50AM -0400, Eric Mill wrote:
> On Wed, May 25, 2016 at 9:50 AM, <tech...@gmail.com> wrote:
>
> >
> > Why should CAs delegate to or rely on browsers for this type of user
> > protection? Isn't it better for CAs to remain involved by revoking certs /
> > refusing to issue certs to known bad sites, like CAs have done for at least
> > the past 8 years - why change that now? Why can't both CAs and browsers
> > work together for maximum user protection?
> >
>
> Because users use browsers (and choose them). Users don't choose what
> certificates or CAs sites use. So users have no recourse if the CA is
> taking an inappropriate action, and no strong market signal gets sent to
> CAs about the appropriateness of their actions.

users do choose what CAs they use (or rather trust). On every new install
I spend a few minutes reviewing CAs and disabling several dozens of those
which I will never miss.

[Peter Gutmann]

Richard Z <r...@linux-m68k.org> writes:

>If any criminal can easily get EV certificates what is the point of https?

The point of HTTPS is twofold:

1. Convince users that the Internet is safe to do business on (financial
transfers, medical data).

2. Provide a steady revenue stream for CAs.

There's also something about privacy from NSA snooping, but that's a recent
thing, and mostly only geeks care about it. In addition depending on how
paranoid the geeks are, HTTPS may not provide the privacy they want).

Finally, point 1 doesn't really need HTTPS, you could just slap a padlock
into the UI and not bother with encryption. So it's mostly point 2.

Peter.

[Ryan Sleevi]

Peter,

This seems both off-topic and not productively addressing the topic at
hand. Further, your statements are a direct suggestion that Mozilla
Foundation does not adhere to its Manifesto or its principles -
https://www.mozilla.org/en-US/about/manifesto/ - and if that's your
position, perhaps you should take that conversation up directly with
Mozilla governance, rather than suggesting it as factual.

[Ryan Sleevi]

On Wed, May 25, 2016 at 6:50 AM, <tech...@gmail.com> wrote:
> If I understand you correctly, you are saying that CAs should not be doing any "internet policing" or "content policing" when they receive credible reports their certs are being used by phishers, malware providers, etc. -- but that browsers can and should do "internet policing" or "content policing" when they blacklist sites on such applications as Google Safe Browsing and Microsoft Smart Screen -- am I stating that correctly? If so, I was not the one to introduce the topic to this string.

As Eric pointed out, no, you are not understanding correctly. I was
merely addressing Kathleen's question about whether all CAs are
required to police, not whether some CAs can, if they so decide. I
don't believe CAs SHOULD police, but that's irrelevant to the more
substantial question - I don't believe CAs MUST police.

> Plus -- I don't agree this string is about promoting encryption only.

That's OK. It's clear we disagree about the value of privacy,
confidentiality, and integrity - which TLS provides. I believe these
three are valuable in and of themselves, and we must not sacrifice
them in order to also add 'brand protection'.

> Kathleen started by asking for interpretation of existing BR language that requires CAs to revoke and/or non-issue for things like "Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates."

And that's what I was responding to, but you then dove-tailed into an
unrelated discussion about how Microsoft/Google technologies work,
which doesn't seem as germane to the question.

> Why should CAs delegate to or rely on browsers for this type of user protection?

Because security works best when it's composed. Why should CAs
delegate encryption to TLS? Why shouldn't each CA come up with their
own encryption technology, and deploy it using browser plugins? Why
should CAs rely on DNS? Why shouldn't they come up with their own
naming schemes?

The answer is that different parties in the ecosystem have different
roles, and are best suited to different tasks. You've already heard,
several times, the answer to your question - because CAs content
policing themselves comes with real risks and harm. While some CAs
may, as part of their brand, choose to do content policing, site
operators have an easy recourse - simply don't use those CAs. The
market is flexible to permit that. Suggesting, however, that ALL CAs
must do so, implies that ALL CAs must share your values, and it's
clear that such a position can and does cause real harm.

> Isn't it better for CAs to remain involved by revoking certs / refusing to issue certs to known bad sites, like CAs have done for at least the past 8 years - why change that now? Why can't both CAs and browsers work together for maximum user protection?

This has already been responded to several times by participants on
the thread. I don't think it adds value to keep saying it, and it's
been said in a variety of ways that I don't think it bears restating.

[Hubert Kario]

On Thursday 26 May 2016 05:13:43 Peter Gutmann wrote:
> Richard Z <r...@linux-m68k.org> writes:
> >If any criminal can easily get EV certificates what is the point of
> >https?
> The point of HTTPS is twofold:
>
> 1. Convince users that the Internet is safe to do business on
> (financial transfers, medical data).
>
> 2. Provide a steady revenue stream for CAs.
>
> There's also something about privacy from NSA snooping, but that's a
> recent thing, and mostly only geeks care about it. In addition
> depending on how paranoid the geeks are, HTTPS may not provide the
> privacy they want).

people don't care only if you are asking the wrong questions[1], if you
frame the question in the way they do understand, they do care:
https://www.youtube.com/watch?v=XEVlyP4_11M

1 - https://www.youtube.com/watch?v=G0ZZJXw4MTA

> Finally, point 1 doesn't really need HTTPS, you could just slap a
> padlock into the UI and not bother with encryption. So it's mostly
> point 2.

I don't think that this level of cynicism is helping...

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[Hubert Kario]

[Peter Gutmann]

Ryan Sleevi <ry...@sleevi.com> writes:

>This seems both off-topic and not productively addressing the topic at hand.

Yeah, maybe it's best taken to another list like cypherpunks or the crypto
list. It was intended as an honest, and probably pretty blunt, assessment of
the state of HTTPS: It was introduced to build consumer, and merchant,
confidence in using the Internet for business, killing the competing SET in
the process, and it's succeeded in doing that. Once that was done, which
happened about 15-20 years ago, its main role became perpetuating the
existence of CAs. Apart from the lucky CAs who have been given government-
mandated monopolies, would any CA still exist today if there weren't a need to
pay someone to turn off the browser warnings?

Peter

[Gervase Markham]

On 27/05/16 13:20, Peter Gutmann wrote:
> Apart from the lucky CAs who have been given government-
> mandated monopolies, would any CA still exist today if there weren't a need to
> pay someone to turn off the browser warnings?

It depends what alternative configuration-free idiot-proof secure
communications technology you have invented in your fantasy world to
take its place.

Whatever the disadvantages of the current system, it must be recognised
that it provides the ability for every single Internet user to have
their communications with any website that opts-in encrypted on the wire
without them having to do, know or configure _anything_. That's huge.

Gerv

[Peter Gutmann]

Gervase Markham <ge...@mozilla.org> writes:

>It depends what alternative configuration-free idiot-proof secure
>communications technology you have invented in your fantasy world to take its
>place.

Are you really trying to claim that the sad farce that is current browser PKI
is absolutely the very best that browser vendors can do in terms of protecting
users online?

>Whatever the disadvantages of the current system, it must be recognised that
>it provides the ability for every single Internet user to have their
>communications with any website that opts-in encrypted on the wire without
>them having to do, know or configure _anything_. That's huge.

So would straight anon-DH. In fact it's interesting to compare the two: Anon-
DH provides encryption on the wire, as does browser PKI. Anon-DH has no
effect on phishing, but then neither does browser PKI. The one thing that
anon-DH doesn't handle is MITM while browser PKI often does, but then again
anon-DH allows automatic, transparent crypto everywhere without having to mess
around with certificates while browser PKI requires it, so let's call that one
a draw depending on which one you consider more important.

In terms of "configuration-free idiot-proof secure communications technology",
the answer is "pretty much anything but browser PKI". Skype, WhatsApp,
Signal, Silent Circle (just off the top of my head, I can google several pages
worth of others if you like) all do a pretty good job of providing secure,
mutually authenticated communications (which browser PKI still can't do thanks
to the failure to launch of client certs) without needing any PKI. Just for
one single example, WhatsApp, about a billion or so nontechnical users have no
problems with secure communications.

Peter.

[Gervase Markham]

On 29/05/16 11:48, Peter Gutmann wrote:
> Are you really trying to claim that the sad farce that is current browser PKI
> is absolutely the very best that browser vendors can do in terms of protecting
> users online?

I'm sure things can always be better. My point was that the current
system, for all its flaws, prevents a great deal of evil in a way which
is pretty much totally transparent to users. And that's a big benefit.
We may find, like people find when they analyse passwords and the
alternatives to them, that actually what we have now has some important
features it's hard to replicate in other systems.

>> Whatever the disadvantages of the current system, it must be recognised that
>> it provides the ability for every single Internet user to have their
>> communications with any website that opts-in encrypted on the wire without
>> them having to do, know or configure _anything_. That's huge.
>
> So would straight anon-DH. In fact it's interesting to compare the two: Anon-
> DH provides encryption on the wire, as does browser PKI. Anon-DH has no
> effect on phishing, but then neither does browser PKI. The one thing that
> anon-DH doesn't handle is MITM

Oh, a tiny and trivial difference. After all, the one thing we've
learned over the past 3 years or so is that the network is generally
secure and trustworthy, right?

> In terms of "configuration-free idiot-proof secure communications technology",
> the answer is "pretty much anything but browser PKI". Skype, WhatsApp,
> Signal, Silent Circle (just off the top of my head, I can google several pages
> worth of others if you like) all do a pretty good job of providing secure,
> mutually authenticated communications (which browser PKI still can't do thanks
> to the failure to launch of client certs) without needing any PKI.

And all have a single point of failure. It's much easier, I agree, to do
what WhatsApp did and deploy encryption to every single user if there's
a central controlling entity. (And Signal is moving that way for
precisely that reason, as perhaps you know.) Doing it in a mechanism
over which no party has total control is much harder - but yet, this is
a key and non-negotiable value of the web.

Gerv

[Richard Z]

On Mon, May 30, 2016 at 09:42:00AM +0100, Gervase Markham wrote:
> On 29/05/16 11:48, Peter Gutmann wrote:

> > Are you really trying to claim that the sad farce that is current browser PKI
> > is absolutely the very best that browser vendors can do in terms of protecting
> > users online?
>

> I'm sure things can always be better. My point was that the current
> system, for all its flaws, prevents a great deal of evil in a way which
> is pretty much totally transparent to users. And that's a big benefit.

IMO it is too much of transparency for my taste, too much is going under
the hood which is important and nobody notices. The complexity of the
system is too much to think that total transparency can be safe.

The current "total transparency" paradigm makes it too easy for
webmasters to do bad security and very hard for users to do
additional verification. As an example for important sites I want
the possibility to manually pin the certificates and manually
verify them. The CertPatrol addon gives me the theoretical ablility
to do it but in practice this is an extreme annoyance as some
important sites use so many domains and renew certificates so
often that it is impossible to keep track of it.