- From: Martin Thomson <notifications@github.com>
- Date: Sun, 20 Sep 2026 23:37:08 -0700
- To: w3c/push-api <push-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/push-api/issues/420@github.com>
martinthomson created an issue (w3c/push-api#420) The current cryptographic design loses many of the good properties we might like to have if a cryptographically-relevant quantum computer is created and applied to recovering secrets. I've started sketches of designs for a replacement cryptographic message protection here: https://github.com/martinthomson/webpush-pq My goal is to take these to the IETF DISPATCH process, as I think that the cryptographic review there is more likely to be robust. It is also easier to obsolete RFC 8291 with another IETF document. The work for the Push API is pretty limited. Defining a new member in [`PushSubscription`](https://www.w3.org/TR/push-api/#dom-pushsubscription) to carry new secrets or keying material is all that is needed, as well as updates to references and the ["receiving a push message"](https://www.w3.org/TR/push-api/#receiving-a-push-message) algorithm. It might make sense to use this opportunity to split out the declarative functions so that it is not necessary to opportunistically parse JSON for every message. The current design spends a lot of bytes on that, plus a bunch of wasted effort to probe for declarative messages. (Tracking that [here](https://github.com/martinthomson/webpush-pq/issues/2).) -- Reply to this email directly or view it on GitHub: https://github.com/w3c/push-api/issues/420 You are receiving this because you are subscribed to this thread. Message ID: <w3c/push-api/issues/420@github.com>
Received on Monday, 21 September 2026 06:37:12 UTC