RE: CSV Format of CA Program reports

[Miskovic Peter]

Hi Rob,



there are two intermediate certification authorities on your missing list (CA 
Disig I2 Certification Service and CA Disig I1 Certification Service) which are 
no more capable to issue a new SSL certificate and which are no more directly 
chain to a certificate included in Mozilla's CA Certificate Program.

According to the Mozilla CA Certificate Inclusion Policy (Version 2.2):

"All certificates that are capable of being used to issue new certificates, and 
which directly or transitively chain to a certificate included in Mozilla's CA 
Certificate Program, MUST be operated in accordance with Mozilla's CA 
Certificate Policy and MUST either be technically constrained or be publicly 
disclosed and audited."



The root for that intermediates (CA Disig) was removed from Mozilla's CA 
Certificate Program (see https://bugzilla.mozilla.org/show_bug.cgi?id=1247711) 
due the expiration.



Regards

Peter Miskovic

-
Peter Miskovic
CA Chief Operating Officer

Disig, a.s., Zahradnicka 151, 821 08 Bratislava 2, Slovakia
phone  +421 2 20 85 01 50

peter.misko...@disig.sk
www.disig.sk











-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+peter.miskovic=disig...@lists.mozilla.org] 
On Behalf Of Rob Stradling
Sent: Tuesday, May 17, 2016 12:31 AM
To: Kathleen Wilson ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CSV Format of CA Program reports



Thanks Kathleen.



PublicAllIntermediateCertsCSV is missing quite a few entries compared to my own 
CSV export of the "All Public Intermediate Certs" report.



I've reviewed the differences.  It looks like you're now omitting incomplete 
records and records for intermediates that didn't actually need to be 
disclosed.  I presume this is deliberate change, and I think it makes sense.



In case anyone's interested, here's a list of the currently disclosed 
intermediates that aren't in PublicAllIntermediateCertsCSV:

https://docs.google.com/spreadsheets/d/1nd2ie-JsS2CxMOX5nBGQgQEelhmkq-OcTKkvCe4U42Q/edit?usp=sharing



One oddity: Some intermediates (e.g. https://crt.sh/?id=17014784) contain the 
EKU extension with the MS SGC and/or NS Step-Up OIDs and _not_ 
id-kp-serverAuthentication.  The policy says that these don't need to be 
disclosed, but Firefox does trust them as issuers of server authentication 
certs.



On 16/05/16 19:27, Kathleen Wilson wrote:

> The new reports are at the following new links. A couple columns were added: 
> 'Parent Name', 'SHA-256 Fingerprint'.

>

> https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCert

> s

> https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCert

> sCSV

>

> I have also updated the links in wiki page.

> https://wiki.mozilla.org/CA:SubordinateCAcerts

>

> Thanks,

> Kathleen



--

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

[Peter Gutmann]

Matt Palmer  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.
___
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

[Charles Reiss]

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.



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

Re: CSV Format of CA Program reports

[Kathleen Wilson]

On Monday, May 16, 2016 at 3:31:56 PM UTC-7, Rob Stradling wrote:
> 
> One oddity: Some intermediates (e.g. https://crt.sh/?id=17014784) 
> contain the EKU extension with the MS SGC and/or NS Step-Up OIDs and 
> _not_ id-kp-serverAuthentication.  The policy says that these don't need 
> to be disclosed, but Firefox does trust them as issuers of server 
> authentication certs.
> 

Good point.

https://bugzilla.mozilla.org/show_bug.cgi?id=982932
"Check issuance date of intermediate certificate in effort to obsolete SGC EKU"
Target Milestone: mozilla49 

So, old intermediate certs like that should not be marked technically 
constrained. New intermediate certs that have the SGC EKU and not 
id-kp-serverAuthentication will not validate in Firefox 49 or later, so those 
may be treated as technically constrained.

Thanks,
Kathleen
___
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

[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

___
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

[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

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

Re: CSV Format of CA Program reports

[Rob Stradling]

Thanks Kathleen.

PublicAllIntermediateCertsCSV is missing quite a few entries compared to 
my own CSV export of the "All Public Intermediate Certs" report.


I've reviewed the differences.  It looks like you're now omitting 
incomplete records and records for intermediates that didn't actually 
need to be disclosed.  I presume this is deliberate change, and I think 
it makes sense.


In case anyone's interested, here's a list of the currently disclosed 
intermediates that aren't in PublicAllIntermediateCertsCSV:

https://docs.google.com/spreadsheets/d/1nd2ie-JsS2CxMOX5nBGQgQEelhmkq-OcTKkvCe4U42Q/edit?usp=sharing

One oddity: Some intermediates (e.g. https://crt.sh/?id=17014784) 
contain the EKU extension with the MS SGC and/or NS Step-Up OIDs and 
_not_ id-kp-serverAuthentication.  The policy says that these don't need 
to be disclosed, but Firefox does trust them as issuers of server 
authentication certs.


On 16/05/16 19:27, Kathleen Wilson wrote:

The new reports are at the following new links. A couple columns were added: 
'Parent Name', 'SHA-256 Fingerprint'.

https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCerts
https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCertsCSV

I have also updated the links in wiki page.
https://wiki.mozilla.org/CA:SubordinateCAcerts

Thanks,
Kathleen


--
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: CSV Format of CA Program reports

[Kathleen Wilson]

On Monday, May 16, 2016 at 11:27:21 AM UTC-7, Kathleen Wilson wrote:
> The new reports are at the following new links. A couple columns were added: 
> 'Parent Name', 'SHA-256 Fingerprint'.
> 
> https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCerts
> https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCertsCSV
> 
> I have also updated the links in wiki page.
> https://wiki.mozilla.org/CA:SubordinateCAcerts
> 


We've added another report that is the CSV report plus the PEM data.

https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCertsWithPEMCSV
 

The link is also available from the wiki page.

Note that all 3 of these reports will be generated once every 24 hours as a 
batch process.

Kathleen

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

Re: Disclosure of intermediates that chain to multiple roots

[Rob Stradling]

On 13/05/16 22:09, Richard Barnes wrote:


Thanks for explaining the specifics, Rob.  To restate and check my
understanding, this is a "Y-shaped" scenario, with the following CAs (by
CN):

(1) AddTrust External CA Root (included, owned by Comodo)
(2) UTN-USERFirst-Hardware (included, owned by Comodo)
(3) Network Solutions Certificate Authority (included, owned by Web.com)
(4) Network Solutions EV Server CA

... and the following certificates (in graphviz notation):

digraph {
  1 -> 3;
  2 -> 3;
  3 -> 3;
  3 -> 4;
}

And the question is who needs to disclose the (3->4) certificate.


Yes, that's my question.


FWIW Rob has exactly specified what I, as a relying party, would want

Mozilla to do on my behalf although I would interpolate ("... and audited")
each time he mentions disclosure.



This seems like a pretty sensible policy to me.  One could consider it as
parallel to a hypothetical non-cross-signed scenario where the root relies
on the intermediate to disclose its subtree, then the root discloses the
intermediate.



I agree with him that the current policy does not clearly state this.



The current policy has the blessing / curse of using the passive voice
("...MUST either be technically constrained or be publicly disclosed and
audited."), which obscures which agent must do the disclosing.  But that
also means (ISTM) that Rob's suggested resolution is consistent with the
policy.  As long as the subordinate below the cross-signed intermediate is
disclosed, it doesn't matter who disclosed it; but if it's not, then all
the cross-signers are out of compliance.


I agree that my suggested resolution is consistent with the Mozilla CA 
Policy.


However, it seems to be inconsistent with what Mozilla's recent CA 
Communication requires CAs to do by the end of June (emphasis mine):
"ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate 
Policy, for any certificate which directly or transitively chains to the 
root certificates you currently have included in Mozilla's CA 
Certificate Program, which are capable of being used to issue new 
certificates, and which are not technically constrained as described in 
Section 9 of Mozilla's CA Certificate Inclusion Policy, *you are 
required* to provide public-facing documentation about the certificate 
verification requirements and annual public attestation of conformance 
to said requirements. *This includes certificates owned by, operated by, 
or issued by third parties, whether or not those issuing certificates 
are already part of Mozilla's CA Certificate Program, if they have been 
cross-signed by a certificate that directly or transitively chains to 
your root certificate.*
To facilitate this public disclosure, Mozilla is requiring that these 
certificates, as well as their CP/CPS and audit statements, be entered 
into Mozilla's CA Community in Salesforce."


I see that Kathleen has added the following text to 
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_Currently_in_Discussion
"Update transitive disclosure policy to reduce duplication of full CA 
hierarchies
Update section 8 of Mozilla's CA Certificate Inclusion policy to say 
that transitive disclosure is not required when the subject of the 
CA-certificate is also the subject of a certificate included directly in 
the Mozilla trust store."


However, ISTM that a "proposed change currently in discussion" is less 
authoritative than the CA Communication (which, as I've said, seems to 
explicitly require multiple disclosures of the same intermediate when 
multiple trust paths exist).


Assuming everyone's happy with my suggested resolution, please would you 
update the requirements for "ACTION #2" before the end of June (the 
earlier the better!) so that multiple disclosures are not required?


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

[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


--
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: CSV Format of CA Program reports

[Kathleen Wilson]

The new reports are at the following new links. A couple columns were added: 
'Parent Name', 'SHA-256 Fingerprint'.

https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCerts
https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCertsCSV

I have also updated the links in wiki page.
https://wiki.mozilla.org/CA:SubordinateCAcerts

Thanks,
Kathleen

___
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

[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


___
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

[Ben Wilson]

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


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

Re: SSL Certs for Malicious Websites

[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

___
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

[Peter Bowen]

On Mon, May 16, 2016 at 6:06 AM, Rob Stradling  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
___
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

[Rob Stradling]

On 16/05/16 01:43, 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:


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

___
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

[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

___
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

[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

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

Re: March 2016 CA Communication Responses

[Rob Stradling]

On 15/05/16 07:39, Charles Reiss wrote:

On 04/13/16 20:32, Kathleen Wilson wrote:

All,

I have added links to reports of the responses to the March 2016 CA
Communication survey:

https://wiki.mozilla.org/CA:Communications#March_2016_Responses


For question 1a, TeliaSonera indicated "2015 Oct 20", but the following
SHA-1 server certificate has a notBefore of 17 March 2016 and appears to
chain to TeliaSonera Root v1:
https://censys.io/certificates/ff7f4a0f23205127347018555628b05d11a355ed92e9aa59d5eabda750f0f622


Hi Charles.

See also https://crt.sh/?id=15647440
(This page failed to display the certificate details until I fixed a bug 
just now, which could explain why you quoted the Censys page instead ;-) )


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