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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Without spending (and repeating) too many words – I agree with Eliot’s position and disagree with Ryan’s.

 

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

 

From: Spasm <[e-mail]> on behalf of Ryan Sleevi <[e-mail]>
Date: Tuesday, July 27, 2021 at 12:19
To: Eliot Lear <[e-mail]>
Cc: Ryan Sleevi <[e-mail]>, LAMPS WG <[e-mail]>, Russ Housley <[e-mail]>
Subject: Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

 

 

 

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.