On 3/2/21 12:44 PM, Phillip
Hallam-Baker wrote:
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.
Or skip all of this complexity and just enroll the naked public key bound to whatever name you like (if any) and having the side benefit of not having to deal with a dinosauric encoding scheme.
Mike
