4 ms·

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 form

by johnp_ 7y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1545836 [1] https://tools.ietf.org/html/rfc8152#section-4.5 https://tools.ietf.org/html/rfc8152#section-4.5 [2] https://searchfox.org/mozilla-central/rev/b9da45f63cb567244933c77b2c7e827a057d3f9b/security/apps/AppSignatureVerification.cpp#644 https://searchfox.org/mozilla-central/rev/b9da45f63cb5672449...

josteink 7y ago
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.
- hunter2_ 7y ago
  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 7y ago
    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.
- Vinnl 7y ago
  > 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.

by johnp_ 7y ago

josteink 7y ago

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.

hunter2_ 7y ago
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 7y ago
  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.
Vinnl 7y ago
> 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.