Re: Criticism of Google Re: Google Trust Services roots

I don't think it's a good idea to design our system around the idea of "What would a user be looking for if they read the cert chain manually". For example, in the US, if such a government agency chose to use a Government CA (as a user might reasonably expect!), their users would all get cert

Re: Symantec Response R

Hi Steve, Tiny nit-picky follow up question. You said: "it's technically not feasible. This is because Symantec does not have access to our customers' TLS server private keys.". X.509 certificates can of course be used for things besides TLS, when you say "TLS server private keys", is that

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

+1 on removal, that paragraph doesn't square with current ideas about what's problematic in the WebPKI; as you've noted wildcards and DV are really orthogonal concerns. Alex On Thu, Apr 20, 2017 at 9:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:

Re: Final Decision by Google on Symantec

Frankly I was surprised to see Chromium reverse course on this -- they have a history of aggressive leadership in their handling of CA failures, it's a little disappointing to see them abandon that. I'd strongly advocate for us perusing an earlier date -- December 1st at the latest. Reasons: 1)

Re: Certificate with invalid dnsName issued from Baltimore intermediate

Ouch. Thanks for clarifying. Alex On Thu, Aug 3, 2017 at 10:46 AM, Ben Wilson wrote: > There are over 300 publicly visible servers, according to Censys.IO. > > > > *From:* Alex Gaynor [mailto:agay...@mozilla.com] > *Sent:* Thursday, August 3, 2017 8:42 AM > *To:* Ben

Re: Certificate with invalid dnsName issued from Baltimore intermediate

If I'm reading this correctly, these certificates are for internal services, not publicly accessible. Could they add their intermediate directly to these trust stores, allowing you to revoke it? Failing that, it sounds like OneCRL would be an appropriate remedy. Alex On Thu, Aug 3, 2017 at

Re: DigiCert-Symantec Announcement

Hi Jeremy, Will the certificates being issued for Symantec starting December 1st be issued under the existing DC roots, or under new roots? Alex On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi everyone, > > > > Today,

Re: StartCom cross-signs disclosed by Certinomis

From RFC6962: The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate). I don't think this text could be any

Re: Certificates with invalidly long serial numbers

This is a great point, re:automated issuance systems like ACME. I've suggested to the Let's Encrypt folks the idea of a "should I re-issue" endpoint that clients can poll. This would give CAs a programatic ability to broadcast to subscribers that they should reissue now because the cert is about

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

Hi Josh, Given that these were all caught by cablint, has Let's Encrypt considered integrating it into your issuance pipeline, or automatically monitoring crt.sh (which runs cablint) for these issues so they don't need to be caught manually by researchers? Alex On Thu, Aug 10, 2017 at 11:00 PM,

Re: Misissued certificates

< dev-security-policy@lists.mozilla.org> wrote: > On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote: > > What's it going to take for mozilla to set up near real-time > > monitoring/auditing of certs showing up in ct logs? > > > > Lee > > >

Re: Certificates with metadata-only subject fields

As a friend of mine sagely points out, fundamentally the current incentives for a CA are, "Issuing certs gets us money, not issuing certs does not get us anything". That's an incentive structure that badly needs correction -- CAs should be accountable for what they issue. Without speaking to

Re: Certificates with less than 64 bits of entropy

Have they fixed whatever issue there is with their PKI infrastructure that leads to this issue? From skimming, I see this pool contains certs issued as recently as one month ago. Alex On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org>

Re: Leaking private keys through web servers

On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > So there are several questions and possible

Re: WoSign new system passed Cure 53 system security audit

Is this a correct summary: - The report included here is supposed to fulfill the network security test portion of the BRs - This report does not attest to BR compliance (or non-compliance) - To complete an application for the Mozilla Root Program, WoSign would be required to additionally provide

How long to resolve unaudited unconstrained intermediates?

Hi all, I wanted to call some attention to a few intermediates which have been hanging out in the "Audit required" section for quite a while: https://crt.sh/mozilla-disclosures#disclosureincomplete Specifically, the TurkTrust and Firmaprofesional ones. Both have issues open in Bugzilla: -

Re: [EXT] Symantec Update on SubCA Proposal

On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin wrote: > 1) *December 1, 2017 is the earliest credible date that any RFP > respondent can provide the Managed CA solution proposed by Google, assuming > a start date of August 1, 2017. Only one RFP respondent initially

Re: Miss-issuance: URI in dNSName SAN

Following up on this (and really several other threads). The BRs require mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs are required to track m.d.s.p. per the Mozilla Root Policy, so really notifying this list _ought_ to qualify as notifying the CAs. In any event, here

Re: dNSName containing '/' / low serial number entropy

Hi Mark, Are you saying you do intend to revoke all of these certificates in the next 24 hours? While subscribers are allowed to continue using bad certificates as long as they desire, the BRs require CAs to revoke non-compliant certificates within 24 hours of becoming aware of them. Alex On

Re: Symantec Update on SubCA Proposal

Just to be explicit: your count includes certificates which, with high probability have already been replaced, because it does not subtract names for which new certificates have been issued? I realize it may seem like I'm putting a lot of emphasis on this one number, but given that it's the basis

Re: Symantec Update on SubCA Proposal

On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Symantec has proposed timing changes that are consistent with the scope of > distrust of the original SubCA proposal as proposed by Google and endorsed > by Mozilla, which

Miss-issuance: URI in dNSName SAN

Morning all, I'd like to report the following instance of miss-issuance: All of the following contain a URI in a dNSName SAN entry. These certificates are neither revoked, nor expired, and all are from CAs currently trusted by the Mozilla Root Program. https://crt.sh/?id=124094761=cablint

Re: Certificate with invalid dnsName issued from Baltimore intermediate

I think there might be a bug in your SQL, one of the offending certs is issued by "C=US, O=U.S. Government, OU=Department of Homeland Security, OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL. Alex On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <

Re: [EXT] Symantec Update on SubCA Proposal

Hi Steve, Thank you for this update on Symantec's progress. I have a few follow-up questions: 1) Did any of the RFP respondents indicate that they could provide the Managed CA solution in the timeframe originally proposed by Google? (August 8th) Alternatively, is December 1st, 2017 the

Re: P-521

I'll take the opposite side: let's disallow it before it's use expands :-) P-521 isn't great, and there's really no value in proliferation of crypto algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't try to catch 'em all". There's no real use cases P-521 enables, and not

Re: FW: P-521

On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I agree crypto algorithms are not "gotta catch 'em all", but the > algorithm is ECDH, which NSS must implement anyway to support P-256 and > P-384, and a curve is just another

Re: Symantec Conclusions and Next Steps

On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Your post made me realize that we never publicly posted the status of these > last few CAs. Sorry about that. Here's the plan: > > 1. ABB - ABB was supposed to be technically

Re: Certificates with invalidly long serial numbers

I think you're largely objecting to a strawman, no one is proposing revoking trust in any of these threads. The only CAs that have ever had _any_ penalty applied to them have been for grotesque abuse of the trust vested in them. Alex On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via

Re: Certificates with invalidly long serial numbers

It's from the BRs 4.9.1.1: The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: It's also not a penalty on the CA, it's a remediation step for them to undertake. Alex On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy <

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

Luckily we have tools like certlint, which can be run on certificates to catch this stuff! I'd feel very differently if CAs were starting these threads because they'd caught issues with certlint, than the fact that independent researchers are noticing. Alex On Tue, Aug 8, 2017 at 7:52 AM, Jakob

Re: Miss-issuance: URI in dNSName SAN

Hi all, Following up on this thread, 8 days ago I emailed Camerfirma, I have not heard back from them, nor have they taken any action. What is the appropriate next step here? Alex On Mon, Jul 31, 2017 at 10:14 AM, Alex Gaynor wrote: > I've been attempting to report a

Re: Certificates with invalidly long serial numbers

This methodology of "letting everyone decide which parts of the spec/BRs aren't important" doesn't make sense. If there's something wrong with the spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of the "fetch" specification). Giving each CA unilateral authority to ignore

Fwd: Misissued certificates - pathLenConstraint with CA:FALSE

(Whoops, accidentally originally CC'd to m.d.s originally! Original mail was to IdenTrust) Hi, The following certificates appear to be misissued: https://crt.sh/?id=77893170=cablint https://crt.sh/?id=77947625=cablint https://crt.sh/?id=78102129=cablint https://crt.sh/?id=92235995=cablint

Re: Certificates with invalidly long serial numbers

You seem to be suggesting that the thoroughness of testing is somehow related to how long it takes. I'd expect any serious (or even not particularly serious...) to have a comprehensive automated test suite that can verify that the software is regression free and correct in minutes or hours. If

Re: Certificates with invalidly long serial numbers

I'm not really sure I agree that there should be multiple tiers of revocation, but just to go along with the thought experiment.. If there were, "key compromise" is definitely not the only case I'd want on the more aggressive schedule, I'd also want to include cases where there was a failure in

Re: Certificates with common names not present in their SANs

Sorry, you're right -- I'd misunderstood the issue with Python. (FWIW, I'm one of the maintainers of the Python ssl module, and I anticipate us having a fix for IDNs by the next release). Alex On Sun, Aug 6, 2017 at 8:38 PM, Nick Lamb via dev-security-policy <

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

Hi Arno, Tools like https://github.com/alex/ct-tools or https://github.com/grahamedgecombe/ct-submit can be used to manually submit specific certificates to CT logs. Alex On Thu, Aug 17, 2017 at 9:07 AM, Arno Fiedler via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Am

Re: Configuring Graduated Trust for Non-Browser Consumption

Once upon a time I would said "yes, we should totally encourage people to lovingly craft their perfect trust store, to reduce their risk profile". Now, not so much. As we've seen in numerous discussions, customers of CAs, particularly large enterprises and vendors (think payment terminals) love

Re: Configuring Graduated Trust for Non-Browser Consumption

Ryan, I think you've correctly highlighted that there's a problem -- the Mozilla CA store is "designed" to be consumed from NSS, and CA-specific remediations are a part of that (hash algorithms, maximum certificate lifetimes, and any number of other important technical controls). Unfortunately,

Re: Configuring Graduated Trust for Non-Browser Consumption

On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Cory, > > On 11/05/17 15:21, Cory Benfield wrote: > > While I’m very supportive of this kind of remediation, it is not a > remediation that non-browser implementations can

Re: Configuring Graduated Trust for Non-Browser Consumption

I think you left this a bit implicit Cory, so I figured it's worth spelling out: the strength of Mozilla's CA program, as a tool for making the web stronger, comes from having people using it, that's the carrot that forces people to meet our standards (also the fact that as a transparent, root

Re: Configuring Graduated Trust for Non-Browser Consumption

, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> Ryan, >>> >>> I think you've correctly highlighted that there's a problem -- the >>> Mozilla >>> CA store is "designed&

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

Hi Ryan, I've lost the thread on how this addresses Cory's original problem statement, if you could spell that out that'd be very helpful. Alex On Tue, May 16, 2017 at 10:22 AM, Ryan Sleevi wrote: > > > On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

Fewer round trips, if you can include everything in a single response. Alex On Tue, May 16, 2017 at 11:11 AM, Ryan Sleevi wrote: > > > On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 16/05/17

Re: Unknown Intermediates

If you're interested in playing around with submitting them yourself, or checking if they're already submitted, I've got some random tools for working with CT: https://github.com/alex/ct-tools Specifically ct-tools check will get what you want. It's all serial, so for

Re: Unknown Intermediates

One of my hobbies is keeping track of publicly trusted (by any of the major root programs) CAs, for which there are no logged certificates. There's over 1000 of these. In the last day, presumably as a result of these efforts, 50-100 CAs were removed from the list. Cheers, Alex On Thu, Jun 22,

Re: Unknown Intermediates

I definitely consider increased visibility into the vast iceberg that is the public PKI to be a good thing! What set of intermediates are you using? If it's reasonably complete, I doubt we'll do any better than you, though maybe someone here has a particularly clever technique for processing

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

While the internet is moderately good at handling a single cross-sign (modulo the challenges we had with 1024-bit root deprecation due to a bug in OpenSSL's path building -- now fixed), as we extend the chains, it seems evident to me that server operators are unlikely to configure their servers to

New undisclosed intermediates

Happy Monday! Another week, another set of intermediate certs that have shown up in CT without having been properly disclosed: https://crt.sh/mozilla-disclosures#undisclosed There are four intermediates here, and with exception of the StartCom one, they were all issued more than a year ago. As

Re: Symantec response to Google proposal

On Tue, Jun 6, 2017 at 10:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 02/06/17 15:53, Gervase Markham wrote: > > https://www.symantec.com/connect/blogs/symantec-s- > response-google-s-subca-proposal > > I'm slightly surprised to see no

Re: Symantec: Draft Proposal

Hi Gerv, One idea that occurred to me (maybe novel, though I doubt it), is requiring mandatory _timely_ CT submission for intermediates/cross signatures. That is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be less than some period, perhaps 3 days. This would ensure rapid

Re: Symantec Conclusions and Next Steps

(I work for Mozilla, but this email doesn't necessarily reflect the views of Mozilla). Hi Steve, I appreciate Symantec taking the time to put this together. There's a lot of unpack here, so I wanted to zoom in on one portion of it. When discussing the feedback you received from enterprise

Re: [EXT] Symantec: Draft Proposal

It is clear to me from reading this that there is a significant gap between Symantec's perspective on the severity of the issues discussed and the perspective of many m.d.s.p. participants. Hopefully this email will serve to highlight some specific areas that contribute to this gap, and which

Re: Draft further questions for Symantec

I'm not the best way to phrase this, so please forgive the bluntness, but I think it'd be appropriate to ask at this point if Symantec has disclosed all necessary intermediates (I believe this would be defined as: chain to their roots in our trust store, are not expired, are not revoked, and are

Re: Symantec: Draft Proposal

Hi Rick, Does Symantec plan to introduce new facts into the conversation, or is all the information we are currently considering accurate and complete? If there's no new information, I don't see why the community of participants in m.d.s.p. should pause. I think it's a point of pride for many of

Re: Draft further questions for Symantec

Thanks Kurt. Alex On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2017-05-08 15:31, Alex Gaynor wrote: > >> I'm not the best way to phrase this, so please forgive the bluntness, but >> I >> think it'd be appropriate to

Re: Symantec: Draft Proposal

Hi all, This morning Symantec disclosed ~20 new intermediate certs. I went through these and identified 7 of them which are a) not revoked, b) not expired, c) lack a BR audit: https://crt.sh/?q=54EFD2977D89EDE24DDC3797CEB5A80668B3905788B58FB1AC6893EF4B78A24A

Re: CA Validation quality is failing

I know several CAs are using certlint (https://github.com/awslabs/certlint) as a pre-issuance check that the cert they're about to issue doesn't have any programmatically detectable deficiencies; if it doesn't already cover some of these cases, it'd be great to add them as a technical means for

Re: New undisclosed intermediates

On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 05/06/17 14:29, Alex Gaynor wrote: > > > As I've

Re: FW: StartCom inclusion request: next steps

I'm fairly confused by your answers, if the only thing you tested in production was CT, why was the system issuing non-compliant certs? Why did production CT testing come before having established, tested, and verified a compliant certificate profile? Alex On Fri, Sep 15, 2017 at 10:35 AM, Inigo

RSA key generation vulnerability in Infineon firmware

Hi all, Today researchers announced a vulnerability they discovered in RSA keys generated by a particular piece of firmware, which allows practical factorization of the private key given just the public key. Full details of the research here: https://crocs.fi.muni.cz/public/papers/rsa_ccs17

Re: PROCERT issues

I believe it's important to consider more than just the issues themselves, and to look at a CA's response to the issues. In the past weeks, we've done a lot of really fantastic work to push CAs on publishing more comprehensive post-mortems, and several CAs have distinguished themselves with timely

Re: Violations of Baseline Requirements 4.9.10

Hi Ben, I'm not sure it should matter that a CA _does_ only issue client certs -- in the DigiNotar-style situation for which this rule was envisioned, the relevant thing is whether the cert is _capable_ of issuing server certs. Alex On Tue, Aug 29, 2017 at 12:43 PM, Ben Wilson via

Re: Certificate with Debian weak key issued by Let's Encrypt

I'd like to push a bit harder on searching for more systemic remediations. "We forgot to get around to revoking it" is a pretty common element of CAs' post-mortems, I think it'd be good for us to dig deeper. For example, does Let's Encrypt have a runbook that gets used on misissuance reports? Is

Re: DigiCert ROCA fingerprint incident report

Hi Jeremy, Have all these certificates been submitted to CT? Thanks! Alex On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey everyone, > > > > Here's the DigiCert incident report about the ROCA fingerprints. Note that >

Re: On the value of EV

Can you share what the working group has been brainstorming on? Near as I can tell, this is a validly issued EV cert, for a valid KY company. If "Stripe, Inc of Kentucky" were in a distinct industry from this Stripe there wouldn't even be a trademark claim (I'm not a lawyer, etc.). Lest anyone

Re: Unrevoked/unexpired certificate with Debian Weak Key

Sorry -- digging into that 500 was on my plate, but there was a logging bug on errors... and then some poor docs for the framework I'm using... and before you know it, the yak stack was piled high. I'll cycle around to that again this evening. Alex On Mon, Jun 18, 2018 at 9:53 AM Rob Stradling

Re: Updating Root Inclusion Criteria

Hi Wayne, After some time thinking about it, I struggled to articulate what the right rules for inclusion were. So I decided to approach this from a different perspective: which is that I think we should design our other policies and requirements for CAs around what we'd expect for organizations

Re: Updating Root Inclusion Criteria

Self-assessment is insufficient :-) That's why we require audits, review issued certificates for technical violations, and attempt to empower domain owners to identify misissuance. As we move to a world with greater participation of public CAs in Certificate Transparency (hopefully 100%

Re: TLS-SNI-01 and compliance with BRs

I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01 performs a DNS lookup for the ADN, connects to that IP, and initiatives a TLS connection with the .acme.invalid SNI value. Certificates don't exist on Domain Names if we think really hard about it, but servers with IPs that

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

It would come at the expense of a more streamlined and secure approach (e.g. the ALPN proposal on the acme-wg list), which once standardized I assume Let's Encrypt (and other ACME CAs) would want to fully migrate to. Alex On Mon, Jan 15, 2018 at 9:27 AM, Gervase Markham via dev-security-policy <

Re: Google Trust Services - Minor SCT issue disclosure

Hi Andy, Just so I follow, this is something you're proactively sharing, right? As far as I can tell, there's no violation of any Mozilla Root Program rules here, just an issue that caused interstitials in Chrome. Either way, I appreciate your sharing. You mentioned the issue was do to some

Re: Retirement of RSA-2048

If I may give a shorter answer than Peter: for authentication purposes (as used in the WebPKI with non-RSA-key-exchange ciphersuites in TLS) there is no current deprecation plans for 2048-bit RSA. Alex On Sat, Jan 20, 2018 at 12:00 PM, Peter Bowen via dev-security-policy <

Re: How do you handle mass revocation requests?

I would say that at the point that Trustico emailed them to DigiCert they necessarily became compromised -- while Trustico may (or may not) have been authorized to escrowing the keys by the subscriber, the subscriber did not authorize them to be emailed around, presumably. Alex On Wed, Feb 28,

Re: Allowing WebExtensions to Override Certificate Trust Decisions

A reasonable compromise that jumps out to me is allowing extensions to make an otherwise-secure connection fail, but not allow them to rehabilitate an insecure connection. This would allow experimenting with stricter controls while avoiding some of the really scary risks. Alex On Tue, Feb 27,

Re: Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

Is it practical to remove the Symantec root certificates and (temporarily) add the Google and Apple intermediates to the trust store? This should facilitate removing trust in Symantec without disruption. Alex On Thu, Mar 1, 2018 at 10:15 AM, Kai Engert via dev-security-policy <

Re: Trustico code injection

For the Trustico folks: While I imagine you're quite busy remediating this serious issue: Can you state whether it would be possible to access any of the private keys you store using this root shell? Alex On Thu, Mar 1, 2018 at 10:28 AM, Hanno Böck via dev-security-policy <

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

I disagree on what this is evidence of: It's evidence that the claimed benefits of EV (by CA, WRT phishing) do not match the technical reality. As Ryan noted, as far as I'm aware this certificate violates neither the BRs, nor the EVG. Alex On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

All that proves is the entire EV model cannot possibly accomplish what CAs claims (with respect to phishing and other similar concerns). To whit: - Two companies can validly possess trademarks for the same name in the United States (and I assume other jurisdictions) - A CA, or anyone else's

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Are you saying that's what actually happened, or that we should all pretend that's what happened? Because I don't believe anyone from GoDaddy has made such a claim, and we ought not put words in their mouths. Alex On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy <

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

e there are certainly advantages to indiscriminately logging all > final certificates, there are downsides to weigh as well, at least for ones > not (yet?) deployed on publicly-accessible web servers. > > On 4/5/18, 3:08 PM, "dev-security-policy on behalf of Alex Gay

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

There's two separable questions here: 1) Should CAs log final certificates after they issue a certificate with embedded SCTs: My answer, yes. 2) Should CAs issue final certificates if they discover they are misissued after logging the pre-certificate. The answers to (1) and (2) do not need to be

825 days success and future progress!

Afternoon all! A month ago a new BR rule went into effect, putting a maximum validity period of 825 days on newly issued certificates. Truthfully, I was expecting tons of CAs to screw up, forget to implement it, or have no technical controls, and there to be tons of miss-issuance. To me delight,

Re: 825 days success and future progress!

That would make much more sense. > > -Tim > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Alex > > Gaynor via dev-security-policy >

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

Mozilla currently doesn't have any policy with respect to Certificate Transparency, so I think diving in on this particular point is putting the cart before the horse :-) Currently Firefox does not check/require SCT presence nor does the Mozilla root program require certificates to be logged.

Re: Increasing number of Errors found in crt.sh

A broader issue is that a lot of the certs listed on these pages are publicly-trusted, but not by the Mozilla Root Program, that is to say, Microsoft or Apple (or occasionally Adobe) trusts them. misissued.com (which is currently erroring on all requests ) tried to address this by only showing

Re: AlwaysOnSSL web security issues

The Mozilla policy does not prohibit backdating, except when it's used to evade time-based policy controls. Backdating certs by a few hours is a relatively common practice to minimize breakages for consumers with busted clocks. Alex On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via

misissued.com FYI

Hi All, For anyone using https://misissued.com/ I wanted to provide a quick FYI about some database maintenance. The database was nearing its storage capacity limit, and so I deleted all certificates from it that had expired before 2019. The main consequence of this is that you can't use

Re: Entropy of certificate serial number

Hi Lijun, Entropy is required in serial numbers to protect against weak hash functions -- historically exploitation of MD5's weakness was possible because CAs used sequential serial numbers, thus allowing an attacker to pre-compute hash prefixes, because they could predict future data that would

Re: DarkMatter Concerns

(Writing in my personal capacity) On Tue, Feb 26, 2019 at 7:31 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: [...] > All of Google, Amazon, and Microsoft are in the program. All of these have > or had significant business with at least the US DOD

Re: DarkMatter Concerns

On Tue, Mar 5, 2019 at 9:01 AM Scott Rea via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I have addressed most if not all of the various technical comments in this > list in respect to DarkMatter’s Roots submission and it might be helpful if > I summarize here the raised

Re: misissued.com FYI

a link for the record here, for others finding this > in the future? > > On Mon, Jan 28, 2019 at 10:05 AM Alex Gaynor via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Hi All, >> >> For anyone using https://misissued.com/ I wanted