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

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 7 Jan 2020 13:53:24 +0000

Thanks for the detailed reply Ryan. See line.

> -----Original Message-----

> 
> If an EAP server operator wants to use a public CA identity cert on their EAP
> server, what recommendations should we give to EAP clients so that the
> supplicant code can handle public or private CA issued EAP server identity in a
> secure a fashion as possible?
> 
> Define “public CA” first, and it’ll be clearer that the question is really
> supplicant-specific.
> 
> That is, most definitions for “public CAs” come down to “I don’t want to think
> about / analyze the security or validation practices of the CA, I want my
> supplicant / software / hardware vendor to do it for me, against some criteria
> the vendor is responsible for, and hope it all works out”. To the extent TLS
> uses ‘public CAs’, it either boils down to the OS or browser vendors reaching
> rough (independent) consensus on who is worth trusting, or the vendor
> going along with everyone else’s decisions for cost (too expensive for the
> vendor to evaluate) or compatibility (everyone else trusts them and it’d
> break things if the vendor doesn’t) reasons.

[ofriel] That’s pretty much it. For supplicants running on standard OSes (Windows, MacOS, iOS, Android), they could use logic similar to Chromium (which you must be familiar with seeing as you helped write it: https://github.com/chromium/chromium/commit/36f20e46515ab61df4ae4af9655b647bf9a0ea5a#diff-fa455b6e65ab2ae19d64635ada88077e ) to ask the OS if a presented EAP cert is one issued by a public CA. This does mean that the supplicant is asking about Web TLS certs that Browsers trust. However, there are ample examples and support cases opened by operators who are trying to do exactly that – get a web PKI cert from a public TLS/Browser CA and deploy it on an EAP server. Is this recommended? Not really. Is it using a Web/TLS cert for a purpose its not strictly intended for? Yes. Does this happen in real deployments? Absolutely. How prevalent is it? I do not have that data.

> 
> Is the supplicant market likely to reach that consensus? It seems unlikely,
> unless and until you define the “thing everyone can and wants and needs to
> validate”, and that thing is either globally unique (like DNS) or sufficiently
> domain specific (e.g. Passpoint) that vendors can agree.
> 

[ofriel] I think the supplicants running on the main OSes would be happy to delegate the question of whether a CA is a ‘public CA’ to the OS. For manufacturers of things/embedded devices/etc. then its currently very much at the manufacturers discretion, and consensus here would be unlikely.

> If at some point in the future, public CAs are willing to issue certs with some
> or all of the above fields, then what is the migration plan, what do we tell EAP
> clients to do now, and how to they migrate their verification logic?
> 
> This statement similarly requires untangling. There are “public CAs” as “The
> set of keys/certificates used for authenticating particular services” and
> “public CAs” as the set of organizations that own/operate those keys.
> 
> The case of the former is extremely unlikely, as the industry is actively
> moving away from that approach to PKI, by trying to ensure separate keys
> for separate use cases or authentication realms, of which EAP would surely
> be. 
 
[ofriel] And by this you mean that a root CA will have e.g. one intermediate with EKUs of id-kp-serverAuth/id-kp-clientAuth, and a different intermediate with an EKU for id-kp-emailProtection, right? The logical extension here for EAP is yet another intermediate with an EKU for id-kp-eapOverLAN.

The case of the latter is already available from said organizations as part
> of “managed CA” or “private CA” offerings, which are operated by that public
> CA organization, but that’s effectively greenfield because you aren’t having
> to interoperate with any extant keys or certificate profiles.
> 

[ofriel] Right, but from a supplicant perspective (or in general for any client running on any OS e.g. Browser on Windows), there is zero difference between an operator who deploys and runs their own private CA, or takes a contract out with a public CA organization and gets them to run a managed/private CA on their behalf.

> The ideal experience would be along these lines for a client with real user
> interactions:
> - client connects to an EAP server
> - client prompts user for userId + realm and password
> - client verifies server cert has id-kp-eapOverLAN set
> 
> What assurance is this to provide?

[ofriel] To assure that the cert is for the intended purpose – 802.1X/EAP server auth. Just like other TLS/Browser clients checks for id-kp-serverAuth

> 
> - NAIRealm in cert matches user’s realm
> 
> This only works iff the NAIs are globally unique (e.g. map to DNS), which
> imposes requirements on NAIs that aren’t present in RFC 7542, and
> seemingly intentionally, compared to 4282.
> 
> - verify the cert signing chain
> 
> The reality today is that if the server cert is issued by a public CA, then all that
> client can really check is:
> - id-kp-serverAuth is set
> - dNSName in cert matches user’s realm
> - verify the cert signing chain
> 
> We would like to document some recommendations for EAP clients and EAP
> operators so that public CAs could be used, and recommend checks for public
> vs. private CA issued EAP server certs.
> 
> If you mean the same set of CAs and keys used for TLS by common operating
> systems and browsers, it bears highlighting again: industry is moving away
> from that. Which is to say that contracts and requirements for PKIs used “by
> default” by browsers and operating systems are being explicit about the
> need to segment purpose and use case and not use such certificates for such
> purposes.
> 

[ofriel] I agree that ideally  Web/TLS Browser certs should not really be used by operators as their EAP server identity certs, however, this does actually happen today. In an ideal world, it would be great if some of the large commercial (or free e.g. LetsEncrypt) public Web/TLS CAs had an intermediate signing CA with id-kp-eapOverLAN. But today, and for the foreseeable future, what can we advise supplicants to do if we know that some operators will put Web/TLS identity certs from public CAs on their EAP servers?

> Already, TLS and e-mail, the two dominant uses of PKI in such systems, are
> required to be distinguished at their intermediate level. Browsers are looking
> to explicitly only trust the TLS-Web side of the PKI, and making sure that the
> TLS-Web PKI side is highly agile. Other cases, such as restricted use server to
> server PKI or industry bespoke cases (such as financial services or system
> networking) are being restricted to PKIs that aren’t federated-by-default.
> 
> For example, X9 recently revived their PKI WG, to define PKI requirements
> appropriate for financial services customers (like ATM to bank), because
> financial services struggle to move at the same speed as modern software,
> for understandable reasons. The use of domain/purpose-specific PKIs is
> something we can and should be embracing more of.

[ofriel] Sure, I’m not saying that id-kp-eapOverLAN is a bad idea or that supplicants should never look for it. But how do we get to the point where we could actually enforce that, given that today operators do try to use EAP with Web/TLS certs.

> 
> It seems like logic should be something like:
> 
> - recommend EAP operators with private CA issued certs on their EAP servers
> set id-kp-eapOverLAN and NAIRealm set
> - recommend EAP operators using public CAs get EAP server certs with id-kp-
> serverAuth and dNSName set
> - recommend clients enable trust in public CAs
> 
> This is why I started with trying to define what “public CAs” are. If you mean
> the extant CAs trusted by browsers and operating systems, both this
> recommendation and the one proceeding it may not be good
> recommendations or long-term viable practices.

[ofriel] Yes, I mean extant CAs trusted by Browsers and OSes. Yes the recommendations as written above would mean using a cert with a EKU for one purpose, for a different purpose, but that is the unfortunate reality. Do we ignore the problem and say ‘Don’t do this’ or do we try to document some compromise recommendations for both supplicants and CAs, with a roadmap of how to evolve?

> 
> That’s not to say you couldn’t, but it means your EAP services and servers
> need to be prepared to be as agile as the Web ecosystem is and modern
> operating systems are converging on. The ability to support or be beholden
> to “legacy” - whether algorithms, profiles, or trust in particular organizations -
> is something that industry is recognizing does not align with user needs. This
> means adopting practices like automation, being able to quantify
> compatibility risks, and being able to move quickly as expectations change, in
> response to ecosystem challenges.
> 

[ofriel] I hope that this problem is easier to tackle for supplicants running on the major OSes. For things/embedded devices, this is a far harder problem to solve for sure.

> Maybe that’s fine for EAP, but I’m willing to suspect that it because updates
> may involve physically replacing client hardware or physically installing
> firmware, you really don’t want EAP needing to be beholden to those agility
> needs of the Web and OSes. And, again, that’s perfectly OK, it just means
> defining a PKI and set of procedures that is appropriate for that use case, and
> convincing industry to adopt it as an “out of the box” configuration. Or,
> alternatively, embracing private PKI.
> 

[ofriel] Maybe an approach to take is to have one set of recommendations for supplicant clients on major OSes where they can delegate, and possibly piggy back on top of, similar OS functionality for Web/TLS; and have a different looser set of recommendations for thing manufacturers. Or possibly frame the requirements as ‘requirements the supplicant should enforce’ vs. ‘requirements the supplicant should delegate to the OS (e.g. is this a public CA?)’.

> - recommend clients implement different cert verification logic depending on
> whether the EAP server cert is issued by a public CA or private CA
> 
> Why is this good?
> 
> To the extent browsers or OSes make this distinction, it’s largely based on
> simply phasing rollouts of new requirements, with the goal to eventually
> require consistent and uniform treatment to ensure simpler code with
> consistent and uniform security properties. Having a long-term segmentation
> of requirements, or even encouraging them without a clear vision back to
> harmonization, is definitely an anti-pattern here.

[ofriel] Completely agree. Which is why I stated below “as a longer term goal see if public CAs will issue id-kp-eapOverLAN and NAIRealm”

> - for public CA certs, client checks that id-kp-serverAuth is set *and*
> dNSName matches user realm. If either check fails, reject.
> - for private CA certs, client checks that id-kp-serverAuth or id-kp-
> eapOverLAN is set *and* NAIRealm matches user realm.. If either check fails,
> reject.
> 
> - as a longer term goal see if public CAs will issue id-kp-eapOverLAN and
> NAIRealm. Although of course if some were to start doing this, then there is
> a migration challenge, and clients cannot make a hard check for these values
> against all public CAs. This doesn’t really seem practical in the near term at all.
> 
> The effect of the separate EKU, which is actually quite desirable, is that it
> functionally makes it difficult for CAs to issue these certificates from
> intermediated that lack this EKU or any EKU. Further,  CAs subject to
> browser/OS vendor oversight are consistently required to segment out their
> EKUs at the intermediate level, and required to always specify EKUs.
> 
> The end result is that, to achieve this long term goal, you’ve effectively
> required the establishment of a new PKI - just at the intermediate level
> rather than the root. And as many of the public CAs can tell you, having
> recently encountered challenges regarding non-TLS intermediates from roots
> that are subject to browser/OS oversight, it’s often easier to use separate
> roots as well.
> 
> Again, I think that’s desirable, to define an entirely new PKI with zero overlap
> with the server auth/TLS PKI used by OSes/browsers, but that does change
> your recommendations and design a bit :) The short term recommendation
> becomes “don’t use public CAs”, and that seems easier to explain and easier
> to evolve the technical requirements, until the time that such a new, EAP-
> specific public PKI can be introduced.
> 

[ofriel] Getting public CAs to manage a new PKI root (if that’s easier than just a new intermediate) with id-kp-eapOverLAN is a really really long road. And we know that some operators do use public Web/TLS certs as EAP identity certs. Which means that we cannot recommend supplicants enforce a check for id-kp-eapOverLAN.

So it looks like there are three choices:
1.	Completely ignore id-kp-eapOverLAN for ever.
2.	Get supplicants to check id-kp-eapOverLAN if its not a public CA (and use Chromium style public CA detection). Rollout of this would need to be carefully managed too so that existing private CA operators who do not set id-kp-eapOverLAN do not break.
3.	Do nothing until  sufficient numbers of public CAs support id-kp-eapOverLAN (in like 2035..?), then change supplicants to always check for id-kp-eapOverLAN.

Its not clear to me where the correct forum is to even document these recommendations, or who needs to be involved.

> In my mind, this is no different from organizations that want TLS certificates
> for their servers named “webmail” (not globally unique) or
> “mail_01.company.example” (not preferred name form / LDH). The answer is
> “use private CAs, don’t use public CAs”
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 7 Jan 2020 10:22:17 -0500

> [ofriel] That’s pretty much it. For supplicants running on standard OSes (Windows, MacOS, iOS, Android), they could use logic similar to Chromium (which you must be familiar with seeing as you help…

  So far as I know, every EAP supplicant checks for the id-kp-serverAuth OID.  So yes, *all* EAP supplicants check that the certificate presented by the EAP server is valid for TLS web servers.

  That seems wrong.  But it's what people do.

> [ofriel] I agree that ideally  Web/TLS Browser certs should not really be used by operators as their EAP server identity certs, however, this does actually happen today. In an ideal world, it would…

  Not "some", but "all".

> 3.	Do nothing until  sufficient numbers of public CAs support id-kp-eapOverLAN (in like 2035..?), then change supplicants to always check for id-kp-eapOverLAN.

  I think there should be continued discussion about what is the end goal, and how we can get there.  Once those issues are defined, then it's simpler to fix the supplicants.

> Its not clear to me where the correct forum is to even document these recommendations, or who needs to be involved.

  The Wi-Fi alliance is already moving ahead with a similar approach.

https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v2.0.pdf

  See Section 5, page 10.

  A shorter description is here:

http://lists.freeradius.org/pipermail/freeradius-users/2019-December/097080.html

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 7 Jan 2020 09:54:15 -0500

Hi Owen,

While I have responses inline below, I am concerned that if I'm disagreeing
so much with you, there might be some high-level impedance mismatches that
we should get sorted first.

At the high-level, I will say that using TLS (id-kp-serverAuth)
certificates, from the intersection of CAs that are commonly trusted by
operating systems and browsers, is bad. It will create security issues,
will create interoperability issues, and will not help users. Conceptually,
it's akin to suggesting a protocol violation, and the best thing to do with
those is be strict in what you accept and break those implementations as
early as possible, in the spirit of
https://tools.ietf.org/html/draft-iab-protocol-maintenance .

The set of CAs that are trusted for TLS on a given device, platform, or
application are intrinsically tied to purpose (TLS) and the library used to
implement that TLS and PKI behaviour. They are not separable, and trying to
do so is a problem, not a solution. This is perhaps most obvious as vendors
like Apple have tightly integrated PKI policy requirements (such as
Certificate Transparency) with the capability of their TLS libraries; for
several macOS/iOS releases, any application using a TLS library other than
Apple's CFNetwork would be unable to successfully verify a number of
certificates from CAs Apple trusted for TLS.

EAP is not TLS, and your use case here is not TLS (clearly), so don't mess
with TLS, or you will break, eventually. The best I can do is try to
explicitly break you sooner, than later, so that I can deal with the
fallout sooner than later, and not when there's a critical issue in the TLS
ecosystem needing rapid resolution.

At a high-level, you're still fundamentally proposing a new root store. I
realize that may not be obvious, given the suggestion of intermediates with
id-kp-eapOverLAN, but that's still fundamentally what's being suggested,
because you still need to define a certificate profile (such as the EKU),
expected policies such as how that information is validated, and a process
for ensuring that validation is performed. I think that's a laudable goal,
and perhaps worth pursuing, but it's important to stress that in defining a
new root store, there's no reason to reuse anything extant. The fact that
operating systems may trust some organizations for other purposes (TLS or
S/MIME) should by no means be dispositive towards whatever you're doing.
Where to best propose certificate profiles or certificate policies for that
root store, I don't know, and that clearly requires a lot more implementor
experience and consensus to end up with something like the CA/Browser Forum
that is useful for TLS.

On Tue, Jan 7, 2020 at 7:31 AM Owen Friel (ofriel) <[email-masked]> wrote:

> *From:* Ryan Sleevi <[email-masked]>
> *Sent:* 15 December 2019 23:43
> *To:* Owen Friel (ofriel) <[email-masked]>
> *Cc:* EMU WG <[email-masked]>; [email-masked]
> *Subject:* Re: [lamps] EAP/EMU recommendations for client cert validation
> logic
>
>
>
>
>
>
>
> On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel) <[email-masked]>
> wrote:
>
> Hi,
>
>
>
> At ACME meeting at IETF106, the last discussion of the week was around EMU
> looking for recommendations for EAP client/peer/supplicant cert
> verification logic when the client is verifying the cert that the EAP
> server presents. Minutes here:
> https://datatracker.ietf.org/doc/minutes-106-acme/  The recommendation
> was to ask lamps. This was also discussed on EMU mailer recently.
>
>
>
> Quoting some additional background that Alan gave on EMU mailer:
>
>
>
> “Background:
>
>
>
> a) the current practice in TLS-based EAP methods is to use certificates
> with "id-kp-serverAuth" OID set for Extended Key Usage.
>
> b) many supplicants check for this OID, and refuse to perform
> authentication if it is missing
>
> c) supplicants do not check DNS names or any other field in the
> certificates
>
> d) as a result of this lack of verification, supplicants ship with all
> known CAs disabled for TLS-based EAP methods”
>
>
>
> The key consideration is that RFCs that recommend cert fields for EAP
> servers that clients should check for are not currently issued by public
> CAs, and in some instances (e.g. SSID) ownership can often not be proven by
> CAs.
>
>
>
> For example:
>
>
>
> https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU
>
>
>
> https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID
>
>
>
> https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm
>
>
>
> If an EAP server operator wants to use a public CA identity cert on their
> EAP server, what recommendations should we give to EAP clients so that the
> supplicant code can handle public or private CA issued EAP server identity
> in a secure a fashion as possible?
>
>
>
> That is, most definitions for “public CAs” come down to “I don’t want to
> think about / analyze the security or validation practices of the CA, I
> want my supplicant / software / hardware vendor to do it for me, against
> some criteria the vendor is responsible for, and hope it all works out”. To
> the extent TLS uses ‘public CAs’, it either boils down to the OS or browser
> vendors reaching rough (independent) consensus on who is worth trusting, or
> the vendor going along with everyone else’s decisions for cost (too
> expensive for the vendor to evaluate) or compatibility (everyone else
> trusts them and it’d break things if the vendor doesn’t) reasons.
>
>
>
> [ofriel] That’s pretty much it. For supplicants running on standard OSes
> (Windows, MacOS, iOS, Android), they could use logic similar to Chromium
> (which you must be familiar with seeing as you helped write it:
> https://github.com/chromium/chromium/commit/36f20e46515ab61df4ae4af9655b647bf9a0ea5a#diff-fa455b6e65ab2ae19d64635ada88077e
> ) to ask the OS if a presented EAP cert is one issued by a public CA. This
> does mean that the supplicant is asking about Web TLS certs that Browsers
> trust. However, there are ample examples and support cases opened by
> operators who are trying to do exactly that – get a web PKI cert from a
> public TLS/Browser CA and deploy it on an EAP server. Is this recommended?
> Not really. Is it using a Web/TLS cert for a purpose its not strictly
> intended for? Yes. Does this happen in real deployments? Absolutely. How
> prevalent is it? I do not have that data.
>

I'm not really sure what you're trying to suggest here, and I'm not really
sure why you mentioned the code in relation to the question.

The problem still remains: you haven't defined public CAs in any
interoperable sense, and I think that's relevant to the discussion in the
IETF, if you want to get interoperable implementations.

I also think it's misguided and misunderstands the code you referenced.
That code is to explicitly reject things that might otherwise be valid, so
that it fails early and isn't accepted, even if there might be reasons to
allow it. If the suggestion is that EAP supplicants should explicitly
reject anything from common TLS-trusted CAs (including from any
intermediates they issue, regardless of key policies), I wholeheartedly
agree with that, but I'm under the impression you're suggesting the exact
opposite.

>
>
> Is the supplicant market likely to reach that consensus? It seems
> unlikely, unless and until you define the “thing everyone can and wants and
> needs to validate”, and that thing is either globally unique (like DNS) or
> sufficiently domain specific (e.g. Passpoint) that vendors can agree.
>
>
>
> [ofriel] I think the supplicants running on the main OSes would be happy
> to delegate the question of whether a CA is a ‘public CA’ to the OS. For
> manufacturers of things/embedded devices/etc. then its currently very much
> at the manufacturers discretion, and consensus here would be unlikely.
>

I'm afraid this side-steps the question for the "main OSes" that everyone
would be happy with: they still need to make a decision, and so you're
still back to manufacturer's discretion, and thus back to a lack of
consensus without a clearly defined problem statement, and this answer has
solved and clarified nothing. Even if you 'want' to handwave to the OS, the
OS vendor still has to make a decision, just like the embedded devices do.
And for that, it needs a clear problem statement.

>
>
> If at some point in the future, public CAs are willing to issue certs with
> some or all of the above fields, then what is the migration plan, what do
> we tell EAP clients to do now, and how to they migrate their verification
> logic?
>
>
>
> This statement similarly requires untangling. There are “public CAs” as
> “The set of keys/certificates used for authenticating particular services”
> and “public CAs” as the set of organizations that own/operate those keys.
>
>
>
> [ofriel] And by this you mean that a root CA will have e.g. one
> intermediate with EKUs of id-kp-serverAuth/id-kp-clientAuth, and a
> different intermediate with an EKU for id-kp-emailProtection, right? The
> logical extension here for EAP is yet another intermediate with an EKU for
> id-kp-eapOverLAN.
>

In a sense, yes, but I don't think it goes far enough, and I think it
misses the problem I was trying to highlight, which is that this means
separate _roots_ for id-kp-eapOverLAN.

Separating at the intermediate is happening, but equally, separating at the
root is happening, and in fact more preferable. We've explicitly rejected
CA applications that use an intermediate level separation, because the
organizational and operational considerations are too great for folks to
effectively manage. We're not the only vendor working through problems like
this - https://wiki.mozilla.org/CA/Audit_Letter_Validation is an entire
system developed jointly with Mozilla and Microsoft trying to work through
these issues, where CAs 'intended' to separate out the intermediates but
failed to do so correctly. It's a flawed design, a flawed system, and with
significantly more operational overhead than simply separating at the root.

We see this in new systems, which purpose-build root hierarchies, like
Passpoint or Wireless Power/Qi or "Made for Apple iPhone". The point is
that the *entire* hierarchy is separate, and not just branches, because
that's seemingly the only practically effective way to manage PKI at
Internet scale.

> The case of the latter is already available from said organizations as
> part of “managed CA” or “private CA” offerings, which are operated by that
> public CA organization, but that’s effectively greenfield because you
> aren’t having to interoperate with any extant keys or certificate profiles.
>
>
>
> [ofriel] Right, but from a supplicant perspective (or in general for any
> client running on any OS e.g. Browser on Windows), there is zero difference
> between an operator who deploys and runs their own private CA, or takes a
> contract out with a public CA organization and gets them to run a
> managed/private CA on their behalf.
>

Perhaps you could rephrase this, because I think I disagree with about
every interpretation I can come to, but I don't want to waste your time if
I'm misunderstanding :)

> The ideal experience would be along these lines for a client with real
> user interactions:
>
> [ofriel] To assure that the cert is for the intended purpose – 802.1X/EAP
> server auth. Just like other TLS/Browser clients checks for
> id-kp-serverAuth.
>

That's a tautological definition though. The intended purpose is the
intended purpose.

This question is trying to pose "What is the information or policy that is
validated". As clarified later on, you've got at least the "NAI realm is
appropriately unique", which in this case means matches to DNS. "Intended
for 802.1X" doesn't seem correct, though, because that would similarly
imply that no extant TLS CA would issue certificates used in EAP, because
every CA would be verifying "intended for TLS server authentication", and
that's clearly not the case when used with EAP.

> from that. Which is to say that contracts and requirements for PKIs used
> “by default” by browsers and operating systems are being explicit about the
> [ofriel] I agree that ideally  Web/TLS Browser certs should not really be
> used by operators as their EAP server identity certs, however, this does
> actually happen today. In an ideal world, it would be great if some of the
> large commercial (or free e.g. LetsEncrypt) public Web/TLS CAs had an
> intermediate signing CA with id-kp-eapOverLAN.
>

No, this would be bad.

> But today, and for the foreseeable future, what can we advise supplicants
> to do if we know that some operators will put Web/TLS identity certs from
> public CAs on their EAP servers?
>

If you know it's a TLS certificate, reject it.
If it has id-kp-serverAuth, reject it.
If it comes from a Root CA you know is or has been trusted for TLS, reject
it.
If it has not been explicitly configured by local policy to accept it,
reject it.

Are there existing certificates that will be rejected? Yes. Replace them.

> This is why I started with trying to define what “public CAs” are. If you
> mean the extant CAs trusted by browsers and operating systems, both this
> recommendation and the one proceeding it may not be good recommendations or
> long-term viable practices.
>
>
>
> [ofriel] Yes, I mean extant CAs trusted by Browsers and OSes. Yes the
> recommendations as written above would mean using a cert with a EKU for one
> purpose, for a different purpose, but that is the unfortunate reality. Do
> we ignore the problem and say ‘Don’t do this’ or do we try to document some
> compromise recommendations for both supplicants and CAs, with a roadmap of
> how to evolve?
>

Supplicants should break this case as soon as possible, because it _will_
break, and it's better to have it break within a maintenance cycle when
you're prepared for breakage and migrating than one day waking up and
finding it's all broken.

The least deliberate form of breakage is the status quo, which is to
require explicit configuration of the trust anchors and hand-wave the rest.
Somewhere in the middle you have things like vendor-flag-days (i.e. this
vendor requires id-kp-eapOverLan in it's new software for all certificates
issued after that supplicant's release date)
At the most deliberate, you have folks borrowing from that Chromium code /
maintaining a list of every CA that has been used for / trusted for TLS,
and explicitly rejecting/preventing certificates from them.

I doubt we'll find consensus on where the 'ideal' answer is, since every
vendor will have to weigh their own risks, but in no circumstances should
folks use TLS CAs.

> to “legacy” - whether algorithms, profiles, or trust in particular
> organizations - is something that industry is recognizing does not align
> with user needs. This means adopting practices like automation, being able
> to quantify compatibility risks, and being able to move quickly as
> expectations change, in response to ecosystem challenges.
>
>
>
> [ofriel] I hope that this problem is easier to tackle for supplicants
> running on the major OSes. For things/embedded devices, this is a far
> harder problem to solve for sure.
>

Only to the extent the supplicant is integrated in the OS, much the way the
TLS library and PKI store are integrated. For anything else, such as 3P
supplicants, it remains an equally hard problem.

> [ofriel] Getting public CAs to manage a new PKI root (if that’s easier
> than just a new intermediate) with id-kp-eapOverLAN is a really really long
> road. And we know that some operators do use public Web/TLS certs as EAP
> identity certs. Which means that we cannot recommend supplicants enforce a
> check for id-kp-eapOverLAN.
>
>
>
>    2. Get supplicants to check id-kp-eapOverLAN if its not a public CA
>    (and use Chromium style public CA detection). Rollout of this would need to
>    be carefully managed too so that existing private CA operators who do not
>    set id-kp-eapOverLAN do not break.
>    3. Do nothing until  sufficient numbers of public CAs support
>    id-kp-eapOverLAN (in like 2035..?), then change supplicants to always check
>    for id-kp-eapOverLAN.
>
>
These are all bad options.

Look, any clients expecting id-kp-serverAuth are broken now. They just
don't realize it, they're walking timebombs, and the answer is to fix them.
Vendors can and should be more explicit in this, by checking
id-kp-eapOverLan, because they're going to eat the incompatibility at some
point. Better to pay for that pain now, rather than continue to defer it
and hope nothing goes wrong. I mentioned above, there's a spectrum of
options for how to phase that in.

To explicitly reiterate #2: The implementation in Chromium very
intentionally does not *grant* capabilities based on that list, it
*removes* capabilities and makes code *more* strict. That is the only
reasonable use for such a list, and even then, it's problematic (e.g. if
the list is out of date, newcomers have advantages over incumbents). That
list has a host of other caveats, and why Chromium is moving to explicitly
rid itself of that list and has been. I appreciate the shout-out, but this
is very much a situation of using the list exactly opposite as intended :)

---

From: Alan DeKok <[email-masked]>
Date: Tue, 7 Jan 2020 11:43:59 -0500

On Jan 7, 2020, at 9:54 AM, Ryan Sleevi <[email-masked]> wrote:
> At the high-level, I will say that using TLS (id-kp-serverAuth) certificates, from the intersection of CAs that are commonly trusted by operating systems and browsers, is bad. It will create security issues, will create interoperability issues, and will not help users.

  It's been accepted practice in all EAP implementations for ~15 years.  Are there practical issues you're aware of?  Because I can't recall seeing any.

  Any security issues are limited.  If a site administrator has access to the public / private keys for a web server, it's possible to re-use those certs for EAP.  This re-use cannot be prevented.

> The set of CAs that are trusted for TLS on a given device, platform, or application are intrinsically tied to purpose (TLS) and the library used to implement that TLS and PKI behaviour. They are not separable, and trying to do so is a problem, not a solution. This is perhaps most obvious as vendors like Apple have tightly integrated PKI policy requirements (such as Certificate Transparency) with the capability of their TLS libraries; for several macOS/iOS releases, any application using a TLS library other than Apple's CFNetwork would be unable to successfully verify a number of certificates from CAs Apple trusted for TLS.
> 
> EAP is not TLS, and your use case here is not TLS (clearly), so don't mess with TLS, or you will break, eventually. The best I can do is try to explicitly break you sooner, than later, so that I can deal with the fallout sooner than later, and not when there's a critical issue in the TLS ecosystem needing rapid resolution.

  I'm not sure what your point is here.  I agree this usage is wrong, but the goal is to *fix* it.  The goal isn't to "bless" the existing usage.

  The goal is to figure out what *should* supplicants do.

> At a high-level, you're still fundamentally proposing a new root store. I realize that may not be obvious, given the suggestion of intermediates with id-kp-eapOverLAN, but that's still fundamentally what's being suggested, because you still need to define a certificate profile (such as the EKU), expected policies such as how that information is validated, and a process for ensuring that validation is performed. I think that's a laudable goal, and perhaps worth pursuing, but it's important to stress that in defining a new root store, there's no reason to reuse anything extant. The fact that operating systems may trust some organizations for other purposes (TLS or S/MIME) should by no means be dispositive towards whatever you're doing. Where to best propose certificate profiles or certificate policies for that root store, I don't know, and that clearly requires a lot more implementor experience and consensus to end up with something like the CA/Browser Forum that is useful for TLS.

  EAP supplicant implementations largely do this already.  So there's no "proposal" of a new root store.  There's a statement that there *is* a different root store.

  i.e. implementations default to not trusting CAs for EAP.  The trust has to be explicitly enabled by an admin, or by the user.  This means that there's a store of CAs *only* for EAP.

  Everyone knows that it's wrong to use id-kp-serverAuth for EAP.   The way forward is to figure out how to fix it.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 7 Jan 2020 12:33:14 -0500

On Tue, Jan 7, 2020 at 11:44 AM Alan DeKok <[email-masked]>
wrote:

> will create interoperability issues, and will not help users.
>
>   It's been accepted practice in all EAP implementations for ~15 years.
> Are there practical issues you're aware of?  Because I can't recall seeing
> any.
>

I'm sure "practical" will be seen as subjective, but here's some examples:

Operational:
- Customers of CAs having trouble when their CA has to perform timely
revocation of their certificates
- Migration off SHA-1
- Migration off 1024-bit RSA
- CAs being shut down or exiting the business due to non-compliance with
browser requirements

Security:
- Cross-protocol considerations due to key reuse seems like a meaningful
security issue that's being dismissed.

>   Any security issues are limited.  If a site administrator has access to
> the public / private keys for a web server, it's possible to re-use those
> certs for EAP.  This re-use cannot be prevented.
>

No. But it results in prompt revocation of that certificate if anyone
demonstrates it being used like that, the same as no one can prevent you
from embedding a private key in software, but doing so gets it swiftly
revoked. [1]

[1] https://www.theregister.co.uk/2019/12/05/atlassian_zero_day_bug/

>   I'm not sure what your point is here.  I agree this usage is wrong, but
> the goal is to *fix* it.  The goal isn't to "bless" the existing usage.
>

There's no short-term or medium-term solution that can rely on 'accepting'
or 'specifying' the use of id-kp-serverAuth, which was the original
proposal as a "recommend". Any of those uses are inherently broken and
unsafe and just time bombs waiting to go off.

>   EAP supplicant implementations largely do this already.  So there's no
> "proposal" of a new root store.  There's a statement that there *is* a
> different root store.
>

That doesn't match Owen's original message, so while I'm glad there's an
acknowledgement here of differences, that doesn't seem to match the
discussion to date.

>   i.e. implementations default to not trusting CAs for EAP.  The trust has
> to be explicitly enabled by an admin, or by the user.  This means that
> there's a store of CAs *only* for EAP.
>
>   Everyone knows that it's wrong to use id-kp-serverAuth for EAP.   The
> way forward is to figure out how to fix it.
>

Update software? I'm glad there's agreement it's bad/wrong to use, but it
seems the only path forward is going to be to breaking, not recommending
for using public (TLS) CAs with id-kp-serverAuth.

Attempting to specify some interoperable behaviour in the interim, before
things are broken, for how folks can keep using id-kp-serverAuth, seems to
be the problem. Just accepting that things need to be broken seems like it
easily allows moving into the discussion about NAIRealm and manual
configuration.

I know that's easy to say when it's individual vendors who have to deal
with the fallout and that's why I suggested there's a spectrum of responses
for how that's phased out. But explicitly moving towards that goal, and not
trying to live in the interim with id-kp-serverAuth, seems the best path
forward.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 7 Jan 2020 12:51:44 -0500

On Jan 7, 2020, at 12:33 PM, Ryan Sleevi <[email-masked]> wrote:
> - Customers of CAs having trouble when their CA has to perform timely revocation of their certificates
> - Migration off SHA-1
> - CAs being shut down or exiting the business due to non-compliance with browser requirements

  How is that specific to the use of TLS (id-kp-serverAuth) certificates?  Any use of TLS certificates by EAP would be subject to the same issues.

> Security:
> - Cross-protocol considerations due to key reuse seems like a meaningful security issue that's being dismissed.

  Who is dismissing it?

> No. But it results in prompt revocation of that certificate if anyone demonstrates it being used like that

  No, it doesn't.

  *Everyone* has been doing this with EAP for a very long time.  i.e. getting a certificate using id-kp-serverAuth from a root CA, and then using that certificate for EAP.  I have never heard of such a certificate being revoked.

> There's no short-term or medium-term solution that can rely on 'accepting' or 'specifying' the use of id-kp-serverAuth, which was the original proposal as a "recommend". Any of those uses are inherently broken and unsafe and just time bombs waiting to go off.

  It's been 15+ years.  There has been no such issue.

  I think it's acceptable to recommend people continue existing practice, where such practice has been shown to be (a) workable, and (b) has no known issues.

> Update software?

  To do *what*?  A concrete proposal would help here.

> I'm glad there's agreement it's bad/wrong to use, but it seems the only path forward is going to be to breaking, not recommending for using public (TLS) CAs with id-kp-serverAuth.

  Please call Microsoft and Apple, and tell them you're going to forbid their 15 year workflow for EAP.  Then, tell them that you *want* their systems to break, and that it's for security reasons.

  I suspect that request won't go over well.

  We just cannot break existing systems without a clear and present security problem.  And none has been demonstrated here.

> Attempting to specify some interoperable behaviour in the interim, before things are broken, for how folks can keep using id-kp-serverAuth, seems to be the problem. Just accepting that things need to be broken seems like it easily allows moving into the discussion about NAIRealm and manual configuration.

  I think it's OK to *document* existing behaviour.  Behaviour that has been demonstrated in to be interoperable with billions of devices.

> I know that's easy to say when it's individual vendors who have to deal with the fallout and that's why I suggested there's a spectrum of responses for how that's phased out. But explicitly moving towards that goal, and not trying to live in the interim with id-kp-serverAuth, seems the best path forward.

  I welcome concrete proposals to move forward.  The discussion here seems to recommend against using id-kp-eapOverLAN and NAIRealm.  Which means we *don't* have a way forward.

  In the absence of a solution, it's best to document existing practice.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 7 Jan 2020 14:19:44 -0500

On Tue, Jan 7, 2020 at 12:51 PM Alan DeKok <[email-masked]>
wrote:

>   How is that specific to the use of TLS (id-kp-serverAuth) certificates?
> Any use of TLS certificates by EAP would be subject to the same issues.

Was there a typo here? I’m not sure how to parse or understand this?

> >   Any security issues are limited.

^ this seems dismissive

If a site administrator has access to the public / private keys for a web
> server, it's possible to re-use those certs for EAP.  This re-use cannot be
> prevented.
> >
> demonstrates it being used like that
>
>   No, it doesn't.
>
>   *Everyone* has been doing this with EAP for a very long time.  i.e.
> getting a certificate using id-kp-serverAuth from a root CA, and then using
> that certificate for EAP.  I have never heard of such a certificate being
> revoked.

The same was said for people embedding private keys in their software.

>
> > There's no short-term or medium-term solution that can rely on
> 'accepting' or 'specifying' the use of id-kp-serverAuth, which was the
> original proposal as a "recommend". Any of those uses are inherently broken
> and unsafe and just time bombs waiting to go off.
>

This is empirically false. The use of certain CA’s certificates in wireless
deployments has absolutely been a barrier to compliance and improvements.

>
>   I think it's acceptable to recommend people continue existing practice,
> where such practice has been shown to be (a) workable, and (b) has no known
> issues.

I’ve demonstrated both a and b are false, perhaps not to your satisfaction,
but it remains true.

>   To do *what*?  A concrete proposal would help here.

The same message you’re replying to contains one, which you dismiss as
unworkable. It’s unclear why, or if the only solution is enshrine the
status quo?

> > I'm glad there's agreement it's bad/wrong to use, but it seems the only
> path forward is going to be to breaking, not recommending for using public
> (TLS) CAs with id-kp-serverAuth.
>
>   Please call Microsoft and Apple, and tell them you're going to forbid
> their 15 year workflow for EAP.  Then, tell them that you *want* their
> systems to break, and that it's for security reasons.

They’re on the same page already. I won’t claim to speak for them, but the
same principles and concerns I’m raising are and have been shared by all
the major OS and browser vendors in some form. This is the path that is on
the way out, not the way forward.

>
>   We just cannot break existing systems without a clear and present
> security problem.  And none has been demonstrated here.

Apologies for the confusion here, but there seems to be a lot of
unresolvable contradictions here. We must do something different, but we
can’t change. We know the current solution is bad, but there’s nothing
wrong with it. We need something better, but we can’t break anything.

Wanting to both have and eat cake is an unwinnable position.

> > Attempting to specify some interoperable behaviour in the interim,
> before things are broken, for how folks can keep using id-kp-serverAuth,
> seems to be the problem. Just accepting that things need to be broken seems
> like it easily allows moving into the discussion about NAIRealm and manual
> configuration.
>
>   I think it's OK to *document* existing behaviour.  Behaviour that has
> been demonstrated in to be interoperable with billions of devices.

I strongly disagree here. Documenting bad behaviour in SDOs serves to try
and legitimize it. The only benefit is to allow existing implementations to
align and new implementations to be interoperable, except the behavior
being specified is bad, and will break, and will cause pain. Even on the
Informational track, that would be actively harmful to the ecosystem.

>   I welcome concrete proposals to move forward.  The discussion here seems
> to recommend against using id-kp-eapOverLAN and NAIRealm.  Which means we
> *don't* have a way forward.

Why not?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 7 Jan 2020 15:19:16 -0500

> Was there a typo here? I’m not sure how to parse or understand this?

  I read your previous messages as claiming there were issues *specific* to EAP using id-kp-serverAuth.  When I asked for specifics, the response was to describe general issues with certificate management.

  My conclusion, then, is that there are no issues specific to EAP using id-kp-serverAuth. 

> >   Any security issues are limited. 

  Nonsense.  I'm asking you to prove your position that there are issues.  I've given detailed explanations of security issues, including pros and cons.  There is no possible way you can see such discussion as me being "dismissive" of the issues.

> The same was said for people embedding private keys in their software.

  I have no idea what that means, or why it's relevant.

  People have advocated all kinds of stupid things over the years.  None of that is relevant.  The concern here is that you're claiming there are major issues with EAP using id-kp-serverAuth, and that those issues *will* be seen.  My counter-position is that it's been 15 years, and no such issues have been seen.

  So please state *what* issues exist.  *Why* they are issues.  *What* effects those issues will have.  Failing that, please stop claiming that there are issues.

> This is empirically false. The use of certain CA’s certificates in wireless deployments has absolutely been a barrier to compliance and improvements.

  How?  How are those barriers *specific* to EAP, and are not generic to any certificate upgrade / change?

  You haven't said.

> I’ve demonstrated both a and b are false, perhaps not to your satisfaction, but it remains true.

  No, you haven't demonstrated that.  And not even "to my satisfaction".  You've made claims with essentially zero evidence.

  And let's be clear here.  Your claim above is that the existing EAP practices are *not* workable.  That claim is disproven by the working of all WiFi equipment.

  Since I'm not satisfied or maybe not understanding your point, please explain *how* the current EAP practices *do not work*, in the face of billions of devices that manifestly do work.  Please make the explanation simple, and specific to EAP.

> The same message you’re replying to contains one, which you dismiss as unworkable. It’s unclear why, or if the only solution is enshrine the status quo?

  Where did I dismiss any solution as unworkable?

> Apologies for the confusion here, but there seems to be a lot of unresolvable contradictions here. We must do something different, but we can’t change. We know the current solution is bad, but there’s nothing wrong with it. We need something better, but we can’t break anything.

  My position is in no way contradictory.  I will re-iterate as it seems to be misunderstood:

* the existing practices work (you claim they do not)
* the existing practices appear to be mostly secure (you claim they are not)
* the existing practices are imperfect (using TLS web server OIDs for EAP is bad, and allows for a security issue)
* we should come up with a better solution
* that better solution CANNOT be implemented by breaking existing systems
* we need a migration path from "now" to "the better solution".
* there has been discussion about what a better solution would look like
* discussion has indicated that others oppose parts of the proposed solution.

> I strongly disagree here. Documenting bad behaviour in SDOs serves to try and legitimize it. The only benefit is to allow existing implementations to align and new implementations to be interoperable, except the behavior being specified is bad, and will break, and will cause pain. Even on the Informational track, that would be actively harmful to the ecosystem.

  How?

>   I welcome concrete proposals to move forward.  The discussion here seems to recommend against using id-kp-eapOverLAN and NAIRealm.  Which means we *don't* have a way forward.

  We don't have a way forward until WG consensus is reached.  Which is why we're having this discussion.

  Honestly, I'm confused at the discussion here.  You're not showing any *concrete* security issues above what I've already discussed.  You're not proposing anything better.  You're claiming that EAP doesn't work today.  You want to fix things by breaking everything.

  That's... not something I understand.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 7 Jan 2020 16:34:19 -0500

Hi Alan,

I've snipped your message, because I think we've gotten to a place where
we're clearly talking past each other, as you claim I've said several
things which I've most definitely not said, or expressed the opposite view.
I'm hoping a reset here might help us find a more productive path forward,
as well as figure out where the confusion started.

I think it's useful to go back to the original message from Owen, at
https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM .
Perhaps there are other messages and context I've missed, since this was
cross-posted across two WGs, but that's the starting point.

In that, I think we've got a path forward for interoperable EAP
implementations: NAIRealm with id-kp-eapOverLAN asserted as an EKU. That
gives a minimal sort of certificate profile to begin discussing.

The question posed in that original message is what to do with extant
certificates and extant practices, such as going to CAs used for TLS and
asking for an id-kp-serverAuth cert, or supplicants looking for
id-kp-serverAuth, and whether to specify that. My answer to that is
categorically "no, don't do that". This is not specific to EAP, but part of
the general problem of repurposing different trust hierarchies and
different implementations, without addressing or mitigating the ecosystem
considerations.

For example, the use of such certificates outside of TLS can and will lead
to them being revoked, because one of the requirements for such
certificates is that they be used in TLS, otherwise they're revoked. Also,
the changes to how PKI libraries validate TLS certificates, and the
expectations for the issuance and management of such certificates, are at
odds with the goals and objectives of interoperability being discussed.
Reusing private key material across protocols and use cases does cause
issues, just like reusing root certificates across trust purposes does
cause issues. So using the TLS PKI is and always will be fraught with
peril, and the maintainers of those TLS PKIs will disregard "your" concerns
(the equipment, software, and users), because "your" use case is explicitly
not supported and not supportable.

These concerns aren't unique to EAP, by any means. But they're reasons why
using id-kp-serverAuth is going down a route of trouble, and just because
it's been done by some vendors doesn't mean it's good. A transition plan is
always challenging, and the IETF is generally a poor venue for figuring out
those logistics, because they're often rarely technical. For example, RFC
7585 exists: implementations "just" need to adopt it. Or, if the desire is
to have an RFC describe what the end state should be, it should focus on
that: describing the end-state. I don't think it should specify the
intermediate states, because those are going to vary on a host of concerns,
and worse, encourage folks to stop at the intermediate state as being 'good
enough'. One such example of an intermediate state is using
id-kp-serverAuth certificates, or trying to make a public/private CA
demarcation. Those are bad steps to take.

I'm not as optimistic as you are for suggesting 'all' EAP
clients/supplicants are behaving and enforcing those extended key usages,
so that doesn't seem too unreasonable. For example, wpa_supplicant doesn't
seem to do so, in the versions used by ChromeOS, Android, or the current
tip of tree (using either the internal or the OpenSSL implementation), and
that seems like it probably covers quite a few devices/clients.

In the TLS PKI, there's lots of industry experience on how to make changes.
These changes often involve significant risk of breakage, and yet have
become somewhat the norm, and with minimal practical impact. These can
involve setting flag days, often starting as per-vendor flag days, such as
was done with SHA-1. They can start with changes in major releases, such as
new behaviours introduced in a major OS release or a major supplicant
release to align closer to the specification or end-state. They may involve
some of the intermediate steps mentioned, but only to the extent those are
intermediate accomodations; for example, Chrome often has Enterprise flags
that allow disabling standards-compliant behaviour when rolling out new
versions, but only for a limited time and under limited situations. These
aren't, I think, good things to specify, but they're certainly good things
to share information about. I don't know if the IETF is the best place for
that, but that's neither here nor there. However, an important part of
those experiences is that things don't move until vendors break things.
Yes, there needs to be a better path, but until you're willing to remove
support for the old, or provide incentives for the new, your users don't
and won't move.

Hopefully that's easier to understand. I'm not sure how we ended up on such
different pages, but I think the assertions and requests from your last
message were a good indicator that we weren't even in the same postal code,
let alone the same page, as far as discussions go.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 7 Jan 2020 21:00:34 -0500

On Jan 7, 2020, at 4:34 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> I've snipped your message, because I think we've gotten to a place where we're clearly talking past each other, as you claim I've said several things which I've most definitely not said, or expressed the opposite view. I'm hoping a reset here might help us find a more productive path forward, as well as figure out where the confusion started.

  OK, that sounds good..

> I think it's useful to go back to the original message from Owen, at https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM . Perhaps there are other messages and context I've missed, since this was cross-posted across two WGs, but that's the starting point.

  I agree.  It would help to have a draft.

> In that, I think we've got a path forward for interoperable EAP implementations: NAIRealm with id-kpid--eapOverLAN asserted as an EKU. That gives a minimal sort of certificate profile to begin discussing.

  My only $0.02 there is that RFC 4334 defines id-kp-eapOverLAN, but seems to imply that it is intended for *client* certificates.  That would need clarification for this use-case.

> The question posed in that original message is what to do with extant certificates and extant practices, such as going to CAs used for TLS and asking for an id-kp-serverAuth cert, or supplicants looking for id-kp-serverAuth, and whether to specify that. My answer to that is categorically "no, don't do that".

  The use of id-kp-serverAuth is suggested in RFC 5216 Section 5.3:

   In the case of the EAP-TLS peer, this involves ensuring that the
   certificate presented by the EAP-TLS server was intended to be used
   as a server certificate.  Implementations SHOULD use the Extended Key
   Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that
   at least one of the following is true:

   1) The certificate issuer included no Extended Key Usage identifiers
      in the certificate.
   2) The issuer included the anyExtendedKeyUsage identifier in the
      certificate (see Section 4.2.1.13 of [RFC3280]).
   3) The issuer included the id-kp-serverAuth identifier in the
      certificate (see Section 4.2.1.13 [RFC3280]).

  Realistically, we can't change these recommendations in an "update EAP for TLS 1.3" document.

> This is not specific to EAP, but part of the general problem of repurposing different trust hierarchies and different implementations, without addressing or mitigating the ecosystem considerations.

  There are many OIDs assigned to extended key purpose:

https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.2

  On quick inspection, most of those don't define their own PKI hierarchy.  So it would seem that most have the same problem.

> For example, the use of such certificates outside of TLS can and will lead to them being revoked, because one of the requirements for such certificates is that they be used in TLS, otherwise they're revoked.

  Based on personal knowledge, such revocation will take down a number of banks world-wide.  And many other enterprises.  Which to me, means it's not going to happen.

  And how the heck is the CA going to find out?  They don't have armies of people trolling SSIDs for "mis-use" of certificates.

  Any user of such a certificate could point to RFC 5216, and rightly claim that this use-case is explicitly allowed.

  Further, RFC 2549 defines id-kp-serverAuth as being for "TLS Web server authentication".  But it doesn't mandate that certificates get revoked if they're used for another purpose.

  TBH, I'd like to see a pointer to an official CA policy saying that such revocation is required.

> Also, the changes to how PKI libraries validate TLS certificates, and the expectations for the issuance and management of such certificates, are at odds with the goals and objectives of interoperability being discussed.

  I'm not sure why.

  Having spent too much time banging my head against the OpenSSL API, I have some depressing familiarity with it.  Their certificate validation API doesn't care about extended key usage.  Those checks have to be added by the application.

  So... if we upgrade EAP implementations to use id-kp-eapOverLAN, then only the EAP applications have to be updated.  The common PKI libraries don't change.

> Reusing private key material across protocols and use cases does cause issues,

  Such as?

> just like reusing root certificates across trust purposes does cause issues. So using the TLS PKI is and always will be fraught with peril, and the maintainers of those TLS PKIs will disregard "your" concerns (the equipment, software, and users), because "your" use case is explicitly not supported and not supportable.

  I disagree rather fundamentally.  For one, it's not "my" use-case.  It's the use-case of literally billions of devices, and of the largest companies on the planet. 

  You're suggesting here that the root CAs will tell those people to "get stuffed" with no repercussions.  I don't see that happening.  Ever.

   If the root CAs try something so stupid, it will be international news, and they will get told in no uncertain terms to stop it.  And they will.

> These concerns aren't unique to EAP, by any means. But they're reasons why using id-kp-serverAuth is going down a route of trouble, and just because it's been done by some vendors doesn't mean it's good.

  Not "some vendors".   All vendors.  BILLIONS of devices.  TRILLION DOLLAR companies.

  In a fight between you and them, I'll bet on them.  I understand where you're coming from, but describing this practice as "done by some vendors" is drastically minimizing the situation.

> A transition plan is always challenging, and the IETF is generally a poor venue for figuring out those logistics, because they're often rarely technical. For example, RFC 7585 exists: implementations "just" need to adopt it. Or, if the desire is to have an RFC describe what the end state should be, it should focus on that: describing the end-state. I don't think it should specify the intermediate states, because those are going to vary on a host of concerns, and worse, encourage folks to stop at the intermediate state as being 'good enough'. One such example of an intermediate state is using id-kp-serverAuth certificates, or trying to make a public/private CA demarcation. Those are bad steps to take.

   Again, this isn't an "intermediate state".  This is decades-long existing practice, and existing standards.

  I think part of the disconnect here is that you're not clear on just how entrenched this use-case is.  You keep saying "some vendors" or describe it as an "intermediate state".  It's simply not true, and that false description is leading you to false conclusions.

> I'm not as optimistic as you are for suggesting 'all' EAP clients/supplicants are behaving and enforcing those extended key usages, so that doesn't seem too unreasonable. For example, wpa_supplicant doesn't seem to do so, in the versions used by ChromeOS, Android, or the current tip of tree (using either the internal or the OpenSSL implementation), and that seems like it probably covers quite a few devices/clients.

  Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth.  wpa_supplicant checks for it, too.  See src/tls/tlsv1_client_read.c.  The requirements of RFC 5216 Section 5.3 are followed.

  Yes, this means that it's theoretically possible for a site to use *only* wpa_supplicant, and therefore not include id-kp-serverAuth in it's EAP server certificate.  But in a multi-vendor environment, the EAP server certificate MUST include id-kp-serverAuth, otherwise many devices will not be able to connect.

  I'll bet that the only EAPoL deployments which don't include id-kp-serverAuth are (a) tests / toys, or (b) controlled environments used only by a tiny number of devices.

  So id-kp-serverAuth is *entrenched*.  It's not used sometimes by some vendors.  It's baked into existing standards and implementations.  Everyone uses it all of the time.  Everywhere.  Always.

> In the TLS PKI, there's lots of industry experience on how to make changes. These changes often involve significant risk of breakage, and yet have become somewhat the norm, and with minimal practical impact. These can involve setting flag days, often starting as per-vendor flag days, such as was done with SHA-1. They can start with changes in major releases, such as new behaviours introduced in a major OS release or a major supplicant release to align closer to the specification or end-state. They may involve some of the intermediate steps mentioned, but only to the extent those are intermediate accomodations; for example, Chrome often has Enterprise flags that allow disabling standards-compliant behaviour when rolling out new versions, but only for a limited time and under limited situations. These aren't, I think, good things to specify, but they're certainly good things to share information about. I don't know if the IETF is the best place for that, but that's neither here nor there. However, an important part of those experiences is that things don't move until vendors break things. Yes, there needs to be a better path, but until you're willing to remove support for the old, or provide incentives for the new, your users don't and won't move.

  I believe a good incentive to deploy the new behaviour has been discussed here: ease of configuration of the end-user devices.

  Other SDOs like the Wi-Fi alliance are moving ahead with their own requirements on certificates.  CAs will support those requirements for the simple reason that it makes them money.

> Hopefully that's easier to understand. I'm not sure how we ended up on such different pages, but I think the assertions and requests from your last message were a good indicator that we weren't even in the same postal code, let alone the same page, as far as discussions go.

  I agree.  I think some of the disconnect may be addressed here.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 8 Jan 2020 03:11:09 -0500

On Tue, Jan 7, 2020 at 9:00 PM Alan DeKok <[email-masked]> wrote:

> categorically "no, don't do that".
>

For EAP-TLS, that is, where you have the full fidelity of TLS, these are
fine-ish requirements. They would be bad requirements outside the context
of TLS (e.g. signed assertions or other protocols).

However, if using the same set or CAs that popular OSes use for TLS, it
does mean that these CAs, and their customers, will still be subject to the
same agility requirements, and limited to the same profile as TLS. Because
of this, there’s ample reason to split further into the dedicated hierarchy
and dedicated EKU.

For example, no CA that is “publicly trusted” for TLS will be able to issue
a certificate with id-kp-serverAuth and also NAIRealm in the otherName,
because they are contractually limited (and in some cases, legally
restricted by their local operating jurisdiction) from including other
forms of subjectAltNames. The use of distinct EKUs, however, would allow
them to do so, because those restrictions and regulations are largely
specific to id-kp-serverAuth.

> This is not specific to EAP, but part of the general problem of
> repurposing different trust hierarchies and different implementations,
> without addressing or mitigating the ecosystem considerations.
>
>   On quick inspection, most of those don't define their own PKI
> hierarchy.  So it would seem that most have the same problem.

Yup. I mentioned in the prior mail, but perhaps it wasn’t clear, that many
of the PKI management concepts from ITU-T don’t work in practice.

That is, while RFC 5280 et al provide the technical flexibility for a wide
variety of PKI approaches, as demonstrated through RFC 4158, and RFC 3647
provides an approach for structuring the policy, the operational concerns
that arise mean that the technological flexibility isn’t usable or useful
in practice. RFC 5280 envisaged that two different applications that had
two different policies (for example, a hypothetical Google Root store vs a
hypothetical Microsoft Root store) would, on a policy level, ensure that
every CA’s 3647-policy was compatible with and audited against their
requirements, and on a technical level, ensure that every certificate they
ingested was mapped to a (Google || Microsoft) specific set of policies
contained in the user-initial-policy-set inputs of 6.1.1 of 5280, with the
Root store applying policyMappings against those trust anchors.

However, that is not and has never been the case, as applications and
verifications don’t use the user-initial-policy-set. The consequence of
this is that, from an administrative perspective, the policy OID is
virtually entirely ignored, and more or less from the first deployment of
v3 certificates, policy has been associated and imposed at the EKU level
instead. That is, if a given EKU is present, then the issuing CA is
contractually and administratively subject to the Root Store’s policies and
expectations, because client software and libraries does not and roughly
had never used the user-initial-policy-set.

In more recent times, the differences in profiles and expectations for
those EKUs (such as timestampping vs email vs TLS), and the challenges in
managing hierarchies that issue multiple different EKUs and ensuring the
hierarchy is adequately compliant with all the expectations, even when
segmented by intermediate and EKU, has seen a shift into separating out the
hierarchies such that a given hierarchy (root and all intermediates) ONLY
issue certain types of certificates. This makes the CP/CPS manageable for
the root store to consume, and manageable for the process of assessing and
auditing.

I apologize for the length of this, but it’s meant to underscore that the
flexibility afforded by 5280/3647 is not usable in practice, not as
idealized in the early 90s when the PKI Gold Rush was going on and folks
like the ABA were figuring out how to audit/assess (c.f. the PKI Assessment
Guidelines that would coevolve into/influence ISO 21188 and later
WebTrust). The hyperfederated models in 4158 work on a technical level, but
not on a practical level, certainly not on an Internet level, and
simplicity is preferred and encouraged.

> For example, the use of such certificates outside of TLS can and will
> lead to them being revoked, because one of the requirements for such
> certificates is that they be used in TLS, otherwise they're revoked.
>
>   Based on personal knowledge, such revocation will take down a number of
> banks world-wide.  And many other enterprises.  Which to me, means it's not
> going to happen.

Folks used to say the same about certain prominent root CAs: that they were
“too big to fail”. The reality is that while I suspect you’re right that
the CA is strongly incentivized not to follow their own stated policies
when those policies would cause harm, in many cases, they are contractually
or legally bound to do so; e.g. they’re required to follow their policies
by the root stores they are included in, and if they fail to do so, they
are removed from those root stores. As removal from the root stores means
things go from “one customer impacted” to “all customers impacted”, or
impact the viability of the business model of the CA, the root CA is
strongly incentivized to follow their policies over special favors for that
customer.

There are countless examples of this in the TLS PKI, because allowing CAs
to selectively ignore stated policies to appease certain customers is, at
its core, indistinguishable from malice or compromise from the point of
view or those who trust that CA. Major companies have had their
certificates revoked even when it left software or services non-functional.
If there is any theme from the TLS PKI for the past 5 years, it’s been “I’m
sorry, that’s unfortunate, but for the greater good you MUST be broken
because you’re certificate does not conform.”

>   And how the heck is the CA going to find out?  They don't have armies of
> people trolling SSIDs for "mis-use" of certificates.

Perhaps it wasn’t clear why I linked to that Atlassian issue in The
Register, but the point in doing so was to highlight that _anyone_ can
report to the CA when a customer is doing something problematic. For the
set of “publicly trusted” CAs, the policies they are governed by require
them to make available problem reporting mechanisms, to respond to those
within 24 hours, and if a violation, to revoke within 24 hours to five days.

This is also why I kept emphasizing the timebomb nature of it: your Wifi
may totally work, until all of a sudden someone decides to report it to the
CA, which obligates the CA to revoke.

  Any user of such a certificate could point to RFC 5216, and rightly claim
> that this use-case is explicitly allowed.
>
>   Further, RFC 2549 defines id-kp-serverAuth as being for "TLS Web server
> authentication".  But it doesn't mandate that certificates get revoked if
> they're used for another purpose.
>

As part of (Day Job), I review the policies of every CA our software
decides to trust, in detail. I also manage what our expectations are for
the CAs we trust.

A common set of expectations is the CA/Browser Forum’s Baseline
Requirements. Section 4.9.1.1 enshrines a number of common expectations of
revocation, although both root stores and CAs are free to add more. For
example, Microsoft’s policies and contracts, at https://aka.ms/rootcert,
require prompt revocation if Microsoft’s directs this, under some
circumstances.

Section 4.9.1.1 of the BRs requires revocation for “misuse”. Misuse is
intentionally (by the root programs, at least; some CAs marketing
departments would prefer otherwise) not defined by the BRs; that’s
something the CA defines, but is required to define. In RFC 3647, this is
often tied to Section 4.4.5, which maps to Section 1.4 of the CA’s CP/CPS,
although in practice CAs split this definition up all over their CP/CPS.

An example of a recent CP/CPS review, where I flagged concerns over how a
CA expressed in their CP/CPS what acceptable uses were in Section 1.4, is
https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13 . Here, the CA
arguably prohibited the use of their certificates in TLS servers
altogether, which is pretty shocking, and why I flagged it. In practice,
the CP/CPSes I review place restrictions that limit a certificate to TLS,
and prohibit the use of the private key to sign other things. In general,
that’s a good definition of “misuse”, but it does mean that using such
certificates in other contexts (e.g. to sign documents) will cause 1.4 to
be violated, which means anyone in the world will be able to request that
certificate be revoked, at any time, and the CA have contractual
obligations to do so if they wish to remain trusted.

> Also, the changes to how PKI libraries validate TLS certificates, and the
>   Having spent too much time banging my head against the OpenSSL API, I
> have some depressing familiarity with it.  Their certificate validation API
> doesn't care about extended key usage.  Those checks have to be added by
> the application.
>
>   So... if we upgrade EAP implementations to use id-kp-eapOverLAN, then
> only the EAP applications have to be updated.  The common PKI libraries
> don't change.

I agree that this goes away if you use an explicit EKU; the problem I was
describing exists only if the profile tries to require id-kp-serverAuth.

> issues,

https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-felsch.pdf
https://www.usenix.org/sites/default/files/conference/protected-files/security16_slides_aviram.pdf
https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf

I’m sure everyone’s got a favorite citation, but the TLS WG spent so long
on formal security proofs in part because of the number of issues that
resulted from the negotiation and key reuse across TLS versions, which are
functionally “different” protocols.

> just like reusing root certificates across trust purposes does cause
> issues. So using the TLS PKI is and always will be fraught with peril, and
> the maintainers of those TLS PKIs will disregard "your" concerns (the
> equipment, software, and users), because "your" use case is explicitly not
> supported and not supportable.
>
>   I disagree rather fundamentally.  For one, it's not "my" use-case.  It's
> the use-case of literally billions of devices, and of the largest companies
> on the planet.
>
>   You're suggesting here that the root CAs will tell those people to "get
> stuffed" with no repercussions.  I don't see that happening.  Ever.

You’re right that we disagree. However, it’s important to note: I didn’t
say no repercussion.

In these situations, the CA is between a rock and a hard place: they can
follow their stated policies and contractual obligations, which generally
means breaking their customer because either the CA or the customer did
something wrong, or they can violate their stated policies and obligations
and risk distrust by the vendors that trust them. This is the inherent
challenge in any third-party operates CA: you can’t delegate trust.

A good example of this is the use of underscores in domain names in
certificates. Underscores are not part of the preferred name syntax, and
thus are not conformant with RFC5280 for inclusion within a subjectAltName,
even if they’re valid DNS labels (since DNS is 8-bits of goodness). Since
resolving libraries were generally more than “just” DNS and didn’t enforce
the preferred name syntax on inputs, the use of underscores in DNS
hostnames slowly crept in to the ecosystem, with major operating systems
like Windows allowing them and resolving such names.

TLS CAs are obligated to follow 5280, and there were a few CAs that ignored
this requirement of 5280, and issued such invalid and unauthorized
certificates. Browsers declared that they must revoke these non-conforming
certificates. Yet this broke high-profile customers like Verizon, CIBC, CVS
  Pharmacy, Discover, Citi, Intuit, and Ericsson. That’s a veritable who’s
who of healthcare, banking, and telecom - and yet they were still broken
none the less, because the harm to them was outweighed by the harm caused
by selective and arbitrary compliance and enforcement. Were they happy with
their CA (and with root stores)? Oh no. Some of them definitely changed
their CA after that, and many harsh and heated threats were sent to root
store vendors. But, it happened. Those certificates were revoked.

The solution for problems like this is to make sure you don’t overlap with
the requirements of other consumers, and why using the separate EKU, which
is the most common way to free yourself of those requirements, is the best
bet.

That said, it may not totally free you. For example, Cisco could
contractually require every CA that Cisco trusts follows Cisco’s policies,
and so if Cisco forbid something your implementation wanted to do or use,
y’all would not be able to use the same set of CAs. That’s the
interoperability challenge I was referencing, and how to resolve that is
arguably beyond the ken of the IETF.

   If the root CAs try something so stupid, it will be international news,
> and they will get told in no uncertain terms to stop it.  And they will.

Hah, you and I live in very different worlds than how CAs are managed.

I didn’t see much international news when the SHA-1 deprecation in the TLS
PKI reportedly threatened to leave entire countries unable to process
payments, did you? Even stuff like
https://blog.mozilla.org/security/2016/02/24/payment-processors-still-using-weak-crypto/
got very little attention. Certainly, I think there’s still only a handful
of people who could name which CA surreptitiously backdated SHA-1
certificates for which payment processor company, in violation of their
policies and requirements, seemingly in order to attract business from them
(as the payment processor used a different CA, and that existing CA
followed the rules).

> These concerns aren't unique to EAP, by any means. But they're reasons
> why using id-kp-serverAuth is going down a route of trouble, and just
> because it's been done by some vendors doesn't mean it's good.
>
>   In a fight between you and them, I'll bet on them.  I understand where
> you're coming from, but describing this practice as "done by some vendors"
> is drastically minimizing the situation.

I’m not sure how this isn’t a full-throated support for the broken and
dangerous status quo. There’s a way forward here, and change is possible. I
fully acknowledge that customer satisfaction often triumphs over technical
considerations, and customers are most satisfied when they have the least
work to do. However, it is possible to change things, even in ways that may
break backwards compatibility, and folks do it all the time.

The context in this is largely around making it zero-config, which is
entirely laudable goal, but inherently Something New and thus the absolute
best opportunity to break things.

> A transition plan is always challenging, and the IETF is generally a poor
> venue for figuring out those logistics, because they're often rarely
> technical. For example, RFC 7585 exists: implementations "just" need to
> adopt it. Or, if the desire is to have an RFC describe what the end state
> should be, it should focus on that: describing the end-state. I don't think
> it should specify the intermediate states, because those are going to vary
> on a host of concerns, and worse, encourage folks to stop at the
> intermediate state as being 'good enough'. One such example of an
> intermediate state is using id-kp-serverAuth certificates, or trying to
> make a public/private CA demarcation. Those are bad steps to take.
>
>    Again, this isn't an "intermediate state".  This is decades-long
> existing practice, and existing standards.

>   I think part of the disconnect here is that you're not clear on just how
> entrenched this use-case is.  You keep saying "some vendors" or describe it
> as an "intermediate state".  It's simply not true, and that false
> description is leading you to false conclusions.

I agree that we have a disconnect, but the context here is from Owen’s
original message, and I get the feeling you have a different design or
conclusion that you’ve not expressed but are operating on, or that I’ve
fundamentally misunderstood.

That original discussion was in the context of public CAs. In the world of
locally-configured or private CAs, I don’t have as strong opinions.
However, if the objective is to get to an end state where EAP is “secure by
default” and any EAP operator can “just” get a certificate, then any
discussion about id-kp-serverAuth isn’t the extant status quo.

Further, the nice thing about private or locally configured certificates is
they provide a very easy transition plan, because you know “someone”
generated the certificate and can generate the “right” thing when it’s
required by a client. The nice thing about EKUs being a SEQUENCE is with
everything we’ve been discussing, it’s possible to support both Old and New
for private use simultaneously, while the zero-touch world can *only* use
New.

>   Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth.
> wpa_supplicant checks for it, too.  See src/tls/tlsv1_client_read.c.  The
> requirements of RFC 5216 Section 5.3 are followed.

Thanks for the pointer! Applying it post-validation is definitely an
interesting strategy, given the operational considerations and issues like
https://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf that can
allow for EKUs to bleed across hierarchies. I had mistakenly looked on the
validation side, since that’s where the identity validation occurs.

However, that’s still not intrinsically at odds with the original message
to Owen, or with the design principles I’ve been trying to capture in these
replies, which is that if the desire to is to have zero-touch auth, you
need to do one of the following:
1) Define a new, non-overlapping trust store (whether for id-kp-serverAuth
or for id-kp-eapOverLan) with its own profile and policies or
2) Accept that any use of a shared or overlapping trust store will be
subject to the agility requirements of the existing trust stores (read:
OSes and browsers)

#2 is almost always going to work out badly for users and deployments,
which is why I’m so strongly discouraging it, even if it’s technically
viable, and so it’s best to accept the cost of #1 upfront rather than defer
it.

  So id-kp-serverAuth is *entrenched*.  It's not used sometimes by some
> vendors.  It's baked into existing standards and implementations.  Everyone
> uses it all of the time.  Everywhere.  Always.

And going back to the original message: is everyone always using public
CAs? I got the impression that our experiences are similar: which is that
it requires manual and explicit configuration, and there’s no “out of the
box” trust store here, and that the use of public CAs is not a concept that
can MSP, because inherently, these are all manually configured.-

I believe a good incentive to deploy the new behaviour has been discussed
> here: ease of configuration of the end-user devices.
>
>   Other SDOs like the Wi-Fi alliance are moving ahead with their own
> requirements on certificates.  CAs will support those requirements for the
> simple reason that it makes them money.

Sure, but Wi-Fi Alliance is also doing the thing I’ve been encouraging:
defining their own trust store. A CA trusted for TLS today cannot comply
with root program requirements and issue Passpoint certificates. The
profiles are incompatible, which is fine, as long as you don’t have trust
overlap. And that’s true everywhere but Windows right now, or at least when
I last did the CP/CPS reviews three months ago.

My issue with Owen’s original proposal, and hopefully it remains clear
here: overlapping the PKIs should be a non-goal. Distinguishing them at the
EKU is fine; distinguishing them at the EKU so extant CAs can issue from
extant trust hierarchies is problematic and should be a non-goal. At the
same time, changing the EKU in order to change the profile, and having
supplicants strictly enforce that profile, _is_ a good idea, in as much as
it allows you to explicitly transition to a sensible and defined profile
and make a clean break.

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Wed, 8 Jan 2020 10:00:25 +0000

Hi Ryan,

This topic seems like a good one to just get on the phone and sort through, but I have one question:

On 8 Jan 2020, at 09:11, Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:

However, if using the same set or CAs that popular OSes use for TLS, it does mean that these CAs, and their customers, will still be subject to the same agility requirements, and limited to the same profile as TLS. Because of this, there’s ample reason to split further into the dedicated hierarchy and dedicated EKU.

Is there an example of a non-EAP use where splitting into a new hierarchy has actually succeeded?

Eliot

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 8 Jan 2020 06:26:39 -0500

On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) <[email-masked]> wrote:

> On 8 Jan 2020, at 09:11, Ryan Sleevi <[email-masked]> wrote:
>

Document signing generally fits there, in that there are a number of CAs
that only offer document signing/identity proofing without overlapping. As
would, say, Cisco’s device/firmware signing model or the PKIs in use in the
financial services/ATM markets.

Relevant to EAP would be the aforementioned Passpoint model, which uses new
and distinct CAs for that. There are definitely flaws with that (e.g.
wanting said CAs to work with browsers), but there are parts of it that do
work.

There’s no technical reason to require the use of the same roots/same
hierarchy, and ample and adequate reason to distinguish: both from the
perspective of a root store maintainer (ensuring certificates comply with
policies) and as a certificate consumer (minimizing risk of misissuance,
ala Flame)

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Wed, 8 Jan 2020 11:29:48 +0000

Thanks, Ryan.  After I sent the note I thought about document signing.  Our SUDI model at Cisco I view as somewhat different, but may be closer to apt to EAP anyway, so worth discussing.

Eliot

On 8 Jan 2020, at 12:26, Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ryan,

Document signing generally fits there, in that there are a number of CAs that only offer document signing/identity proofing without overlapping. As would, say, Cisco’s device/firmware signing model or the PKIs in use in the financial services/ATM markets.

Relevant to EAP would be the aforementioned Passpoint model, which uses new and distinct CAs for that. There are definitely flaws with that (e.g. wanting said CAs to work with browsers), but there are parts of it that do work.

There’s no technical reason to require the use of the same roots/same hierarchy, and ample and adequate reason to distinguish: both from the perspective of a root store maintainer (ensuring certificates comply with policies) and as a certificate consumer (minimizing risk of misissuance, ala Flame)

---

From: Alan DeKok <[email-masked]>
Date: Wed, 8 Jan 2020 08:14:38 -0500

> However, if using the same set or CAs that popular OSes use for TLS, it does mean that these CAs, and their customers, will still be subject to the same agility requirements, and limited to the sam…

  We absolutely need a dedicated hierarchy.  A major reason why EAP uses id-kp-serverAuth is because no other hierarchy has been available.

> For example, no CA that is “publicly trusted” for TLS will be able to issue a certificate with id-kp-serverAuth and also NAIRealm in the otherName, because they are contractually limited (and in some cases, legally restricted by their local operating jurisdiction) from including other forms of subjectAltNames. The use of distinct EKUs, however, would allow them to do so, because those restrictions and regulations are largely specific to id-kp-serverAuth.

  Except, of course, CAs don't really have a process to issue certs with distinct EKUs.  So they're impossible to get in practice.

> Perhaps it wasn’t clear why I linked to that Atlassian issue in The Register, but the point in doing so was to highlight that _anyone_ can report to the CA when a customer is doing something problematic. For the set of “publicly trusted” CAs, the policies they are governed by require them to make available problem reporting mechanisms, to respond to those within 24 hours, and if a violation, to revoke within 24 hours to five days.
> 
> This is also why I kept emphasizing the timebomb nature of it: your Wifi may totally work, until all of a sudden someone decides to report it to the CA, which obligates the CA to revoke.

  There's a big difference between "my bank has some IT issues", and "all of enterprise WiFi stops working, world-wide".  That's my concern.  And, why I think existing practices will continue into the foreseeable future.

> Section 4.9.1.1 of the BRs requires revocation for “misuse”. Misuse is intentionally (by the root programs, at least; some CAs marketing departments would prefer otherwise) not defined by the BRs; that’s something the CA defines, but is required to define. In RFC 3647, this is often tied to Section 4.4.5, which maps to Section 1.4 of the CA’s CP/CPS, although in practice CAs split this definition up all over their CP/CPS.

  If mis-use isn't defined, then it's reasonable to argue that following IETF standards isn't mis-use.

> I agree that this goes away if you use an explicit EKU; the problem I was describing exists only if the profile tries to require id-kp-serverAuth.

  I don't see how.  Validation of id-kp-serverAuth is the responsibility of the application, not the TLS library.  i.e. the TLS library exports APIs which (a) do TLS, and (b) allow the application to selectively validate certificates.

  It is inappropriate for a TLS library to enforce one EKU on all users of TLS.  And how would the library do that?  It is entirely unaware of the transport protocol (TCP / HTTPS vs EAP).

> https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf

  On initial reading, none of those attacks are relevant here.

  The situation we have here is that we have a normal TLS "web server" certificate which is being used for TLS.  The transport protocol here is EAP, not TCP.  You seem to be claiming that there are security issues with this use-case.  I don't see how.

  i.e. we're not re-using the same private key material across disparate encryption protocol.  Which is what those papers discuss.  We're using TLS as TLS, in the same way that other people use TLS.  It's 100% normal TLS, with 100% the same certificate.  The only thing that changes is the transport layer which encapsulates the TLS protocol.

  I fail to see how using an EAP header is insecure, whereas using a TCP header is fine.  The only attack I'm aware of is an administrative one.  A TLS web admin can use the web certificate to set up an unauthorized SSID.  And, an EAP admin can use the EAP certificate to set up an unauthorized web server.  That's really it.

> I’m sure everyone’s got a favorite citation, but the TLS WG spent so long on formal security proofs in part because of the number of issues that resulted from the negotiation and key reuse across TLS versions, which are functionally “different” protocols.

  But using the *same* TLS version across different transport protocols is insecure?  If so, why?

> You’re right that we disagree. However, it’s important to note: I didn’t say no repercussion.

  Sure.

> In these situations, the CA is between a rock and a hard place: they can follow their stated policies and contractual obligations, which generally means breaking their customer because either the CA or the customer did something wrong, or they can violate their stated policies and obligations and risk distrust by the vendors that trust them. This is the inherent challenge in any third-party operates CA: you can’t delegate trust.

  I agree CAs can shut down individual use-cases if they desire.  My push-back is against the idea of turning off enterprise WiFi whole-sale, world-wide.  That's just not going to happen, no matter what the policies of the CA.

> I didn’t see much international news when the SHA-1 deprecation in the TLS PKI reportedly threatened to leave entire countries unable to process payments, did you?

  "My bank has IT issues due to stupid tech stuff" is completely different from "Wi-Fi is broken world-wide".

> I’m not sure how this isn’t a full-throated support for the broken and dangerous status quo.

  It's simple English.  Stating that this *is* the status quo doesn't mean I think it's a good idea.  I've spent many messages agreeing it's bad, and working on a better solution.  It's not just possible to describe my position as a "full-throated support for the broken and dangerous status quo."

  That attitude is approaching ad hominem invective, and it's entirely inappropriate.

> I agree that we have a disconnect, but the context here is from Owen’s original message, and I get the feeling you have a different design or conclusion that you’ve not expressed but are operating on, or that I’ve fundamentally misunderstood.

  The disconnect is largely that I don't think we can simply shut-down Wi-Fi world-wide.  Plus, you think that me describing the current system means I'm supporting it.  That's just not true.

> That original discussion was in the context of public CAs. In the world of locally-configured or private CAs, I don’t have as strong opinions. However, if the objective is to get to an end state where EAP is “secure by default” and any EAP operator can “just” get a certificate, then any discussion about id-kp-serverAuth isn’t the extant status quo.

  I have no idea what that means.  It reads like you're saying the use of id-kp-serverAuth isn't the existing practice.  Which it is.  So... why the disconnect?

  My recommendation for ~15 years for EAP has been that people should use private CAs.  It avoids all of the issues we're discussing here.

> Thanks for the pointer! Applying it post-validation is definitely an interesting strategy, given the operational considerations and issues like 
> https://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf that can allow for EKUs to bleed across hierarchies. I had mistakenly looked on the validation side, since that’s where the identity validation occurs.

  I think that's another disconnect.  TLS libraries don't perform HTTPS validation checks for all certificates.  They can't, because they have no idea what the underlying transport is.  All the TLS library knows is that it gets handed a TLS blob.  The library does its TLS magic, and hands decoded data to the application.

  All of the transport-specific validation happens in the application.  Because only the application knows what transport is being used.  And only the application can tie the two together.

  This is how TLS applications have been written for a very long time.  So I'm not sure why you describe checking id-kp-serverAuth as "post-validation".  It's not.  It's just one step of many.  The TLS library does some checks, and the application does other checks.  And doing it this way isn't an "interesting strategy", it's the only possible way to do it.  it's been industry practice for decades,

  A think a good chunk of the disconnect here is simple unfamiliarity with the subject space.

> However, that’s still not intrinsically at odds with the original message to Owen, or with the design principles I’ve been trying to capture in these replies, which is that if the desire to is to have zero-touch auth, you need to do one of the following:
> 1) Define a new, non-overlapping trust store (whether for id-kp-serverAuth or for id-kp-eapOverLan) with its own profile and policies or
> 2) Accept that any use of a shared or overlapping trust store will be subject to the agility requirements of the existing trust stores (read: OSes and browsers)
> 
> #2 is almost always going to work out badly for users and deployments, which is why I’m so strongly discouraging it, even if it’s technically viable, and so it’s best to accept the cost of #1 upfront rather than defer it.

  I agree.

> And going back to the original message: is everyone always using public CAs? I got the impression that our experiences are similar: which is that it requires manual and explicit configuration, and there’s no “out of the box” trust store here, and that the use of public CAs is not a concept that can MSP, because inherently, these are all manually configured.-

  Many people use private CAs.  Many use public CAs.  *All* of them use id-kp-serverAuth.  Common EAP supplicants (MS / Apple / etc.) ship with known root CAs.  These root CAs are trusted by default for web browsing.  None are trusted by default for EAP.

> My issue with Owen’s original proposal, and hopefully it remains clear here: overlapping the PKIs should be a non-goal. Distinguishing them at the EKU is fine; distinguishing them at the EKU so extant CAs can issue from extant trust hierarchies is problematic and should be a non-goal. At the same time, changing the EKU in order to change the profile, and having supplicants strictly enforce that profile, _is_ a good idea, in as much as it allows you to explicitly transition to a sensible and defined profile and make a clean break.

  That's been my position from the beginning.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 8 Jan 2020 09:29:37 -0500

On Wed, Jan 8, 2020 at 8:14 AM Alan DeKok <[email-masked]> wrote:

>   Except, of course, CAs don't really have a process to issue certs with
> distinct EKUs.  So they're impossible to get in practice.
>

I'm not sure what your data to support this is, but this does not match the
commercial space. While I think we're in agreement you "shouldn't" be using
publicly trusted CAs, it's not at all true that they don't really have a
process. Perhaps this was more true a decade ago, but the work on Delegated
Credentials and Signed HTTP Exchanges - both which require custom
certificate profiles for issuance, and both which are relatively recent and
yet available from CAs.

> IETF standards isn't mis-use.

I'm not sure how you reached this conclusion. I gave you an example of
where misuse is defined to preclude such certificates, and that's but one
of many examples if you read commercial CA's CP/CPSes. The argument you
might be making is that "Well, they can change" - and sure, but that's just
continuing to move the goalposts, when the high level message is the same:
that overlaying with extant CAs, the original proposal, is a bad idea and
full of sharp edges.

> > I agree that this goes away if you use an explicit EKU; the problem I
> was describing exists only if the profile tries to require id-kp-serverAuth.
>
>   I don't see how.  Validation of id-kp-serverAuth is the responsibility
> of the application, not the TLS library.  i.e. the TLS library exports APIs
> which (a) do TLS, and (b) allow the application to selectively validate
> certificates.
>
>   It is inappropriate for a TLS library to enforce one EKU on all users of
> TLS.  And how would the library do that?  It is entirely unaware of the
> transport protocol (TCP / HTTPS vs EAP).
>

I'm guessing you may be more familiar with the embedded libraries that roll
their own TLS stacks or build on OpenSSL?  This isn't how many of the
popular root stores and PKI libraries are implemented, which again goes
back to Owen's original question, for "public" certificates and extant root
stores - for example, the root stores and PKI/TLS libraries in a number of
popular operating systems, such as Windows, macOS/iOS, Android, and
ChromeOS.

These libraries have the client say "I want it for TLS", and the validation
library not only does validation for items like EKU, but that the
certificate complies with the root store policies for such certificates.
The root store policies may (as I mentioned previously) *also* have
dependencies on the particular TLS library being used; that is, they're not
designed to be used/operated outside of a given library.

>   The situation we have here is that we have a normal TLS "web server"
> certificate which is being used for TLS.  The transport protocol here is
> EAP, not TCP.  You seem to be claiming that there are security issues with
> this use-case.  I don't see how.
>

I'm afraid we're quickly diverging again, because I'm worried this claim
isn't being taken in the context it was made, so perhaps we should circle
back to this once we're on the same page on the fundamentals?

> > I’m sure everyone’s got a favorite citation, but the TLS WG spent so
> long on formal security proofs in part because of the number of issues that
>   But using the *same* TLS version across different transport protocols is
> insecure?

I didn't say it was.

>   I agree CAs can shut down individual use-cases if they desire.  My
> push-back is against the idea of turning off enterprise WiFi whole-sale,
> world-wide.  That's just not going to happen, no matter what the policies
> of the CA.
>

Great. I don't think anyone has suggested turning off enterprise WiFi,
whole-scale, world-wide, or even anything remotely close to that, so I
think we're good?

>   It's simple English.  Stating that this *is* the status quo doesn't mean
> I think it's a good idea.  I've spent many messages agreeing it's bad, and
> working on a better solution.  It's not just possible to describe my
> position as a "full-throated support for the broken and dangerous status
> quo."
>

I think I've spent as many messages saying the same thing: let's work on a
better solution. I've tried to articulate one several times, which doesn't
involve "break WiFi world wide", so perhaps we can focus on that?

>   The disconnect is largely that I don't think we can simply shut-down
> Wi-Fi world-wide.  Plus, you think that me describing the current system
> means I'm supporting it.  That's just not true.
>

I certainly haven't suggested we shut-down Wi-Fi world-wide. I have argued
against specifying the extant behaviour, in as much as standards imply
support, even informational. Even as tombstones of ideas that didn't work,
they serve as attractive nuisances for implementors.

> > That original discussion was in the context of public CAs. In the world
> of locally-configured or private CAs, I don’t have as strong opinions.
>   I have no idea what that means.  It reads like you're saying the use of
> id-kp-serverAuth isn't the existing practice.  Which it is.  So... why the
> disconnect?
>

Put simply: There's no "obtain a certificate from a public CA and it just
works", where that certificate contains id-kp-serverAuth. I don't and
haven't disagreed that people can and do use id-kp-serverAuth for private
CAs, and I also don't doubt people obtain server certs from public CAs and
then manually configure them, but there's no "it just works". If the goal
is to specify "it just works", there's no reason or need to be constrained
by id-kp-serverAuth.

>   My recommendation for ~15 years for EAP has been that people should use
> private CAs.  It avoids all of the issues we're discussing here.
>

We're in quite violent agreement :)

>   I think that's another disconnect.  TLS libraries don't perform HTTPS
> validation checks for all certificates.  They can't, because they have no
> idea what the underlying transport is.  All the TLS library knows is that
> it gets handed a TLS blob.  The library does its TLS magic, and hands
> decoded data to the application.
>

I think we have very different perspectives of the industry, and I suspect
this is unfamiliarity with our divergent areas. I get the impression you're
speaking more about embedded libraries and stuff like OpenSSL, and you're
true. That's not an accurate reflection of the stacks in a number of
operating systems - e.g. Windows, macOS/iOS, Linux Standard Base (via NSS),
Android, or ChromeOS. These libraries and APIs, used to underpin much of
the client TLS traffic (including browsers) are often abstracted APIs in
which the library handles the transport as well as the verification, and
they explicitly don't support disconnects.

>   Many people use private CAs.  Many use public CAs.  *All* of them use
> id-kp-serverAuth.  Common EAP supplicants (MS / Apple / etc.) ship with
> known root CAs.  These root CAs are trusted by default for web browsing.
> None are trusted by default for EAP.
>

Right: we're in agreement, I believe? Getting "trusted by default for EAP"
means disconnecting from id-kp-serverAuth, as part of, well, introducing
the concept of "trusted by default for EAP".

---

From: Alan DeKok <[email-masked]>
Date: Wed, 8 Jan 2020 10:38:16 -0500

To clarify. we agree on the following:

* id-kp-serverAuth is wrong to use for EAP
* we should use something else, whatever that is

  The rest of the disagreement is (from what I see), bringing up situations or use-cases which are unrelated to EAP, and therefore confusing the issue.

On Jan 8, 2020, at 9:29 AM, Ryan Sleevi <[email-masked]> wrote:
> I'm not sure what your data to support this is, but this does not match the commercial space. While I think we're in agreement you "shouldn't" be using publicly trusted CAs, it's not at all true that they don't really have a process. Perhaps this was more true a decade ago, but the work on Delegated Credentials and Signed HTTP Exchanges - both which require custom certificate profiles for issuance, and both which are relatively recent and yet available from CAs. 

  I've looked, and haven't been able to find a process where I can get a cert with id-kp-eapOverLan set.

> I'm not sure how you reached this conclusion. I gave you an example of where misuse is defined to preclude such certificates,

  Hmm... that wasn't clear at all.  I can't find any policies which say "certificates will be revoked if they're used for purposes other than TLS web server".  All of the text I see on revocation is about malware, leak of private keys, etc.

> I'm guessing you may be more familiar with the embedded libraries that roll their own TLS stacks or build on OpenSSL?

  I'm familiar with application use-cases.  Most EAP applications use OpenSSL.  As do RADIUS applications, web servers, DNS servers, etc.  They all operate the same way,

  Other systems implement things differently, of course.  OS vendors are locking down their cert stores to more stringently control access.  This includes limiting the API used by applications.  What other PKI systems do is irrelevant, because they don't implement the application protocols.

> [re: security issues with using TLS web server certs with EAP ]
> 
> I'm afraid we're quickly diverging again, because I'm worried this claim isn't being taken in the context it was made, so perhaps we should circle back to this once we're on the same page on the fundamentals?

  I was reacting to the following statement:

> I will say that using TLS (id-kp-serverAuth) certificates, from the intersection of CAs that are commonly trusted by operating systems and browsers, is bad. It will create security issues, will create interoperability issues, and will not help users.

> Reusing private key material across protocols and use cases does cause issues,

   With pointers to papers that shows private key usage across disparate encryption methods.  These papers are entirely irrelevant to the use-case discussed here, i.e. these certs being used for EAP-TLS.

  So I don't know how I'm misunderstanding you.  You claimed the use-case was insecure, and it would cause interoperability issues. 

  Maybe you're referring to other use-cases.  But if so, you're not making that clear.  I've been talking about EAP and WiFi.  Other use-cases aren't applicable here.

> Great. I don't think anyone has suggested turning off enterprise WiFi, whole-scale, world-wide, or even anything remotely close to that, so I think we're good?

  Suggesting that CAs will revoke all certificates mis-using id-kp-serverAuth *is* implying that enterprise WiFi will be disabled world-wide.  I explained in detail why I believe this correlation to be true.

> Put simply: There's no "obtain a certificate from a public CA and it just works", where that certificate contains id-kp-serverAuth.

  The only required step is for supplicants to explicitly enable that CA to be used for EAP.  As I said earlier, the root CAs are all enabled for the web, and none are enabled by default for EAP.

> I don't and haven't disagreed that people can and do use id-kp-serverAuth for private CAs, and I also don't doubt people obtain server certs from public CAs and then manually configure them, but there's no "it just works". If the goal is to specify "it just works", there's no reason or need to be constrained by id-kp-serverAuth. 

  Which is what I've been saying for a long time.  My goal to move to something else is to get it to the point where it just works.

> I think we have very different perspectives of the industry, and I suspect this is unfamiliarity with our divergent areas. I get the impression you're speaking more about embedded libraries and stuff like OpenSSL, and you're true. That's not an accurate reflection of the stacks in a number of operating systems - e.g. Windows, macOS/iOS, Linux Standard Base (via NSS), Android, or ChromeOS. These libraries and APIs, used to underpin much of the client TLS traffic (including browsers) are often abstracted APIs in which the library handles the transport as well as the verification, and they explicitly don't support disconnects.

  i.e. when you say "the library handles the transport as well as the verification", this is manifestly not true for EAP.  That's my point.  I'm trying to discuss EAP use-cases.

  Linux uses wpa_supplicant (or iwd), which *do* work the way I described.  The Apple supplicant code is also online, and last I checked, also works this way.  I don't know how the MS code works, but I highly doubt that their crypto library implements EAP.  I suspect that they also have an EAP implementation which calls a TLS library to do the TLS work.

  So I don't really care how OS vendors implement certificate checking for HTTPS.  It doesn't apply to EAP.  Bringing up irrelevant issues is just confusing and unhelpful.

> Right: we're in agreement, I believe? Getting "trusted by default for EAP" means disconnecting from id-kp-serverAuth, as part of, well, introducing the concept of "trusted by default for EAP".

  Yes.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 8 Jan 2020 11:29:32 -0500

On Wed, Jan 8, 2020 at 10:38 AM Alan DeKok <[email-masked]>
wrote:

>   The rest of the disagreement is (from what I see), bringing up
> situations or use-cases which are unrelated to EAP, and therefore confusing
> the issue.
>

They're related to the proposal that started this thread, which I'm trying
to focus the discussion on, and which may be why we keep finding
misalignment.

> > I'm not sure what your data to support this is, but this does not match
> the commercial space. While I think we're in agreement you "shouldn't" be
> using publicly trusted CAs, it's not at all true that they don't really
> have a process. Perhaps this was more true a decade ago, but the work on
> Delegated Credentials and Signed HTTP Exchanges - both which require custom

Thanks. It seems like you meant process as "They won't sell it to me", and
I meant process as "They can't sell it to me / Don't know how to sell it to
me".

> where misuse is defined to preclude such certificates,
>
>   Hmm... that wasn't clear at all.  I can't find any policies which say
> "certificates will be revoked if they're used for purposes other than TLS
> web server".

The CA must revoke if the certificate is misused; that's required by
contract.
The CA defines what misuse means.
A number of CAs define misuse as "used for purposes other than TLS web
server"
Ergo, obtaining and using certificates with EAP means these certificates
are at risk of revocation.

> > I'm guessing you may be more familiar with the embedded libraries that
> roll their own TLS stacks or build on OpenSSL?
>
>   I'm familiar with application use-cases.  Most EAP applications use
> OpenSSL.  As do RADIUS applications, web servers, DNS servers, etc.  They
> all operate the same way,
>
>   Other systems implement things differently, of course.  OS vendors are
> locking down their cert stores to more stringently control access.  This
> includes limiting the API used by applications.  What other PKI systems do
> is irrelevant, because they don't implement the application protocols.
>

It's extremely relevant to the original proposal, at
https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM,
and to the subsequent follow-ups (e.g.
https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ )

If you reject messages like that, then it's understandable you might
disagree on the relevance.
If you support the goal (of no-touch access), then it's still relevant in
as much as there's plenty of academic literature on how you design those
APIs (e.g.
https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html ),
but that's more of an implementation discussion.

> > I will say that using TLS (id-kp-serverAuth) certificates, from the
> intersection of CAs that are commonly trusted by operating systems and
> browsers, is bad. It will create security issues, will create
> interoperability issues, and will not help users.
>
>   I asked *what* security issues there were, and what interoperability
> issues existed when these certificates were used for EAP.  I stated that
> 15+ years of experience showed no issues.  Your response was:
>
> > This is empirically false. The use of certain CA’s certificates in
> wireless deployments has absolutely been a barrier to compliance and
> improvements.
>

I didn't see interpret your reply as you've summarized, but your follow-up
indicates that you disagree that it's a "security" issue if, for example, a
CA decides to not revoke certain certificates or to keep issuing certain
certificates, because that's seemingly seen as an interoperability issue.
Again, this is in the context of using the same set of CAs for EAP and for
TLS web server - I'm not speaking about other contexts here. In these
contexts, the security issue is for the TLS clients trusting certificates
from CAs that violate the policies. For example, continuing to issue SHA-1
certificates to support devices/clients that only trust SHA-1 certificates,
from the same hierarchy used for TLS. The interoperability issues are
indistinguishable from security issues in situations like this.

>    With pointers to papers that shows private key usage across disparate
> encryption methods.  These papers are entirely irrelevant to the use-case
> discussed here, i.e. these certs being used for EAP-TLS.
>

It looks like I should have spelled out a situation clearer:
- Consider that TLS 1.2 had interoperability issues with wpa_supplicant
versions and certain Cisco devices, due to confusion about the PRF
algorithm used
  - This led Apple, Google, and Microsoft to not enable TLS 1.2 for their
supplicants for quite some time, due to the ineroperability issues
  - These concerns were not applicable to the use of TLS web server
authentication, and such clients were able (and long had enabled) TLS 1.2
support
  - As a consequence, if the EAP-TLS and TLS web server shared the same
certificate, you can exercise some of those cross-protocol attacks
  - This similarly applies to TLS 1.2 (EAP) vs TLS 1.3 (web) deployments

This is an example of how certs being used for EAP-TLS, indistinguishable
from the Web hierarchy, leads to security issues. We may disagree on
categorization (e.g. "It's a deployment issue with a site, not an inherent
security issue"), but my objective is to try to prevent situations where
deployment issues result in security issues. Hence the recommendation to
make it *impossible* to reuse the same certificate across these different
consumers and use cases.

>   Suggesting that CAs will revoke all certificates mis-using
> id-kp-serverAuth *is* implying that enterprise WiFi will be disabled
> world-wide.  I explained in detail why I believe this correlation to be
> true.
>

Thanks. I think this conclusion is based on a misunderstanding. I have not
suggested CAs are going to know which certificates are used for EAP-TLS and
proactively revoke those. As you've correctly noted, and I've agreed, they
can't know. What I have suggested is that anyone, at any time, may be able
to notify the CA of potential misuse (according to the CA's definition),
thus requiring revocation. This creates an operational burden for those
deployments, and creates an incentive for the CA to ignore their stated
policies, which creates security issues for TLS clients (any CA ignoring
their policies is, fundamentally, indistinguishable from a security issue).

The way to mitigate that risk - of required revocation - involves clients
and servers make sure the certificates they accept are not subjected to
that.

> > Put simply: There's no "obtain a certificate from a public CA and it
> just works", where that certificate contains id-kp-serverAuth.
>
>   The only required step is for supplicants to explicitly enable that CA
> to be used for EAP.  As I said earlier, the root CAs are all enabled for
> the web, and none are enabled by default for EAP.
>

Yes, but I don't think that fits with the objectives of the original
message,
https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM and
the followups, such as
https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ

My observations have been that the means of achieving that goal are
problematic; that is, we _don't_ want to enable the extant root CAs for EAP
by default, with the described mechanism. My comments MUST be taken in
consideration as describing what that future world should look like and how
to get there.

  So I don't really care how OS vendors implement certificate checking for
> HTTPS.  It doesn't apply to EAP.  Bringing up irrelevant issues is just
> confusing and unhelpful.

Perhaps you missed replies like
https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ that
brought that up?

It sounds like much of our disagreement has just been on lacking the
context from the overall thread and discussion (with others), and thus
arriving at different conclusions based on that lack of context?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 8 Jan 2020 13:07:36 -0500

On Jan 8, 2020, at 11:29 AM, Ryan Sleevi <[email-masked]> wrote:
> On Wed, Jan 8, 2020 at 10:38 AM Alan DeKok <[email-masked]> wrote:
> They're related to the proposal that started this thread, which I'm trying to focus the discussion on, and which may be why we keep finding misalignment.

  I'm not sure how that happened, but whatever.

> Thanks. It seems like you meant process as "They won't sell it to me", and I meant process as "They can't sell it to me / Don't know how to sell it to me".

  I mean both.

> It's extremely relevant to the original proposal, at https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM, and to the subsequent follow-ups (e.g. https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ )
> 
> If you reject messages like that, then it's understandable you might disagree on the relevance.

  I don't see how it's relevant, because EAP just isn't implemented like that.  I've asked for explanations, and gotten unsatisfactory answers.

  I also don't see why you would construe my comments as "rejecting" those messages.  I've taken great pains to explain my position clearly, and in detail.

  I'm starting to wonder if this conversation can go anywhere.   Why are you putting negative motives on my behaviour?

> I didn't see interpret your reply as you've summarized, but your follow-up indicates that you disagree that it's a "security" issue if, for example, a CA decides to not revoke certain certificates or to keep issuing certain certificates, because that's seemingly seen as an interoperability issue. Again, this is in the context of using the same set of CAs for EAP and for TLS web server - I'm not speaking about other contexts here. In these contexts, the security issue is for the TLS clients trusting certificates from CAs that violate the policies. For example, continuing to issue SHA-1 certificates to support devices/clients that only trust SHA-1 certificates, from the same hierarchy used for TLS. The interoperability issues are indistinguishable from security issues in situations like this.

  It's a *procedural* issue, and a *policy* issue, IMHO.  There is no additional *security* issue.  Even your examples below aren't EAP specific.  They apply to any uses of TLS.

> - Consider that TLS 1.2 had interoperability issues with wpa_supplicant versions and certain Cisco devices, due to confusion about the PRF algorithm used
>   - This led Apple, Google, and Microsoft to not enable TLS 1.2 for their supplicants for quite some time, due to the ineroperability issues
>   - These concerns were not applicable to the use of TLS web server authentication, and such clients were able (and long had enabled) TLS 1.2 support
>   - As a consequence, if the EAP-TLS and TLS web server shared the same certificate, you can exercise some of those cross-protocol attacks

   The same attack applies to any application using TLS, including HTTP.  And most people are aware enough to *not* use the same certificate for multiple systems.  Which means that this attack is (a) not specific to EAP, and (b) only applicable in misconfigured systems.

  It helps to describe *precisely* what you're talking about.  I've been asking for many messages now exactly what you mean.  Until now, I've been getting the run-around.  That's unproductive.

> Yes, but I don't think that fits with the objectives of the original message,

  <sigh>  Please pay attention.

  That is the way things work NOW.  There should be no confusion about what OBJECTIVES I'm working towards, because I stated them clearly in the message you're replying to.

  Such replies are unproductive.

> It sounds like much of our disagreement has just been on lacking the context from the overall thread and discussion (with others), and thus arriving at different conclusions based on that lack of context? 

  And TBH, me asking for specific details, and getting answers which are only tangentially related to the question.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jan 2020 15:00:00 -0500

Alan DeKok <[email-masked]> wrote:
    alan> Many people use private CAs.  Many use public CAs.  *All* of them
    alan> use id-kp-serverAuth.  Common EAP supplicants (MS / Apple / etc.)
    alan> ship with known root CAs.  These root CAs are trusted by default
    alan> for web browsing.  None are trusted by default for EAP.

How can anyone be using public CAs for EAP, if none are trusted for EAP, and no
public CAs issue certificates with id-kp-serverAuth?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alan DeKok <[email-masked]>
Date: Wed, 8 Jan 2020 15:47:42 -0500

> public CAs issue certificates with id-kp-serverAuth?

  Every CA is manually enabled.

  Either by an end user, or by / on behalf of, an administrator.

  The goal I'd like to reach is some method to allow supplicants to automatically trust and enable certificates for EAP.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 15 Jan 2020 19:20:37 -0800

There has been a lot of discussion on this thread, but I do not see
anything actionable for the EAP-TLS 1.3 specification.

Joe

On Wed, Jan 8, 2020 at 12:48 PM Alan DeKok <[email-masked]>
wrote:

>   The goal I'd like to reach is some method to allow supplicants to
> automatically trust and enable certificates for EAP.
>
>   Alan DeKok.
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 15 Jan 2020 20:07:15 -0800

A couple things that stand out to me from having basically read the whole
thread in one go (this is not intended to be an exhaustive list of open
questions):

It was implied but not fully clear to me, that Ryan thinks that someone so
inclined could, right now, go around trying to connect to wifi using EAP
authentication, grab a packet capture of the remote server using its
id-kp-serverAuth certificate for authenticating the TLS-over-EAP
connection, and report that certificate to its issuing CA as "misuse"
requiring prompt revocation, at least for several major CAs.  It's quite
probably that I missed them as they went by, but specific links to specific
CA policy documents that would classify such certificate usage as "misuse"
(requiring revocation) would help clarify things, at least for me.

Is there anything better for implementations to actually do (as distinct
from what we write down as recommendations) than to start setting up a
parallel (purpose-specific) PKI now and trusting that in parallel with what
they're currently doing, with the hope of being able to have a flag day
many years down the line when the new PKI becomes the only thing that's
trusted?

-Ben

> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Jan 2020 15:56:37 -0500

> many years down the line when the new PKI becomes the only thing that's

  I don't think so.

  It's common practice to use private CAs.  Usually, self-signed ones.

  One major driver for private CAs was initially that EAP supplicant implementations did not cache the server certificate.  So if the supplicant trusted a root CA, it trusted *all* certificates issued by that root CA.  Which was a major security issue.

  Supplicants now cache the server certificate, even if they trust the root CA.  This lets them warn the user if the server certificate changes.

  But this process also means that the user is warned on normal certificate expiration / replacement.  There is currently no guidance to implementations as to what should be done here.

  Alan DeKok.

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Thu, 16 Jan 2020 21:02:01 +0000

On 8 Jan 2020, at 17:29, Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:

The CA must revoke if the certificate is misused; that's required by contract.
The CA defines what misuse means.
A number of CAs define misuse as "used for purposes other than TLS web server"
Ergo, obtaining and using certificates with EAP means these certificates are at risk of revocation.

Ok not for nothing but this is getting silly.  If a CA actually revoked a cert for someone using it for EAP, would they also have to revoke for someone using it for SMTP, XMPP, and IMAP?  Has that ever happened?

Eliot

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Jan 2020 17:52:29 -0500

On Jan 16, 2020, at 4:02 PM, Eliot Lear (elear) <[email-masked]> wrote:
> 
> Ok not for nothing but this is getting silly.

  Yes.

>  If a CA actually revoked a cert for someone using it for EAP, would they also have to revoke for someone using it for SMTP, XMPP, and IMAP?

  That is apparently the claim.

>  Has that ever happened?

  I have no idea.

  Perhaps we should try?

$ openssl s_client -connect smtp.mozilla.org:587 -starttls smtp > mozilla.crt
$ openssl x509 -text -in mozilla.crt

...
            X509v3 Subject Alternative Name:
                DNS:smtp1.mdc1.mozilla.com, DNS:smtp1.private.mdc1.mozilla.com, DNS:smtp1.private.mdc2.mozilla.com, DNS:smtp.mozilla.com, DNS:smtp.mozilla.org, DNS:smtp1.mdc2.mozilla.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
...

  Yup.  *Everyone* uses id-kp-serverAuth.  For *everything*.

  Should we report this mis-use?  If so, why?  If not, why not?

  At this point, it might be simplest to just update 2459:

...
    id-kp-serverAuth              OBJECT IDENTIFIER ::=   {id-kp 1}
   -- TLS Web server authentication
...

  new ID: delete the word "Web".

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 17 Jan 2020 14:53:23 +0000

> many years down the line when the new PKI becomes the only thing that's
This seems like a reasonable way forward to me.

--Mohit

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 17 Jan 2020 12:33:36 -0500

> (requiring revocation) would help clarify things, at least for me.

While I think people are missing the forest for the tree, here's an example
CP/CPS from a CA:
https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf

1.4.2 Prohibited certificate uses
> Any usage of a certificate other than the usage explicitly allowed in the
> CPS, is prohibited.
> 1.4.1 Appropriate certificate uses
> Certificates may be used in applications that satisfy at least the
> following conditions:
> • Manage properly the public and private keys,
> • Certificates and associated public keys are used in compliance with
> their declared
> purpose, confirmed by CERTSIGN,
> • Have built-in mechanisms of certificate status verification,
> certification path creation
> and validation control (signature availability, expiration date etc.),
> • Provides relevant information regarding certificates and their status
> for users.

It's already been flagged, for the CA to fix in their next CP/CPS update (
https://bugzilla.mozilla.org/show_bug.cgi?id=1403453 ), that they're
conflating requirements on Relying Party applications (i.e. those that
verify certificates) and Subscriber applications (i.e. those that serve
certificates). Does your RADIUS endpoint support and use OCSP stapling and
disable WiFi if the certificate is expired? No? Then it's a potential
violation of this CP/CPS.

Now, folks might be unhappy with that, thinking certSIGN isn't a "major"
CA. Here's DigiCert's CPS -
https://www.digicert.com/wp-content/uploads/2019/11/DigiCert_CPS_v420.pdf .
4.9.1 states that:

> DigiCert may revoke a certificate within 24 hours and will revoke a
> Certificate within 5 days if one or more of the following occurs:

...
> 3. The Subscriber or the cross-certified CA breached a material obligation
> under the CP, this CPS, or the relevant agreement;

DigiCert's Subscriber Agreement (the relevant agreement) is at
https://www.digicert.com/legal-repository/Subscriber-Agreement.pdf and, in
Section 2.2, makes reference to their Certificate Terms Of Use -
https://www.digicert.com/legal-repository/Certificate-Terms-of-Use.pdf

This Terms of Use has gems like (in Section 12)

>  Customer will use passwords that
> are randomly generated with at least 16 characters containing uppercase
> letters, lowercase letters, numbers, and symbols
> to transport Private Keys. Customer will only allow Customer’s employees,
> agents, and contractors to access or use Private
> Keys if the employee, agent, or contractor has undergone a background
> check by Customer (to the extent allowed by law)
> and has training or experience in PKI and other information security
> fields.

And in Section 16:

>   Customer will only use a TLS/SSL Certificate on the servers accessible
> at the domain names listed in the issued Certificate

Remind me how an EAP-TLS/RADIUS server is accessible at that domain name?
And if someone points their domain name to my server, would that require
revocation?

Or in Section 17:

> DigiCert may revoke a Certificate without notice for the reasons stated in
> the CPS, including if DigiCert reasonably believes
> that:
>
...

f. the Certificate was used without authorization, outside of its intended
> purpose or used to sign Suspect Code;
>

id-kp-serverAuth sure does seem to mean "WWW server", since RFC 5280 states:

>    id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
>    -- TLS WWW server authentication

This may seem pedantic and overbroad (OK, it definitely is), but that's the
entire meta-point here.

There's two parts of discussion from the thread:
1) What do extant clients do, today, in the verification of certificates
used in EAP-TLS
2) What should future clients do, 'tomorrow', to make this easier to use
and secure, ideally by default.

Much of the answer was around #2, which is "Don't try to glom on to
something existing, you need to build your own thing", as well as "Some of
the answers in #1 are problematic and you should try and discourage them"

In the hopes it makes it more accessible, imagine a situation where both
Ben and I need gears (widgets, sprockets, take your pick).
Ben needs gears that are 4cm in diameter and capable of being used in
temperatures from 0-20 degrees Celsius.
I need gears that are 4cm in diameter and capable of being used in
temperatures from 0-30 degrees Celsius.
We both get our gears from a single supplier: Cogswell's Cogs

Ben has a bunch of spare gears around for my equipment, and realizes he can
just use my gears in his equipment, and everything just works. Our
requirements are seen as compatible. That's convenient! However, when Ben
approaches Cogswell's Cogs, to sign a supply agreement, it's important that
the contract doesn't say "Ben will get 100 of whatever gears Ryan gets".
Instead, Ben should say "Ben will get 100 gears that are 4cm in diameter
and capable of being used in temperatures from 0-20 degrees Celsius": what
Ben actually requires.

That's because I may (read: will) change my gears to be 5cm in the future,
and be used in temperatures from 15-45 degrees Celsius, and those won't
work anymore for Ben. However, if Ben's contract says "I'll have what
Ryan's having", then that's what he's going to get, and sad times will be
had. I certainly won't have much sympathy for Ben, when Ben comes asking
that I change my equipment back to how it used to be, because Ben's needs
are different than my needs, and it's entirely Ben's fault for not
specifying his contract based on what he required, rather than what I was
getting.

Similarly, it'd be a bad idea to give instructions to say "Ryan's gears
work with Ben's equipment", especially when my specs can and will change.
They can even end up completely incompatible. For example, Ben might
require durable, long-lived gears, because Ben's equipment goes into hard
to reach places that are difficult to service, and thus that they may be
made of metal. My gears might be made of metal now, but that's expensive
for the machining and milling, and I may be planning to switch to plastic,
as part of ensuring they're mass-market affordable and easily replaceable.

To connect it back to the discussion: The discussion about revocation, and
what a CA's CP/CPS says is or isn't allowed for a usage, matters, because
browsers require CAs promptly revoke those certificates in 24 hours/5 days
for situations when they specify bad requirements. Can problematic CAs fix
their CP/CPS to allow this? Yes. But you've still got a host of other
expectations/requirements that can and will diverge, over time.

In the specific context of thinking about "#2" - what a touch-free future
looks like - having it use the same root store as Web browsers is the
anti-pattern, because the requirements are different. It's like Ben saying
"I want Ryan's gears", rather than thinking about "I need gears that are
4cm in diameter, capable of being used in temperatures from 0-20 degrees
Celsius, and durable enough to be used in hard to reach places" - and
finding someone who can and will manufacture those for you. You might end
up using Cogwell's Cogs, just like I do, and it might be that, for a time,
our gears are produced on the same production line - but your requirements
and my requirements aren't intertwined.

> many years down the line when the new PKI becomes the only thing that's

There's no doubt the status quo is "Everything is manually configured" and
"It's inconsistent what is validated". The goal is to get to #2, "It just
works"

- Define your requirements (the certificate profile)
- Define your policies (what do you expect CAs to verify, and how do they
verify)
- Provide a way to distinguish "new certificates" from "The old and manual
cruft" - for example, an explicit EKU
- Pick your poison.... er, CAs... for the new root store (e.g. as WiFi
Alliance has done, or Wireless Power Consortium has done, or plenty of
vendors have done)
- Have CAs issue certificates with both EKUs (old and new) in the leaf.
It's a SEQUENCE for a reason.
- Have supplicants configured that
   - If new EKU is present, look in built-in store
   - If old EKU is present, require manual configuration

This gets you half-way to #2: things can just work if you pick one of the
new-CAs with new-EKUs, and otherwise require manual configuration for
old-EKUs

At that point, supplicant vendors can slowly phase out support for 'old EKU'
- If the certificate is manually generated by the wifi server, it is 'easy'
to just generate certificates with the new EKU (potentially with *both* new
and old EKUs)
- If the certificate is coming from a "Web PKI" CA, it intentionally
'breaks' / makes this case difficult.

Similarly, RADIUS/EAP-TLS servers can require, when certificates are being
installed, that the 'new' EKU be present (potentially alongside the 'old'
EKU), and that the certificate conforms with the 'new' profile.

At some point, down the line, you can explicitly prohibit the new root
store from issuing with id-kp-serverAuth. Supplicants will all be looking
for/requiring the new EKU. Your RADIUS/EAP-TLS servers will all be
requiring the new EKU to be configured. But when, where, and how you cross
that rubicon is up to y'all, and that's the only flag day involved: when to
turn off the old.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jan 2020 13:29:37 -0500

> $ openssl x509 -text -in mozilla.crt

You omitted an important part of that output, which is the name of the CA,
which I include below.
It could be that the CSP permits SMTP, or SUBMISSION service.
Ryan has suggested that CAs could put EAP-TLS (or EAP-TEAP) into their CSP,
and that also seems like an out.

Certainly, some of the excitement for ACME/Letsencrypt with DNS-01 challenge
is that it makes it easy to get a certificate for a non-HTTP thing.

I think we need to fix the lawyers, not the protocol.

The detail:
        Issuer: C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA

       Subject: C = US, ST = California, L = Mountain View, O = Mozilla
       Corporation, OU = WebOps, CN = smtp.mozilla.org

But, let's do some more tests:
dooku-[/var/tmp](2.6.5) mcr 10051 %host letsencrypt.org
letsencrypt.org has address 162.243.166.170
letsencrypt.org has IPv6 address 2604:a880:400:d1::89c:7001
letsencrypt.org mail is handled by 5 alt2.aspmx.l.google.com.

dooku-[/var/tmp](2.6.5) mcr 10052 %echo QUIT | openssl s_client -connect
alt2.aspmx.l.google.com:25 -starttls smtp >| letsencrypt.crt

dooku-[/var/tmp](2.6.5) mcr 10053 %openssl x509 -text -in letsencrypt.crt|
grep Issuer
        Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1
                        CA Issuers - URI:http://pki.goog/gsr2/GTS1O1.crt

What do CA's do?

dooku-[/var/tmp](2.6.5) mcr 10054 %host digicert.com
digicert.com has address 45.60.121.229
digicert.com has address 45.60.131.229
digicert.com mail is handled by 20 us-smtp-inbound-2.mimecast.com.

dooku-[/var/tmp](2.6.5) mcr 10055 %echo QUIT | openssl s_client -connect
us-smtp-inbound-2.mimecast.com:25 -starttls smtp >| digicert-smtp.crt
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global
Root G2

dooku-[/var/tmp](2.6.5) mcr 10056 %openssl x509 -text -in digicert-smtp.crt|
grep Issuer
        Issuer: C = US, O = DigiCert Inc, CN = DigiCert Global CA G2
                        CA Issuers -
URI:http://cacerts.digicert.com/DigiCertGlobalCAG2.crt

What's that quote about doctor's fixing themselves?

---

From: Alan DeKok <[email-masked]>
Date: Fri, 17 Jan 2020 13:40:18 -0500

Sure.

  I agree.

> I think we need to fix the lawyers, not the protocol.

  That is likely the best approach.  At this point, use of id-kp-serverAuth is wide-spread *outside* of HTTP.  EAP / RADIUS is not unique in it's mis-use of that OID.

  As such, this discussion should more productively focussed on non-HTTP mis-uses of id-kp-serverAuth.  Which means pretty much everything using TLS.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 17 Jan 2020 14:39:17 -0500

On Jan 17, 2020, at 12:33 PM, Ryan Sleevi <[email-masked]> wrote:
>  Does your RADIUS endpoint support and use OCSP stapling and disable WiFi if the certificate is expired? No? Then it's a potential violation of this CP/CPS.

   I'm not sure how a RADIUS server will disable WiFi.  They are entirely separate systems.

> And in Section 16:
>   Customer will only use a TLS/SSL Certificate on the servers accessible at the domain names listed in the issued Certificate 
> 

  The RADIUS server has a domain name, which is commonly used in the certificate.

  If that is insufficient for the CAs purposes, then we should also acknowledge that the revocation requirement likely also applies to SMTP, XMPP, DNS over TLS, and IMAP.  i.e. *all* non-WWW protocols which use TLS.

 We should not single-out EAP / RADIUS as mis-using the certificates in this manner.  The mis-use of these certificates in other protocols is orders of magnitude larger than the EAP / RADIUS problem.

> 1) What do extant clients do, today, in the verification of certificates used in EAP-TLS

  EAP supplicants follow RFC 5216 Section 5.3.

> 2) What should future clients do, 'tomorrow', to make this easier to use and secure, ideally by default.
> Much of the answer was around #2, which is "Don't try to glom on to something existing, you need to build your own thing",

  True.

> as well as "Some of the answers in #1 are problematic and you should try and discourage them"

  There were *allegations* of problems.

> To connect it back to the discussion: The discussion about revocation, and what a CA's CP/CPS says is or isn't allowed for a usage, matters, because browsers require CAs promptly revoke those certificates in 24 hours/5 days for situations when they specify bad requirements. Can problematic CAs fix their CP/CPS to allow this? Yes. But you've still got a host of other expectations/requirements that can and will diverge, over time.

  If I was mean, I would write scripts to troll the net for mis-use of certificates in SMTP, XMPP, IMAP, VPNs, etc.  Then, make the script auto-submit notices to the relevant CAs.  That process is simple to do, and by the above rules, would require the CAs to revoke the relevant certs.

  i.e. certs which affect a high percentage of daily internet traffic.

  If that scenario were to play out, I suspect that CAs would very quickly stop revoking the relevant certs.  A straight-forward approach to enforcing the rules would be over-ruled by simple practicalities:  Turning off big chunks of the Internet is a non-starter.

  As Michael Richardson pointed out, then solution here is likely to fix the rules, not the protocols.

> In the specific context of thinking about "#2" - what a touch-free future looks like - having it use the same root store as Web browsers is the anti-pattern, because the requirements are different.

  And therefore we need a different root store for *each* of EAP, RADIUS, SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc.  Note that we need *different* stores for EAP and RADIUS, because RADIUS server are reachable on port 2083 as RADIUS over TLS, *and* they implement TLS over EAP, which in turn carried over RADIUS.  Different use-cases, different root stores.

  There may be significant push-back against that many root stores.

> There's no doubt the status quo is "Everything is manually configured" and "It's inconsistent what is validated". The goal is to get to #2, "It just works"
> 
> - Define your policies (what do you expect CAs to verify, and how do they verify)
> - Provide a way to distinguish "new certificates" from "The old and manual cruft" - for example, an explicit EKU
> - Pick your poison.... er, CAs... for the new root store (e.g. as WiFi Alliance has done, or Wireless Power Consortium has done, or plenty of vendors have done)
> - Have CAs issue certificates with both EKUs (old and new) in the leaf. It's a SEQUENCE for a reason.
> This gets you half-way to #2: things can just work if you pick one of the new-CAs with new-EKUs, and otherwise require manual configuration for old-EKUs

  That's good, but insufficient.  There is a lot more verification that EAP supplicants need to do before automatically trusting a root CA.

  I suspect that most CAs already know that their customers mis-use certs for non-WWW purposes.  EAP / RADIUS is just a minor (almost insignificant) part of this problem.  I also suspect most CAs operate based on the hope that no one notices, and then requires them to revoke many, many, certificates.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jan 2020 17:30:30 -0500

Ryan Sleevi <[email-masked]> wrote:
    > While I think people are missing the forest for the tree, here's an
    > example CP/CPS from a CA:

certsign.ro uses a Fortinet.com certificate on their SMTP server.
Does Fortinet.com's CSP permit SMTP usage?
The certificate does not have the serverAuth bit set.

    > Customer will only use a TLS/SSL Certificate on the servers
    > accessible at the domain names listed in the issued Certificate

    > Remind me how an EAP-TLS/RADIUS server is accessible at that domain
    > name? And if someone points their domain name to my server, would that
    > require revocation?

"accessible" is not defined.  maybe CAFORUM needs to write port 443 from now on?
If you were part of eduroam, and you uses [email-masked] as your
identity, then the roaming mechanism would connect eventually to your Radius
server using that name.  Thus, it is accessible.

Your gear analogy is understood, but for many of us, we see the specs as
having been designed by lawyers rather than engineers in order to maximize
profit and minimize interoperability.  I'm not arguing we are right.
It just feels like needless and wastefully restrictive attempts to create market verticals.

    > In the specific context of thinking about "#2" - what a touch-free
    > future looks like - having it use the same root store as Web browsers
    > is the anti-pattern, because the requirements are different.

And yet, almost every single thing out there would like to be connected to by a browser.
They can't, so we have an app-per-thing, and/or no-security.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Sat, 18 Jan 2020 05:34:43 +0000

If the PKI community as a whole (vendors, standards bodies, consortia, CAs) has managed to engineer a situation where, according to the strict letter of the law, CAs would have no choice but to revoke operators identity certificates for many of their services if Alan was actually mean and wrote his script, which would cause widespread outages, then, quoting Charles Dickens, "the law is a ass", and I'm with Alan and Richard and the law (the CP/CPS) should probably change.

> From: Spasm <[email-masked]> On Behalf Of Alan DeKok
> Sent: 17 January 2020 19:39
> To: Ryan Sleevi <[email-masked]>
> Cc: [email-masked]; Michael Richardson <[email-masked]>; Joseph
> Salowey <[email-masked]>; Benjamin Kaduk <[email-masked]>; EMU WG
> <[email-masked]>
> Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation
> logic
> 
> 
> >  Does your RADIUS endpoint support and use OCSP stapling and disable WiFi if
> the certificate is expired? No? Then it's a potential violation of this CP/CPS.
> 
> >   Customer will only use a TLS/SSL Certificate on the servers accessible at the
> domain names listed in the issued Certificate
> >
>   If that is insufficient for the CAs purposes, then we should also acknowledge
> that the revocation requirement likely also applies to SMTP, XMPP, DNS over
> TLS, and IMAP.  i.e. *all* non-WWW protocols which use TLS.
> 
>  We should not single-out EAP / RADIUS as mis-using the certificates in this
> manner.  The mis-use of these certificates in other protocols is orders of
> magnitude larger than the EAP / RADIUS problem.
> 
> something existing, you need to build your own thing",
> 
>   True.
> 
> browsers require CAs promptly revoke those certificates in 24 hours/5 days for
> situations when they specify bad requirements. Can problematic CAs fix their
> CP/CPS to allow this? Yes. But you've still got a host of other
>   If I was mean, I would write scripts to troll the net for mis-use of certificates in
> SMTP, XMPP, IMAP, VPNs, etc.  Then, make the script auto-submit notices to the
> relevant CAs.  That process is simple to do, and by the above rules, would
> require the CAs to revoke the relevant certs.
> 
>   If that scenario were to play out, I suspect that CAs would very quickly stop
> revoking the relevant certs.  A straight-forward approach to enforcing the rules
> would be over-ruled by simple practicalities:  Turning off big chunks of the
> Internet is a non-starter.
> 
> > In the specific context of thinking about "#2" - what a touch-free future looks
> like - having it use the same root store as Web browsers is the anti-pattern,
> because the requirements are different.
> 
>   And therefore we need a different root store for *each* of EAP, RADIUS,
> SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc.  Note that we need *different*
> stores for EAP and RADIUS, because RADIUS server are reachable on port 2083
> as RADIUS over TLS, *and* they implement TLS over EAP, which in turn carried
> over RADIUS.  Different use-cases, different root stores.
> 
> > There's no doubt the status quo is "Everything is manually configured" and "It's
> inconsistent what is validated". The goal is to get to #2, "It just works"
> >
> > - Pick your poison.... er, CAs... for the new root store (e.g. as WiFi Alliance has
> done, or Wireless Power Consortium has done, or plenty of vendors have done)
> > This gets you half-way to #2: things can just work if you pick one of the new-
> CAs with new-EKUs, and otherwise require manual configuration for old-EKUs
> 
>   That's good, but insufficient.  There is a lot more verification that EAP
> supplicants need to do before automatically trusting a root CA.
> 
>   I suspect that most CAs already know that their customers mis-use certs for
> non-WWW purposes.  EAP / RADIUS is just a minor (almost insignificant) part of
> this problem.  I also suspect most CAs operate based on the hope that no one
> notices, and then requires them to revoke many, many, certificates.
> 
>   Alan DeKok.
>

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 18 Jan 2020 02:20:52 -0500

Or... just stop using those certs/roots already? We’ve already identified
that there is absolutely zero reason to do so in the extant status quo,
because it still requires manual configuration. You get no benefits and
clearly downsides, so just... don’t do that? Any complaints about how that
existing PKI is managed is just a complaint that it doesn’t fit your
purposes and doesn’t do what you want, which is fine: that’s the entire
point.

If you don’t like CAs being required to do what they say, and be held
accountable to stated policies, then sure, let them issue whatever they
want and decide unilaterally what the risks are. Of course, then you’ll end
up with situations like CAs issuing certificates with duplicate serial
numbers, with one of the duplicates being a CA certificate used for active
MITM of user connections, and the issuing CA complaining that revoking
would be disruptive for those other holders with the same serial number.
Which is a real thing that happened, and indistinguishable from a policy
perspective to Alan’s example. Or you can deal with the commiserate legal
risks involved in selectively enforcing when you agree or disagree with the
CA’s risk assessment and what is “reasonable”, with the CA who issues
certificates used for MITM lamenting it’s “unfair” and “inconsistent” that
they aren’t allowed to declare there is no risk for those certificates,
while other CAs get to declare there’s no risk for EAP-TLS, despite their
policies stating they don’t allow it.

If you don’t want to deal with those problems, which are messy and complex,
then yes, manually configure your certs, and don’t manually configure ones
that expose you to all of this. Problem solved, and no need for Dickens.

I can appreciate that, if you’re not involved with managing a PKI or trust
store, it would seem undesirable to actually enforce standards and
contracts and policies as they were written, especially when inconvenient.
Yet documents like RFC 3647 exist precisely because the world is not a
technocratic utopia, trust is a hard problem, and it exists in a world
where there are messy and complex legal problems. If you want to use want
to use PKI, and you want to do more than just require explicit manual
configuration, then you have to deal with all of that and more. You can
pretend it doesn’t exist, but you can’t escape that reality. DigiNotar is
an example, but one of dozens at this point. Manual configuration lets you
localize that to things you control, and so that’s an eminently reasonable
status quo.

On Sat, Jan 18, 2020 at 12:34 AM Owen Friel (ofriel) <[email-masked]>
wrote:

> If the PKI community as a whole (vendors, standards bodies, consortia,
> CAs) has managed to engineer a situation where, according to the strict
> letter of the law, CAs would have no choice but to revoke operators
> identity certificates for many of their services if Alan was actually mean
> and wrote his script, which would cause widespread outages, then, quoting
> Charles Dickens, "the law is a ass", and I'm with Alan and Richard and the
> law (the CP/CPS) should probably change.
>
> >    I'm not sure how a RADIUS server will disable WiFi.  They are
> entirely separate
> > systems.
> >
> > > And in Section 16:
> accessible at the
> name?
> > > 1) What do extant clients do, today, in the verification of
> certificates used in
> > EAP-TLS
> >
> > > 2) What should future clients do, 'tomorrow', to make this easier to
> use and
> > secure, ideally by default.
> > > as well as "Some of the answers in #1 are problematic and you should
> try and
> > discourage them"
> >
> >   As Michael Richardson pointed out, then solution here is likely to fix
> the rules,
> > not the protocols.
> >
> future looks
> Alliance has
> > > - Have CAs issue certificates with both EKUs (old and new) in the
> leaf. It's a
> > SEQUENCE for a reason.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Jan 2020 08:05:09 -0500

On Jan 18, 2020, at 2:20 AM, Ryan Sleevi <[email-masked]> wrote:
> 
> Or... just stop using those certs/roots already? We’ve already identified that there is absolutely zero reason to do so in the extant status quo, because it still requires manual configuration.

  ... for EAP.  And only for EAP.

  That comment doesn't apply to SMTP, XMPP, IMAP, DNS over TLS, VPNs, RADIUS over TLS, etc..  SMTP servers mis-use "WWW" certificates precisely *because* it requires zero client configuration.  It leverages an existing trust store to increase security.  And that's a good thing.

  As noted by Michael, CAs are using certificates in a way that violates their own policy.  The mis-use problem is therefore larger, and worse, than the minor issue of EAP *sometimes* using WWW certs.

  My previous messages explained that the common practice for EAP is to use private CAs.  For the reasons you outlined above, and more.  Pretty much everyone in the EAP community was convinced of this 15+ years ago.  It has been standard / recommended practices for 15+ years.

  Finally, there are reasons to use public CAs for EAP.  I have customers who do this today, for internal corporate policy reasons.  I've recommended that they don't do it, but their internal "security" team over-rules me.

  The rest of your comments are trying to convince people of things that they're already convinced of.  We already know this, we already agree (mostly).

  The disagreement is this: your underlying assumption is that these are the rules, and they have to be followed.  I believe that this is the IETF, and that we make the rules.  If we need to change the rules, then we just do so.  And the Internet community has to follow.

  There are details as to which rules apply where, and to who.  But as the IETF, we are entirely within our purview to allow the use of id-kp-serverAuth in EAP, SMTP, etc..  Or, to come up with a new scheme that replaces id-kp-serverAuth.

  If the rules have to be applied strictly, then you have been made aware that the CAs you pointed to are violating their own policies.  Therefore, you are under a moral obligation to report this mis-use to them.  Failure to do so is a tacit admission that you are not applying the rules in practice.  While at the same time, claiming that the rules have to be stringently followed.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 18 Jan 2020 08:55:32 -0500

On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok <[email-masked]>
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, and I suspect folks still haven’t actually read
the CP/CPSes or done the work.

As I explain again, later on, this is fixating on a branch on a tree and
ignoring the forest in which it is in. I provided the example to illustrate
the broader problem, but apparently I picked too distracting an example.

>
>   Finally, there are reasons to use public CAs for EAP.  I have customers
> who do this today, for internal corporate policy reasons.  I've recommended
> that they don't do it, but their internal "security" team over-rules me.

Right. These people are wrong and their reasons bas :)

For example, a certain CA, no longer in business, vociferously opposed the
deployment of Certificate Transparency and the forbidding of issuance to
non-qualified domain names (e.g. “mail” and “intranet” and the like). More
than half of their business selling their premium ($2000+/cert) EV
certificates was selling them to enterprises they had convinced required EV
certificates, and they were opposed to anything that would disrupt or
diminish that practice. Yet it’s obviously laughable to believe someone
validated unique control, via DNS on the public internet, of the name
“mail” - effectively a TLD.

I mention this anecdote because I’m quite familiar with corporate security
teams requiring things, “for reasons” (typically, an effective
sales/marketing team), but that doesn’t make it any more correct. This is
where supplicants and servers refusing such certificates is not
unreasonable as a means of signaling technically that which is
operationally true.

  The rest of your comments are trying to convince people of things that
> they're already convinced of.  We already know this, we already agree
> (mostly).
>
>   The disagreement is this: your underlying assumption is that these are
> the rules, and they have to be followed.  I believe that this is the IETF,
> and that we make the rules.  If we need to change the rules, then we just
> do so.  And the Internet community has to follow.

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

Nothing you say or do has any impact without implementor, and if you go
against the grain of where implementors are going or already at, they are
useless standards that will be ignored.

It would similarly be a mistake to think “Ah, but I control an SMTP server,
I am thus an implementor and empowered”. You are indeed an implementor...
for your root store. And if existing contracts and requirements prevent a
CA from serving your needs from the same hierarchy they are serving other
root store needs, which they increasingly will, then again, there’s no real
power unless you define your own root store.

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.

Put differently: This is as explicitly an area of policy, not technology.
As tempting as it may seem to focus on individual problems and say “Ah, but
those could be addressed by technology and more standards,” without
appreciating the broader and big picture, which is inherently policy, the
work on the technology is doomed.

  There are details as to which rules apply where, and to who.  But as the
> IETF, we are entirely within our purview to allow the use of
> id-kp-serverAuth in EAP, SMTP, etc..  Or, to come up with a new scheme that
> replaces id-kp-serverAuth.

Yes, and the latter is more relevant than the former.

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.

We don’t expect IETF to be the One Standards Org for everything, such a
railway gauge tolerances and fire resistant building material codes and
maximum reflectivity of space equipment. Those are both beyond our ken and
our focus. The same is true for PKI: there does not need to be one set of
Policy to Rule Them All, and it’s ok to have many policies, each written by
different constituents to reflect their needs.

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.

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 18 Jan 2020 09:15:00 -0500

On Jan 18, 2020, at 8:55 AM, Ryan Sleevi <[email-masked]> wrote:
> 
> No. The root store operators make the rules. Standards that align with their needs are the standards they use and apply.
> 
> Nothing you say or do has any impact without implementor, and if you go against the grain of where implementors are going or already at, they are useless standards that will be ignored.
> 
> It would similarly be a mistake to think “Ah, but I control an SMTP server, I am thus an implementor and empowered”. You are indeed an implementor... for your root store. And if existing contracts and requirements prevent a CA from serving your needs from the same hierarchy they are serving other root store needs, which they increasingly will, then again, there’s no real power unless you define your own root store.
> 
> 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.
> 
> Put differently: This is as explicitly an area of policy, not technology. As tempting as it may seem to focus on individual problems and say “Ah, but those could be addressed by technology and more standards,” without appreciating the broader and big picture, which is inherently policy, the work on the technology is doomed.

I don’t “have a dog in this fight”, being retired for several years now.  However, I’ve been following this thread out of interest.  I’ve long held that the problems with deployment and interoperability of PKI are in the business domain, not the technical domain.  It’s interesting, and perhaps a bit disappointing, to see that it still the case.  And now, back to your regular programming…

Regards,

Dave Nelson

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Jan 2020 14:21:53 +0000

Hiya,

> power unless you define your own root store.

I have to say that comes across as fairly arrogant. I guess
that's by the by, but it makes me happy that I don't need
to play in the CAB forum space:-) [I'm sure it wasn't meant
to be arrogant, and it has been a long thread which can
lead to irritability, but that's how it struck me.]

I've no real axe to grind here (definitely not wrt EAP),
but, as a private key holder I do use web PKI CAs for
email servers as well as for web servers. Turning that
off would disimprove security for the Internet without
(IMO) any real justification as to it producing a real
improvement in the web PKI. (I do control the domains.)
I don't buy that mentions of diginotar or equivalent
misissuance problems are really relevant myself.

That, and I've always considered CP/CPS as legal window
dressing, initially for the benefit of CAs but judging
from the above, now apparently mostly for the benefit of
web PKI root store maintainers (aka browsers).

So yeah, count me amongst those who'd suggest fixing the
policy to match what's better for the Internet is the
right approach, even if it's not an approach that might
get traction in CAB forum.

S.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Jan 2020 09:43:08 -0500

On Jan 18, 2020, at 8:55 AM, Ryan Sleevi <[email-masked]> wrote:
> On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok <[email-masked]> 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,…

  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.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 18 Jan 2020 10:14:41 -0500

> lead to irritability, but that's how it struck me.]

It certainly was not meant that way.

It is the essence of “rough consensus and running code”. Standards that
describe idealized states, that don’t reflect reality, are standards that
aren’t valuable. Similarly, when we talk standards that do things like
deprecate insecure crypto or older protocol versions, we know there isn’t
an IETF Enforcement Bureau that makes sure all of the “-diediedie” drafts
are observed and implemented In a timely fashion. That’s what makes jokes
like RFC 6919 so endearing and funny, because we know that it better
reflects our unfortunate realities than 2119.

> misissuance problems are really relevant myself.

They are relevant in that they require they all be treated the same, for
legal, policy, and other non-technical reasons, even when it’s
understandably undesirable.

I don’t disagree that there’s ample need for robust TLS issuance, and I
agree that there’s ample ill-definition about what “WWW authentication”
means and contains. Some CPSes are more explicit, some less, about what
they allow. Supposedly, every time you’re getting a cert, you’re carefully
reviewing all of these agreements as part of your selection of which CA to
use ;)

> web PKI root store maintainers (aka browsers).

I mean, this is why RFC 3647 exists. It exists for CAs to shift liability
to Relying Parties (“We told you we do this stupid thing, right here”), and
for Root Stores to shift liability to CAs (“You told us you would do this,
right here”). CAs like to use it to further try to defend against any risk
of distrust (“We told you we would do a stupid thing, and you trusted us
anyway, so you can’t distrust us for doing a stupid thing”)

There are CPSes that don’t include problematic clauses regarding EKUs, for
sure, or which explicitly state how it’s interpreted in their PKI. That
particular example is not meant to be a “universal example” of something
forbidden, but to highlight how even if one relying party would like to
ignore the CPS, when there are multiple constituencies, that doesn’t work.
The only way you sort through those is to make sure the only two parties
are you and the CA - aka defining a root store.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Jan 2020 15:28:43 +0000

Hiya,

> are you and the CA - aka defining a root store.

I disagree. PKI inherently has 3 parties involved. Ignoring
any one or two of them is what I think leads to the kind of
silliness that results in us even mentioning possible mass
revocation because of an ill-defined OID. Heartbleed might
just about have justified that, this very much does not.

I do fully agree with you that the idea that end entities
ever read a CP/CPS is about as realistic as "click yes to
accept cookies" or other similar things being meaningful.
Sadly, such legal nonsense does seem to be required but we
ought not let it drive what we do - in this case, IMO the
blindingly obviously correct thing to do is to recognise
the reality of the use of the OID and regularise that.

But if that's not going to happen, then the 2nd best (and
99.999% just as good) thing to do is to happily continue to
ignore the supposed problem.

Cheers,
S.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 18 Jan 2020 11:10:13 -0500

> the mark rather substantially,

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.

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

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Jan 2020 14:23:40 -0500

On Jan 18, 2020, at 11:10 AM, Ryan Sleevi <[email-masked]> 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.

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 18 Jan 2020 19:56:47 +0000

> There’s no set of entities blessed in some special power which only they can mint certificates

Thank you for injecting some much-needed humor into this thread.  That's the funniest f---ing thing I've read from you in a long time.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 18 Jan 2020 16:11:11 -0500

On Sat, Jan 18, 2020 at 2:23 PM Alan DeKok <[email-masked]>
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.?
> >

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”

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

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Jan 2020 17:58:02 -0500

On Jan 18, 2020, at 4:11 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> 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.

  I'm trying to solve the problem of bootstrapping.  I agree that various CAs have various rules.  I agree that anyone can run their own private CA, and do whatever they want.  I've been doing that, and recommending it, for ~20 years.

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

  Where you say "TLS CA", you mean "WWW CA".  All these other applications use TLS, too.

  In practice, that WWW CA design translates into "CAs which are included with OS distributions".  Which means "CA trivially usable by applications".  ALL applications.  Not just the browser.

  Is it any surprise that *all* applications ended up leveraging that functionality?

  When the CA *isn't* included with the OS distribution, it means that CA *cannot* be used to bootstrap TLS-enabled applications.  Each application (not just EAP) MUST be manually configured with the CA.

  The alternative is to ask the application to naively trust a CA it doesn't know, and a CA which isn't included with the OS distribution.  I don't think that will happen.

  It's easy for a browser vendor to tell a CA "issue certs our customers can use".  It's much, much, harder for anyone else to do the same thing.

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

  It's less of an objection than a statement that we're back to the initial conclusion: use a private CA, manually configure, and ignore the root CAs shipped with the OS distribution.

  How does that help with the bootstrapping problem?

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

  I'm happy to use a new PKI.  But we *cannot* and *must not* rely on every application to "do it yourself".  There must be a trust anchor shipped with OS distributions, that applications can leverage.

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

  Sure.  So how does *my* application get Microsoft, Apple, etc. to ship a new PKI?

  Answer: even Microsoft and Apple can't do it for their own applications.  They just leverage the pre-existing WWW PKI.

  If trillion dollar companies can't deploy a new PKI for their own applications, it's entirely unreasonable to ask that of a minor cog like me.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 18 Jan 2020 18:30:10 -0500

On Sat, Jan 18, 2020 at 5:58 PM Alan DeKok <[email-masked]>
wrote:

>   I'm trying to solve the problem of bootstrapping.  I agree that various
> CAs have various rules.  I agree that anyone can run their own private CA,
> and do whatever they want.  I've been doing that, and recommending it, for
> ~20 years.

Great. Let’s focus on one problem at a time to make sure it’s easier to
follow along. Earlier in the thread you seemed fixated on the first
problem, so it’s unclear when/where/how shifted to the second.

  When the CA *isn't* included with the OS distribution, it means that CA
> *cannot* be used to bootstrap TLS-enabled applications.  Each application
> (not just EAP) MUST be manually configured with the CA.

This isn’t true, if you mean that the end user needs to manually configure.
Modern OSes allow the application vendor - such as the supplicant vendor -
to explicitly configure.

  The alternative is to ask the application to naively trust a CA it
> doesn't know, and a CA which isn't included with the OS distribution.  I
> don't think that will happen.

The alternative is the application ships it’s own root store. Which
applications have been doing for 20+ years and which modern OSes make even
easier.

  It's easy for a browser vendor to tell a CA "issue certs our customers
> can use".  It's much, much, harder for anyone else to do the same thing.

Not really? CAs are plenty happy to sell whatever folks want. Look at stuff
like the drone PKI being developed.

What other application developers can’t do - and this is intentional - is
to get their certs and profiles for the same roots, even if they’re the
same issuing organization.

  It's less of an objection than a statement that we're back to the initial
> conclusion: use a private CA, manually configure, and ignore the root CAs
> shipped with the OS distribution.
>

I already gave that answer several times. Define your profile and policies,
pick (different) roots, and ship them in your software. It’s mistaken to
suggest that you HAVE to use the same roots as the OS.

  I'm happy to use a new PKI.  But we *cannot* and *must not* rely on every
> application to "do it yourself".  There must be a trust anchor shipped with
> OS distributions, that applications can leverage.

No, there doesn’t. That’s an unreasonable demand, because it’s insisting
that advocates of the problem don’t want to actually do the work involved
in developing a solution for the problem. There’s absolutely no reason to
require that it be shipped as part of the OS. Plenty of PKIs exist without
requiring that, and modern OSes make it easier.

Now, it may be that OSes do this, in the future, but that only happens by
first building the profile and policies. Because that’s all an OS root
store is: a set of CAs known to meet particular profiles and policies.
Anyone can define that.

>   Sure.  So how does *my* application get Microsoft, Apple, etc. to ship a

Provide a problem statement and a solution that’s compelling enough for
them to use? Fixating on the “new PKI” or “must be shipped in the OS” is
completely unreasonable expectation, especially when even the _existing_
PKI doesn’t solve the bootstrap problem unless you convince the OS. There’s
zero advantages to using extant PKI, and ample downside, and you can move
quicker and ship things by just doing the work.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 19 Jan 2020 10:07:31 -0500

On Jan 18, 2020, at 6:30 PM, Ryan Sleevi <[email-masked]> wrote:
> Great. Let’s focus on one problem at a time to make sure it’s easier to follow along. Earlier in the thread you seemed fixated on the first problem, so it’s unclear when/where/how shifted to the second.

  Perhaps less "fixated" than "trying to achieve a common understanding.

  It's best to understand the current situation before designing any solution.

> The alternative is the application ships it’s own root store. Which applications have been doing for 20+ years and which modern OSes make even easier.

  The question here is *what* root store?  It's easy for browsers to ship root stores.  The WWW root stores are well known. 

  What root store is already widely known, and trusted for EAP?

> Not really? CAs are plenty happy to sell whatever folks want. Look at stuff like the drone PKI being developed.

  CAs are in *theory* happy to sell things.  In practice, it's difficult to get non-WWW certificates.

> I already gave that answer several times. Define your profile and policies, pick (different) roots, and ship them in your software. It’s mistaken to suggest that you HAVE to use the same roots as the OS.

  I think you're operating from a WWW perspective.  That use-case is very different from EAP.  In WWW, 99% of the TLS-enabled traffic is from the server to the client.  The client doesn't know what the information is, and doesn't really care.  Even secret information like passwords sent to a web server are generated by / on that web server.  So a client can verify (a) the password was created for a proven server using a trusted CA, and next time (b) prove it's the same server, so it's OK to send over the password.

  EAP is completely different.  I have *my* password.  It's secret, and I made it.  I want to be sure that I give it *only* to the site which is authorized.  This means that I don't really care that a root CA is trusted.  That root CA might sign certificates for 1000 companies.  I want to have my password only to one company; the correct one.  I want the client supplicant to *not* hand my password to the other ones.  I have no DNS to leverage, either.

  To put it another way, in WWW, the server has data that the client wants.  In EAP, the client has data (passwords) that the server wants.  The trust models are very different.

  The goal then is to get to the point where a supplicant can verify that the server cert is signed by a trusted CA, *and* that it's the server cert that the client wants.

  Shipping a trusted root CA on the supplicant OS is the *only* way to do this.

> No, there doesn’t. That’s an unreasonable demand, because it’s insisting that advocates of the problem don’t want to actually do the work involved in developing a solution for the problem. There’s absolutely no reason to require that it be shipped as part of the OS. Plenty of PKIs exist without requiring that, and modern OSes make it easier.

  See above.

  This isn't just "ship a root CA with an EAP / RADIUS server".  That's a trivial problem to solve.  If you want to use a RADIUS server, it may be OK to trust the CAs included with that product.  The same goes for browsers.

  But what are the poor end users going to do with their EAP supplicants?  Pretty much *zero* of them have ever downloaded a supplicant "application".  So that route is completely off of the table.

  Instead the supplicant is shipped with the OS. Therefore, any root CAs needed by the supplicant MUST be included with the OS.

  It really is that simple.

  In conclusion, we need a new PKI, and the root CAs must be included with OS distributions.  But the OS vendors won't do that until we define the requirements, solution, and transition path.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 19 Jan 2020 10:54:35 -0500

I think we’re in more agreement than disagreement here, but I think part of
your analysis missed the mark.

On Sun, Jan 19, 2020 at 10:07 AM Alan DeKok <[email-masked]>
wrote:

>   The question here is *what* root store?  It's easy for browsers to ship
> root stores.  The WWW root stores are well known.
>

There isn’t one today, which is exactly why you have no need to use
anything existing.

You define your certificate profile.
You define your certificate policies - what information they validate and
how they validate.

The root store is the result of defining those two, and then allowing CAs
interested in that set to apply and be evaluated against that. There’s
nothing extant, as we’ve agreed multiple times, because everyone manually
configures.

There’s zero need to use any existing CAs. If the concern is “Our root
store is initially empty”, well then yes, it matches the status quo today:
there is no root store. Rome wasn’t built in a day, and figuring out who
should be in that store takes time. There’s no doubt a dozen CAs that would
happily issue, if they knew what the expected profile and policies were,
and would stand up dedicated roots.

Of course, the CAs are only going to do that if there are users: those who
will buy or rely on those certificates. So you need to convince supplicants
that a zero-touch world is worth it, AND that it can be as secure as manual
configuration.

Supplicant vendors - whether they are open-source or operating system - are
taking on the work to manage and police that root store. To ensure that the
CAs included follow the profiles, policies, and practices. So you have to
convince them that it’s worthwhile for their users.

If this sounds like a lot of work: Yes. It is. Yet organizations like the
WiFi Alliance or the Wireless Power Consortium or the USB-IF have all
managed to do so, to varying degrees of success.

  I think you're operating from a WWW perspective.  That use-case is very
> different from EAP.  In WWW, 99% of the TLS-enabled traffic is from the
> server to the client.  The client doesn't know what the information is, and
> doesn't really care.  Even secret information like passwords sent to a web
> server are generated by / on that web server.  So a client can verify (a)
> the password was created for a proven server using a trusted CA, and next
> time (b) prove it's the same server, so it's OK to send over the password.
>
>   EAP is completely different.  I have *my* password.  It's secret, and I
> made it.  I want to be sure that I give it *only* to the site which is
> authorized.  This means that I don't really care that a root CA is
> trusted.  That root CA might sign certificates for 1000 companies.  I want
> to have my password only to one company; the correct one.  I want the
> client supplicant to *not* hand my password to the other ones.  I have no
> DNS to leverage, either.
>
>   To put it another way, in WWW, the server has data that the client
> wants.  In EAP, the client has data (passwords) that the server wants.  The
> trust models are very different.

They are not at all different. In both cases, the client has a principal it
wants to validate: in RFC 6125, this is the reference name. This is the
name in your credential in the case of EAP, the name of the host in the URL
in WWW. The client wants to make sure it’s talking to the entity authorized
for that name.

You can manually preconfigured exactly that entity. In EAP, this is
incredibly easy to do when you’re provisioning the client credential to
also provision the peer identity. This is the existing flow.

The long-term goal seems to be to want to indirect that, so that explicitly
provisioning credentials is not necessary. In that model, you need a
third-party, the CA, to vet and validate the identity, so your EAP server
can attest it. Rather than having to rely on a preconfigured identity, you
want to make sure the reference name matches the names presented in the
certificate.

The trust model is _identical_ to WWW, as you describe it.

If the argument is that the only information that needs validation is a DNS
name, and that it’s profile is similar to, or could be identical to, TLS,
then you still have the burden of demonstrating the operational
considerations are the same before you make the case to reuse the existing.
For example, the payment terminal example I mentioned used the same
policies and profiles, but the operational consideration was these devices
are not field upgradable and only support certificates from a limited
number of CAs. The lack of updates and the lack of agility were an
insurmountable gulf of difference from the constraints of operating systems
(patches) and browsers (regular updates), and so these devices need
separate PKIs, which ANSI X-9 is happy to oblige:
https://x9.org/asc-x9-launches-new-security-study-groups-on-public-key-infrastructure-pki-and-transport-layer-security-tls/

If this future world is a world where the provisioning of certificates is
only done via ACME, and manual configuration is “unsupported” (even if
technically capable, it’s in the “may break you at any time if you decide
to do this” level of support), and your profiles are explicitly short-lives
to help ensure this, then yes, it’s reasonable to talk about overlap.

>   Shipping a trusted root CA on the supplicant OS is the *only* way to do

This is not true.

Shipping the trusted root CA list in the supplicant _software_ totally
works. Conflating the supplicant with the OS is continuing to muddy the
waters.

  Instead the supplicant is shipped with the OS. Therefore, any root CAs
> needed by the supplicant MUST be included with the OS.
>

This may seem like splitting hairs, but it’s a _profound_ distinction if
you’ve ever managed PKIs on operating systems, as this is not true.
Shipping a CA list in the supplicant shipped in the OS != shipping a CA
list in the OS. They are very different models of managing and configuring
that should not be conflated. Android has plenty of OS components that ship
their own root stores, separate from the root store it provides as part of
its public API contract. We only need the former, not the latter.

It sounds like this has circled back into “How do we get
Apple/Microsoft/Google/whomever to have their supplicants trust a set of
CAs by default”, and the steps outlined above continue to be it. For
Google/Android/ChromeOS, I’m not going to want to conflate the TLS PKI and
the EAP PKI if they have different operational considerations (e.g. the
ease of replacement of certs and the ability to respond to CA incidents),
different profile considerations (the information being attested), and
different policy considerations (how that information is validated). The
advocates of such a solution need to do the work in defining the profiles
and policies and presenting that as the use case for why.

To the OS vendor, managing these profiles and policies is a non-trivial
undertaking involving a host of folks: Legal (for contracts and CP/CPS
review), Engineering, Project/Program Management (it’s a lot of work to
review several thousand CAs a year, let alone the 60-70 organizations in
the root store), Release Management, etc. There has to be a value
proposition here, because the convenient part of the much maligned manual
configuration is that it outsourced all the risk the OS vendor might be
taking on, and instead allows it to be the customer’s problem. That may
seem unfair and non-ideal, but that’s where the risk/value calculus is
right now, and to get vendors to change, you need to present a compelling
value case that demonstrably minimizes risk. Trust is hard and expensive 🤷

  In conclusion, we need a new PKI, and the root CAs must be included with
> OS distributions.  But the OS vendors won't do that until we define the
> requirements, solution, and transition path.

The transition path has been repeatedly defined, so that’s 1/3 of the way
there 👍

---

From: Russ Housley <[email-masked]>
Date: Sun, 19 Jan 2020 11:26:36 -0500

It seems to me that RFC 4334 offers a way for an enterprise to assert that the certificate is intended to be used with a particular SSID.  This seems better than a self-signed certificate with just a domain name.

I understand that CA/B Forum does not allow these extensions and attributes, but as already highlighted in thi discussion, these certificates are not part of the Web PKI.

Russ

> On Jan 19, 2020, at 10:07 AM, Alan DeKok <[email-masked]> wrote:
>

---

From: Alan DeKok <[email-masked]>
Date: Sun, 19 Jan 2020 11:42:00 -0500

On Jan 19, 2020, at 10:54 AM, Ryan Sleevi <[email-masked]> wrote:
> There’s zero need to use any existing CAs.

  I agree.

> Of course, the CAs are only going to do that if there are users: those who will buy or rely on those certificates. So you need to convince supplicants that a zero-touch world is worth it, AND that it can be as secure as manual configuration.

  First the solution needs to be defined.

> Supplicant vendors - whether they are open-source or operating system - are taking on the work to manage and police that root store.

  They "are" doing this?  I don't see that.

> They are not at all different. In both cases, the client has a principal it wants to validate: in RFC 6125, this is the reference name. This is the name in your credential in the case of EAP, the name of the host in the URL in WWW. The client wants to make sure it’s talking to the entity authorized for that name.
> 
> You can manually preconfigured exactly that entity. In EAP, this is incredibly easy to do when you’re provisioning the client credential to also provision the peer identity. This is the existing flow.

  I agree that they're similar, I'm not sure that they're identical.

> This may seem like splitting hairs, but it’s a _profound_ distinction if you’ve ever managed PKIs on operating systems, as this is not true. Shipping a CA list in the supplicant shipped in the OS != shipping a CA list in the OS. They are very different models of managing and configuring that should not be conflated. Android has plenty of OS components that ship their own root stores, separate from the root store it provides as part of its public API contract. We only need the former, not the latter.

  What matters is that the product the user ends up with has the CAs preconfigured for EAP.  The internal corporate structure is (to me) irrelevant.

> It sounds like this has circled back into “How do we get Apple/Microsoft/Google/whomever to have their supplicants trust a set of CAs by default”, and the steps outlined above continue to be it. For Google/Android/ChromeOS, I’m not going to want to conflate the TLS PKI and the EAP PKI if they have different operational considerations (e.g. the ease of replacement of certs and the ability to respond to CA incidents), different profile considerations (the information being attested), and different policy considerations (how that information is validated). The advocates of such a solution need to do the work in defining the profiles and policies and presenting that as the use case for why.

  Sure.

> To the OS vendor, managing these profiles and policies is a non-trivial undertaking involving a host of folks: Legal (for contracts and CP/CPS review), Engineering, Project/Program Management (it’s a lot of work to review several thousand CAs a year, let alone the 60-70 organizations in the root store), Release Management, etc. There has to be a value proposition here, because the convenient part of the much maligned manual configuration is that it outsourced all the risk the OS vendor might be taking on, and instead allows it to be the customer’s problem. That may seem unfair and non-ideal, but that’s where the risk/value calculus is right now, and to get vendors to change, you need to present a compelling value case that demonstrably minimizes risk. Trust is hard and expensive 🤷

  There have been attempts to simplify supplicant configuration with a standard XML format.  The vendors expressed zero interest.  And that's a *lot* easier to do than adding a new root store.

  Alan DeKok.

---

From: Peter Bowen <[email-masked]>
Date: Sun, 19 Jan 2020 08:53:50 -0800

On Sun, Jan 19, 2020 at 8:26 AM Russ Housley <[email-masked]> wrote:
> I understand that CA/B Forum does not allow these extensions and attributes, but as already highlighted in this discussion, these certificates are not part of the Web PKI.

I don't think it is that straight forward.  The operating system
vendors that ship supplicants heavily overlap with the ones who set
the CA/Browser Forum requirements.  They are also the ones who require
CAs in their OS trust stores follow the CA/BF requirements.

The CA/BF has made it clear over the last year or two they are willing
to include other (non-WWW) types of certificates as permitted in their
requirements, but look to IETF and other organizations to set the
technical standards.  For RFC 4334, we have a technical standard
(good!).   However 4334 calls out that "SSIDs may not be unique".
This makes it very tricky to use a shared root setup, as it does not
provide any guidance on who gets to have a certificate for the SSID
"Guest".  This is analogous to the issue of unqualified hostnames
mentioned earlier in this discussion (who gets a TLS certificate for
"mail"?)

How are CAs trusted by supplicants expected to decide who gets a
certificate for a given SSID?

Thanks,
Peter

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 19 Jan 2020 12:12:25 -0500

On Sun, Jan 19, 2020 at 11:42 AM Alan DeKok <[email-masked]>
wrote:

> > Supplicant vendors - whether they are open-source or operating system -
> are taking on the work to manage and police that root store.
>

This was trying to describe the world in which the second problem was
solved. They “would be”, which is why the message later clarified how to
justify the risk/value proposition.

> They are not at all different. In both cases, the client has a principal
> it wants to validate: in RFC 6125, this is the reference name. This is the

This is why advocates need to define the profile and policies :) Figuring
our what information is needed is essential to figuring out the
similarities and differences.

>   What matters is that the product the user ends up with has the CAs
> preconfigured for EAP.  The internal corporate structure is (to me)
> irrelevant.

Don’t conflate technical requirements with corporate structure. You’re
insisting on a precise technical requirement, and I’m explaining to you why
you’re using the term wrong, and in a way that meaningfully detracts and
profoundly conflates things. There’s a tremendous amount of difference in
cost and engineering between the two approaches, and so it’s important to
be clear the requirement - which is the less expensive one.

  There have been attempts to simplify supplicant configuration with a
> standard XML format.  The vendors expressed zero interest.  And that's a
> *lot* easier to do than adding a new root store.

I’m not sure how this is relevant?

It seems we’re in agreement that the status quo is manual configuration, it
seems we’re in agreement that there’s no technical or procedural reason to
use the set of publicly trusted CAs for TLS (it doesn’t get you automatic
recognition, it does increase your risk surface), and it seems we’re in
agreement that defining a unified store is a lot of work with an unclear
value proposition that justifies that work.

> Going back to the original mail, there’s nothing to be gained from trying
to repurpose extant stores, and best practice remains manual configuration.
If folks want more than that, they need to define what they want and how
it’s validated, and figure out what CAs do that. All of this was part of
that first reply, so are we just in agreement?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Jan 2020 08:53:50 -0500

On Jan 19, 2020, at 12:12 PM, Ryan Sleevi <[email-masked]> wrote:
> Don’t conflate technical requirements with corporate structure. You’re insisting on a precise technical requirement, and I’m explaining to you why you’re using the term wrong, and in a way that meaningfully detracts and profoundly conflates things. There’s a tremendous amount of difference in cost and engineering between the two approaches, and so it’s important to be clear the requirement - which is the less expensive one.

  I fully understand that applications can easily ship root CAs.  We can therefore agree that the root CAs MUST be distributed with the software.

  But, precisely *zero* end users download their supplicant software.  The supplicant software comes with the OS.  Which means that the root CAs must be distributed with the OS. 

  While, there are commercial supplicant products, these products are overwhelmingly used by the enterprise, on computers owned by the enterprise, and managed by the enterprise systems.  They have zero impact on the average user.

  So whatever "product" the end-user buys already has the supplicant software pre-installed.  Which means distributed with the OS.  There isn't even an option I've seen in iOS or Android to replace the supplicant software.  It's possible to download a supplicant *configuration* for one SSID, but that isn't standardized (see XML format below).   And when you're downloading the supplicant configuration, it's just a manual configuration with fewer steps.  There's no *automatic* way to trust an EAP / RADIUS server and get on the net.

  This is really the main point of disagreement.  Your position is that it's easy, and it's just not.

  The same goes for root CAs.  While it's superficially true that someone can start "Billy Bobs Tackle Shop & CA", no one has any reason to *use* that CA.  Saying "you can start a CA" and by implication have people *use* it, is no more realistic than me saying "you write software, Bill Gates wrote software, there's nothing preventing you from being as rich as he is."

  It's theoretically true, but false in practice.

  In practice, an SDO like the Wifi Alliance, 3G / 4G  / 5G groups can demand their members put root CAs into devices.  That can even demand that the CAs follow certain policies.

  I have no such power.  So it's unhelpful to say "just start your own CA!"

> I’m not sure how this is relevant?

  It demonstrates that vendors have shown little interest in making WiFi easier to use for their end users.  This decision is likely to have an impact on these efforts.

> It seems we’re in agreement that the status quo is manual configuration, it seems we’re in agreement that there’s no technical or procedural reason to use the set of publicly trusted CAs for TLS (it doesn’t get you automatic recognition, it does increase your risk surface), and it seems we’re in agreement that defining a unified store is a lot of work with an unclear value proposition that justifies that work.
> Going back to the original mail, there’s nothing to be gained from trying to repurpose extant stores, and best practice remains manual configuration. If folks want more than that, they need to define what they want and how it’s validated, and figure out what CAs do that. All of this was part of that first reply, so are we just in agreement?

  We are in agreement on most of that.  We are in disagreement that people can just use other CAs.

  Let's use a concrete example.  Right now, when I add a new IMAP server to my phone / laptop, the process is largely this:

* choose IMAP configuration
* add host name of IMAP server
* maybe get a certificate pop-up if the CA being used isn't already trusted, OR a pop-up saying it's trusted
* add user name
* add password

  Lo and behold, it works.  Note that I did *not* download any software.  The only things I need are (a) already on my computer, and (b) in my brain.

  The workflow I want to see for WiFi is this:

* select an SSID
* maybe get a certificate pop-up if the CA being used isn't already trusted, OR a pop-up saying it's trusted
* add user name
* add password

  With your proposed work flow, this is just impossible.  It's really just manual configuration with fewer steps.  It still requires extra software / configuration / whatever to be downloaded.  And that's the situation I'm trying to avoid.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 20 Jan 2020 09:29:13 -0500

On Mon, Jan 20, 2020 at 8:53 AM Alan DeKok <[email-masked]>
wrote:

>   I fully understand that applications can easily ship root CAs.  We can
> therefore agree that the root CAs MUST be distributed with the software.
>
>   But, precisely *zero* end users download their supplicant software.  The
> supplicant software comes with the OS.  Which means that the root CAs must
> be distributed with the OS.
>

I tried to address this in my previous message, but it looks like that may
not have come across clearly. It might seem like there's a distinction
without a difference to say "must ship with the supplicant which ships with
the OS" and "must ship with the OS", but going back to Owen's original
message, there's a profound difference in the two. As this thread itself
demonstrates, there's ample confusion on "distributed with the OS" and what
trust purposes it's good for - policies, practices, operational procedures
- and continuing to insist "distributed with the OS" is to continue to
further that confusion.

As I hoped my previous message conveyed, but it looks like it may not have
been clear for you, I'm not dismissive that for supplicants distributed by
the OS vendor, you (eventually) need to convince that OS vendor to
distribute roots with their supplicants, and from the end-user perspective,
a default install of that OS "just works". However, it's a very meaningful
distinction in the context of root stores, even if it may not be for
supplicant authors, to highlight the need to distribute roots _with the
supplicant_, not the OS. This is not a corporate distinction, but it is
meaningful to how solutions are engineered and the problem space, and
that's why it does a great disservice to dismiss that distinction.

>   The same goes for root CAs.  While it's superficially true that someone
> can start "Billy Bobs Tackle Shop & CA", no one has any reason to *use*
> that CA.  Saying "you can start a CA" and by implication have people *use*
> it, is no more realistic than me saying "you write software, Bill Gates
> wrote software, there's nothing preventing you from being as rich as he
> is."

This is again shifting the discussion. If you don't believe it is, then
certainly, how you're communicating is not coming across clearly.

As I've mentioned several times, anyone can issue certificates, which is
all that matters for manual configuration. There's no need for anyone
special or blessed - it's just manual configuration.

If you'd like to go to automatic configuration, then you need to define
policies and practices for issuance and verification. Anyone who can comply
with those can become a CA. The usefulness of "Billy Bob's Tackle Shop &
CA" is dictated by those who need a CA - the supplicants - and how well
Billy Bob complies with the policies and practices. You're absolutely
correct that if you don't define those, then _no one_ can become a CA.
There's no reason to believe that Billy Bob is more or less qualified than
an extant CA unless and until you define those. And, of course, once you
define those, the usefuless of Billy Bob - how likely his
CA-slash-tackle-shop is to be included - is dictated by those defining the
root store. That's where the SDOs come in to place.

>   It demonstrates that vendors have shown little interest in making WiFi
> easier to use for their end users.  This decision is likely to have an
> impact on these efforts.
>

Then why are we wasting electrons discussing how to do it? If you believe
it's a doomed effort from the start, why bother replying?

The nice thing about the transition plan I've outlined several times is you
don't need the OS vendors to all adopt apriori for it to be useful. Other
supplicant vendors can go ahead, define their policies and practices,
select their CAs, and build their root store. If it provides something
useful - i.e. users do find it easier and the security tradeoffs are
appropriately mitigated, such as by taking the many concerns I've expressed
on this thread into consideration - then vendors may eventually come
around. As I mentioned several times, there's a risk/benefit calculus at
play, and advocates of the idea of a common trust store need to make a
compelling case as to how to mitigate those risks.

  With your proposed work flow, this is just impossible.  It's really just
> manual configuration with fewer steps.  It still requires extra software /
> configuration / whatever to be downloaded.

I'm afraid you've considerably misunderstood the proposal then, as I've
tried to express several times. I'm well aware the end goal is that on a
'stock' install of your OS of choice, everything just works. I've outlined
several times a plan to get to that - and which does not involve shipping
roots in the OS, but roots in the supplicant that comes with the OS. The
distinction is quite meaningful for the reasons outlined throughout this
thread, even if the end user experience is "it just works"

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 20 Jan 2020 10:13:24 -0500

On Jan 20, 2020, at 9:29 AM, Ryan Sleevi <[email-masked]> wrote:
> 
> I'm well aware the end goal is that on a 'stock' install of your OS of choice, everything just works. I've outlined several times a plan to get to that - and which does not involve shipping roots in the OS, but roots in the supplicant that comes with the OS. The distinction is quite meaningful for the reasons outlined throughout this thread, even if the end user experience is "it just works” 

I think the distinction you’re trying to make between the OS and supplicants is very much an “inside baseball” view.  Modern OSes rely on a number of support components to deliver core functionality.  The OS is more than the kernel, GUI, CLI and browser.  From an end user perspective, all the OS-vendor shipped support components and utilities *are* the OS.  It’s not a useful distinction from a User Experience perspective that the supplicant code is or is not written by the same company as the kernel (and I suspect often it is).  It’s shipped as part of the product.

The arguments about the differentiated policies for use of certificates and trust of CAs is probably technically sound.  I think the notion that supplicant components can ship with a separate root CA store from that used for the browser is perhaps workable.  However, it’s still the OS vendor that must include this configuration for it to “just work out o the box”.  For that reason, I think the claim that it’s not the OS which must support the appropriate CAs is a distinction without a difference, and perhaps a red herring.

Regards,

Dave Nelson

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 20 Jan 2020 10:44:08 -0500

On Mon, Jan 20, 2020 at 10:13 AM David B. Nelson <[email-masked]>
wrote:

> The arguments about the differentiated policies for use of certificates
> and trust of CAs is probably technically sound.  I think the notion that
> supplicant components can ship with a separate root CA store from that used
> for the browser is perhaps workable.  However, it’s still the OS vendor
> that must include this configuration for it to “just work out o the box”.
> For that reason, I think the claim that it’s not the OS which must support
> the appropriate CAs is a distinction without a difference, and perhaps a
> red herring.

It’s a distinction that cuts to the heart of the original proposal, echo’d
several times on this thread: Can’t we just use the TLS CAs shipped by the
OS today for this, ideally so that OS vendors don’t have any added work.

In that context, it’s essential to make the distinction that while the
end-user experience is indistinguishable, the engineering involved - and
the work of standards here - is meaningfully different. If we conflate the
two or think “let’s just use what we have”, then the world of zero touch
will not happen. That’s why it’s essential to focus on the notion of
defining a new root store, one that doesn’t have to be generally available
to software running on that OS, limited for a particular purpose, so that
we can enumerate the necessary profiles and practices.

It’s also essential to understanding that this solution isn’t gated on a
first-mover problem, as had also been suggested, where everything is doomed
unless and until the OS moves. There’s considerable work that can - and
should - be done, which makes it easier to bring about the second solution
(“zero-touch”), by making sure that the first problem (“what SHOULD you
do”) adequately focuses on making a transition possible.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Jan 2020 11:19:21 -0500

On Jan 20, 2020, at 9:29 AM, Ryan Sleevi <[email-masked]> wrote:
> As I hoped my previous message conveyed, but it looks like it may not have been clear for you, I'm not dismissive that for supplicants distributed by the OS vendor, you (eventually) need to convince that OS vendor to distribute roots with their supplicants, and from the end-user perspective, a default install of that OS "just works". However, it's a very meaningful distinction in the context of root stores, even if it may not be for supplicant authors, to highlight the need to distribute roots _with the supplicant_, not the OS. This is not a corporate distinction, but it is meaningful to how solutions are engineered and the problem space, and that's why it does a great disservice to dismiss that distinction.

  We'll have to disagree here.  That distinction is entirely a technical detail which is irrelevant to the end user.  It doesn't matter to the standards bodies, either.

  The distinction doesn't even matter in the content of root stores.  The vendor downloads N root CAs, and places them into files / DBs in the product.  Whether those files from from A and go to B, or come from C and go to D is *entirely* irrelevant to the end product.  Whether it's Department A that downloads the roots CAs or Department B is also irrelevant.

  Whether we have to convince "the OS vendor", or just "the supplicant division in the OS vendor" is largely the same thing.

> This is again shifting the discussion. If you don't believe it is, then certainly, how you're communicating is not coming across clearly.

  It's not shifting the discussion.  It's directly addressing your point, as clearly as I can make it.

> As I've mentioned several times, anyone can issue certificates, which is all that matters for manual configuration. There's no need for anyone special or blessed - it's just manual configuration.

  The issue, as I've mentioned several times, is that's where we are today.  There's no need to bring up current behaviour as an option - we know it's an option.  We're trying to fix it.

> If you'd like to go to automatic configuration, then you need to define policies and practices for issuance and verification. Anyone who can comply with those can become a CA. The usefulness of "Billy Bob's Tackle Shop & CA" is dictated by those who need a CA - the supplicants - and how well Billy Bob complies with the policies and practices. You're absolutely correct that if you don't define those, then _no one_ can become a CA. There's no reason to believe that Billy Bob is more or less qualified than an extant CA unless and until you define those. And, of course, once you define those, the usefuless of Billy Bob - how likely his CA-slash-tackle-shop is to be included - is dictated by those defining the root store. That's where the SDOs come in to place. 

  Which is largely what I was saying.  So I think we're in agreement here.

  But again, this doesn't *help*.  I can't get my CA shipped with vendor products, and nothing you've said convinces me that it's possible.

> Then why are we wasting electrons discussing how to do it? If you believe it's a doomed effort from the start, why bother replying?

  I never said it was "doomed".  I was trying to suggest that there we need to have clear benefits, and a clear path to implementing the benefits.

> The nice thing about the transition plan I've outlined several times is you don't need the OS vendors to all adopt apriori for it to be useful. Other supplicant vendors can go ahead, define their policies and practices, select their CAs, and build their root store.

  And not a single person will download and use the new supplicant software.  Making it 100% useless.

  Any "supplicant division" of an OS vendor will require high-level signify before massively changing user workflow.  So in the end, it *is* the "OS vendor" who has to be convinced.

> I'm afraid you've considerably misunderstood the proposal then, as I've tried to express several times. I'm well aware the end goal is that on a 'stock' install of your OS of choice, everything just works. I've outlined several times a plan to get to that - and which does not involve shipping roots in the OS, but roots in the supplicant that comes with the OS. The distinction is quite meaningful for the reasons outlined throughout this thread, even if the end user experience is "it just works" 

   When I do RADIUS stuff, I say "the vendor has to do X".  It's never been useful to say "Bob in engineering department X has to do it".  The distinction you're making is 100% irrelevant.

  If this distinction is necessary and important, why has every other WG avoided doing it?

  i think we're at an impass.  We agree on the end goal, but disagree fundamentally on some major points.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Jan 2020 11:22:15 -0500

>  Any "supplicant division" of an OS vendor will require high-level signify before massively changing user workflow.  So in the end, it *is* the "OS vendor" who has to be convinced.

  Please read "sign-off", not "signify". :(

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Jan 2020 11:28:53 -0500

On Jan 20, 2020, at 10:44 AM, Ryan Sleevi <[email-masked]> wrote:
> It’s a distinction that cuts to the heart of the original proposal, echo’d several times on this thread: Can’t we just use the TLS CAs shipped by the OS today for this, ideally so that OS vendors don’t have any added work.

  There has been consensus already that it's wrong to use the existing TLS CAs

> In that context, it’s essential to make the distinction that while the end-user experience is indistinguishable, the engineering involved - and the work of standards here - is meaningfully different. If we conflate the two or think “let’s just use what we have”, then the world of zero touch will not happen. That’s why it’s essential to focus on the notion of defining a new root store, one that doesn’t have to be generally available to software running on that OS, limited for a particular purpose, so that we can enumerate the necessary profiles and practices.

  I agree.

> It’s also essential to understanding that this solution isn’t gated on a first-mover problem, as had also been suggested, where everything is doomed unless and until the OS moves. There’s considerable work that can - and should - be done, which makes it easier to bring about the second solution (“zero-touch”), by making sure that the first problem (“what SHOULD you do”) adequately focuses on making a transition possible.

  I don't think "doomed".  I think *required*.  i.e. the end goal *is* to have it "just work" out of the box.

  I think we may be arguing semantics, and avoiding some common points.

  I *do* agree that we can define new CAs just for EAP today.  I do agree that these CAs can be used by supplicants that exist today, via manual configuration.

  However, I do also believe that we will not get new behaviour without changing the supplicant implementations.  So the intermediate step of just using a "new CA" has near-zero benefits to the end user.

  And, if the new CA must be configured manually, then that step is no different than what we have today.  Which means that this intermediate step further has near-zero benefits.

  That's why I'm focussed on the end goal: updating the root CAs *and* supplicant implementations at the same time.  And, making sure that all of these updates ship with the product that the consumer buys.  The intermediate steps gain nothing.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 20 Jan 2020 11:51:44 -0500

On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok <[email-masked]>
wrote:

>   The distinction doesn't even matter in the content of root stores.  The
> vendor downloads N root CAs, and places them into files / DBs in the
> product.  Whether those files from from A and go to B, or come from C and
> go to D is *entirely* irrelevant to the end product.  Whether it's
> Department A that downloads the roots CAs or Department B is also
> irrelevant.

This is not at all how root stores work or have worked for ages, and I
suspect this lack of familiarity may be the cause of the significant
confusion demonstrated here.

There isn’t “a” root store on any modern OS. Even if you factor Linux with
the LSB, there are multiple root stores. Multiple independent root stores
are maintained for separate purposes, with their own policies and profiles,
administered not only by different parts of the organization, but also
against different standards and with different industry bodies.

This basic understanding of how modern PKI works is essential to
understanding how to make productive contributions in this space, because
it shapes how the profiles are developed, how the policies are
administered, and how one makes progress convincing the right stakeholders
of the vision.

  Whether we have to convince "the OS vendor", or just "the supplicant
> division in the OS vendor" is largely the same thing.

It isn’t, and there’s been zero evidence to support that conclusion, but I
can tell reality isn’t that convincing :)

  But again, this doesn't *help*.  I can't get my CA shipped with vendor
> products, and nothing you've said convinces me that it's possible.

You can’t get your non-existent CA that issues against undefined profiles
and undefined practices included, and you’re lamenting that? I mean,
there’s no place I can go buy a unicorn burger, but I’m not exactly sending
letters to McDonald’s complaining about this.

The path to getting it shipped with vendor products involves, as I’ve said
repeatedly: define the profile and define the policies. That makes it even
possible for Billy Bob to issue in the first place, and to assess how well
Billy Bob does issue, and that’s the path forward. Lamenting that you can’t
get a unicorn burger today doesn’t move the discussion further.

  And not a single person will download and use the new supplicant
> software.  Making it 100% useless.

This sort of fatalism is doomed to be unproductive. Fixating on the OS
vendor as an excuse to not do the work just means won’t get done.

Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You
have paths forward.

   When I do RADIUS stuff, I say "the vendor has to do X".  It's never been
> useful to say "Bob in engineering department X has to do it".  The
> distinction you're making is 100% irrelevant.

You’re confusing “everyone at the vendor needs to move their car” with “Bob
needs to move his car”. You’re doomed to failure if you keep insisting
everyone at the company needs to move their car, when all you need is Bob
to move and not block your car in.

The distinction you keep insisting on is like asking “You must invest $10
million”, when all you need is $10. Yes, if you had $10 million, you would
have your $10. Continually saying “but I really need the money” rather than
“I just need $10” leads to impasses.

This is not about which department is involved. The distinction is about
the scope of trust. Saying shipped in the OS, both in the context of this
thread and more generally, is presuming a broad scope and maintained
interfaces for third-parties, neither of which you need. Not recognizing
that a “root store” on a modern OS is merely an abstraction over disparate
trust bits is meaningful, particularly when not addressing what the “trust
bits” should be or how they’re maintained.

A good example of this is HotSpot 2.0. It works, it’s not part of the root
stores on Windows or Android, yet it uses its own roots and policies and
practices and works out of the box. To any developer on those platforms,
it’s not part of the OS, yet to the user, it just works.

The IETF primarily targets those developers, not the end-user, and it’s
essential to understand why and how it works to understand what work is
needed to make something similar for EAP. Dismissing that as organizational
structure just means dismissing the requirements and means to success, in
which case, you’re going to be as unsatisfied as my appetite for a fresh
unicorn burger.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Jan 2020 12:22:11 -0500

Alan DeKok <[email-masked]> wrote:
    > While, there are commercial supplicant products, these products are
    > overwhelmingly used by the enterprise, on computers owned by the
    > enterprise, and managed by the enterprise systems.  They have zero
    > impact on the average user.

Today.
But, since a goal here was for IoT devices, this changes things:

1) Enterprises want to manage IoT device onboarding, and they overwhelmingly
   want to use EAP/1x.

2) IoT devices don't have users and can't even load a non-standard XML
   configuration.

    > In practice, an SDO like the Wifi Alliance, 3G / 4G  / 5G groups can
    > demand their members put root CAs into devices.  That can even demand
    > that the CAs follow certain policies.

    > I have no such power.  So it's unhelpful to say "just start your own

Well, even if you were the Wifi Alliance, you'd also have a mindshare/bootstrap problem.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 20 Jan 2020 12:28:32 -0500

On Jan 20, 2020, at 11:51 AM, Ryan Sleevi <[email-masked]> wrote:
> It isn’t, and there’s been zero evidence to support that conclusion, but I can tell reality isn’t that convincing :)

I have to disagree with that.  There are exceptions to very rule, of course, but I have never downloaded, installed and configured a supplicant on any of my computing devices.  I’m a highly technical end-user (long time IETF and IEEE contributor).

> This is not about which department is involved. The distinction is about the scope of trust. Saying shipped in the OS, both in the context of this thread and more generally, is presuming a broad scope and maintained interfaces for third-parties, neither of which you need. Not recognizing that a “root store” on a modern OS is merely an abstraction over disparate trust bits is meaningful, particularly when not addressing what the “trust bits” should be or how they’re maintained.

And *that* is an artifact of the way vendors have chosen to ship their OS products.  I think what you’re saying is that large industry software providers aren’t going to change their behavior just because it inconveniences users (customers).  Maybe that’s true.  However, it’s an organizational and implementation argument, not a technical one.

> The IETF primarily targets those developers, not the end-user, and it’s essential to understand why and how it works to understand what work is needed to make something similar for EAP. Dismissing that as organizational structure just means dismissing the requirements and means to success, in which case, you’re going to be as unsatisfied as my appetite for a fresh unicorn burger.

Sure.  Standards are voluntary.  All *good* standards start with clear and accurate Use Cases and User Stories.  The ”users” have to include end-users, not just developers. Technical standards are successful when they solve end-user, market driven problems.  Standards that seek (primarily or secondarily) to preserve “the way we’ve always done it” among the vendor base, are not very useful, IMHO.

We all seem to agree that change is required.  Where we disagree is how change is implemented and who has to make it.  I’m not a unicorn-seeking idealist, but if the rationale behind a particular path to change is suboptimal because of vendor intransigence, then that needs to be very clearly documented for all stakeholders to see.

Regards,

Dave Nelson

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 20 Jan 2020 13:08:47 -0500

On Mon, Jan 20, 2020 at 12:28 PM David B. Nelson <[email-masked]>
wrote:

> I have to disagree with that.  There are exceptions to very rule, of
> course, but I have never downloaded, installed and configured a supplicant
> on any of my computing devices.  I’m a highly technical end-user (long time
> IETF and IEEE contributor).
>

How is this related? This isn’t about downloading third-party supplicant
software, this is about scoping the problem and the solution. Shipping as
part of the OS, as a root store, is several magnitudes more work than
shipping as part of a supplicant that is part of that OS, and which itself
is exponentionally more work - and risk, both technical and legal - to
requiring manual configuration.

In the context of the original post, it’s about using a hammer as a
screwdriver, when we all seemingly agree a screwdriver is the right tool.

> And *that* is an artifact of the way vendors have chosen to ship their OS
> products.  I think what you’re saying is that large industry software
> providers aren’t going to change their behavior just because it
> inconveniences users (customers).
>

You’re right that organizations are not going to take on more technical
complexity, more security risk across their products, and more legal risk
to the organization, “just” because some folks are inconvenienced.
Especially when that fraction of inconvenienced folk represent a remarkable
minority of their user base. That’s why advocates _have_ to demonstrate
value AND demonstrate solutions that understands those complexities and
risks and mitigates them appropriately. Ignoring those needs is bound to
get half-assed solutions that get ignored.

Maybe that’s true.  However, it’s an organizational and implementation
> argument, not a technical one.
>

This isn’t correct either. The point - going back to the very original
reply - is that the primary means of mitigating those risks and
complexities is of a technical nature. It’s absolutely true that legal
risks, for example, are not easily expressed as technical solutions, but
this design and selection of root stores, and the risks involved, very much
depends on technical decisions that are made. If folks want to ignore those
concerns, it’s at their peril, but different technical decisions amplify or
mitigate those concerns. Hence, again, back to profiles and their
corresponding policies.

Sure.  Standards are voluntary.  All *good* standards start with clear and
> accurate Use Cases and User Stories.  The ”users” have to include
> end-users, not just developers. Technical standards are successful when
> they solve end-user, market driven problems.  Standards that seek
> (primarily or secondarily) to preserve “the way we’ve always done it” among
> the vendor base, are not very useful, IMHO.
>
>
Sure, but standards that exist to ignore the problems of constituents, and
then lament no one adopts them, are not very useful. There isn’t
disagreement on the benefit to users, but there’s clearly not an
understanding how the entire discussion of PKI is a risk-shifting design,
and has been since its very inception as a framework outside of the scope
of X.500 DIT authorization.

Standards that shift all risk onto the vendor are almost certainly doomed,
even if it’s incredibly convenient for end-users to have someone else bear
the burden. That’s why it’s essential for _good_ and _useful_ standards to
understand how the technical decisions affect the implementation risks and
costs, so that they actually have a shot at adoption. If the rationale
behind a standard is to write checks that get debited out of someone else’s
account, then it needs to be clearly documented for all stakeholders to see.

I’d like to avoid that scenario, which is why I keep trying to emphasize
designs that have a chance at achieving the end-goal, are incrementally
deployable, and which can demonstrate real value to vendors. Trying to make
it one size fits all, and with existing solutions, is simply doomed, if
only because the market has realized the substantial and non-trivial hidden
costs of that. Centralizing configuration, which the whole idea of a root
store is about, centralizes risk, and it’s essential that the risk be both
managed and not bleed into unrelated areas if you want to convince vendors
to take on that risk.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Jan 2020 15:31:17 -0500

On Jan 20, 2020, at 11:51 AM, Ryan Sleevi <[email-masked]> wrote:
> On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok <[email-masked]> wrote:
> This is not at all how root stores work or have worked for ages, and I suspect this lack of familiarity may be the cause of the significant confusion demonstrated here.

  In a word: no.

> There isn’t “a” root store on any modern OS. Even if you factor Linux with the LSB, there are multiple root stores. Multiple independent root stores are maintained for separate purposes, with their own policies and profiles, administered not only by different parts of the organization, but also against different standards and with different industry bodies.

  So in a message where I explicitly say that CAs go to multiple places, your conclusion is that I believe there's only one root store?

> This basic understanding of how modern PKI works is essential to understanding how to make productive contributions in this space, because it shapes how the profiles are developed, how the policies are administered, and how one makes progress convincing the right stakeholders of the vision.

  I could say the same thing about previous misconceptions in how EAP is implemented.

> Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You have paths forward.

  Cisco: yes.  Jouni: No.

  wpa_supplicant / hostap is just a collection of source code in a git tree.  It includes no CAs.  And if it did, people would ignore them.  Any open source author has minimal influence on how their end product is used.  I know this from 20+ years of experience.

  You seem to think you can convince me if you just repeat often enough "but you can define your own CA!"  I know this.  I don't care.  It's irrelevant, for reasons I've explain.

> You’re confusing “everyone at the vendor needs to move their car” with “Bob needs to move his car”. You’re doomed to failure if you keep insisting everyone at the company needs to move their car, when all you need is Bob to move and not block your car in.

  That is absolutely not the conclusion you can draw from what I said.  When I say "the customer sees one end product, and therefore I don't care which group does the update", I do NOT mean "every individual department which works on the OS has to be updated in order to get this new EAP functionality".

  To be frank, this insinuation uncalled for.  You're implying that I'm an idiot who "keeps insisting everyone at the company needs to" do the update.  That is absolutely not true, and you should apologize for saying something so outlandish.

> The IETF primarily targets those developers, not the end-user, and it’s essential to understand why and how it works to understand what work is needed to make something similar for EAP. 

  In a word: no.

  In a longer phrase: you're essentially claiming that the entire IETF process (which does NOT do this) is wrong, and doesn't work.

  Since we're not making progress, I'll stop.

  Alan DeKok.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 20 Jan 2020 15:58:13 -0500

On Mon, Jan 20, 2020 at 3:31 PM Alan DeKok <[email-masked]>
wrote:

>   wpa_supplicant / hostap is just a collection of source code in a git
> tree.  It includes no CAs.  And if it did, people would ignore them.  Any
> open source author has minimal influence on how their end product is used.
> I know this from 20+ years of experience.

I’m afraid this is quite disconnected from reality, then. The premiere root
store on more devices than any other is the Mozilla Root Store, developed
as part of the open-source NSS package, shipped in virtually every
mainstream Linux/BSD distro, and used in wide swaths beside that (e.g.
curl, server programming languages, IoT, cars, thermostats)

The decisions made by Mozilla - to add or remove CAs for given purposes,
like TLS or S/MIME - reverberate on a host of ecosystems, for better and
for worse. The reason for that adoption is on the strength of the profiles
and policies, and addressing a real need, which are the things not being
addressed here for EAP.

There’s nothing that prevents a “Like-Mozilla-but-for-EAP” root store being
developed. Like all root stores, it requires defining your profiles for how
the information is expressed, the practices for how clients validate and
use that information, and the policies for how CAs appropriately vet and
validate that information. The first two - profiles and practices - are
excellent candidates for standardization efforts. The latter, policies, is
as the name suggests, more about policy and left to industry efforts. The
technical decisions in the profiles and practices affect the policies -
some decisions create more work, some less, such as the discussions around
EKUs.

The choice to implement, as an OS/supplicant vendor, is about evaluating
the risk of the policies. How much do the technical decisions expose users
to risk vs mitigate risks of misconfiguration? How can those policies be
customized or adjusted to the needs of the vendor, and what
interoperability risks exist when they are so customized? If you’re talking
PKI, it’s inherently risk management, which is managing the policies to
support the technologies.

We generally don’t hear, for example, the SSH community remarking on a lack
of an out-of-the-box PKI that just works for all their hosts. That’s
because the policies, and the needs of constituents, aren’t really aligned
with that sort of global model. Local PKIs - whether TOFU or local SSH PKIs
- better balance the risk. Today, that calculus is largely true for EAP, at
least from the POV of supplicant implementors. If you want to convince
otherwise, it’s about defining those profiles and policies that can show
that different calculus.

  That is absolutely not the conclusion you can draw from what I said.
> When I say "the customer sees one end product, and therefore I don't care
> which group does the update", I do NOT mean "every individual department
> which works on the OS has to be updated in order to get this new EAP
> functionality".

This is not what I said either.

The notion of “add to the OS root store” has impact on every OS component,
which needs to be evaluated holistically. The decision _impacts_ them, from
a risk management standpoint, even when it doesn’t need to and shouldn’t.
That’s everyone having to move their car, or asking for $10 million.

You don’t need impact on every OS component. You only care about EAP,
clearly. Thats why it’s important to be precise on what is needed -
something _just_ for EAP. That’s only needing Bob to move his car, or
asking for $10.

So when talking about what this hypothetical root store should be, it needs
to be clear that it’s only for EAP, and saying “added to the OS” is far
more than EAP, with far more impact than needed or intended. It leads to
confusion, such as in the original message, around concepts like “public
CAs”, which only hurts the conversation. Plenty of folks have been
confused, for example, ingesting the Mozilla source files without realizing
it is three separate root stores, each with their own policies, management,
and constraints, some of which are not expressed purely in a single file.
That this happens often, or messages like Owen highlight “public CAs”
without qualification, are the same reason it’s important to be clear we’re
talking about a _new_ root store for a _new_ purpose, and thus nothing
extant has any bearing whatsoever on this store.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Jan 2020 17:44:39 -0500

> 2) IoT devices don't have users and can't even load a non-standard XML

I think it best that we focus on meeting the needs of customers rather than
engaging in the spec lawyer-ing seen earlier in the thread.

We already have the EU and the US House and Senate looking at the PKI world
as one example of what they believe to be a 'Big Tech' agenda set against
the little guy. And not just on the left. Most of the people I have been
talking to are Republicans or staffers thereof.

So no, let us not suggest that we can find some wording in some CA's CPS
that enables us to force them to revoke certificates that are clearly not
being abused. And certainly not on the basis of some arbitrary
interpretation of a CPS. Such would likely prove a career-limiting move.

Let us instead focus on the onboarding problem Michael poses, because that
goes to the heart of the matter in my view. Enterprises want to onboard
devices with as little manual intervention as is possible. They are
currently using the WebPKI roots of trust because that is expedient. This
exposes them to real risks which is precisely the reason why the product
that was the focus of much of my early VeriSign work was OnSite which is
designed to provide enterprises with their own separate PKI for their
exclusive use.

The reason I have been delving into threshold cryptography and writing the
Mathematical Mesh is precisely to support that set of use cases for both
personal and enterprise use. What I call connecting a device to a personal
Mesh is essentially a PKI driven onboarding process in which the device may
be connected by means of one of the following types of identifier

* Unique device ID passed to the customer during procurement (most
enterprise suppliers provide MAC addresses of the devices that are shipped.)

* QR Code printed on the device during manufacture, scanned by customer.

* Ad hoc credentials generated by customer-installed application.

The device that is onboarded acquires:

1) The ultimate root of trust for that connection context
2)  A set of device keys for Encryption, Authentication and Signature to
use within that connection context
3) A connection statement credentialing the device keys under the
connection context

The use of threshold techniques allows the usual concerns about use of
manufacturer provided vs centrally generated key pairs to be finessed by
providing all the advantages of both. The disadvantages only appear if both
the admin device and the device being connected are compromised by the same
party.

The reason I have moved to a new syntax for this PKI (JSON) is that in my
trust model, every user, every enterprise is their own root of trust. It is
much easier to design a completely new PKI than to attempt to impose that
restriction on PKIX or SAML. I can easily spit out X.509 certs as needed
but these are products of the enterprise PKI, they are not the primary
accreditation trust path.

The traditional approach used to engineer this in OnSite is about as well
as can be achieved using 1990s technology when the machines were severely
limited in their CPU capabilities and processing RSA path math took seconds.

Automating the device and service management processes is a necessary
precondition for using client side PKI, and security policy and thus making
effective use of DNSSEC.

The key difference in my new approach is that under the OnSite approach,
enterprises that outsourced their PKI to VRSN were handing over the keys to
their kingdom. Using threshold, that is no longer necessary.