Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[sanjay_modi]

We used SHA1 and SHA2 in signing algorithm to sign end-entity SMIME 
certificates. SHA2 is the current practice for new end-entity SMIME 
certificates. We will be stopping SHA1 ICA usage by the end of 2016 for SMIME. 
We plan to use a new ICA that has a compliant EKU to issue SMIME certificates 
by the end of 2016.

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

Re: ISRG Root Inclusion Request

[Jason -]

Kathleen, what is the progress here? Are any queries left over?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When does Technically Constrained != Technically Constrained?

[Rob Stradling]

On 23/05/16 22:41, Richard Barnes wrote:

On Mon, May 23, 2016 at 5:28 PM, Rob Stradling wrote:



Why invent a new thing?


Even if we make an old thing new, there's still the transition :)


That's true, but it would be an easier transition.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Eric Mill]

On Sat, May 21, 2016 at 12:04 PM,  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,  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,