Le 24/12/2014 17:37, Nicholas Alexander a écrit : > Yes, I'm all for using curves like *25519, which is what backs > libsodium. In fact, I want to use it for FxA public/private key pairs > precisely so that it's easier to generate strong keypairs without > having to do RSA or DSA key generation. But that's not what I'm > talking about here. > > This isn't about limiting the number of key pairs at any point in the > flow. What I wanted to limit was the number transferred during one > interaction, meaning the user agent can say "only give me these 3 > keys" rather than getting an unbounded list of keys. The motivation > is that, as written, it looks like we guarantee the entire set of > possible keys gets transferred, and every one is public key encrypted > -- separately -- with the same public key. What I'm suggesting is to > do *one* public key encryption of the set of keys.
Ok for me they are only kAr and kBr (kAr linked to an account, kBr linked to an account's password) > > > What I understood is that the public key is send only on the > /authorization endpoint and kept for use on the /token > > > The spec returns the keys that was sent to /authorization. If we're > tunneling them through, but we can't rely on them, why tunnel them at all? I didn't get that. What cannot we rely on and what do you want to tunnel? In the FxA database they are kA and wrap-kB that we derive to get encrypted((kAr,kBr), DH(transactionPublicKey, tempPrivateKey)) that we get back on /token with tempPublicKey. And transactionPublicKey is sent on /authorization My question is how do we makes sure that the server doesn't store/log kAr and kBr before encryption? — Rémy
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
