If the PKI community as a whole (vendors, standards bodies, consortia, CAs) has managed to engineer a situation where, according to the strict letter of the law, CAs would have no choice but to revoke operators identity certificates for many of their services if Alan was actually mean and wrote his script, which would cause widespread outages, then, quoting Charles Dickens, "the law is a ass", and I'm with Alan and Richard and the law (the CP/CPS) should probably change.
> -----Original Message----- > From: Spasm <spasm-boun...@ietf.org> On Behalf Of Alan DeKok > Sent: 17 January 2020 19:39 > To: Ryan Sleevi <ryan-i...@sleevi.com> > Cc: sp...@ietf.org; Michael Richardson <mcr+i...@sandelman.ca>; Joseph > Salowey <j...@salowey.net>; Benjamin Kaduk <ka...@mit.edu>; EMU WG > <emu@ietf.org> > Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation > logic > > > On Jan 17, 2020, at 12:33 PM, Ryan Sleevi <ryan-i...@sleevi.com> 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 > separate > systems. > > > And in Section 16: > > Customer will only use a TLS/SSL Certificate on the servers accessible at > > the > domain names listed in the issued Certificate > > > > Remind me how an EAP-TLS/RADIUS server is accessible at that domain name? > > The RADIUS server has a domain name, which is commonly used in the > certificate. > > If that is insufficient for the CAs purposes, then we should also > acknowledge > that the revocation requirement likely also applies to SMTP, XMPP, DNS over > TLS, and IMAP. i.e. *all* non-WWW protocols which use TLS. > > We should not single-out EAP / RADIUS as mis-using the certificates in this > manner. The mis-use of these certificates in other protocols is orders of > magnitude larger than the EAP / RADIUS problem. > > > There's two parts of discussion from the thread: > > 1) What do extant clients do, today, in the verification of certificates > > used in > EAP-TLS > > EAP supplicants follow RFC 5216 Section 5.3. > > > 2) What should future clients do, 'tomorrow', to make this easier to use and > secure, ideally by default. > > Much of the answer was around #2, which is "Don't try to glom on to > something existing, you need to build your own thing", > > True. > > > as well as "Some of the answers in #1 are problematic and you should try and > discourage them" > > There were *allegations* of problems. > > > To connect it back to the discussion: The discussion about revocation, and > what a CA's CP/CPS says is or isn't allowed for a usage, matters, because > browsers require CAs promptly revoke those certificates in 24 hours/5 days for > situations when they specify bad requirements. Can problematic CAs fix their > CP/CPS to allow this? Yes. But you've still got a host of other > expectations/requirements that can and will diverge, over time. > > If I was mean, I would write scripts to troll the net for mis-use of > certificates in > SMTP, XMPP, IMAP, VPNs, etc. Then, make the script auto-submit notices to the > relevant CAs. That process is simple to do, and by the above rules, would > require the CAs to revoke the relevant certs. > > i.e. certs which affect a high percentage of daily internet traffic. > > If that scenario were to play out, I suspect that CAs would very quickly > stop > revoking the relevant certs. A straight-forward approach to enforcing the > rules > would be over-ruled by simple practicalities: Turning off big chunks of the > Internet is a non-starter. > > As Michael Richardson pointed out, then solution here is likely to fix the > rules, > not the protocols. > > > In the specific context of thinking about "#2" - what a touch-free future > > looks > like - having it use the same root store as Web browsers is the anti-pattern, > because the requirements are different. > > And therefore we need a different root store for *each* of EAP, RADIUS, > SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc. Note that we need *different* > stores for EAP and RADIUS, because RADIUS server are reachable on port 2083 > as RADIUS over TLS, *and* they implement TLS over EAP, which in turn carried > over RADIUS. Different use-cases, different root stores. > > There may be significant push-back against that many root stores. > > > There's no doubt the status quo is "Everything is manually configured" and > > "It's > inconsistent what is validated". The goal is to get to #2, "It just works" > > > > - Define your requirements (the certificate profile) > > - Define your policies (what do you expect CAs to verify, and how do they > verify) > > - Provide a way to distinguish "new certificates" from "The old and manual > cruft" - for example, an explicit EKU > > - Pick your poison.... er, CAs... for the new root store (e.g. as WiFi > > Alliance has > done, or Wireless Power Consortium has done, or plenty of vendors have done) > > - Have CAs issue certificates with both EKUs (old and new) in the leaf. > > It's a > SEQUENCE for a reason. > > - Have supplicants configured that > > - If new EKU is present, look in built-in store > > - If old EKU is present, require manual configuration > > > > This gets you half-way to #2: things can just work if you pick one of the > > new- > CAs with new-EKUs, and otherwise require manual configuration for old-EKUs > > That's good, but insufficient. There is a lot more verification that EAP > supplicants need to do before automatically trusting a root CA. > > I suspect that most CAs already know that their customers mis-use certs for > non-WWW purposes. EAP / RADIUS is just a minor (almost insignificant) part of > this problem. I also suspect most CAs operate based on the hope that no one > notices, and then requires them to revoke many, many, certificates. > > Alan DeKok. > > _______________________________________________ > Spasm mailing list > sp...@ietf.org > https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
