Bound validity periods to 90 days.

[jyasskin]

This is not necessarily the limit we'll want in the long run, but it
helps ensure that any future changes can go into effect reasonably
quickly.

I won't submit this until I have some indication that the folks who have already started experimenting with signed exchanges can handle 90-day certificates.

@clintwilson, I want to make sure this doesn't cause any problems for you, since I believe Digicert has been issuing certificates with validity periods longer than 90 days. I don't intend to declare that any of your existing certificates are out of bounds.

@AGWA, this isn't intended to stop discussion on #378, just to put some limit in place while we figure out what the right limit is.

Preview: https://jyasskin.github.io/webpackage/90-day-lifetime/draft-yasskin-http-origin-signed-responses.html#cross-origin-cert-req
Diff: https://tools.ietf.org/rfcdiff?url1=https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.txt&url2=https://jyasskin.github.io/webpackage/90-day-lifetime/draft-yasskin-http-origin-signed-responses.txt

[clintwilson]

We don't, today, enforce a maximum validity outside of the 825 days for all public TLS certs. It'll require a relatively small change to add a lower max validity, but it's not a major issue. My only concern would be a nearish-term change to that max validity again. Meaning that I'd like to see some very rough consensus on max validity before we start working in that update.
In the meantime, any validity can be issued today between 1-825 days, so we can support testing efforts with shorter lived certificates immediately.
Does that seem like a fair approach, or would it be better to have that 90 day enforcement in place first?

[shigeki]

We are now ordering a SXG certificate to Digicert. Shortening its lifetime affects our budget and operation plan for our SXG trial. Please also consider the issuing process with CA because ACME is not used for it.

[kinu]

I won't submit this until I have some indication that the folks who have already started experimenting with signed exchanges can handle 90-day certificates.

It'd be probably helpful to clarify what should / would happen to the sites that are already experimenting (or ordering) when this change takes effect, and on any other nearish-term changes.

[clintwilson]

@shigeki Just a note that ordering for shorter validity will also automatically prorate/decrease the price of the certificate relative to the validity selected. If you need any help with your account or testing, please don't hesitate to reach out.
I think we could also get ACME to work for provisioning if that's beneficial. We'll have to map the inclusion of the extension out of band, so I'd need to come up with a solution there, but otherwise it should be feasible.

[shigeki]

@clintwilson Thank for offering your help. We can purchase only one or two years SXG certs via Cyberturst in Japan.

ACME needs challenge and response so that we can do it to fallbackURL if it is online. Currently fallbackURL is implemented as reqeustURL. That has a risk to renew the existing cert in online .

I think it is too early to limit the lifetime of SXG cert in 90 days for we do not know if it can really operative.

6.2. Off-path attackers in Security considerations only describes about an attacker who already possesses a valid certificate. We should add the consideration of how much we need to care about misissuance of CA before discussing SXG cert lifetime. Do we really need to care about a serious CA incident such as DigiNotar in 2011?

[jyasskin]

@shigeki Thanks for the feedback and for continuing the conversation via @sisidovski. It looks like you've found a way to get a <1-year certificate that matches the timeline I added here since your comment.

I wrote up some considerations at #378 (comment) that I think mean we should go for a 90-day max-lifetime for this year, and the other 2 people who voted, agreed. Given that, I'm going to merge this change.