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

[Ryan Sleevi <[e-mail]>]

On Sat, Jan 18, 2020 at 2:23 PM Alan DeKok <[e-mail]>
wrote:

> >   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.


You’re conflating several things, as well as seemingly shifting the goal
posts here. Perhaps it’s just a poor expression of the problem, as you see
it, in which case, it might help to be clearer.

_Some_ CAs forbid their certificates from being used with web servers.

_Some_ CAs forbid their certificates from being used with SMTP, or DNS over
TLS, or XMPP.

If those CAs certificates are used for those purposes, they need to be
revoked if the CA obtains evidence of this.

If the CA doesn’t like that, they can change their policies - although in
many cases, how they’ve forbidden things do not retroactively permit it.

If the Subscriber doesn’t like this, they can choose another CA.

If the software developer doesn’t like this, they can trust different CAs.

Can’t get eapOverLan from a TLS CA? Ok. That’s not a bug, that’s not a
misdesign, that’s how it works and is supposed to work.

The CA you’d like to use has a policy that forbids using your certificates
that way? Find a different CA. Run your own internal CA. These aren’t
difficult or unreasonable things.

> 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".


Yes, exactly, which is why I’m not sure the objection.

This is why I tried to cleanly separate out the problems, which seem to
keep getting conflated. The problem of “what does it mean today” and “what
does it mean in a future where nothing has to be manually configured” are
different problems, and it’s unreasonable to keep demanding that the second
be solved when addressing the first.

  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.


For certain purposes, according to certain policies.

If you don’t like those policies, or you want more purposes, do your own
thing. The same modern OS distributions provide that capability for
applications to do so, to allow the application vendor to select their
trust store, and It Just Works.

Can’t find someone who does what you want? That’s not a problem: you can do
it yourself. In discussing the second problem, there is absolutely zero
reason to use anything existing. None whatsoever.

It’s completely unreasonable to be complaining “CA X won’t let me use
certificates for this purpose” if you’re not addressing that with CA X. And
it’s completely unreasonable to complain that Root stores intended for use
case Y cannot be used with use case Z. Hammers make lousy screwdrivers,
even if they are both “tools one uses when building furniture”

> 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.


Fantastic! That’s exactly what I’m saying more folks should do for the
“current”. That’s a feature, not a bug.