[johnp_]

It seems Mozilla is in the process[0] of moving the signature scheme to COSE, which allows timestamping[1]. A code comment[2] says that the current package format doesn't allow it.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1545836

[1] https://tools.ietf.org/html/rfc8152#section-4.5

[2] https://searchfox.org/mozilla-central/rev/b9da45f63cb5672449...

[josteink]

If that is true, they should mention this in the post-mortem.

Code signing is a well understood problem with a well known solution, but the blog post discusses everything except the well known solution.

Right now you have a problem caused directly by lack of time stamping, and the article doesn’t even acknowledge that.

That’s not inspiring confidence. I’m genuinely still not sure if they have understood what the actual problem is and how to solve it properly.

[Vinnl]

> If that is true, they should mention this in the post-mortem.

They might:

> We’ll be running a formal post-mortem next week and will publish the list of changes we intend to make

The lessons noted down here are just some thoughts by the author of this blog post:

> but in the meantime here are my initial thoughts about what we need to do.

[hunter2_]

Exactly, the article specifically calls for inventorying, not eliminating, "ticking time bombs." As for the inventory, dealing with non-ACME certificate creation without some kind of calendar/reminder mechanism is pretty crazy to me.

[tialaramex]

Nice password by the way.

I thought the mention of "ticking time bombs" showed someone is thinking about this properly because end users get the same experience if e.g. a timer gets treated as negative in 2038 or the browser depends on the century field being 20 as they do if an X.509 certificate expires. If you are sure you handled all certs, but you blow up because your GPS epoch wrapped then you still screwed up.