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

[Ryan Sleevi <[e-mail]>]

On Sat, Jan 18, 2020 at 9:43 AM Alan DeKok <[e-mail]>
wrote:

> On Jan 18, 2020, at 8:55 AM, Ryan Sleevi <[e-mail]> wrote:
> > Um, no. I largely didn’t respond to Michael’s email because it missed
> the mark rather substantially,
>
>   In what way?


Which CAs (plural) are you referring to? The CertSign example given - the
stronger of the restrictive CPSes - uses a cert from a CA not subject to
these (or any) requirements. That is, it’s an untrusted root.

Certificates from other services were examined, but without a similar
analysis of the issuing CA, which is the point. You can’t claim multiple
CAs, when there was a smattering of examples without any evidence of an
analysis of the relevant CP/CPS.

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. It’s the same procedure if, for example, you ever handled a
private key for a certificate issued by DigiCert and had not had a
background check conducted and/or conducted a background check on anyone
you have access to.

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


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.

Obviously, CAs can (and do) paint themselves in corners of absurdity, much
in the same way specs can end up with internal contradictions and
inconsistencies. In order to untangle those bits, everyone has to agree.
And it’s easier to get agreement among just two or three than it is around
two dozen, especially when contracts and agreements are involved.

As it ties back to the original discussion, it’s not _just_ agreements on
the CP/CPS you need to worry about, but things like profiles and transition
timelines and acceptable practices. The more stakeholders you continually
add, the harder it is to find agreement or interoperability. The joy of PKI
is that the solution is simple: disparate policies, enshrined by disparate
hierarchies, since multiple policies for a single hierarchy doesn’t work in
practice.

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.


Agreed.

However, and this is where it’s messy: the IETF getting its house in order
here does not resolve conflicts Once and For All. That’s because, for
better or worse, the certificatePolicies extension doesn’t work, and so EKU
has (and this was debated in PKIX even before 5280 replaced 3280) become
synonymous with policy, at least by implementors.

The best analogy I can think of is comparing to the X.501 DN attributes.
X.501 defines their syntax, and tries to define the semantics, but in the
absence of the global DIT, what a given attribute means and how it’s
validated depends on the context and issues. That is, the value of an
Organization field, or an OrganizationIdentifier, is going to depend on
which PKI it is used in. The same is true for EKU, for better or for worse.

  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.


Oh, I agree whole heartedly there.

  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 entire point is the generic policies being why it’s important to
separate things, and why it’s problematic to just assume one cert can or
should work everywhere. What you’re calling unproductive is the essence and
totality of the message, and perhaps that’s why I similarly find it
unproductive to fixate on the single field and ignore the overall point.

  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

  If the answer is "nowhere", then that's a problem.  The CAs have
> neglected their responsibilities to the customers.


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.

If you mean “The CAs” as the organizations operating key material in
certain root stores, then many (most?) will happily issue you whatever
certificates you want, from a hierarchy dedicated to your needs. I don’t
even need to provide advertising links, just pick your favorite vendor and
ask them about “private” or “enterprise” CA offerings.

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.

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.

If you’re willing to accept id-kp-serverAuth, and willing to accept that
the interpretations and expectations will be dictated by the root store(s)
recognizing that EKU, that as a Subscriber the timelines for changes will
be dictated by those root stores, that as a Relying Party the profile will
be dictated by those root stores, then yes, by all means, go ahead with
that. Just know that, as a Subscriber and/or as a Relying Party, you can’t
complain when things change, if profiles are made incompatible, or if
things change too soon.

I’m not saying you absolutely cannot and should not use id-kp-serverAuth
issued by CAs in common root stores. You just have to be aware that it’s
specifying your needs as “I’ll have 100 of whatever Ryan orders for gears”,
and being prepared to accept that and make it work.