On Mar 17, 2018, at 5:22 PM, Mohit Sethi wrote:
> In the morning, the client and server were always able to authentication each
> other successfully. We added about 7 intermediate CAs in-between the client
> end-entity certificate and the root-CA certificate. However, the client and
> server we
Hi Alan and Bernard,
Darshak, Aleksi and I are currently running some experiments at the IETF
hackathon to re-produce the problem of EAP-TLS authentication with large
certificates and long chains.
We have been generating root CA certificates, intermediate CA
certificates, and end-entity cert
On Feb 5, 2018, at 4:03 AM, Mohit Sethi wrote:
> Thanks for raising this issue. I am trying to understand the problem of large
> certificates and longer certificate chains a bit better.
>
> From your deployment experience, is the problem equally bad for
> authentication in both directions (i.e.
Hi Alan,
Thanks for raising this issue. I am trying to understand the problem of
large certificates and longer certificate chains a bit better.
From your deployment experience, is the problem equally bad for
authentication in both directions (i.e. both client and server
certificates are larg
> On Jan 18, 2018, at 9:25 AM, Jari Arkko wrote:
>
> Here’s a second spin of the potential WG charter. I will talk to the ADs and
> see what we can do with this… would also appreciate any further comments or
> expressions of support or objection from you all :-)
That looks good to me. I th
Alan, John,
> On Dec 22, 2017, at 1:12 PM, John Mattsson wrote:
>> In TLS 1.3, ECC is mandatory to support. This drastically reduces the sizes
>> of certificates and signatures (public key sizes from 384 bytes (RSA and
>> DHE) to 32 bytes (ECDHE) and signatures from 384 bytes (RSA) to 64 bytes
On Dec 22, 2017, at 1:12 PM, John Mattsson wrote:
> In TLS 1.3, ECC is mandatory to support. This drastically reduces the sizes
> of certificates and signatures (public key sizes from 384 bytes (RSA and DHE)
> to 32 bytes (ECDHE) and signatures from 384 bytes (RSA) to 64 bytes (ECDSA
> and EdDS
On Dec 21, 2017, Alan DeKok wrote:
>The question I have is whether we can do anything to EAP-TLS to address the
>issue. Answering that question >requires a deeper dive into TLS.
In TLS 1.3, ECC is mandatory to support. This drastically reduces the sizes of
certificates and signatures (public k
On Dec 21, 2017, at 9:07 AM, Jari Arkko wrote:
>
>> I've seen people run into this issue with large certificates and long
>> certificate chains. It would be good to find a way to allow this use-case.
>
> That’s interesting.
>
> Do you have any suggestions on what to do about this issue, or we
> The Session ID also needs to be defined for SIM and AKA, as per Jouni's
> comments. That doesn't fit in with AKA' changes.
Yeah, I was thinking about that but didn’t go far enough. But you’re right.
Maybe this needs to be a separate item for EAP-SIM.
> It may also be worth re-examining EAP-
On Dec 21, 2017, at 8:40 AM, Jari Arkko wrote:
>
> I’ve been thinking of what to do with the EAP work that got discussed both in
> the SAAG meeting last time (my drafts), as well on the list. The latter was
> more on the EAP-TLS side, and it seems that the discussion has converged to a
> reaso
11 matches
Mail list logo
