Agreed it is basically an aesthetic change.
Thanks,
Xuelei
On Tue, Jul 25, 2017 at 4:58 PM Eric Rescorla wrote:
> Given that this document has been through 2 WGLCs, and this is basically
> an aesthetic change, I don't think it gets over the barrier.
>
> -Ekr
>
>
> On Tue, Jul 25, 2017 at 4:48 P
Given that this document has been through 2 WGLCs, and this is basically an
aesthetic change, I don't think it gets over the barrier.
-Ekr
On Tue, Jul 25, 2017 at 4:48 PM, Xuelei Fan wrote:
> Hi,
>
> The TLS 1.3 Certificate handshake message is defined as:
>
>struct {
>opaque certi
Hi,
The TLS 1.3 Certificate handshake message is defined as:
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
certificate_request_context If this message is in response to a
CertificateRequest, the v
Hi Martin,
post-handshake authentication is indeed probably something that is less
likely to happen in the embedded environment and I will check whether
there are some use cases that require it.
If it isn't required then the best possible alternative at the moment is
for an embedded client implem
I don't think it would be sensible to set an upper limit in this case
(those lead to regrets in my experience), however, recommending that
the value be kept as small as possible seems OK. It's probably
redundant advice though.
Since this is extremely transitory state, I sort-of assumed that it
wo
Hi Martin,
this may be an implementation specific issue but some of the parameters
I have to keep in memory while others I "only" have to parse. In some
cases the embedded implementation also has control over the number of
parameters being included in a message (which is useful for bandwidth
reaso
On 7 October 2016 at 20:45, Hannes Tschofenig wrote:
> the problem is that with embedded implementations you need to be
> prepared to receive this amount of data when the specification says so.
How are you managing 65k session tickets, extensions, cipher suite
lists, supported group lists, etc...
Hi Martin,
the problem is that with embedded implementations you need to be
prepared to receive this amount of data when the specification says so.
On 10/07/2016 10:59 AM, Martin Thomson wrote:
> On 7 October 2016 at 19:34, Ilari Liusvaara wrote:
>> If application supports any sort of multiplex
On 7 October 2016 at 19:34, Ilari Liusvaara wrote:
> If application supports any sort of multiplexing (e.g. HTTP/2), one
> presumably wants the context to be non-opaque and identify the stream
> that caused the request + some parameters about the request (to avoid
> duplicating those in applicatio
On Fri, Oct 07, 2016 at 09:48:32AM +0200, Hannes Tschofenig wrote:
> Hi all,
>
> I am wondering why the certificate_request_context field found in the
> CertificateRequest and in the Certificate message is so long. It is
> supposed to be used to match a certificate request against incoming
> certi
Hi all,
I am wondering why the certificate_request_context field found in the
CertificateRequest and in the Certificate message is so long. It is
supposed to be used to match a certificate request against incoming
certificate.
Does the field really need to be up to 256 bytes long? I think 8 bytes
11 matches
Mail list logo
