I don't support this PR. Compactness of wire presentation is important
(and acknowledged - why would there be a compressed header otherwise)
and implicit CIDs should hence allowed and authenticated via AEAD additional
data,
preferably by generally adopting the pseudo header AAD approach.
Disappoin
I am reluctant to make CTLS standards-track without a statement from someone
that they are likely to implement it. We already have such a statement from
Stephen about OpenSSL for ECH, and I'll add to that.
___
TLS mailing list
TLS@ietf.org
https://ww
This is the 3rd WGLC for "Exported Authenticators in TLS" draft available at
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. The
secdir review during IETF LC raised some issues and as a result there have been
a couple of new versions. Please respond to the list with any
We have already implemented ECH (old versions) for NSS and are eager to
deploy it in Firefox.
We are likely to implement cTLS.
-Ekr
On Fri, May 22, 2020 at 6:20 AM Salz, Rich wrote:
> I am reluctant to make CTLS standards-track without a statement from
> someone that they are likely to implem
* We are likely to implement cTLS.
I believe we need to hear more definitively, ideally from others, before moving
this to standards-track.
Right now, I believe it should stay experimental.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma
On Thu, May 21, 2020 at 11:23 AM Ryan Sleevi wrote
>>
>> I am aware of the "fight" about EKU chaining. I have a view, but I did not
>> really want to drag subcerts into that controversy.
>
>
> Sure, but unfortunately, the design of DC/subcerts is a direct result of that
> running code.
One of
> On May 22, 2020, at 9:23 AM, Sean Turner wrote:
>
> This is the 3rd WGLC for "Exported Authenticators in TLS" draft available at
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. The
> secdir review during IETF LC raised some issues and as a result there have
> be
>One of the hard requirements for our deployment was that the same
certificate be useable with DCs and without. A different EKU would be
more problematic then an extension for this purpose
That's a good point, and I accept Ryan's comments about EKU deployment.
