On Apr 14, 2021, at 1:29 PM, Tim Cappalli wrote:
>
> The equivalent to HTTPS with EAP would be if the ESSID was a subject name in
> the certificate and ESSIDs could be registered and validated. That doesn't
> exist today and wouldn't ever really work (or scale). The closest thing to it
> is se
The equivalent to HTTPS with EAP would be if the ESSID was a subject name in
the certificate and ESSIDs could be registered and validated. That doesn't
exist today and wouldn't ever really work (or scale). The closest thing to it
is server certificates for Passpoint OSU, which have their own iss
On Apr 14, 2021, at 10:56 AM, Tim Cappalli wrote:
>
> Honestly, no information in an EAP server certificate is good enough for a
> user to make a "walk up" informed decision.
I'm curious how this is different from say, HTTPS. The use-cases seem pretty
similar.
> At least requiring an EAP-s
Honestly, no information in an EAP server certificate is good enough for a user
to make a "walk up" informed decision. If the supplicant is not properly
pre-configured, all bets are off. TOFU is not acceptable.
At least requiring an EAP-specific EKU or OID would require operating systems
to sep
On Apr 13, 2021, at 8:17 PM, Michael Richardson wrote:
> Why did you need the HTTPS server cert?
> Did you need the OIDs, and stuff out of it? Why wasn't the realm name enough
> to make the imposter cert from the non-authorized CA?
>
> I'm just trying to understand how the HTTPS cert is involved
