Re: Mozilla's Expectations for OCSP Incident Reporting

Browsers by default just ignore any OCSP error. So while the browser might have seen an error getting the OCSP reply, the user is not aware of it. And why Browsers do ignore OCSP errors? Because some CA don't take OCSP errors seriously. So yes, it has an impact: it comfort Browsers in that

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

e decision-making for the participants in our study interms of user trust in a web site. These new identity indicators were ineffectivebecause none of the participants even noticed their existence." http://citeseerx.ist.psu.edu/viewdoc/download?doi=

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

are also studies that indicate users don't pay attention to the (positive) security indicators. To phish users, it's unnecessary to get an EV indicator vs a DV indicator. The simpler explanation for the correlation is that EV is more expensive (both in direct c

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

On Thu, Aug 15, 2019, 7:46 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Peter, > > Do you have any empirical data to backup the claims that there is no > benefit > from EV certificates? From the reports I've seen, the percentage of > phishing and

Re: Use of Certificate/Public Key Pinning

anchor, and operate a root CA oneself, managing it as one would a public CA (offline root, possibly offline intermediates, etc) -tom On Tue, 13 Aug 2019 at 15:12, Nuno Ponte via dev-security-policy wrote: > > Dear m.d.s.p., > > I would like to bring into discussion the use of certif

Re: Mitigating DNS fragmentation attacks

that is not available to everyone, a comprehensive solution is also desirable. -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Possible violation of CAA by nazwa.pl

Thanks Jakob, I think you summed things up well. -tom On 27 July 2018 at 01:46, Jakob Bohm via dev-security-policy wrote: > On 26/07/2018 23:04, Matthew Hardeman wrote: >> >> On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy < >> dev-security-policy@

Re: Possible violation of CAA by nazwa.pl

> The party actually running the authoritative DNS servers is in control of the domain. I'm not sure I agree. They can control the domain, but they are supposed to be subordinate of the domain owner. If they did something without the owner consent/approval, it really looks like a domain

Re: Possible violation of CAA by nazwa.pl

hink those are two very difference cases. If you initiated it, they didn't CAA (because they weren't required to.) If you didn't... isn't that a rogue issuance? -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Submission to ct-logs of the final certificate when there is already a pre-certificate

Following the discussion on https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394 What is the position of Mozilla about the submission to ct-logs of the final certificate when there is already a pre-certificate? As it helps discover bugs (

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

cates signed by this root. -- Tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

Le 15/03/2018 à 20:04, Wayne Thayer a écrit : This incident, and the resulting action to "integrate GlobalSign's certlint and/or zlint into our existing cert-checker pipeline" has been documented in bug 1446080 [1] This is further proof that pre-issuance TBS certificate linting (either by

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

rather than creating test certificates. -- Tom Prince ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

> During final tests for the general availability of wildcard certificate support, the Let's Encrypt operations team issued six test wildcard certificates under our publicly trusted root: > > https://crt.sh/?id=353759994 > https://crt.sh/?id=353758875 > https://crt.sh/?id=353757861 >

Re: Trustico code injection

> Therefore, it is not unreasonable to assume that this key has been > compromised. So it means that any private keys generated on that website could be compromised: - If any third-party JS were compromised (and we know how insecure js-based ads are - last time it was a crypto miner on

Re: How do you handle mass revocation requests?

tes through crt.sh or through a manual cert search? (Some special Intermediate/CRL/OID/string...?) Has Trustico said anything about whether or not they will provide more information in the future? -tom ___ dev-security-policy mailing list d

Re: Allowing WebExtensions to Override Certificate Trust Decisions

sign a cert saying "No really, I just want you to include this weird data under this weird not-documented/not-standardized x509 extension". Unless people show up claiming that that functionality is sufficient for them to do things they want to do; I don't think it would be valuable to impl

Re: Investigating validations & issuances - The high value IP space BGP Hijacks on 2017-12-12

This is an extremely good point. I wonder: 1. If Mozilla should ask/require CAs to perform this check. 2. If Mozilla should ask/require CAs to invest in the capability to make this check for future requests in the future (where we would require responses within a certain time period.) -tom

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

It can be confusing even for people following these things. That's where I think collecting problem reporting info from audited sub-CAs in CCADB would help. For everyone else, finding the correct problem reporting information is mostly a matter of luck. Perhaps we should require an email address

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

The thing is, extraneous names on a certificate present a subtle security flaw, even if control over those names was validated properly I agree, if the user is not fully aware of these addition, it can add subtle security flaw such as "virtual host confusion attacks" (

Re: Possible future re-application from WoSign (now WoTrus)

Nevertheless, WoTrus is (presumably) a commercial operation. Whoever owns that organization bought or built it with an expectation of at least the possibility of commercial success (profit). The organization's long term success requires inclusion in major root programs. For information,

Re: Certificate with invalid dnsName

Following that discovery, I've search for odd (invalid?) DNS names. Here is the list of certificated I've found, it may overlap some discovery already reported. If I'm correct, theses certificate are not revoked, not expired, and probably trusted by Mozilla (crt.sh issuer are marked trusted by

Re: Certificate with invalid dnsName issued from Baltimore intermediate

The "www..*" search is also intersting, I think: https://crt.sh/?dNSName=www..%25 crt.sh IDLogged At ⇧ Not Before IdentityIssuer Name 397448732016-10-02 2012-12-29 www..coinfling.com 386479982016-10-01 2011-03-24

Re: P-521

e code most likely (unless we were particularly clever about not hitting those code paths until after the user trusted a self-signed cert.) -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

that a newly issue certificate for the same domain will not be used in the exact same way. Is it reasonable for us to ask a CA to do this (that is, to ask their customer)? Is it reasonable to require it? -tom ___ dev-security-policy mailing list d

Re: Appropriate role for lists of algorithms and key sizes

Le 07/02/2017 à 05:01, Patrick Figel a écrit : > On 27/01/2017 19:53, Ryan Sleevi wrote: >> On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham wrote: >>> >>> * RSA keys with a minimum modulus size of 2048 bits >>> >> >> Nits and niggles: Perhaps 2048, 3072, 4096? >> >> - 8K RSA

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

" must be avoided before all. And the logical way to do it in my opinion is in the Mozilla CA Certificate Policy. Tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

According to The Uniform Domain-Name Dispute-Resolution Policy, letsencrypt.cn seem use in bad faith. On December 20, 2016 2:45:47 PM GMT+08:00, "谭晓生" wrote: >It is ICP license you talked about, you can find some information here:

Re: CA Public Key Material

On December 15, 2016 10:46:31 AM GMT+08:00, Tavis Ormandy wrote: >test.wgh.cn no longer resolves, but wgh.cn is the personal blog of a >WoSign employee. Uh... It is blog of Wosign CEO Wang Gaohua(aka Richard Wang). >Is it possible key material was accidentally used in a web

Re: Mozilla CT Policy

a should run a DNS log query front-end to provide diversity from Google's. -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

On 4 November 2016 at 07:19, Gervase Markham wrote: > * How do we decide when to un-trust a log? What reasons are valid > reasons for doing so? Do we want different types of distrust for a log? That is, a "We don't trust you at all anymore" distrust vs a "We don't trust

Re: Cerificate Concern about Cloudflare's DNS

before taking action. I would imagine that for DV revocations, such verification would be pretty much identical to DV verification. The hard part is merely automating the process for scale like they do for DV issuance. (But if a CA got enough of these requests it could save some engineering by

Re: Cerificate Concern about Cloudflare's DNS

and pair it up with the CT logs to see how much of an issue this is/could be. -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

e we're talking about a CA which used their private keys to get around baseline requirements/prohibitions by backdating, I would not be comfortable trusting them with operating a log where they could do the same thing. The addition of the Google log prevents thi

Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

n FF, do you want to include it in the export?' Are there other actionable things Mozilla could do to make things better-by-default for downstream users? -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

in the list... but only if the correct leaf was specified first. (Kind of surprised by that, I'd have imagined that be a more common misconfiguration, but I guess not.) Tested with Chrome/Firefox/IE/Edge on Windows 10. (Seems Edge doesn't honor the HSTS hard fail mecha

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

y... I guess the main thing I'd wonder about is if a client has a root marked as untrusted, it may build a chain to that root for the purposes of *not* trusting it. (As opposed to building a chain to a completely unknown root.) Not that I think this is a good idea. -tom

Re: StartEncrypt considered harmful today

a way that does not significantly improve their security. (And various shades in between) But I'm biased, being a security consultant and all. -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Name-constraining government CAs, or not

, and standards for issuing, maintaining, or revoking certificates, including audit frequency and procedure. -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

, despite all the efforts in detecting misissuance (Perspectives, Decentralized Observatory, HPKP reporting, etc) - all recent misissued certificates were found via Chrome's PKP in Chrome. The community does not have a good track record on this. -tom ___ dev