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

[Ryan Sleevi <[e-mail]>]

On Tue, Jul 27, 2021 at 11:44 AM Eliot Lear <[e-mail]> wrote:

> CAs can barely handle three.  Adding one more will be challenging enough,
> which is why I asked if there was an intent to deploy by CAs, and the
> answer was, “yes”.
>
I don't think it's appropriate at all to generically refer to CAs like
this, given that we have ample industry evidence to the contrary. It
equally seems to be mistaken of the concerns to think that it's a question
about what the CA deploys, since this is a question of and for relying
party applications.

> On (1), RFC 5280 was written prior to the requirement for explicit IANA
> policies, but there is no basis to believe that a protocol is required to
> establish an EKU.
>
This is a very broad statement, and it's unclear if you're requesting to
understand more of the historic basis for the {Extended, Enhanced} Key
{Usage, Purpose} and its historic evolution. As the brackets note - this is
a field that has had many names through its evolution, and while you're
entirely right that RFC 7299 post-dates RFC 5280 and the previous work
(e.g. ipki-part1-05 borrowing the field from ISO), and you can certainly
examine the contemporary discussions around the intersection with keyUsage.

> Finally, we do not want a requirement for more specific EKUs (or any other
> extension) to become a barrier to deployment.  In the end that just makes
> it less practical to use certificates.  If you're reading this as, “the CAs
> can't/won't keep up”, then you've understood my message.
>
Again, I believe it's misguided to speak of "the CAs" without speaking to
the trust framework; your "CAs" are not my "CAs", and that's perfectly fine
and working as intended. I understand and appreciate your sensitivities of
concern with manual certificate management and the use of legacy smart
cards; however, these concerns do not generically extend to all
certificates or all CAs, nor are they sufficient to justify IANA/IETF
action.

This document "could" be entirely reasonable as an Individual Submission;
while that does not at all redeem its flaws, it also reflects the reality
that what's being proposed here is explicitly not something that can or
should be used in an interoperable way. It certainly, in its present form,
explicitly conflicts with the objectives set forth in RFC 5280, Section 2.2:

   The goal of the Internet Public Key Infrastructure (PKI) is to meet
   the needs of deterministic, automated identification, authentication,
   access control, and authorization functions.  Support for these
   services determines the attributes contained in the certificate as
   well as the ancillary control information in the certificate such as
   policy data and certification path constraints.

Namely, that the objective of this EKU is, as stated, for
non-deterministic, manual identification of certificates. This further
contradicts Section 2.3's goal of ensuring the specification recognizes
"the limitations in sophistication and attentiveness of the users
themselves".

Concretely, our disagreement appears to be this: When faced with the
question of a hypothetical new EKU, do the specifications provide
sufficient guidance to relying party applications to make an automated
determination about whether or not the use is appropriate or not?
Explicitly, it does not: it does not provide a way, for example, to
distinguish whether this "XMLDSig" signed thing is permitted, no more than
it permits this "PDF-via-CMS" or "PDF-with-CMS" is permitted. It does not
provide any further insight into either the CA's intended capability for
the named subject, nor to the relying parties expectations of that
capability, and intentionally so. A relying party application instead is
expected to treat this as abstract, to be determined by each application
whether or not it's appropriate, creating a fundamental disconnect between
any CA that tries to issue such certificates and any relying party
attempting to use them.

The solution for this disconnect is simple: relying parties and CAs to
agree on semantics that are unambiguous as to what is acceptable or not.
This is true with or without IANA/IETF action, as reflected by deployed
reality.

>