Hi Ben,
Am 16.09.20 um 08:31 schrieb Achim Kraus:
Hi Ben,
If I did't get it, it may be easier to discus this as issue in the
github repo.
I think you got it; I am just failing to remember where the "MUST anyway
use new handshakes" requirement comes in from. And I guess that also
raises th
Sounds good to me.
I'm happy to send a PR making these changes, but couldn't find the
repository for the document.
Could you please point me to it?
best,
Nimrod
On Thu, 17 Sep 2020 at 17:12, Douglas Stebila wrote:
> Given that all the finalists and alternate candidates have fixed
> length shar
Rich,
Just to close the loop on this, there are three values: Y, N, and blank. I tend
to think we should mark is as “N”:
If an item is not marked as "Recommended" (i.e., "N"), it does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through
On Fri, Sep 18, 2020 at 10:28 AM Sean Turner wrote:
> Also, should we be adding “_legacy” to the names of the code points as was
> done for rsa_pkcs1_sha256_legacy by:
> https://www.ietf.org/archive/id/draft-davidben-tls13-pkcs1-00.txt?
>
My inclination is no. We didn't go about renaming the hug
Okay, I am find with the Y->N change. Nick, Yoav?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
ekr> Taking a step back from details, ISTM that the whole design of this
ekr> document is antithetical to extensibility:
I agree. It was my first reaction as well.
I then had another thought: there are dozens of entities out there that want
to do this regardless, enough that it broke the TLS ver
On Fri, Sep 18, 2020 at 3:12 PM Michael Richardson
wrote:
>
> ekr> Taking a step back from details, ISTM that the whole design of this
> ekr> document is antithetical to extensibility:
>
> I agree. It was my first reaction as well.
> I then had another thought: there are dozens of entities out t
