On Tue, Mar 2, 2021 at 1:39 PM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
On Tue, Mar 02, 2021 at 10:19:53AM -0800, Michael Thomas wrote:
> [...] And once you rely
> on online crl's, it's all the same.
Yes, well, wherever possible we should be using short-lived credentials
and dispense with revocation.
Getting back to the constraints of 30MHz Windows 95 PCs. Has anyone here tried to create a 2048 bit RSA key on a BBN safekeyper box?
The notary videographer did not expect to be spending eight hours filming absolutely nothing happening.
Back in 1995, signing a new cert for each subscriber every day was impossible. Now it is completely feasible.
With threshold techniques, we don't even need the subscriber to make a new cert request and we can still roll the key:
* Alice creates public/private key pair {a.P, a}, sens a.P to Carol
t=0) Carol validates the request generates a new keypair {c0.P, c0} and sends back a certificate for { (a+c0).P, a+c}. and the value c0 Carol doesn't know a of course but she can calculate a.P + c0.P which is the same thing. This cert is valid for 48 hours.
t=1) The next day, Carol sends a certificate for { (a+c1).P, a+c}. and the value c1
t=2) The next day, Carol sends a certificate for { (a+c2).P, a+c}. and the value c3
t=3) 'Alice' turns out to have never been Alice, it was Mallet. Carol stops sending her new certificates.
I could write a spec for this in PKIX if anyone was interested. Of course, you would end up listening to me yacking on about the Mesh while I did it.
This approach would completely eliminate the need for CRLs except for purposes of recording the fact an issue arose for purposes of interpreting signatures.
Of course, we would have to modify TRANS to make this work or else those logs are gonna BLOW! Basically, you would have to log a template for the cert rather than the cert itself. And there would need to be an extension in the cert so things were all tickety boo. But it is all doable.
