All,
It’s time to put this one to bed. ekr’s going to put back user_mapping for
Andrei/MS, but we’re going to ban/orphan the client_authz and server_authz
extensions. If it turns out that there’s some need to later unban/unorphan
them, then somebody can write a draft that specifies how they’r
I agree that client_authz and server_authz have not enjoyed much implementation.
Russ
On Sep 3, 2016, at 3:54 PM, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/pull/624
>
> We currently have code points assigned for
>
> user_mapping [RFC4681]
> client_authz [RFC5878]
Yes, I think so.
Cheers,
Andrei
From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Saturday, September 3, 2016 4:07 PM
To: Andrei Popov
Cc: tls@ietf.org
Subject: Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3
Thanks for flagging this. Looks like it can just go right before Certificate
omain users). We do not implement client/server_authz.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Saturday, September 3, 2016 12:54 PM
> *To:* tls@ietf.org
> *Subject:* [TLS] PR #6
: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3
https://github.com/tlswg/tls13-spec/pull/624
We currently have code points assigned for
user_mapping [RFC4681]
client_authz [RFC5878]
server_authz [RFC5878]
These aren't well-specified for use in TLS 1.3 and my sense is that they
are b
https://github.com/tlswg/tls13-spec/pull/624
We currently have code points assigned for
user_mapping [RFC4681]
client_authz [RFC5878]
server_authz [RFC5878]
These aren't well-specified for use in TLS 1.3 and my sense is that they
are barely used. Any objections to just banning them? If not, I
