> The browser would be able to take policy of simply never trust a certificate whose signer has changed
This assumes that the signer's keys can't be compromised, and re-introduces the issues of key pinning that the WebPKI community has been pushing very hard to eliminate from its dependents. I don't think it's a workable solution.
I think you are very likely to use the same signer if you actually lose the key, so this isn’t something I think a naive sysadmin is going to fuck up the way they fuck up host pinning.
How can you use the same signer when the signer's keys are lost?
Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?
The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised, you have to re-issue all certs. When the client pins the CA key then the chain of trust is permanently broken.
> How can you use the same signer when the signer's keys are lost?
You mean, hypothetically if Letsencrypt suddenly loses the ability to sign new requests from me?
Well, then I have around 30 days to detect that and choose a new signer.
> Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?
Again, to be clear, you're talking about Letsencrypt's own signing keys in this case, being compromised and them being denied access to them. That seems incredibly unlikely to have both failures at the same time, but again: I have 30 days to find a new signer.
> The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised
No! In fact, if Letsencrypt sublicenses signing to a third-party that certificate would be considered separate and so the switcheroo would be detected!
> When the client pins the CA key then the chain of trust is permanently broken
That's why it is important to extend TLS to allow multiple keypairs and certificates to be used to mutually authenticate the session key, so that any of the previous pinned keys can be used to update the pin. I did not say I wanted this for no reason!
I remember that PR for similarly interesting reasons:
Someone on the pgsql-hackers@ mailing list noticed that, with a then-recent OpenSSL version on graviton, there were issues validating the "control file" of a PostgreSQL instance [0] (control files contain some basic ground truths about a cluster).
The report included a lot of detailed information about the program state, sufficient for me to figure out that one of the registers was definitely getting clobbered during the pg_strong_random() calls[1], but without access to the environment I couldn't prove whether it was the OpenSSL library, or a compiler bug.
A few days later an Apt developer was debugging the same issue from another direction, eventually figured out that this was caused by a typo in openssl's register restoration code (which was written in ASM introduced in the PR linked by parent post), and then submitted a PR to OpenSSL to fix the issue [2], now (presumably) for good.
> Having secondary indexes point the primary key enables things like undo logging
That's neither here nor there. Heap-oriented tables can have undo logging, too; and index-oriented tables don't strictly require undo logging.
It's just that you're much more likely to want something like undo logging for index-oriented tables, because maintaining uniqueness for rows that are not in-place updated in the index becomes very expensive as more and more versions of the same key value may need to be checked for visibility and liveness, and removing old deleted versions becomes a maintenance hassle, too. It can be done without undo logging, but apparently that wasn't a sufficiently robust (or performant) design.
Only in the worst case when the plans are equivalent: If one plan is significantly faster, then it'll finish first, and the loser can get canceled before it finishes.
Good and bad plans can have orders of magnitude performance difference. The bad one can easily do enough damage cutting the performance in half before it is canceled.
Nope, it doesn't. It's current legal basis is a series of treaties, the attempt to create a constitution failed when in 2005 the various countries' local referenda on supporting an EU constitution failed to garner the required support. FRA' referendum failed 45-55, and NLD's consultative referendum on June 1 also gave a solid "no" (38.5% yes vs 61.5% no).
Assuming a given fixed key size, where does RSA need non-fixed-width arithmatic? AFAIK you can do all RSA maths with registers just double as wide as the key, no variable width anything required there. And I don't think that this is much different from ECC maths, apart from ECC's keys just being way less wide for an approximately equivalent security level.
RSA operations are performed modulo n, where n is the product of 2 primes. A 2048-bit RSA key is an n that is 2048 bits long (with the most significant bit set by definition).
There are no consumer CPUs that have 2048-bit-wide registers; even AVX10 tops out at 512 bits. Thus, mathematical operations on RSA keys are performed using arbitrary precision integer libraries like OpenSSL's own BN (BigNum) library, or GMP (the GNU Multiple Precision Arithmetic Library) as used by GNUTLS, in software.
For example, adding 1 to an arbitrary precision integer is not a CPU add or increment instruction, nor is multiplying 2 integers (or an integer and a constant factor) a CPU multiplication instruction.
and the more recent (post-quantum) lattice-based stuff can get away with ~16 bit arithmetic (it's vectors of ~512-1024 dimension, but the operations are SIMD-friendly)
Whilst they may provide a strong signal, I wouldn't call it a guarantee. If I wanted to avoid vibe-coded contributions I might add such files, but with instructions for the agents that they're not allowed to read or touch any of the files in the repository.
This assumes that the signer's keys can't be compromised, and re-introduces the issues of key pinning that the WebPKI community has been pushing very hard to eliminate from its dependents. I don't think it's a workable solution.
reply