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

[Alan DeKok <[e-mail]>]

On Jan 18, 2020, at 8:55 AM, Ryan Sleevi <[e-mail]> wrote:
> On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok <[e-mail]> wrote:
>   As noted by Michael, CAs are using certificates in a way that violates their own policy. 
> 
> Um, no. I largely didn’t respond to Michael’s email because it missed the mark rather substantially,

  In what way?

  It seems pretty black and white to me.  Your claim is that non-WWW use of these certs violates the policies of a particular CA.  Michael showed that the same CA was using certs for non-WWW purposes.

  You can't have it both ways.  Either your claims are true, and the CA should revoke the cert it's using for SMTP.  Or, your claims are false, and the CA's policy is *not* to revoke certs when used for non-WWW purposes.

  This is really the major disconnect here.  You're making fairly serious claims, and have little or no evidence to back them up.  You just can't say that Michael's email "missed the mark rather substantially", and expect everyone to believe that naked assertion.

  To put it another way, there are multiple people who read your statements as meaning one thing, but when pressed, you claim that you meant something else entirely.

> and I suspect folks still haven’t actually read the CP/CPSes or done the work.

  Those policies can best be described as "opaque".  There is no clear statement that "using certs with id-kp-serverAuth in non-WWW protocols is grounds for revocation".

> No. The root store operators make the rules. Standards that align with their needs are the standards they use and apply.

  Then this is an issue of warring standards bodies.  Each one thinks that they're in charge.  Their requirements conflict.  So *someone* has to win.

  The IETF has defined id-kp-serverAuth as "TLS WWW", *and* suggested it's use in non-WWW protocols.  This is a conflict that the IETF has to fix.

  Separately, people have discovered that using WWW certificates in non-WWW protocols is cheap, easy, and solves a need.  The failure here is both that CAs make it difficult to get non-WWW certificates, and implementors make it difficult to use different root stores.

> When a vendor, be it Apple or Microsoft or Mozilla or Google, says a CA in their root store needs to do something, they need to do it. If you don’t like that, which the email clearly demonstrates, there isn’t a heckler’s veto via the IETF: you instead need to create your own root store to do the things you want or like. Attempting to change those policies via the IETF, without understanding why they exist, just leads to IETF standards being ignored because they are not useful nor aligned with the needs of consumers.

  If everyone finds it useful to violate CA policies, then we need to find a way to fix that.  I suggest that fixing CA policies is likely simpler than fixing millions (or billions) of implementations.

> You’re seemingly fixated on the detail of the EKU, without acknowledging that the EKU is merely a technical example of the broader point of how requirements and policies work and flow, and how certificate consumers, even when used over the same transport substrate (TLS), have substantially different operational considerations. Those operational considerations impact the design of the PKI and thus the selection of the roots, and why multiple root stores, with their own policies and expectations, is the natural end-point.

  I'm fixated on the EKU because it is a concrete example to pin an argument on.  We can have a vague discussion about generic policies, but that would be unproductive.

> The important thing, that I keep trying to emphasize, is that separate policies are best technically accounted for at different roots. Yes, the dream of PKI was one root per organization and a grand and global mesh network of policy, and so we have all this technical complexity in specs like RFC 5280 to accomplish that. But the technology does not work, in the real world, and in fact makes it more difficult and risky, rather than less. So just use separate PKIs, built to common profiles when applicable/relevant, and move on. What happens in other PKIs shouldn’t affect you or be relevant, much like ISO standardizing how food processing equipment should be inspected is not really relevant here.

  Where can I get a certificate with id-kp-eapOverLAN?  Or where can I get a cert designed for use with STMP, XMPP, etc.?

  If the answer is "nowhere", then that's a problem.  The CAs have neglected their responsibilities to the customers.  And in the failure of the CAs to do things properly, customers use what works:  use id-kp-serverAuth.

  If the CAs don't like that, they have only themselves to blame.

  Alan DeKok.