[noise] certificate chains

[Arvid Picciani]

thanks trevor,

i'm using  IX now like so:
again, u is ed25519 pub key, and u(s) is signature over s plus a
protocol identifier as suggested by travor

       <- u
       ....
      -> e, s
      <- e, ee, se, s, es, u(s)
      -> u, u(s)


are there any specs from this group for signature chains?
i'm making up my own now, but i'd love to read something with the
quality of the noise spec.

this is what i have:

general structure:

1. public key of signer
2. the stuff signed
3. signature

example:

1. id of authority
2. grant access for public id of server
3. to public key of client
4. signature of authority

5. id of client
6. bind to static x25519 key s
7. signature of client








































On Sun, Jul 1, 2018 at 11:39 PM, Trevor Perrin <trevp at trevp.net> wrote:
> On Sun, Jul 1, 2018 at 8:06 PM, Arvid Picciani <aep at exys.org> wrote:
>>
>> i feel like the full details would be a bit boring and offtopic,
>> but essentially it's distributed routing table where a route is signed
>> by the recipient.
>> so each recipient is necessarily an ed25519 public key.
>>
>> simplified table:
>>
>> recipient |  via | otherstuff | signature
>> ---------------------------------------------------
>> pub key 1 |  pub key 2 | .. | signed by privkey 1
>>
>> in order to each a party, you validate its signature in the table and
>> connect to the peer in via.
>> there's some port magic done and we end up with a direct stream socket
>> established between pubkey1 and the initiator
>> now we're in noise land.
>
> That's still pretty vague, but it seems like you have long-term
> signing keys that are being used to sign things, and you want to also
> use them for authentication in Noise.
>
> It's safest to not reuse keys in different protocols, so a good option
> would be to sign a Noise DH static key, which is only used in Noise.
> Then you could just send these signatures along with the static DH
> keys in XX.  You would have to be careful that the static signatures
> cannot be confused with other signatures (cross-protocol attacks),
> e.g. by always signing a "signature type" value that describes the
> purpose of the signature.
>
> As a starting point, you might see if that works.
>
>
>>> unauthenticated Noise handshake, then exchange signatures over the handshake hash afterwards
>>
>> by that you mean XX or is the handshake hash in NN safe? I am really
>> scared of singing anything that is based on just ephemerals
>> transmitted on the wire. It just seems like it might be easy to
>> replay.
>
> The handshake hash in NN is based on your own ephemeral, which is a
> fresh random value, so cannot be replayed.
>
> But again, you'd have to be careful about signatures and cross-protocol attacks.
>
>
>>> Offline signing keys
>>
>> this sounds very close to what i want, but isnt it the wrong way
>> around? If i read this correctly my case is more like:
>> (naming signature 'u' here, for a lack of understanding this properly,
>> very sorry)
>>
>>   <- u
>>   ...
>>   -> e
>>   <- e, ee, s, u(s), es,
>>   -> s, u(s), se,
>
> I don't know what you mean by the "wrong way around".  You would just
> send the signatures in the handshake payloads, you wouldn't have to
> modify the pattern.
>
>
>>> to use signatures directly.
>>
>> well, that would be really cool, but a totally different cryptosystem
>> so i dont feel comfortable wandering there alone.
>> Can you just simply sign the ephermal?
>
> You'd want to sign the handshake hash, by replacing the "es" and "se"
> tokens with signatures.  This is "on the roadmap" for Noise, but we
> haven't fleshed it out.
>
> Trevor