Hey Jacob, You missed the part in Karthik's email where he said that both keys have to sign both keys :) The current structure has a copy/paste vulnerability. I went ahead fixed this in the current parallel-signature structure...
https://github.com/ietf-wg-acme/acme/issues/149 https://github.com/ietf-wg-acme/acme/pull/150 ... though it's simpler in the nested-signature case, so I would propose we move back to that. https://github.com/ietf-wg-acme/acme/issues/148 --Richard On Fri, Jul 1, 2016 at 1:39 PM, Jacob Hoffman-Andrews <[email protected]> wrote: > > In principle, this suggestion would work, but could you clarify the > structure of the JSON object? Does it still contain the oldKey? > > Yep: "The protected header must contain a JWK field containing the > current account key." > > > The safest design would be to have the JSON object include the > thumbprints of both the old and new keys and then sign it with both the > new and old keys. > > This design means that the JSON object contains not the thumbprints, but > the full keys, both old and new. The old key is in the JWS protected > header (and therefore covered by both signatures), and the new key is in > the payload body. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
