[noise] certificate chains

[Arvid Picciani]

ok x255519 can be derived from ed25519 just fine.
here's what's working for me with XK:

1. initiator knows the ed25519 pubkey of the responder from an offline exchange
2. responder knows the ed25519 pubkey of a CA
3. responder derives a static x255519 sk/pk pair from its static ed25519
4. initiator derives a static x255519 sk/pk pair from its static ed25519
5. -> e, es
6. <- e, ee
7. > s, se  with payload being the initiators ed25519 plus its signature chain
8. responder derives x255519 pubkey from the ed25519 in payload and
verifies it is identical with s
9. responder verifies the rest of the chain contains a signature by the CA

Other than using constant time comparison in 8, any other pitfalls in
this model?
In theory sending the static key in 7 isn't even nessesary since it
can be derived from the payload,
but i dont see a buildin noise mode that does the right thing here.

https://github.com/aep/0x/blob/361559e195ec5ae4b89ef1f3f6a16521b300c6a7/src/session.rs#L222

On Sun, Jul 1, 2018 at 9:44 AM, Justin Cormack
<justin at specialbusservice.com> wrote:
> If you need the signature keys to match, then one option might be to use a
> one way Noise message of type K (or X) from the the guarantor to the
> recipient which contains the initiators public key. The recipient can then
> decrypt this, check or validate it is from the right party and that it
> decrypts to the right public key. It is a bit longer than a signature but
> uses the same keys.
>
> On Sat, 30 Jun 2018, 23:41 Arvid Picciani, <aep at exys.org> wrote:
>>
>> Nice, Thanks.
>>
>> unfortunately i can't figure out how to use XK, because Noise of
>> course uses x25519 not ed25519 so the public identities for DH dont
>> match the identities used for signing,
>> I found this thread from Trevor on signing using x25519
>> https://moderncrypto.org/mail-archive/curves/2014/000205.html  but
>> there's no conclusion.
>>
>> So short of any way of doing that i either have to use static keys
>> that are actually not static but generated on the fly and signed, or
>> use NN and not auth at all.
>> or am i missing something?
>>
>>
>>
>>
>> On Sat, Jun 30, 2018 at 8:11 PM, Trevor Perrin <trevp at trevp.net> wrote:
>> > Hi Arvid,
>> >
>> > You could also look at the "NLS" draft in the wiki:
>> >
>> > https://github.com/noiseprotocol/nls_spec/blob/rev2/output/nls.pdf
>> >
>> > This defines some protobuf structures for use in handshake payloads.
>> > These protobufs can negotiate "evidence blob" types and then send
>> > "evidence blobs".
>> >
>> > The evidence blobs could contain certificates.  We're naming them so
>> > generically because they might contain different types of certificates
>> > or signatures, or things like Certificate Transparency proofs -
>> > basically they should contain "evidence" for the static public key...
>> >
>> > Trevor
>> >
>> >
>> >
>> > On Sat, Jun 30, 2018 at 2:53 PM, Arvid Picciani <aep at exys.org> wrote:
>> >> Thanks to you both, got it working by using the payload in -> s, se
>> >> with XK as suggested.
>> >> The rest was actually nicely documented and easy to understand. Noise
>> >> is incredible!
>> >>
>> >> On Sat, Jun 30, 2018 at 4:16 PM, Justin Cormack
>> >> <justin at specialbusservice.com> wrote:
>> >>> You may want to include both the peer and recipient public keys in the
>> >>> cert,
>> >>> and potentially do an XK handshake. Otherwise your cert is rather
>> >>> broadly
>> >>> applicable.
>> >>>
>> >>> On Sat, 30 Jun 2018, 14:10 Marian Beermann, <public at enkore.de> wrote:
>> >>>>
>> >>>> For something like Noise_XX you'd do it like this:
>> >>>>
>> >>>> Have certificates for each peer signed by your authority. They
>> >>>> include a
>> >>>> X25519/X448 public key, which is the static key used for the
>> >>>> exchange(s).
>> >>>>
>> >>>> Do the ephemeral exchange. No extra messages here (empty payloads).
>> >>>>
>> >>>> Then, when each peer sends her public static key, the payload is her
>> >>>> certificate.
>> >>>>
>> >>>> Each peer verifies that (a) the public key received matches the
>> >>>> public
>> >>>> key in the certificate (=a weak form of binding) (b) the certificate
>> >>>> was
>> >>>> signed by the authority.
>> >>>>
>> >>>> -Marian
>> >>>>
>> >>>> On 30.06.2018 14:38, Arvid Picciani wrote:
>> >>>> > Could you point me at the specific things i should be careful
>> >>>> > about?
>> >>>> > Simply putting something like an x509 in the first message would
>> >>>> > mean
>> >>>> > i separate authentication from encryption.
>> >>>> > Leaving the safe guidance of noise by disabling part of it feels a
>> >>>> > little scary.
>> >>>> >
>> >>>> > On Sat, Jun 30, 2018 at 2:25 PM, Justin Cormack
>> >>>> > <justin at specialbusservice.com> wrote:
>> >>>> >> There is nothing officially defined yet, although there are
>> >>>> >> mentions
>> >>>> >> that it may be in a future release,
>> >>>> >> to replace some of the DH by certs.
>> >>>> >>
>> >>>> >> However you can implement it yourself by using the extra messages
>> >>>> >> in
>> >>>> >> the handshake to include a
>> >>>> >> certificate that signs the key that has been passed (in an X or I
>> >>>> >> handshake), and using that to validate
>> >>>> >> the key. You need to be a little careful about the security
>> >>>> >> properties
>> >>>> >> of the additional messages at
>> >>>> >> the point where it is sent.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On 30 June 2018 at 13:05, Arvid Picciani <aep at exys.org> wrote:
>> >>>> >>> Hi,
>> >>>> >>>
>> >>>> >>> i'm super confused if cert chains are actually possible with
>> >>>> >>> noise.
>> >>>> >>> The initial AKE seems to assume that the static keys are ALWAYS
>> >>>> >>> used
>> >>>> >>> for auth and crypto at the same time.
>> >>>> >>>
>> >>>> >>> Am i looking at this from the wrong angle here? I'm trying to
>> >>>> >>> figure
>> >>>> >>> out a way to have:
>> >>>> >>>
>> >>>> >>> - an encrypted connection from A to B
>> >>>> >>> - where B only knows about C
>> >>>> >>> - but A has obtained prior proof that C authorized A (ed25519 for
>> >>>> >>> example)
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> /b/
>> >>>> >>> Arvid
>> >>>> >>> _______________________________________________
>> >>>> >>> Noise mailing list
>> >>>> >>> Noise at moderncrypto.org
>> >>>> >>> https://moderncrypto.org/mailman/listinfo/noise
>> >>>> > _______________________________________________
>> >>>> > Noise mailing list
>> >>>> > Noise at moderncrypto.org
>> >>>> > https://moderncrypto.org/mailman/listinfo/noise
>> >>>> >
>> >>>>
>> >>>> _______________________________________________
>> >>>> Noise mailing list
>> >>>> Noise at moderncrypto.org
>> >>>> https://moderncrypto.org/mailman/listinfo/noise
>> >> _______________________________________________
>> >> Noise mailing list
>> >> Noise at moderncrypto.org
>> >> https://moderncrypto.org/mailman/listinfo/noise