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

From: Russ Housley <[email-masked]>
Date: Mon, 26 Jul 2021 18:13:10 -0400

We have already discussing the assignment of an object identifier for document signing, and we had a presentation at IETF 111.  Following the IETF 111 presentation, no one spoke against against adoption of this work.  This call is to see if there is rough consensus for the LAMPS WG to proceed with this work.

Please send your reply about whether you support adopting draft-ito-documentsigning-eku as a WG document.  Please voice your support or raise concerns by 14 August 2021.

For the LAMPS WG Chairs,
Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Jul 2021 23:00:50 +0000

I support adoption.  I will read and comment if adopted.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Jul 2021 01:24:09 +0200

+1 on all below.

On 27.07.21 01:00, Salz, Rich wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 26 Jul 2021 21:21:05 -0400

I have read the draft, as well the meeting materials from IETF 111 [1], and
I do not support adoption.

Explicitly, I do not believe it furthers its stated goal of promoting
interoperability.

The existing set of IANA-assigned EKUs [2] have a practical
correspondence to IETF-defined protocols:
* id-kp-serverAuth corresponds to the TLS protocol (RFC 8446), typically
combined with HTTP (RFC 7231) as further expanded by RFC 6125
* id-kp-OCSPSigning corresponds to the OCSP protocol (RFC 6960)
* id-kp-timeStamping corresponds to the use of the Time Stamp Protocol (RFC
3161)
* id-kp-emailProtection corresponds to the use of CMS (RFC 5652) as used by
S/MIME (RFC 8551)

The current draft [3] fails to properly justify the need for an
IANA-defined EKU within introduction, and fails to define any practical
protocol that this key usage should be bound to. It intentionally and
explicitly leaves it ambiguous on the appropriateness or inappropriateness
of its use, and thus fails to provide any interoperable value. The draft
suggests that there is value in assigning from the IANA arc, but fails to
provide any practical or technical justification to that effect.

These are, I believe, blockers towards the adoption of the work: Without a
clear justification that both informs the goal and the potential scope of
work, I do not believe the draft should be adopted as a work item for the
WG.

At its core, the value provided for this EKU is to indicate a
locally-interpreted meaning which lacks interoperability, namely:
"Inclusion of this KeyPurposeId in a certificate indicates that the use of
any Subject names in the certificate is restricted to use by a document
signing service or a software". That is, it seeks to assign semantic
meaning to an area subject to local policy (e.g. a naming authority). Using
a policy OID appropriate for the local naming authority is entirely
appropriate and suitable, but a generic OID to indicate a certificate is
subject to "a" naming authority is not valuable in and of itself.

[1]
https://datatracker.ietf.org/meeting/111/materials/slides-111-lamps-sessa-general-purpose-eku-for-document-signing-00
[2]
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3
[3] https://datatracker.ietf.org/doc/html/draft-ito-documentsigning-eku-01

On Mon, Jul 26, 2021 at 6:13 PM Russ Housley <[email-masked]> wrote:

> We have already discussing the assignment of an object identifier for
> document signing, and we had a presentation at IETF 111.  Following the
> IETF 111 presentation, no one spoke against against adoption of this work.
> This call is to see if there is rough consensus for the LAMPS WG to proceed
> with this work.
>
> Please send your reply about whether you support adopting
> draft-ito-documentsigning-eku as a WG document.  Please voice your support
> or raise concerns by 14 August 2021.
>
> For the LAMPS WG Chairs,
> Russ

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Jul 2021 17:43:46 +0200

Hi,

We should separate two different arguments you are making.

 1. Whether the IETF is the right forum to allocate an OID in one of its
    own arcs
 2. Whether the document is clear enough to be used properly.

Taken in reverse order, the document needs to be clear as to when this 
particular EKU MUST and MUST NOT be used.  I agree with Ryan Sleevi that 
the document could do a better job in explaining this, but for a number 
of reasons, I still support.  In the IETF we ourselves have overloaded 
id-kp-emailProtection at least in part because the other alternative – 
id-kp-codeSigning – is more expensive to deploy.  It is simply *not* 
practical to support gazillions of EKUs.  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”.

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.  What is required is understanding of the lack of 
semantic claims over such a generic signature.

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.

Eliot

On 27.07.21 03:21, Ryan Sleevi wrote:
> I have read the draft, as well the meeting materials from IETF 111 
> [1], and I do not support adoption.
>
> * id-kp-serverAuth corresponds to the TLS protocol (RFC 8446), 
> typically combined with HTTP (RFC 7231) as further expanded by RFC 6125
> * id-kp-timeStamping corresponds to the use of the Time Stamp Protocol 
> (RFC 3161)
> * id-kp-emailProtection corresponds to the use of CMS (RFC 5652) as 
> used by S/MIME (RFC 8551)
>
> IANA-defined EKU within introduction, and fails to define any 
> practical protocol that this key usage should be bound to. It 
> intentionally and explicitly leaves it ambiguous on the 
> appropriateness or inappropriateness of its use, and thus fails to 
> provide any interoperable value. The draft suggests that there is 
> value in assigning from the IANA arc, but fails to provide any 
> practical or technical justification to that effect.
>
> These are, I believe, blockers towards the adoption of the work: 
> Without a clear justification that both informs the goal and the 
> potential scope of work, I do not believe the draft should be adopted 
> as a work item for the WG.
>
> "Inclusion of this KeyPurposeId in a certificate indicates that the 
> use of any Subject names in the certificate is restricted to use by a 
> document signing service or a software". That is, it seeks to assign 
> semantic meaning to an area subject to local policy (e.g. a naming 
> authority). Using a policy OID appropriate for the local naming 
> authority is entirely appropriate and suitable, but a generic OID to 
> indicate a certificate is subject to "a" naming authority is not 
> valuable in and of itself.
>
> [1] 
> <https://datatracker.ietf.org/meeting/111/materials/slides-111-lamps-sessa-general-purpose-eku-for-document-signing-00>
> [2] 
> <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3>
> [3] 
> https://datatracker.ietf.org/doc/html/draft-ito-documentsigning-eku-01 
> <https://datatracker.ietf.org/doc/html/draft-ito-documentsigning-eku-01>
>
> On Mon, Jul 26, 2021 at 6:13 PM Russ Housley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     We have already discussing the assignment of an object identifier
>     for document signing, and we had a presentation at IETF 111.
>     Following the IETF 111 presentation, no one spoke against against
>     adoption of this work.  This call is to see if there is rough
>     consensus for the LAMPS WG to proceed with this work.
>
>     draft-ito-documentsigning-eku as a WG document.  Please voice your
>     support or raise concerns by 14 August 2021.
>
>     For the LAMPS WG Chairs,
>     Russ
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/spasm>
>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 27 Jul 2021 12:18:17 -0400

On Tue, Jul 27, 2021 at 11:44 AM Eliot Lear <[email-masked]> 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.

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 27 Jul 2021 16:26:10 +0000

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 <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Date: Tuesday, July 27, 2021 at 12:19
To: Eliot Lear <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>, LAMPS WG <[email-masked]>, Russ Housley <[email-masked]>
Subject: Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

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:

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.

---

From: Tomofumi Okubo <[email-masked]>
Date: Tue, 27 Jul 2021 19:33:26 +0000

Thanks for the input Ryan.
We intend to add a section that addresses how the relying party can tell whether the EKU applies to a particular situation.
Cheers,
Tomofumi

From: Spasm <[email-masked]> On Behalf Of Ryan Sleevi
Sent: Wednesday, July 28, 2021 1:18 AM
To: Eliot Lear <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; LAMPS WG <[email-masked]>; Russ Housley <[email-masked]>
Subject: Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

On Tue, Jul 27, 2021 at 11:44 AM Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 27 Jul 2021 18:07:40 -0400

On Tue, Jul 27, 2021 at 3:33 PM Tomofumi Okubo <[email-masked]>
wrote:

> We intend to add a section that addresses how the relying party can tell
> whether the EKU applies to a particular situation.
>
> Cheers,
>
> Tomofumi
>

Will it resolve the charter issue? Am I mistaken in believing there is a
charter issue at play here?

---

From: Tomofumi Okubo <[email-masked]>
Date: Tue, 27 Jul 2021 22:31:26 +0000

Hello Ryan,

Yes we believe so.
The section will be referring to an existing RFC which is currently in use.
Our expectation is that it will serve as a concrete example for the usage of this EKU.
We will try to update the document as soon as possible.

Cheers!
Tomofumi

From: Ryan Sleevi <[email-masked]>
Sent: Wednesday, July 28, 2021 7:08 AM
To: Tomofumi Okubo <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; Eliot Lear <[email-masked]>; LAMPS WG <[email-masked]>; Russ Housley <[email-masked]>
Subject: Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

On Tue, Jul 27, 2021 at 3:33 PM Tomofumi Okubo <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the input Ryan.
We intend to add a section that addresses how the relying party can tell whether the EKU applies to a particular situation.
Cheers,
Tomofumi

Will it resolve the charter issue? Am I mistaken in believing there is a charter issue at play here?

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 27 Jul 2021 21:32:56 -0400

> The section will be referring to an existing RFC which is currently in use.
I eagerly anticipate waiting to see which part of the charter [1] you’re
proposing this new work item fits under.

I cannot help but still be concerned, despite the stated belief, that is is
a clear abrogation of the following language from the charter:

The LAMPS WG may produce
clarifications where needed, but the LAMPS WG shall not adopt
anything beyond clarifications without rechartering.

[1]
https://datatracker.ietf.org/wg/lamps/about/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Jul 2021 10:02:49 +0200

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.

Eliot

On 28.07.21 03:32, Ryan Sleevi wrote:
>
>
> On Tue, Jul 27, 2021 at 6:31 PM Tomofumi Okubo 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> I eagerly anticipate waiting to see which part of the charter [1] 
> you’re proposing this new work item fits under.
>
> I cannot help but still be concerned, despite the stated belief, that 
> is is a clear abrogation of the following language from the charter:
>
> The LAMPS WG may produce
> <https://datatracker.ietf.org/wg/lamps/about/>
>

---

From: Deb Cooley <[email-masked]>
Date: Wed, 28 Jul 2021 08:25:03 -0400

While I understand that relying parties often do not/cannot validate fields
like certificate policies, EKUs and even KUs.

I do, however, think it is important to have an EKU between
id-kp-emailProtection and id-kp-codeSigning.  Clearly the code signing EKU
is inappropriate for document signature, as is the email protection EKU.
There is currently no general purpose EKU for 'document' signing - however
'document' is defined (and I don't believe boiling the ocean is required
here).

If there are CAs that are issuing code signing EKUs to enable document
signing, I do take issue with that practice, it should not be condoned.
Code signing is an extremely sensitive function and the use of keys to do
this must be limited.

If there are multiple private EKUs for document signing, I also take issue
with that practice.  They just create silos and are a barrier to
interoperability.

As such, I am in favor of this draft.  Providing the authors can pin down
the definition in quick order.  Charters can be changed, I don't find that
to be a barrier per se.

Deb Cooley
[email-masked]

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

> On Tue, Jul 27, 2021 at 6:31 PM Tomofumi Okubo <
> [email-masked]> wrote:
>
> I cannot help but still be concerned, despite the stated belief, that is
> is a clear abrogation of the following language from the charter:
>
> The LAMPS WG may produce
> Spasm mailing [email-masked]://www.ietf.org/mailman/listinfo/spasm
>

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 28 Jul 2021 11:01:06 -0400

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

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Jul 2021 17:28:03 +0200

Hi Ryan,

I want to just address one point:

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

IMHO The issue at this stage is not whether the document at this point 
is well specified, but whether it *can* be well well specified by WG 
last call.  To reiterate, I agree with you that when you use and when 
you don't use this approach could be better specified, but that can 
happen as the normal part of draft development.

Eliot

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 28 Jul 2021 12:10:57 -0400

On Wed, Jul 28, 2021 at 11:01 AM Ryan Sleevi <[email-masked]> wrote:

> [5]
> https://mailarchive.ietf.org/arch/msg/pkix/c8aIik0B_7WOaBdGuiURrkvE_h0/
>

Sorry, bad paste buffer - this should have been the parent message,
https://mailarchive.ietf.org/arch/msg/pkix/tpTT2hAxqylJh56bTtY9hD1W6yk/ ,
which captures this past discussion about "EKU for industry" vs "EKU for
protocol"

---

From: Deb Cooley <[email-masked]>
Date: Wed, 28 Jul 2021 14:52:57 -0400

Just to push on this a little more (apologies).  What do you believe is the
correct path forward?  Abuse of the code signing EKU is worrying.

I'm with you on the 'there are a billion different issues' which interfere
w/ interoperability - algorithm suites, policy oids, KUs, EKUs, and lastly
the trust stores themselves.  Do we pitch it all out?  start over?   Is
there a better way?

I also struggle with 'if RPs don't parse certificate policies', then why do
we bother.  I usually get slapped by one of the authors of 5280 (I'll let
you guess which one) and one of my coworkers who understands why we have
these things.  KUs, EKUs fall into that same bucket, for me, at least.  It
is pretty much a constant struggle in my own mind - prolly more than you
needed to know about me.

Deb Cooley
[email-masked]

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 28 Jul 2021 15:39:54 -0400

On Wed, Jul 28, 2021 at 2:53 PM Deb Cooley <[email-masked]> wrote:

> Just to push on this a little more (apologies).  What do you believe is
> the correct path forward?  Abuse of the code signing EKU is worrying.
>

The context behind this request is the CA/Browser Forum is working to
specify S/MIME policies, and are similarly interested in fixing these
abuses. I am, without a doubt, 100% on board with this. I just see it as a
matter of domain-specific policy, rather than IETF coordination.

Concretely: I would see vendors that are targeting specific signature
protocols to have EKUs for those protocols. For example, ETSI ESI TC has a
suite of specifications that the European Union has granted the presumption
of legal recognition (in certain cases) or
mandatory-to-implement/interoperate assumptions (e.g. for public services).
These are PAdES, CAdES, XAdES, and collectively describe signature
requirements for PDF, CMS, and XML. Nothing would prevent ETSI ESI from
using its OID arc (0.4) to assign an EKU to indicate "Used in conjunction
with the ETSI ESI document signing specifications" - with the assumption
here is that ETSI ESI TC will ensure that these distinct formats do not
permit cross-format attacks that allow for confused deputy (of which there
have been many [1]).

In implementation practice, EKUs effectively operate as substitutes for
certificatePolicies. Whether we hate that or not - and the past debate has
been clear there's folks in both camps - that's the implementation reality.
For example, to have a certificate successfully validate with
'id-kp-serverAuth' on a macOS system, you need to comply with Apple's
certificate policies. This doesn't matter whether you're a CA included by
default in the OS, or something locally configured in the Enterprise: any
application using Apple's cryptographic libraries has to comply with the
policies if they assert the particular EKU, that EKU is required to use
their TLS client libraries, and that's a net-positive for users. [2].
Sometimes, these changes only apply to CAs included in their software by
default [3], but other times, it's system wide.

In practice, the EKU is used to indicate compliance, or non-compliance, to
a particular certificate profile, defined by the vendor of the relying
party application. This is true for major trust store vendors like
Microsoft, Apple, Google, Mozilla, and across different protocols: Google's
GMail has its policies [4], just like Adobe has their AATL [5]. The EKU is
enforced at the protocol level, but equally, it implies and reflects
compliance with policy.

In the browser space, the CA/Browser Forum exists to help coordinate the
interpretation of 'id-kp-serverAuth' as it applies to browsers, and to
reduce the risk of conflicts in those profile requirements. There's nothing
preventing similar groups - such as ETSI (in the case of the *AdES family)
or the CA/Browser Forum (in a hypothetical document signing chartered
working group) to do the same, with an EKU specific to their constituency
to reflect the "I intend to use it with this {protocol}, which has {these
policy assumptions in the PKI design}". Yes, in a perfect world, this would
have used certificatePolicies, with client libraries requiring end-entity
certificates asserting a particular policy, and validating that policy is
in the effective policy set, and that EKU is purely a protocol indicator:
but that's not the world we ended up at.

The issue with the IETF defining a generic EKU here is that we don't have a
"Document Signing Protocol WG" that defines the format and semantics of
what a signed document is, in the way we have a TLS WG or an IPSEC WG or a
Kerberos WG. Within those WGs, we do see efforts at preventing
cross-protocol and cross-format confusion, and we also see the use of
multiple certificates and keys when appropriate, and including new EKUs as
needed, when possible. For example, TLS Delegated Credentials work
proposes... an additional certificate for servers to obtain to express
further restrictions on private key usage [6]. This was due to needing to
work around the fact that few TLS client implementations outside of
browsers robustly support features like those in RFC 4158 [7], and the TLS
WG had to work around that legacy, as otherwise, EKU would have been
appropriate.

Concretely: ETSI could easily allocate OIDs for PAdES, CAdES, and XADeS. I
haven't done the protocol analysis to know if there's cross-format attacks,
so it could be three OIDs, or it could be a singular OID if they are
robustly secured, indicating compliance with the ETSI specifications and
the eIDAS policy framework. Adobe could similarly take a lead here, with
respect to PDF signing, and say "This EKU is used for PDFs according to
this {Adobe, ISO} specification and the AATL policy". If the CA/Browser
Forum was chartered for this (it presently is not, but that, like all
charters, is changable), it could also define an EKU to say "This EKU is
used in conjunction with {these document signing protocols} and the
CA/Browser Forum policy". CAs that, say, meet the requirements of all three
organizations, could easily assert all three EKUs in a single certificate,
provided that they (and relying parties) have analyzed for
cross-protocol/cross-format attacks. But we can't pretend they're the same
constituencies: even where there's overlap (and there's plenty of 2-of-3
and 3-of-3 overlap in these examples), they are still fundamentally
different use cases and policy authorities.

[1] https://pdf-insecurity.org/index.html
[2] https://support.apple.com/en-us/HT210176
[3] https://support.apple.com/en-us/HT211025
[4] https://support.google.com/a/answer/7300887?hl=en
[5] https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html
[6]
https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10#section-4.2
[7] https://datatracker.ietf.org/doc/html/rfc4158

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Jul 2021 17:13:37 -0400

After consultation with the Security AD for this group, a small recharter is necessary to adopt this document.

So, I amend this call for adoption as follows:

Please send your reply about whether you support adopting draft-ito-documentsigning-eku as a WG document after a recharter.  Please voice your support or raise concerns by 14 August 2021.

For the LAMPS WG Chairs,
Russ

> On Jul 26, 2021, at 6:13 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Jul 2021 23:18:16 +0200

I continue to support the work, and the recharter.

Eliot

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 28 Jul 2021 18:14:29 -0400

Russ,

I do not support adoption of this work.  A need has not been clearly demonstrated in the document.

Separately, and not related to adoption, the document is technically erroneous, flawed and incomplete.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Wednesday, July 28, 2021 5:18 PM
To: Russ Housley <[email-masked]>; LAMPS WG <[email-masked]>
Subject: Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

Eliot

---

From: Deb Cooley <[email-masked]>
Date: Wed, 28 Jul 2021 20:43:51 -0400

Thanks for that. I'd be lying if I said I'd read all the references....

I'm not sure that we (by this I mean US DOD) need this per se, at least
I've not heard it asked for.  I suspect we (again DOD) are doing this today
merely w/ the DS KU (and maybe a timestamp piece).

What I'd really like to avoid is to have to add a bazillion EKUs to a
signing certificate just to handle Adobe, or whatever the application is du
jour.  I know that some people like to make this complicated, but I'd
really like it to be easy to understand (I know, stop laughing, we are well
past that point).

I guess that makes two things that worry me -
1.  mis-use of the code signing EKU (which certainly doesn't have a working
group or RFC to define it either) and
2.  having to deal w/ a bazillion EKUs because US DOD uses every blasted
application in the world (maybe I'll retire before then).

Deb Cooley
[email-masked]

On Wed, Jul 28, 2021 at 3:40 PM Ryan Sleevi <[email-masked]> wrote:

> The issue with the IETF defining a generic EKU here is that we don't have
> a "Document Signing Protocol WG" that defines the format and semantics of

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 29 Jul 2021 15:54:26 +0000

You’re in a very good company! 😉

What I'd really like to avoid is to have to add a bazillion EKUs to a signing certificate just to handle Adobe, or whatever the application is du jour.  I know that some people like to make this complicated, but I'd really like it to be easy to understand (I know, stop laughing, we are well past that point).

I think adding “too many” EKUs is the surest road to disaster, far worse than any potential “cross-format risk”.

1.  mis-use of the code signing EKU (which certainly doesn't have a working group or RFC to define it either) and

2.  having to deal w/ a bazillion EKUs because US DOD uses every blasted application in the world (maybe I'll retire before then). 

I concur, though I’m not as worried about code signing EKU misuse. After all, if an authority does not want a particular class of certificates used for code signing – don’t add the code-signing EKU to its template. Sounds fairly simple.

“A bazillion of EKUs” is a much greater risk, in my opinion. Which I’d like to avoid at all costs. 

Thanks

 

Just to push on this a little more (apologies).  What do you believe is the correct path forward?  Abuse of the code signing EKU is worrying.

The context behind this request is the CA/Browser Forum is working to specify S/MIME policies, and are similarly interested in fixing these abuses. I am, without a doubt, 100% on board with this. I just see it as a matter of domain-specific policy, rather than IETF coordination.

Concretely: I would see vendors that are targeting specific signature protocols to have EKUs for those protocols. For example, ETSI ESI TC has a suite of specifications that the European Union has granted the presumption of legal recognition (in certain cases) or mandatory-to-implement/interoperate assumptions (e.g. for public services). These are PAdES, CAdES, XAdES, and collectively describe signature requirements for PDF, CMS, and XML. Nothing would prevent ETSI ESI from using its OID arc (0.4) to assign an EKU to indicate "Used in conjunction with the ETSI ESI document signing specifications" - with the assumption here is that ETSI ESI TC will ensure that these distinct formats do not permit cross-format attacks that allow for confused deputy (of which there have been many [1]).

In implementation practice, EKUs effectively operate as substitutes for certificatePolicies. Whether we hate that or not - and the past debate has been clear there's folks in both camps - that's the implementation reality. For example, to have a certificate successfully validate with 'id-kp-serverAuth' on a macOS system, you need to comply with Apple's certificate policies. This doesn't matter whether you're a CA included by default in the OS, or something locally configured in the Enterprise: any application using Apple's cryptographic libraries has to comply with the policies if they assert the particular EKU, that EKU is required to use their TLS client libraries, and that's a net-positive for users. [2]. Sometimes, these changes only apply to CAs included in their software by default [3], but other times, it's system wide.

In practice, the EKU is used to indicate compliance, or non-compliance, to a particular certificate profile, defined by the vendor of the relying party application. This is true for major trust store vendors like Microsoft, Apple, Google, Mozilla, and across different protocols: Google's GMail has its policies [4], just like Adobe has their AATL [5]. The EKU is enforced at the protocol level, but equally, it implies and reflects compliance with policy.

In the browser space, the CA/Browser Forum exists to help coordinate the interpretation of 'id-kp-serverAuth' as it applies to browsers, and to reduce the risk of conflicts in those profile requirements. There's nothing preventing similar groups - such as ETSI (in the case of the *AdES family) or the CA/Browser Forum (in a hypothetical document signing chartered working group) to do the same, with an EKU specific to their constituency to reflect the "I intend to use it with this {protocol}, which has {these policy assumptions in the PKI design}". Yes, in a perfect world, this would have used certificatePolicies, with client libraries requiring end-entity certificates asserting a particular policy, and validating that policy is in the effective policy set, and that EKU is purely a protocol indicator: but that's not the world we ended up at.

The issue with the IETF defining a generic EKU here is that we don't have a "Document Signing Protocol WG" that defines the format and semantics of what a signed document is, in the way we have a TLS WG or an IPSEC WG or a Kerberos WG. Within those WGs, we do see efforts at preventing cross-protocol and cross-format confusion, and we also see the use of multiple certificates and keys when appropriate, and including new EKUs as needed, when possible. For example, TLS Delegated Credentials work proposes... an additional certificate for servers to obtain to express further restrictions on private key usage [6]. This was due to needing to work around the fact that few TLS client implementations outside of browsers robustly support features like those in RFC 4158 [7], and the TLS WG had to work around that legacy, as otherwise, EKU would have been appropriate.

Concretely: ETSI could easily allocate OIDs for PAdES, CAdES, and XADeS. I haven't done the protocol analysis to know if there's cross-format attacks, so it could be three OIDs, or it could be a singular OID if they are robustly secured, indicating compliance with the ETSI specifications and the eIDAS policy framework. Adobe could similarly take a lead here, with respect to PDF signing, and say "This EKU is used for PDFs according to this {Adobe, ISO} specification and the AATL policy". If the CA/Browser Forum was chartered for this (it presently is not, but that, like all charters, is changable), it could also define an EKU to say "This EKU is used in conjunction with {these document signing protocols} and the CA/Browser Forum policy". CAs that, say, meet the requirements of all three organizations, could easily assert all three EKUs in a single certificate, provided that they (and relying parties) have analyzed for cross-protocol/cross-format attacks. But we can't pretend they're the same constituencies: even where there's overlap (and there's plenty of 2-of-3 and 3-of-3 overlap in these examples), they are still fundamentally different use cases and policy authorities.

[6] https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10#section-4.2

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 14:04:22 -0400

On Thu, Jul 29, 2021 at 11:54 AM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> “A bazillion of EKUs” is a *much* greater risk, in my opinion. Which I’d
> like to avoid *at all costs*.
>

Since the scenario here is largely hyperbolic, entirely unrealistic, and I
think reflects a misunderstanding of the proposal, perhaps you can clarify:

Do you share the same concerns regarding certificatePolicies?

---

From: Carl Wallace <[email-masked]>
Date: Thu, 29 Jul 2021 14:18:47 -0400

On Thu, Jul 29, 2021 at 11:54 AM Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:

Since the scenario here is largely hyperbolic, entirely unrealistic, and I think reflects a misunderstanding of the proposal, perhaps you can clarify:

[CW] Isn’t this apples and oranges given there is nothing like user-initial-policy-set for EKU? Maybe there should have been, but there wasn’t.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 29 Jul 2021 18:36:56 +0000

> Since the scenario here is largely hyperbolic, entirely unrealistic, 

I think it’s very realistic, and only mildly hyperbolic. What I do think is hyperbolic and not entirely realistic is your concern of cross-format threats.

>  .  .  .  and I think reflects a misunderstanding of the proposal, perhaps you can clarify:

> Do you share the same concerns regarding certificatePolicies? 

As a matter of fact, I do not [share the same concerns], and here’s why:

KU usually is marked Critical, and everybody is expected to correctly grok it or die;
EKU is sometimes marked Critical, and everybody should grok it correctly – there’s reasonably small set of them, covering reasonable expected use cases;
Certificate policies are rarely marked Critical, they cover <whatever>, very often admin domain-specific, and if an app cannot grok it – the common practice is “just ignore and proceed”.

I would hate to see EKU proliferating in quantity and “degrading” in quality to the point of “I don’t really care …”

For me and my use cases it is very convenient to distinguish a cert for authenticating from a cert for signing documents and/or emails, but absolutely counter-productive to go OCD-route and distinguishing between signing PDF, signing Word, signing XML, signing ROT-13… Plus, as I said earlier – my use case involves hardware tokens that have only one certificate slot for Digital Signature. In theory I could load that one cert with 2KB of EKUs, but it makes zero sense.

It looks to me like there are organizations that have very narrow use cases, e.g., just signing PDF – and they’d like to be able to set one EKU on a single cert that they want to issue, to do exactly that and nothing more. I can understand that.

There are other organizations whose use cases are broader than the above. Their options are: (a) EKUs that are not “too narrow”, (b) cram signing cert with a ton of EKUs to address all the use cases, and (c) issue a ton of certs, each for specific use case. It seems that the preference of the majority is (a), and for a good practical reason. As I explained earlier, cert management is costly.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 16:14:27 -0400

On Thu, Jul 29, 2021 at 2:18 PM Carl Wallace <[email-masked]>
wrote:

> [CW] Isn’t this apples and oranges given there is nothing like
> user-initial-policy-set for EKU? Maybe there should have been, but there
> wasn’t.
>

No.

It's a fair comparison for two points:

1) The concern about multiple certificates (with different EKUs) is just as
applicable to multiple certificates (with different certificate policies).
That is, if we accept certificatePolicies as designed (e.g. with
user-initial-policy-set used by relying parties), then we're implicitly
saying we accept multiple certificates. I'm aware of policyMappings as a
way to try to reduce that, but that doesn't remove the multiple
certificates risk. So if that's the angst for Uri, then it's an entirely
unreasonable position to hold in light of RFC 5280.

2) The point is that, as widely implemented (e.g. in virtually every modern
OSS library, as well as the widely used OS libraries), EKU functionally
behaves as the user-initial-policy-set for the relying party application.
That is, the industry has *not* widely adopted certificatePolicies for this
purpose, and has long used EKU - predating the work of PKIX itself,
initially through custom vendor-specific extensions (Netscape and
Microsoft, respectively), and then through EKU. The "rough consensus and
running code", as it were, already uses EKU as this set.

So that's why the comparison here: We can disagree on abstract spec purism,
but that doesn't reflect the implemented reality, and an argument against
EKUs for fear of multiple certificates is logically inconsistent with the
very design of RFC 5280, and so is equally irrational. If
certificatePolicies are accepted as a RP-specific community attribute, then
EKU poses no further additional risk for proliferation than
certificatePolicies. And if they're somehow rejected, that's logically
consistent a position, but inconsistent with the specification and reality.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 16:16:26 -0400

On Thu, Jul 29, 2021 at 2:37 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

>    - *KU* usually is marked Critical, and *everybody* is expected to
>    correctly grok it or die;
>    - *EKU* is *sometimes* marked Critical, and everybody *should* grok it
>    correctly – there’s reasonably small set of them, covering *reasonable*
>    expected use cases;
>    - *Certificate policies* are *rarely* marked Critical, they cover
>    <whatever>, very often admin domain-specific, and if an app cannot grok it
>    – the common practice is “just ignore and proceed”.
>
> This is not an accurate reflection of what EKU is, then. This at least
helps me understand the disconnect, which is a misunderstanding about EKU
and its semantics, at least in terms of what implementation reality
reflects.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 29 Jul 2021 16:27:28 -0400

<snip>

2) The point is that, as widely implemented (e.g. in virtually every modern OSS library, as well as the widely used OS libraries), EKU functionally behaves as the user-initial-policy-set for the relying party application. That is, the industry has not widely adopted certificatePolicies for this purpose, and has long used EKU - predating the work of PKIX itself, initially through custom vendor-specific extensions (Netscape and Microsoft, respectively), and then through EKU. The "rough consensus and running code", as it were, already uses EKU as this set.

So that's why the comparison here: We can disagree on abstract spec purism, but that doesn't reflect the implemented reality, and an argument against EKUs for fear of multiple certificates is logically inconsistent with the very design of RFC 5280, and so is equally irrational. If certificatePolicies are accepted as a RP-specific community attribute, then EKU poses no further additional risk for proliferation than certificatePolicies. And if they're somehow rejected, that's logically consistent a position, but inconsistent with the specification and reality.

[CW] Then write *that* spec so that we cut out the folklore stuff and all work from the same sheet of music. It’s not abstract spec “purism”, it’s what the spec says. Make it say something different.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 29 Jul 2021 20:45:42 +0000

· KU usually is marked Critical, and everybody is expected to correctly grok it or die;

· EKU is sometimes marked Critical, and everybody should grok it correctly – there’s reasonably small set of them, covering reasonable expected use cases;

· Certificate policies are rarely marked Critical, they cover <whatever>, very often admin domain-specific, and if an app cannot grok it – the common practice is “just ignore and proceed”.

This is not an accurate reflection of what EKU is, then. This at least helps me understand the disconnect, which is a misunderstanding about EKU and its semantics, at least in terms of what implementation reality reflects.

OK, fair enough. While I’d argue about which (or whose 😊) view is a “misunderstanding” of what EKU is, the fact is that our visions re. what EKU is and how/what-for it is used, differ.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 17:04:08 -0400

On Thu, Jul 29, 2021 at 4:27 PM Carl Wallace <[email-masked]>
wrote:

> [CW] Then write **that** spec so that we cut out the folklore stuff and
> all work from the same sheet of music. It’s not abstract spec “purism”,
> it’s what the spec says. Make it say something different.
>

Check the footnotes in
https://mailarchive.ietf.org/arch/msg/spasm/bV34V37xxxuHhbR85qR1NG47gq0/ to
see how well that's been received in LAMPS/PKIX previously.

The resistance to updating the spec to match widely-deployed reality is
real, unfortunately, but that doesn't change what implementations have been
doing for the past 25 years and will continue to do.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 29 Jul 2021 17:27:15 -0400

Sure but given cert lifetime management is relatively tight now and the implementations you likely care about more easily updated, EKU2 could be written to match reality and be deployed without glacial delay. You’d just need a new OID and some processing language. 

> On Jul 29, 2021, at 5:04 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> 
> 
>> On Thu, Jul 29, 2021 at 4:27 PM Carl Wallace <[email-masked]> wrote:
> Check the footnotes in https://mailarchive.ietf.org/arch/msg/spasm/bV34V37xxxuHhbR85qR1NG47gq0/ to see how well that's been received in LAMPS/PKIX previously.
> 
> The resistance to updating the spec to match widely-deployed reality is real, unfortunately, but that doesn't change what implementations have been doing for the past 25 years and will continue to do.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 17:31:26 -0400

On Thu, Jul 29, 2021 at 5:27 PM Carl Wallace <[email-masked]>
wrote:

> Sure but given cert lifetime management is relatively tight now and the
> implementations you likely care about more easily updated, EKU2 could be
> written to match reality and be deployed without glacial delay. You’d just
> need a new OID and some processing language.
>

I may be misunderstanding, but that seems to be just saying "Ah, but if you
can't spec the existing, widely implemented behaviour, which fully conforms
to the spec, you should change all the implementations to a new behaviour
that does the exact same thing as the existing behaviour, and maybe you can
spec it then"

Everything I've stated about EKU on this thread is both fully consistent
with RFC 5280 _and_ fully consistent with 20 years of discussion in
PKIX/LAMPS, as to why I don't support this draft. I'm unclear if you're
saying that, however true that may be, every implementation should change,
in order to make some vocal folks in this WG... happy?

---

From: Carl Wallace <[email-masked]>
Date: Thu, 29 Jul 2021 17:49:39 -0400

On Thu, Jul 29, 2021 at 5:27 PM Carl Wallace <[email-masked]> wrote:

I may be misunderstanding, but that seems to be just saying "Ah, but if you can't spec the existing, widely implemented behaviour, which fully conforms to the spec, you should change all the implementations to a new behaviour that does the exact same thing as the existing behaviour, and maybe you can spec it then"

Everything I've stated about EKU on this thread is both fully consistent with RFC 5280 _and_ fully consistent with 20 years of discussion in PKIX/LAMPS, as to why I don't support this draft. I'm unclear if you're saying that, however true that may be, every implementation should change, in order to make some vocal folks in this WG... happy?

[CW] I am also not saying anything to make “vocal folks” happy but instead am saying a spec for each camp might be the best way. At least then the situation would be documented. Without two specs there is only perpetual “widely implemented” vs “documented”. Who does that serve? A spec for each camp worked for cert enrollment protocols:-) Note, I am not against changing the current definition, but don’t much care for folklore.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 30 Jul 2021 14:37:33 +0000

This is tougher than I thought. Ryan has more in-the-trenches experience with these things than most, and perhaps more than most of us combined. On the other hand, defining an EKU is pretty small potatoes, and there's likely not to be much cost to the s/w stacks because they already have to make the cert, ku, eku available to the application anyway. On the third hand, the idea of CABforum starting to address email worries me -- will membership open up to allow email app providers? I guess that's really not our concern.

So I support changing the charter and adopting this.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 30 Jul 2021 12:02:53 -0400

On Fri, Jul 30, 2021 at 10:37 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> This is tougher than I thought. Ryan has more in-the-trenches experience
> with these things than most, and perhaps more than most of us combined. On
> the other hand, defining an EKU is pretty small potatoes, and there's
> likely not to be much cost to the s/w stacks because they already have to
> make the cert, ku, eku available to the application anyway.

The only value, for the stated goal, however, is if applications check
this. That's why the most relevant feedback is not from e-mail app
providers (which already check for emailProtection), or from TLS client
libs (which already check for id-kp-serverAuth), but from those that are
consuming digital signatures. This is why I suggested ETSI is wholly
appropriate if they wanted to specify an EKU for their specifications (as
the misuse of emailProtection is primarily coming from European CAs
targeting European relying parties implementing ETSI ESI specifications).
And, by and large, these apps aren't checking EKU at all - that is, they'd
be perfectly fine validating a document signed with a TLS certificate, if a
CA issued such a certificate. So the CA using a different EKU provides no
value without the relying party apps changing, and if you can identify who
that constituency is (of app implementors), you've necessarily identified
who can and should just get an EKU for their constituency.

This is why I'm trying to flag "implementor interest" is both critical, and
absent, for achieving the stated goals.

> On the third hand, the idea of CABforum starting to address email worries
> me -- will membership open up to allow email app providers? I guess that's
> really not our concern.
>

Yes, it already is, and yes, it should worry you :)

The CA/Browser Forum has two other Chartered WGs, and participation in
either CWG (as with TLS) allows participation in the overall CA/B Forum
(although not necessarily other CWGs)
- https://cabforum.org/working-groups/smime-certificate-wg/ (For e-mail app
providers)
- https://cabforum.org/code-signing-working-group/ (Effectively, the
Microsoft Code Signing WG)

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 30 Jul 2021 16:40:47 +0000

> This is tougher than I thought.

It does seem tough enough.

> Ryan has more in-the-trenches experience with these things than most,
> and perhaps more than most of us combined. 

I wouldn't bet on it. ;-)

> On the other hand, defining an EKU is pretty small potatoes, and there's likely not to be much cost
> to the s/w stacks because they already have to make the cert, ku, eku available to the application anyway. 

This is where one disconnect is. 

Merely *defining* an EKU is cheap. The cost to the s/w stacks is negligible, as far as I'm concerned.

The real cost is in the certificate management. 

And [in]ability of principals to carry multiple certs. E.g., think of how many Signature certs PIV or CAC token can have.

> On the third hand, the idea of CABforum starting to address email worries me -- will membership
> open up to allow email app providers? I guess that's really not our concern.

It may well become one.

> So I support changing the charter and adopting this.

I do not know. I don't support it, but I'm not violently opposing it.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jul 2021 19:47:07 -0400

Russ Housley <[email-masked]> wrote:
    > After consultation with the Security AD for this group, a small
    > recharter is necessary to adopt this document.

    > draft-ito-documentsigning-eku as a WG document after a recharter.
    > Please voice your support or raise concerns by 14 August 2021.

I agree with the change.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide