On Wed, Jul 13, 2016 at 03:07:46PM -0700, Eric Rescorla wrote:
> On Wed, Jul 13, 2016 at 1:36 PM, Ilari Liusvaara
> wrote:
>
>
>
> >
> > > And then add new code points for being able to use the PSK with and
> > > without signatures (from the server). We had pretty rough consensus in
> > > B-A t
On Thursday 14 July 2016 09:17:06 Martin Thomson wrote:
> On 14 July 2016 at 03:01, Eric Rescorla wrote:
> >
> > Obviously, you could add a check that said that if an EC cipher suite was
> > advertised, then you had to look for key shares even if you picked one, but
> > it's not a check you otherw
On Thu, Jul 14, 2016 at 11:32:00AM +0300, Ilari Liusvaara wrote:
>
> I was thinking of just scanning the server key_share in order the groups
> appear... With no mixing if no key_share is absent.
>
> This would unify DHE-PSK and PSK for purposes of later handshake.
>
> Would need a way to ensure
The consensus of the WG is to not make the changes to the referred to by this
msg.
Hannes,
Please respond to the RFC Editor to complete AUTH48 processing of this draft.
J&S
> On Jul 06, 2016, at 13:45, Sean Turner wrote:
>
> Anirudh noted [0] that existing implementation practices in TLS sta
Naïve question: why not simply get a constrained CA certificate and issue
short-validity end entity certs? Unless I’m missing something, this would work
with existing TLS implementations, no extensions required.
Short-lived credential approach seems more viable than
draft-mglt-lurk-tls-requirem
> Naïve question: why not simply get a constrained CA certificate and issue
> short-validity end entity certs?
Wouldn't you need one for every potential user? And the nameConstraints then
becomes a union of all SAN fields?
> Short-lived credential approach seems more viable than
> draft-mglt-l
