<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jul 1, 2018 at 8:41 AM, Arvid Picciani <span dir="ltr"><<a href="mailto:aep@exys.org" target="_blank">aep@exys.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nice, Thanks.<br>
<br>
unfortunately i can't figure out how to use XK, because Noise of<br>
course uses x25519 not ed25519 so the public identities for DH dont<br>
match the identities used for signing,<br>
I found this thread from Trevor on signing using x25519<br>
<a href="https://moderncrypto.org/mail-archive/curves/2014/000205.html" rel="noreferrer" target="_blank">https://moderncrypto.org/mail-<wbr>archive/curves/2014/000205.<wbr>html</a>  but<br>
there's no conclusion.<br></blockquote><div><br></div><div>The CA's signature on the certificate needs to use ed25519, but the subject's actual key would be x25519; i.e. "I the CA with signing key s warrant that DH key d belongs to the subject with name n".  The subject might also own other keys, including for signing other people's certificates.  Those may also be included in the certificate but don't matter for Noise session establishment.</div><div><br></div><div>Another approach is two-level: the CA signs the user's identity certificate containing the user's ed25519 key, which the user themselves uses to issue a transport certificate with their DH key.  Both are included in the certificate chain.  This would make it easier for the user to rotate transport keys over time under the same long-term identity.<br></div><div><br></div><div>Cheers,</div><div><br></div><div>Rhys.<br></div></div></div></div>