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

[Alan DeKok <[e-mail]>]

On Jan 18, 2020, at 11:10 AM, Ryan Sleevi <[e-mail]> wrote:
> If the point was a singular CA seeming to violate their CP/CPS (that is, DigiCert), then yes, absolutely, you can go submit a CA problem report and the CA is obligated to respond in 24 hours with their analysis to your problem report. 

  I would recommend putting policies into practice.

  I disagree with those policies, so I don't feel responsible for putting them into practice.

> >  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".
> 
> I whole heartedly agree! To continue to connect it back to the original discussion, so that thread is not lost: if your use case (for example, EAP-TLS) wants to allow subjectivity and flexibility in how statements like this are interpreted, then you have to make sure other stakeholders are not also involved. That’s all.

  I don't understand the relevance of that statement.

  The concern is that *existing* CAs have policies which prevent EAP-TLS admins from using their certificates.  These policies apply to pretty much all non-WWW protocols.  The implication above is that these people can just start their own CAs.

  That's nice, but doesn't solve the problem.

>   Where can I get a certificate with id-kp-eapOverLAN?  Or where can I get a cert designed for use with STMP, XMPP, etc.?
> 
> https://wiki.xmpp.org/web/XMPP_Server_Certificates
> https://xmpp.org/about/xsf/records/proposals/intermediate-certificate-authority

  XMPP.  Not id-kp-eapOverLAN.  And not SMTP, not RADIUS over TLS  Not DNS over TLS, and so on.

> This is the problem with ignoring the broader message. “The CAs” is a term without useful meaning. Everyone can be a CA. You can be a CA. I can be a CA. Anyone who wants can issue certificates. There’s no set of entities blessed in some special power which only they can mint certificates, and thus their choices not to do so somehow be a sign of neglect.

  That is mostly true, but unhelpful.  Windows doesn't ship with "Billy bob's tackle shop & CA" root certificates.  Neither does Linux, OSX, etc.  Your statement here is just a rephrasing of "use a private CA", and "manually configure things".

  The root CAs that ship on modern OS distributions *are* blessed with a special power.  Only they can mint certificates which are *automatically* trusted by most applications on the OS.

> Want id-kp-eapOverLan? Sure, plenty will happily do that for you, for a price. Don’t like the price? Run your own CA and issue them yourself. There’s zero cost, and plenty of open-source tools to make “run your own CA” be a single line on a command-shell.

  Windows actually *forbids* id-kp-eapOverLAN from being used by the well-known root CAs:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj200219(v%3Dws.11)

...
You must deploy a private CA rather than obtain server certificates from a third party public CA. In addition, the certificate template that you use to issue the certificates must contain the RADIUS EKU extension. This extension is id-kp-eapOverLAN and the object identifier (OID) for this EKU is 1.3.6.1.5.5.7.3.14. This EKU extension can only be configured on a private CA and is used by Windows 8 to determine whether a private CA issued the certificate.
...

  This use-case would also seem to be outside of the scope envisioned by RFC 4334, which applies to client certificates.

> Now, it may be that when you CAs, what you mean is “I can’t get a certificate from the set of organizations that operate private keys/trust anchors, trusted for this purpose in a default install of my operating system / browser / insert X here, and which chains to that public key”. That is, you can’t get one of these certs chaining to the same root. Some might, but you’re right, that’s much more rare. And that’s a feature, not a bug or neglect, because you should be using separate hierarchies if you have different needs.

  That statement is a decade too late.

  Alan DeKok.