[noise] certificate chains

[Arvid Picciani]

ack. so essentially all i need is to send a signature from C of s,
does that make sense?
the responder can then _after_ the kex decide if the connection is
authorized by verifying rs was actually an ok key by verifying _only_
the signature it receives as encrypted message is signed by C and its
actually a valid signature of the text rs.

Or could i use the prologue for this somehow? It looks like that wont
work because its hash is included in the session key?

On Sat, Jun 30, 2018 at 2:53 PM, Justin Cormack
<justin at specialbusservice.com> wrote:
> No, you can't do that, the cert has to refer to the key in the Noise protocol.
>
> Justin
>
>
> On 30 June 2018 at 13:38, Arvid Picciani <aep at exys.org> 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