[noise] certificate chains

[Justin Cormack]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180630/d9aab15d/attachment.html>