Yes, digesting the chain is likely to fail. The set of "intermediates" that
are included are not a strictly deterministic set. Counter-signing of trust
anchors and other such practices mean that the client and server wouldn't be
able to agree to the point that a digest would be reliable.
Ther
Hi Martin,
Could you comment on how the client and server know they agree on the
certificate chain?
Would it be possible for the client and server to resolve the certificate
chain down two distinct paths, for example in the case of cross signed
certificates?
If so, is there a security risk here,
On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote:
> And one more
>
> "The 0xTBD flag can only be send in a ClientHello or CertificateRequest
> message. Endpoints that receive a value of 1 in any other handshake
> message MUST generate a fatal illegal_parameter alert."
>
> This goes agai
And one more
"The 0xTBD flag can only be send in a ClientHello or CertificateRequest
message. Endpoints that receive a value of 1 in any other handshake message
MUST generate a fatal illegal_parameter alert."
This goes against draft-nir-tls-tlsflags
"A server that supports this extension
Some more comments after reading the draft in detail.
- The abstract and introduction only talks about the ClientHello use case.
Should shortly mention the CertificateRequest use case as well.
- I notice that the draft does not have any requirement on how the client gets
access to the intermedi
Hi,
I am strongly supporting of solving the problem this draft is trying to solve.
This is a problem that the EMU WG has identified and discussed in the past.
https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02
I will add text discussing draft-thomson-tls-sic-00 to
draft-ms-emu-eaptlscert-0
