After I created OCSP Watch[1], I regularly detected CAs returning an OCSP response of unknown or unauthorized for certificates found in CT logs, indicating that they had basically forgotten that they had issued a certificate. I find that rather troubling. Indeed, OCSP Watch is currently reporting several forgotten NETLOCK certificates. (The certificates from other CAs are recently issued and will probably have OCSP responses provisioned in the near future.)
CRLs can't be used to detect this, because they only list revoked certificates rather than providing a definitive status for every issued certificate.
I do wish the root programs had merely removed the requirement to include an OCSP URL in certificates, but required OCSP URLs for every issuer to be disclosed in the CCADB. That would have solved the privacy problems and made OCSP responders much cheaper to operate, while continuing to provide transparency into the status of certificates.
BTW what is the need for a CA to remember issued certificates?
Certificates should work as long as they are not expired, not on a CRL, and while the same applies to their.CA's certificate used to sign it.
The only good use for remembering issued certificates that I see is that a CA could detect a compromise if it's handed a certificate it does not remember issuing. It looks far-fetched to me, but I know nothing about CA operation.
When a CA has an incident, such as learning that one of their domain validation methods is flawed, they need to be able revoke all certificates impacted by the incident. Without a reliable database of certificates, there's no guarantee they'll find all of the impacted certificates. OCSP could fail closed in this situation. CRLs always fail open.
Aside: it was in fact envisioned that OCSP could be used to detect CA compromises, and the BRs used to say "The CA SHOULD monitor the OCSP responder for requests for 'unused' serial numbers as part of its security response procedures." I'm not sure how many CAs actually implemented that, and in any case I don't think it ever detected any compromises.
This central authority for certificate validation seems like extra infrastructure without which the internet fails.
Once upon a time, internet communication was between two computers. Now there is a third computer to verify that the communication between two computers is legitimate.
Is there another communication design that works without the need for a third computer?
Edit: I don't think so. Identity validation of a public computer should be done by another well-trusted computer.
Could dust off DANE here, the connection probably already included a DNS lookup, why not get the public key info from the same.
So many reasons, but the simplest is that those lookups will constantly fail because middleboxes makes variegated inane decisions about 53/udp and 53/tcp, which means you need to have a fallback mechanism, which will inevitably be exploitable. DANE is a dead letter.
Between two distrusting parties, a third mediating party is needed. But that party does not need to be centralized. Indeed, there are many TLS certificate registrars.
require sufficient info to identify the validation method to be included in an extension in the precert?
Yeah, that would be a good idea.
Though sometimes the CA needs to know more than just the validation method to determine if a certificate should be revoked, and it's not practical to stuff it all in an extension (e.g. this recent GoDaddy issue which required examining past CAA queries: https://bugzilla.mozilla.org/show_bug.cgi?id=1904748).
CAs need to know every certificate they've issued so that
a) if they receive a request to revoke that certificate, they can actually do so; and
b) if they need to revoke all of their certs (e.g. due to discovering a validation process failure) they don't miss any.
Isn't it more "a lot" of certs? Surely if they need to revoke all certs they can just revoke the intermediate.
There is a middle ground between "all certs" and "a few certs". An example would be https://community.letsencrypt.org/t/revoking-certain-certifi... (2.4% of all certificates). This needs a full list of affected certificates but is too small to revoke the intermediate.
And the GP used the word "all" which is what I was replying to.
Dumb q, but why not just revoke/invalidate the signing certificate used to sign the certificates?
it's exactly that. the thing is that if you're a CA, that's not farfetched at all.
OCSP systems at scale are complex. At the core there is an on-demand or pre-signed OCSP response generation system, then there is usually an internal caching layer (redis or similar), then there is an external CDN layer. Just because the outer layer appears not to know about a certificate (a bug, to be sure), doesn't necessarily mean that other CA systems don't know about it.
Requiring CAs to run OCSP makes running a CA more complex and expensive, which has considerable downsides like it does for any system, particularly as it is a zero sum game. Every dollar or hour of engineering time that Let's Encrypt spends on OCSP (and it is a considerable amount) is a dollar or hour not being spent on other parts of the CA. From the outside that may not be very visible because it's not obvious what isn't getting done instead but there is a real and considerable cost that is not worth it IMO.
CAs are money printing machines. If they cannot even track the state of their delegated trust, then why should they be trusted themselves?! Trust is their core value proposition, the only reason they exist!
The person you're replying to (Josh Aas) is the head of the largest CA in the world, which has never charged anyone for a certificate and has never made a profit. That CA, at least, isn't a money-printing machine!
Good point. Though being a non-profit doesn't remove the fact that the value proposition of CAs is trust.
Perhaps there is some compromise like they just have to submit all issuances certs to a 3rd party, and maintain the last few months worth of issuances.
Part of that compromise is already in effect:
https://certificate.transparency.dev/
Why don’t CT logs include revocations? Seems like that could provide transparency into this without the need for another system (OCSP)
For what it's worth, the person you're replying to is the founder and executive director of Let's Encrypt, the non-profit free and open CA which decidedly isn't a money-printing machine.
They are so complex, and in practice unreliable, that my employer runs a caching proxy for our (non-browser) users (they mostly don’t want fail open).
IMO it is unfixable and should go
I don’t understand what relevance your caching proxy has. if you have time, are you able to explain this a bit further?
The CA ocsp endpoints are so unreliable we have to run a cache (the sdk we provide will use it).
Do you disagree that OCSP would be significantly less costly and complex if the responder URL were not included in certificates, freeing the responders from having to serve hundreds of millions of clients?
Yes, I disagree. Best case scenario I think it would just allow us to get rid of the CDN layer. We'd still have to build and manage the rest with utmost care.
Even that really depends on what the "SLA" expectation is. How many QPS would we be required to support before we're allowed to start dropping queries? If there's any possibility of a burst beyond what we can handle locally we'd keep the CDN, so maybe the CDN bill would be significantly smaller on account of lower volume but all the complexity and care of operation would still be there.
A unique per certificate CRL might work in theory. Theory is not the same as practice
Per-certificate CRLs are possible, though have about the same privacy problems as OCSP (without any of the possible advantages like OCSP pinning)
Internal / private certificate distribution monitoring, but yes privacy beyond that.
The CA did not forget the certificate if it's in their CT logs. The whole point of CT (unlike OCSP) is to make it impossible for a CA to forget what they've signed. If they forget to put a certificate in their CT logs, then the cert isn't valid. Anyone can download and retain copies of the logs, because they're signed and hash treed. Removing a cert after-the-fact is about as disruptive as editing Git history on Linus Torvalds' tree, meaning it will be incredibly obvious that the CA is trying to lie about what they signed.
The reason why OCSP forgets about certificates is that it was never intended to make CAs permanently remember every cert they ever signed. It was intended to replace CRLs with something less resource-intensive, except they screwed up the design, so it's now just a data siphon that provides little protection.
CT doesn't tell you if a certificate is revoked, so the CA still has to operate a revocation system. That revocation system can forget about certificates.