Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

[Ryan Sleevi <[e-mail]>]

On Wed, Jul 28, 2021 at 4:03 AM Eliot Lear <[e-mail]> wrote:

> How about the second paragraph:
>
> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working
> Group is chartered to make updates where there is a known constituency
> interested in real deployment and there is at least one sufficiently
> well specified approach to the update so that the working group can
> sensibly evaluate whether to adopt a proposal.
>
> I hope my previous emails sufficiently explained why this document should
not be considered as meeting the bar "sufficiently well specified
approach", and how the definition of "real deployment" in the context of a
multi-stakeholder ecosystem like PKI (CAs, relying parties, users) is
equally questionable.

To be clear: I agree with Deb in the abstract that there is potential value
here in having an approach that can address this demonstrably real-world
use case of CAs misusing emailProtection or codeSigning, so I am supportive
of "something" to indicate in this space that there is a different use
case. My concern remains that it does not require IETF or IANA action to do
so, and the past two decades of real-world implementation experience, as
shown by the running code on billions of devices, has revealed that the
generic approach proposed here is not only not promoting interoperability,
but actively harming it.

For example, the use of id-kp-serverAuth within multiple disparate trust
frameworks, while useful in ensuring a protocol-level binding of the key,
has actively harmed the agility and security improvement of relying
parties. Concretely, consider the case of both payment terminals using IoT
stacks, and only being capable of supporting SHA-1, with those of web
browsers or government systems, requiring 'modern' security such as SHA-2.
These are clearly very distinct use cases, and these use cases impose
protocol constraints that make it "TLS, but not the same TLS". For example,
whether or not a device has generic Internet connectivity or limited
connectivity to a single server, or whether or not both client and server
support OCSP stapling, or even the memory constraints of the device itself,
all impose assumptions and restrictions on the PKI implementation that
meaningfully affect whether or not the private key is "appropriate" for
this case. Similarly, this (present) misguided overlap creates security
risks, by combining disparate client groups (e.g. the IoT payment terminal
and the web browser) onto a single server and PKI, the ability to make
security-positive changes (e.g. the deployment of CT, the migration to
SHA-2) is impaired. These aren't hypothetical. These are lessons from the
real world of deprecations (MD5, SHA1, SHA2), and we shouldn't continue to
pretend they're all just one interoperable family when we know they aren't.

This is clearly something that will result from document signing, as we see
there are a myriad of technical approaches, which then further dictate the
protocol capabilities, which then further dictate the PKI design, such that
there is not a "one size/one key fits all" case. Even seemingly simple
things, such as online verification versus offline verification,
timestamping countersignatures, or legal recognition show the distinction.
This is nothing new to anyone familiar with PKI as practiced: this group
has long been aware, for example, that some digital signatures on documents
may convey a presumption of legal certainty and liability, while others may
not. These are already expressed today as different certificates, with
their own policies and constraints, but also reflect different protocol
assumptions, expectations, and constraints with respect to the "document"
being signed. Pretending they're the same is misleading, at best: document
signing is _not_ a generic case, it is inherently tailored to specific,
distinct communities of relying parties and ISVs, whether those be
communities with jurisdictional overlap (e.g. qualified signatures) or
communities of similarly interested parties (e.g. industry consortia like
the CA/Browser Forum)

The concerns being raised here, regarding multiple certificates, are
demonstrably inconsistent with the existing specification and expectations.
We have and accept policy OIDs precisely to express the need for different
management scopes and authorities, and to allow distinction between
different PKIs, so that relying parties can ensure their needs are met. The
real world demonstrates this is not a barrier to adoption or deployment: we
see virtually every consumer-focused CA offering certificates bearing
multiple policy OIDs reflective of the supervision schemes they take part
of, as well as common policy OIDs for their constituencies of note (e.g.
CA/Browser Forum, ETSI Qualified Certificates, vendor-specific PKIs like
WFA, USB, mFI, or Qi, etc).

Without wanting to misrepresent opinions, it seems the disconnect is that
opponents to distinct EKUs are either not familiar with, or in opposition
to, the deployed reality that both EKUs and policy OIDs _together_ serve to
distinguish PKIs and (collective) protocols. Considering this has been a
part of deployed reality that predates PKIX existing, and has long remained
controversial within the PKIX group, perhaps I should be unsurprised that
we're at the same impasse we were in 2016 [1], 2013 [2], 2009 [3], and 2000
[4]. We equally seem to be rewriting history, contrary to the contemporary
discussions about what EKU was and how it would evolve [5].

While I certainly cannot prevent the adoption of this document, and I'm
aware that I am presently the lone objector, I am very concerned that the
arguments in favor here are simply echoing design mistakes and misguided
beliefs of the 1990s that we should know better in 2021. As an implementer
of relying party software and as someone who has dealt with countless
security issues resulting from the misuse of PKI, is a very clear,
preventable, and avoidable mistake, and this document, and its goals, would
only serve to leave users less secure.

[1] https://mailarchive.ietf.org/arch/msg/pkix/MHwcSWuuzezj4qHuzSmbYeGUbdI/
[2] https://mailarchive.ietf.org/arch/msg/pkix/EzBA2NgSx6zi2CG-D2oKaOBbGvE/
[3] https://mailarchive.ietf.org/arch/msg/pkix/M80kRfzAX9bWcqibV97z4MOMqJI/
[4] https://mailarchive.ietf.org/arch/msg/pkix/QQ4vHlYLyYFYnswc14_jTdHHbLg/
[5] https://mailarchive.ietf.org/arch/msg/pkix/c8aIik0B_7WOaBdGuiURrkvE_h0/