[{"author": "Alan DeKok", "text": "<p>Looks like a small (but hopefully dedicated) crowd. :)</p>", "time": "2022-07-27T19:00:05Z"}, {"author": "Jan-Frederik Rieckers", "text": "<p>@meetecho can you pan the camera?</p>", "time": "2022-07-27T19:06:32Z"}, {"author": "Jonathan Hammell", "text": "<p>draft-ietf-tls-external-psk-importer has recently been published as RFC 9258</p>", "time": "2022-07-27T19:16:11Z"}, {"author": "Hazel Smith", "text": "<p>Unsure if the echo is from in the room, but it's still pretty bad</p>", "time": "2022-07-27T19:31:54Z"}, {"author": "Deb Cooley", "text": "<p>definitely feedback in the room....</p>", "time": "2022-07-27T19:35:56Z"}, {"author": "Deb Cooley", "text": "<p>Meetecho is here, though</p>", "time": "2022-07-27T19:36:05Z"}, {"author": "Hazel Smith", "text": "<p>Presumably certificates from WebPKI are only useful if you have a subject domain name that you can somehow trust is \"appropriate\" for the network (or is at least shown to the user, so they can decide if joining a network with domain name \"<a href=\"http://totallyrealtelco.geocities.com\">totallyrealtelco.geocities.com</a>\" is for them or not)?</p>", "time": "2022-07-27T19:37:39Z"}, {"author": "Alan DeKok", "text": "<p>EAP-TLS typically used already with certificates from webPKI</p>", "time": "2022-07-27T19:44:49Z"}, {"author": "Alan DeKok", "text": "<p>which then means that the certificate contains a domain, which is sent to the EAP peer in a TLS exchange</p>", "time": "2022-07-27T19:45:17Z"}, {"author": "Hazel Smith", "text": "<p>Yeah, quite. I guess I simply meant that whatever CA you use, the client needs some way to decide whether it \"likes\" the domain name presented? (Is that shown to the user? Is that an administrator-configured thing? Is it more like a \"the domain just has to be consistent from step to step in the process\" thing?</p>\n<p>(Sorry if the question is overly naive here.)</p>", "time": "2022-07-27T19:46:35Z"}, {"author": "Alan DeKok", "text": "<p>That would be nice, but domain name verification is poorly done in EAP.  Largely it's \"trust server certs from this CA\".  Any information about the certs is well hidden from the user :(</p>", "time": "2022-07-27T19:48:49Z"}, {"author": "Alan DeKok", "text": "<p>some suppliants support configuration which says \"server cert must have subjectAltName from domain <a href=\"http://example.com\">example.com</a>\", but not every one supports that</p>", "time": "2022-07-27T19:49:43Z"}, {"author": "Hazel Smith", "text": "<p>Yeah :(</p>\n<p>(At the university I used to work at, we had a \"$universityname-wifi-setup\" network that basically captive-portal-redirected you to a page with some provisioning config files and/or tools for Android/IOS/WIndows/Linux/MacOS and you basically just had to satisfy yourself that you were happy downloading these files/programs from wifisetup.$universityname.ac.uk)</p>", "time": "2022-07-27T19:50:30Z"}, {"author": "Deb Cooley", "text": "<p>Is that the usability document?</p>", "time": "2022-07-27T19:52:04Z"}, {"author": "Alan DeKok", "text": "<p>yes</p>", "time": "2022-07-27T19:52:09Z"}, {"author": "Alan DeKok", "text": "<p>I would like implementors to correctly implement existing EAP methods first :)</p>", "time": "2022-07-27T19:52:54Z"}, {"author": "Jan-Frederik Rieckers", "text": "<p>+1 for certificate guidelines</p>", "time": "2022-07-27T19:53:54Z"}]