<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">Le 24/12/2014 17:37, Nicholas Alexander
      a écrit :<br>
    </div>
    <blockquote
cite="mid:CAMnWBR38-Tav8wpeW6Bv912R-gTToDoW4eNv1BY5rdjg9YzWew@mail.gmail.com"
      type="cite">
      <div dir="ltr">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.<br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>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.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Ok for me they are only kAr and kBr (kAr linked to an account, kBr
    linked to an account's password)<br>
    <br>
    <blockquote
cite="mid:CAMnWBR38-Tav8wpeW6Bv912R-gTToDoW4eNv1BY5rdjg9YzWew@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">What I
              understood is that the public key is send only on the<br>
              /authorization endpoint and kept for use on the /token<br>
            </blockquote>
            <div><br>
            </div>
            <div>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?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I didn't get that. What cannot we rely on and what do you want to
    tunnel?<br>
    <br>
    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.<br>
    And transactionPublicKey is sent on /authorization<br>
    <br>
    My question is how do we makes sure that the server doesn't
    store/log kAr and kBr before encryption?<br>
    <br>
    — Rémy<br>
  </body>
</html>