On Jan 18, 2020, at 11:10 AM, Ryan Sleevi <ryan-i...@sleevi.com> 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
