On 4/20/21 7:00 PM, Martin Thomson wrote:
> On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote:
>> Taking a step back, it would be great if we could reach consensus on
>> whether or not this is a use case we actually want to solve.
>
> The Web currently recognizes IP certificates. The
Hi! Thanks for all those who volunteered. Chris Wood, Chris Patton, David
Benjamin, Stefen Farrell, and Eric Rescorla are the members of the ECH+HRR DT.
They will report out at our next interim which we are planning for late May.
Cheers,
spt
___
TLS
>All that said, IP certificates are naturally a feature with narrow
> applicability. For something like ECH fallback, which should be rare, we
> benefit more from reduced options and simplicity than we do by enabling niche
> features. Adding a dependency on a rarely used feature, optional
Hi Francesca,
> Then I guess 53 will become unassigned, no need to reserve it, right?
After a "reserved period", yes.
If that value is then assigned for TLS or DTLS 1.3 only, then that
period may be very short. If that value is assigned also for DTLS 1.2
(again), I would prefer a longer
Hi Hannes, Achim,
Thanks, that's all I was curious about! No need to add that to the IANA
considerations, this was more of a question on my side. Then I guess 53 will
become unassigned, no need to reserve it, right?
Thomas: thanks for creating the issue - I will track there.
Francesca
On
Hi John,
[*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew
obfuscation!
Which one of these is clearer seems like a question of taste, I should think.
It's worth noting that because the length prefix is determined by the ceiling,
arguably 2^8-1 is clearer.
I don’t
Hi Francesca,
~ snip ~
5. -
Section 10.2
FP: Just checking - why is 53 "incompatible with this document"?
[Hannes] Maybe someone responded already regarding this point. I don't know
whether it is good or bad practice to provide all this background in the IANA
considerations but the
