Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Ryan Sleevi
Or... just stop using those certs/roots already? We’ve already identified that there is absolutely zero reason to do so in the extant status quo, because it still requires manual configuration. You get no benefits and clearly downsides, so just... don’t do that? Any complaints about how that

Re: [Emu] [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP.

2020-01-17 Thread Benjamin Kaduk
Hi Michael, You mention in a couple places that EAP server certificate should be identifying an rfc822Name DN, and I think I'm confused about what you mean. (I suspect I'm seeing "rfc822Name" and jumping to what ACP does, which is wrong.) Could you walk through an example of what that would look

[Emu] using public CAs for IDevID and device certificates

2020-01-17 Thread Michael Richardson
Michael Richardson wrote: > 3. End User Client Certificates > A client certificate used to authenticate an end user may be used for > mutual authentication in TLS, ***EAP-TLS***, or messaging. The client > (to be very very very clear: not a consensus document at this

Re: [Emu] Using public CA infrastructure for autonomic bootstrapping over EAP.

2020-01-17 Thread Alan DeKok
On Jan 17, 2020, at 5:19 PM, Michael Richardson wrote: > } c) supplicants do not check DNS names or any other field in the > certificates > } d) as a result of this lack of verification, supplicants ship with all > known > } CAs disabled for TLS-based EAP methods" For (d), CAs are

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Michael Richardson
Ryan Sleevi wrote: > While I think people are missing the forest for the tree, here's an > example CP/CPS from a CA: > https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf certsign.ro uses a Fortinet.com

[Emu] Using public CA infrastructure for autonomic bootstrapping over EAP.

2020-01-17 Thread Michael Richardson
{I've intentionally broken the thread, and I'm restarting the discussion. Please forgive the length} Alan DeKok wrote: >> Certainly, some of the excitement for ACME/Letsencrypt with DNS-01 challenge >> is that it makes it easy to get a certificate for a non-HTTP thing. >> >> I

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Alan DeKok
On Jan 17, 2020, at 12:33 PM, Ryan Sleevi wrote: > Does your RADIUS endpoint support and use OCSP stapling and disable WiFi if > the certificate is expired? No? Then it's a potential violation of this > CP/CPS. I'm not sure how a RADIUS server will disable WiFi. They are entirely

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Alan DeKok
On Jan 17, 2020, at 1:29 PM, Michael Richardson wrote: > You omitted an important part of that output, which is the name of the CA, > which I include below. Sure. > It could be that the CSP permits SMTP, or SUBMISSION service. > Ryan has suggested that CAs could put EAP-TLS (or EAP-TEAP) into

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Michael Richardson
Alan DeKok wrote: > Perhaps we should try? > $ openssl s_client -connect smtp.mozilla.org:587 -starttls smtp > mozilla.crt > $ openssl x509 -text -in mozilla.crt You omitted an important part of that output, which is the name of the CA, which I include below. It could be that the

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Ryan Sleevi
On Wed, Jan 15, 2020 at 11:07 PM Benjamin Kaduk wrote: > A couple things that stand out to me from having basically read the whole > thread in one go (this is not intended to be an exhaustive list of open > questions): > > It was implied but not fully clear to me, that Ryan thinks that someone

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Mohit Sethi M
On 1/16/20 6:07 AM, Benjamin Kaduk wrote: > Is there anything better for implementations to actually do (as distinct > from what we write down as recommendations) than to start setting up a > parallel (purpose-specific) PKI now and trusting that in parallel with what > they're currently doing,