Key rotation is important, so STAR orders expire, after which the client can renew with a new key. So keys need not be any longer-lived under STAR than they are with today's long-lived certs.
-
-
It may not be necessary for Google, but if this makes short-lived certs palatable to other operators, it's an improvement over the status quo, even if keys are not rotated ~daily.
2 replies 0 retweets 0 likes -
Replying to @__agwa @ivanristic
I’m not speaking as Google just Ryan; I get that it lets you renew against same key for a fixed period. That’s the most impactful element of the proposal since cached validations reduce need to recalibrate on renewal. I just ask why?
1 reply 0 retweets 0 likes -
Replying to @rmhrisk @ivanristic
Arguments like https://github.com/WICG/webpackage/issues/378#issuecomment-457011076 …: "7-day lifetime would limit uptime. In practice they see longer downtime periods for certificate issuance than OCSP."
1 reply 0 retweets 1 like -
Replying to @__agwa @ivanristic
In practice the reason they see that is they have been using legacy CAs that frequently experience hours of issuance outage. Making the issuance asynchronous doesn’t meaningfully change that a CA outage means you don’t get your new cert.
1 reply 0 retweets 2 likes -
Replying to @rmhrisk @ivanristic
It seems like batch signing certs and pushing them out to CDNs will always be fundamentally more reliable than an Internet-facing signing-on-demand service, which can be affected by unexpected usage spikes, DoS attacks, buggy clients causing retry storms, etc.
1 reply 0 retweets 2 likes -
Replying to @__agwa @ivanristic
It’s a bit like rearranging deck chairs on a sinking ship. If your a SAAS service, let’s say WordPress, where you need to spin up a new site for your customer who just completed a wizard, if your cert issuance is down your site is down.
1 reply 0 retweets 1 like -
Now with the batches signed certs you could have certs on a CDN that were pre produced for your existing customers so they don’t go down also.
1 reply 0 retweets 1 like -
But down is down, you need to have reliable issuance. Once you have two or three ACME endpoints you can use then both cases are handled without the pre production.
1 reply 0 retweets 1 like -
Is pre production bad? Of corse not but did it solve the core issue? Only in the narrowest case I think.
1 reply 0 retweets 1 like
The number of renewals will dwarf the number of brand new issuances, especially as lifetimes go down, so it's quite the opposite of the narrowest case. But I do agree redundant ACME endpoints would be ideal; just as long as the others can absorb the load when one goes down :-)
-
-
Replying to @__agwa @ivanristic
I also think if this many sub cert concept people prefer then secondary certs probably make more sense; https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/ …
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.