Hi Hannes,
From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com]
> [Hannes] It is true that the raw public key RFC does not use long-term ECDH
> keys
> but instead uses those only in an ephemeral way. I would consider a design
> feature rather than a bug.
I'm certainly not calling it a
Ludwig, Hannes,
The differences with RFC7250 are twofold:
1. The raw public keys are not exchanged in the handshake sequence. Even with
cached info (RFC7924), a fingerprint of the certificate (or raw public key) is
exchanged. Also, a ClientVerify message is needed if mutual authentication is
Hi Tony,
If I understand your idea correctly then you have just re-invented the raw
public key concept defined in https://tools.ietf.org/html/rfc7250
Ciao
Hannes
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Tony Putman
Sent: 06 December 2017 14:42
To: ace@ietf.org
Subject: [Ace]
On 2017-12-06 15:41, Tony Putman wrote:
Hi,
I recently produced an I-D for a TLS authentication method using
pre-shared ECDH asymmetric keys, which I believe will be useful for
constrained environments. IMHO the key benefits are:
- a breach of server security does not result in client
Hi,
I recently produced an I-D for a TLS authentication method using pre-shared
ECDH asymmetric keys, which I believe will be useful for constrained
environments. IMHO the key benefits are:
- a breach of server security does not result in client impersonation (unlike
PSK)
- a single EC
Thanks Samuel,
I agree with your answers and proposed actions except for the below:
> I think the language in section 3 is enough to get robust implementations.
> "all claims that are not understood by implementations MUST be ignored."
Ignoring a claim is very different from ignoring an
Thanks Esko for your review it is greatly appreciated.
see comments inline
On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk wrote:
> Dear all,
>
> Overall the document looks in good shape to go forward if the earlier
> mentioned issue of multiple values for "audience"