[1] https://stackoverflow.com/questions/18291620/why-will-stdsor...

Also, Mozilla Corporation's sole "shareholder" is the not-for-profit Mozilla Foundation.

In fact, I've read several such rants about Firefox removing functionality from other parts of their UI.

It's sure hard to make everyone happy.

The increased certificate size would also be painful for Certificate Transparency logs, which are required to store certificates and transmit them to anyone who asks. MTC doesn't require logs to store the subject public key.

Comments URL: https://news.ycombinator.com/item?id=47075332

Points: 3

# Comments: 0

CAs can cache the record lookup for no longer than 10 days. After 10 days, they have to check it again. If the record is gone, which would be expected if the domain has expired or been transferred, then the authorization is no longer valid.

(I would have preferred a much shorter limit, like 8 hours, but 10 days is a lot better than the current 398 day limit for the original ACME DNS validation method.)

Mozilla root store policy: https://www.mozilla.org/en-US/about/governance/policies/secu...

Chrome root store policy: https://googlechrome.github.io/chromerootprogram/

Apple root store policy: https://www.apple.com/certificateauthority/ca_program.html

Baseline Requirements: https://github.com/cabforum/servercert/blob/main/docs/BR.md

There are countless examples of non-compliant certificates documented in the Bugzilla component I linked above. A recent example: a certificate which was backdated by more than 48 hours, in violation of section 7.1.2.7 of the Baseline Requirements: https://bugzilla.mozilla.org/show_bug.cgi?id=2016672

The good news is that since Prosody requires the serverAuth EKU, the misissued cert would be in-scope of Mozilla's root program, so if it's discovered, Mozilla would require an incident report and potentially distrust the CA. But that's reactive, not proactive.

Having the customer grant permission to a single master service account is vulnerable to confused deputy attacks.

In any case, why should I have to pursue "other solutions" to something that's in their documentation?

I would think it's more secure than clientAuth certs because if an attacker gets a misissued cert they'd have to actually execute a MitM attack to use it. In contrast, with a misissued clientAuth cert they can just connect to the server and present it.

Another fun fact: the Mozilla root store, which I'd guess the vast majority of XMPP servers are using as their trust store, has ZERO rules governing clientAuth issuance[1]. CAs are allowed to issue clientAuth-only certificates under a technically-constrained non-TLS sub CA to anyone they want without any validation (as long as the check clears ;-). It has never been secure to accept the clientAuth EKU when using the Mozilla root store.

[1] https://www.mozilla.org/en-US/about/governance/policies/secu...

I've seen non-XMPP systems where you configure the DNS name to require in the client certificate.

It's possible to do this securely, but I agree entirely with your other comment that using a public PKI with client certs is a recipe for disaster because it's so easy and common to screw up.

They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of.

The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong.

A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated.

[1] https://groups.google.com/g/mozilla.dev.security.policy/c/RH...

[2] https://groups.google.com/g/mozilla.dev.security.policy/c/yh...

[3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM...

[1] https://www.agwa.name/blog/post/accessing_your_customers_goo...

As for the 2025h2 logs, these will not be acquiring any newly-issued certificates, but someone might be copying previously-issued certificates from other logs.

Even if it did work, the privacy value of hiding the SNI is pretty minimal for an IP address that hosts only a couple domains, as there are plenty of databases that let you look up an IP address to determine what domain names point there - e.g. https://bgp.tools/prefix/18.220.0.0/14#dns

Great, so now GitHub can't change the structure of their IDs without breaking this person's code. The lesson is that if you're designing an API and want an ID to be opaque you have to literally encrypt it. I find it really demoralizing as an API designer that I have to treat my API's consumers as adversaries who will knowingly and intentionally ignore guidance in the documentation like this.