[noise] certificate chains

[Justin Cormack]

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