Subject: Re: [lamps] The problem with EKU for document signing demonstrated

From: Stefan Santesson <[email-masked]>
Date: Wed, 1 Dec 2021 17:47:28 +0100

I'm not sure I'm able to follow you fully Ryan.

What I say basically is that a standard defining an EKU can only define
what that EKU means (what type of usage that matches this EKU), within
the context of RFC 5280 definition of EKU.

Any requirements on when it must be included etc must be defined in a
protocol standard or specification that can make such claims.
Consequently such requirements then only apply to those who have agreed
to follow that standard or specification.

This EKU draft therefore cannot state a requirement on what verifiers
MUST do when this EKU is not present, simply because all users of
Certificates and EKUs are not bound by this document.

For me that is obvious and not even up for debate. Its just how things
work. I hope we agree on that.

/Stefan

On 2021-11-30 20:13, Ryan Sleevi wrote:
>
>
> On Tue, Nov 30, 2021 at 2:16 AM Stefan Santesson <[email-masked]>
> wrote:
>
>     1) One or more EKU = Restricted to those usages
>
>     2) One or more EKU + anyExtendedKeyUsage = Suitable for the listed
>     usages but MAY be used for any purpose
>
>     3) No EKU = Unrestricted.
>
>
>     This means that case 2 can be suitable for document signing at the
>     discretion of the verifier and case 3 is suitable for document
>     signing. No EKU definition can change that.
>
> I must be missing something, because RFC 5280 seems quite clear that a
> verifier may choose to reject Option 3, and it equally acknowledges
> further specs can profile things down, including requiring the
> explicit EKU (rejecting anyEKU).
>
> That is, Option 1 has always been how RFC 5280 is defined, and it
> offers anyEKU as an optional relaxation of that, but not the default.
> It’s true that for X.509v1 comparability, verifiers had to deal with
> the absence of this, but it’s very clear from the contemporary
> discussion and the spec that the proposed restriction is exactly what
> was envisaged.
>
>     There simply is no place for your broad claim that: "Clients MUST
>     reject documents signed by certificates without this EKU, except
>     if being operated in a legacy-compatibility mode."
>
> I’m not sure what’s meant by “broad claim.” This was meant as specific
> language proposed to be added. It’s unclear if you disagree on the
> technical merits of that, such as why cross-protocol protection is
> useful or how and why EKUs are specified, or if you were pointing out
> that it’s not (currently) in the text.
>
>     The only way you can change this is by defining a new protocol for
>     document signing that requires this EKU. But no such generic
>     standard for document signing exists where such requirement could
>     be stated. And it would still just affect those who operate under
>     the context of that standard.
>
> This call for adoption is exactly that though: defining a spec that
> says “this is the EKU and this is what it means” (i.e. defining a
> protocol). Which is precisely why I was proposing such text be
> considered, because I think we’d both agree that it dramatically
> affects the scope.
>
> We should only define an EKU if we’re defining a protocol. This was
> the essence of my previous remarks on the earlier draft. At that time,
> it didn’t really define anything of a protocol, and so defining an EKU
> makes no sense. Now, it proposes a bit more of a protocol (hi there,
> CMS), which makes it less objectionable and more concrete. That’s why
> I’m uncertain why you seem to be foreclosing on this necessary step of
> defining the protocol.
>
>     This is what makes document signing fundamentally different from,
>     say TLS client auth. or Timestamping. In those cases we have
>     distinct standards that can state requirement on the presence of
>     an EKU.
>
> This may be the source of my disconnect. In the past, the IETF
> documents defining a protocol have generally defined the EKU (such as
> OCSP), or dealt with unimplementable messiness (such as IPSec). 
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3
> shows that it’s perfectly normal to define the protocol with the EKU.
>
> Here, the task for “protocol” is quite simple:
>
> 1. What are you signing? This was my complaint with -00. -02’s Section
> 4 tries to answer that by saying “CMS”. I don’t feel strongly on this
> - it’s perfectly fine to say X or Y or Z, as long as we’re confident
> that these are all distinguishable in context, which means being
> explicit and precise about what is permitted.
>
> 2. How should clients process these certificates? These are your
> general “security considerations” that bear reiterating 20+ year old
> good and recognized practices [1], like encouraging separation of
> protocols/EKUs and encouraging clients to make sure that the protocol
> was explicitly authorized vs confused deputy. It’s also where you can
> define any particular certificate profile restrictions or issuance
> practices, which can affect the security of the protocol.
>
> These seem the minimally necessary bits to define an EKU, which
> requires defining a base protocol.
>
> Going back to your original message and concerns, I get the feeling
> you disagree with 2 being necessary, or even appropriate. While there
> have been varying explanations, such as having to deal with compat
> issues, or that it’s incompatible with how EKU is defined, I hope I’ve
> shown these aren’t actually issues.
>
> The latest explanation seems to be that document signing isn’t and
> can’t be a protocol, because it’s too broad a concept, but the very
> purpose of an EKU is to narrow that broadness down to a protocol, so
> this feels a bit circular. I’m not trying to misrepresent, but it just
> seems to me we’ve shifted explanations, so if there’s something
> connecting these concerns, I’m probably missing it.
>
> [1] 
> https://marc.info/?l=ipsec&m=93372705705184&w=2
> <https://marc.info/?l=ipsec&m=93372705705184&w=2>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 1 Dec 2021 12:57:32 -0500

On Wed, Dec 1, 2021 at 11:47 AM Stefan Santesson <[email-masked]> wrote:

> what that EKU means (what type of usage that matches this EKU), within the
> context of RFC 5280 definition of EKU.
>
>
> protocol standard or specification that can make such claims. Consequently
> such requirements then only apply to those who have agreed to follow that
> standard or specification.
>
> This EKU draft therefore cannot state a requirement on what verifiers MUST
> do when this EKU is not present, simply because all users of Certificates
> and EKUs are not bound by this document.
>
We don't agree, and I don't think your description of how things works
aligns, as I tried to previously demonstrate through IETF examples.

It would appear you see there being two distinct RFCs - one document
defining an EKU and another defining its use. However, this separation is
not only not necessary, but it's inconsistent with past IETF practice: it
shows up only in failures (e.g. the IPSEC EKUs), not success (e.g. OCSP
EKU).

Specifically: I'm saying a single document is responsible for defining the
protocol standard _and_ the EKU. That's exactly how EKU was designed and
intended, and happy to continue to provide historically contemporary
explanations of this, to show that it was well understood at the time.
Consequently, a document defining an EKU is perfectly fine to set
conditions on when and how that EKU is present and processed. Not only is
it perfectly fine, but I'm arguing it's inherently necessary in order to
achieve the goal of having a defined EKU in the first place.

Thus, this document can precisely define what to do what a verifier, which
supports this document (and EKU), encounters a certificate that signs some
particular data of interest (e.g. a CMS "document"), and lacks this EKU.
Conformance is to this document - the one defining the EKU and how to
process it.

It's certainly true that there's zero requirement that can be placed on an
implementation that ignores this EKU. That is, a verifier that does not
claim to support this (draft, standard) will not process the certificate as
defined in this (draft, standard). We don't disagree there. But that
doesn't mean that the (draft, standard) can't place requirements on those
that do support it, such as saying that they MUST NOT accept certificates
that lack this EKU (except where trying to deal with a legacy transition).

It would seem you're saying "We can't place requirements on those that
don't implement this document, therefore we shouldn't place requirements on
those that do", and that's what I don't understand. That's not how things
have ever worked.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 1 Dec 2021 20:47:16 +0100

Ryan,

I assume the current scope of the draft:

"This document defines a general Document Signing extended key usage."

Besides, I challenge you to come up with a scope of a standard that will
create the effect on the market that you envision. Until that is adopted
by this work, I will assume the current scope.

/Stefan

On 2021-12-01 18:57, Ryan Sleevi wrote:
>     What I say basically is that a standard defining an EKU can only
>     define what that EKU means (what type of usage that matches this
>     EKU), within the context of RFC 5280 definition of EKU.
>
>
>     Any requirements on when it must be included etc must be defined
>     in a protocol standard or specification that can make such claims.
>     Consequently such requirements then only apply to those who have
>     agreed to follow that standard or specification.
>
>     This EKU draft therefore cannot state a requirement on what
>     verifiers MUST do when this EKU is not present, simply because all
>     users of Certificates and EKUs are not bound by this document.
>
>     For me that is obvious and not even up for debate. Its just how
>     things work. I hope we agree on that.
>
> defining an EKU and another defining its use. However, this separation
> is not only not necessary, but it's inconsistent with past IETF
> practice: it shows up only in failures (e.g. the IPSEC EKUs), not
> success (e.g. OCSP EKU).
>
> Specifically: I'm saying a single document is responsible for defining
> the protocol standard _and_ the EKU. That's exactly how EKU was
> designed and intended, and happy to continue to provide historically
> contemporary explanations of this, to show that it was well understood
> at the time. Consequently, a document defining an EKU is perfectly
> fine to set conditions on when and how that EKU is present and
> processed. Not only is it perfectly fine, but I'm arguing it's
> inherently necessary in order to achieve the goal of having a defined
> EKU in the first place.
>
> Thus, this document can precisely define what to do what a verifier,
> which supports this document (and EKU), encounters a certificate that
> signs some particular data of interest (e.g. a CMS "document"), and
> lacks this EKU. Conformance is to this document - the one defining the
> EKU and how to process it.
>
> It's certainly true that there's zero requirement that can be placed
> on an implementation that ignores this EKU. That is, a verifier that
> does not claim to support this (draft, standard) will not process the
> certificate as defined in this (draft, standard). We don't disagree
> there. But that doesn't mean that the (draft, standard) can't place
> requirements on those that do support it, such as saying that they
> MUST NOT accept certificates that lack this EKU (except where trying
> to deal with a legacy transition).
>
> don't implement this document, therefore we shouldn't place
> requirements on those that do", and that's what I don't understand.
> That's not how things have ever worked. 
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 1 Dec 2021 20:26:12 +0000

FWIW, in this argument I think Stefan's position and interpretation of RFC 5280 is correct (and Ryan's isn't), and reflects the real life state of affairs.

Regards,
Uri

> On Dec 1, 2021, at 14:48, Stefan Santesson <[email-masked]> wrote:
> 
> 
> Ryan,
> 
> Besides, I challenge you to come up with a scope of a standard that will create the effect on the market that you envision. Until that is adopted by this work, I will assume the current scope.
> 
> /Stefan
> 
> 
> 
>>> What I say basically is that a standard defining an EKU can only define what that EKU means (what type of usage that matches this EKU), within the context of RFC 5280 definition of EKU.
>>> 
>>> 
>>> 
>>> Any requirements on when it must be included etc must be defined in a protocol standard or specification that can make such claims. Consequently such requirements then only apply to those who have agreed to follow that standard or specification.
>>> 
>>> This EKU draft therefore cannot state a requirement on what verifiers MUST do when this EKU is not present, simply because all users of Certificates and EKUs are not bound by this document.
>>> 
>>> For me that is obvious and not even up for debate. Its just how things work. I hope we agree on that.
>>> 
>> We don't agree, and I don't think your description of how things works aligns, as I tried to previously demonstrate through IETF examples.
>> 
>> It would appear you see there being two distinct RFCs - one document defining an EKU and another defining its use. However, this separation is not only not necessary, but it's inconsistent with past IETF practice: it shows up only in failures (e.g. the IPSEC EKUs), not success (e.g. OCSP EKU).
>> 
>> Specifically: I'm saying a single document is responsible for defining the protocol standard _and_ the EKU. That's exactly how EKU was designed and intended, and happy to continue to provide historically contemporary explanations of this, to show that it was well understood at the time. Consequently, a document defining an EKU is perfectly fine to set conditions on when and how that EKU is present and processed. Not only is it perfectly fine, but I'm arguing it's inherently necessary in order to achieve the goal of having a defined EKU in the first place.
>> 
>> Thus, this document can precisely define what to do what a verifier, which supports this document (and EKU), encounters a certificate that signs some particular data of interest (e.g. a CMS "document"), and lacks this EKU. Conformance is to this document - the one defining the EKU and how to process it.
>> 
>> It's certainly true that there's zero requirement that can be placed on an implementation that ignores this EKU. That is, a verifier that does not claim to support this (draft, standard) will not process the certificate as defined in this (draft, standard). We don't disagree there. But that doesn't mean that the (draft, standard) can't place requirements on those that do support it, such as saying that they MUST NOT accept certificates that lack this EKU (except where trying to deal with a legacy transition).
>> 
>> It would seem you're saying "We can't place requirements on those that don't implement this document, therefore we shouldn't place requirements on those that do", and that's what I don't understand. That's not how things have ever worked. 
>> 
>>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Dec 2021 20:34:26 +0000

We can’t control what others do.  We can guide them to the right path. One way might be to add text into the draft which explains that this is covered by the general EKU processing rules in RFC 5280.

Another idea to consider is remove the change the sentence “This document defines a general Document Signing extended key usage” because it appears to be leading some, at least Stefan, into thinking that the draft allows implementors to ignore all context.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Dec 2021 15:43:11 -0500

I agree.  I would look at this RFC to define the OID and its processing rules for the RPs for the path as well as for end certificate and RP behavior when the extension is absent, has anyExtendedKeyUsage, has Adobe Document Signing, has Microsoft Document Signing, yada, yada, yada.

From: Spasm [mailto:[email-masked]] On Behalf Of Ryan Sleevi
Sent: Wednesday, December 1, 2021 12:58 PM
To: Stefan Santesson <[email-masked]>
Cc: David von Oheimb <[email-masked]>; Ryan Sleevi <[email-masked]>; Carl Wallace <[email-masked]>; Russ Housley <[email-masked]>; Mike Jenkins <[email-masked]>; [email-masked]; Uri Blumenthal <[email-masked]>
Subject: Re: [lamps] The problem with EKU for document signing demonstrated

On Wed, Dec 1, 2021 at 11:47 AM Stefan Santesson <[email-masked] <mailto:[email-masked]> > wrote:

---

From: Carl Wallace <[email-masked]>
Date: Wed, 01 Dec 2021 15:57:34 -0500

This gets at a good point with regards to adoption. Given the unpublished (?) “Microsoft rules” are prevalent for EKU processing, it’ll be a while before this EKU is in any wide use, which may assuage some of Stefan’s concern. Though I’ve no dog in this fight, I also agree with Ryan’s read re: reading of EKU-related verbiage.

From: Santosh Chokhani <[email-masked]>
Date: Wednesday, December 1, 2021 at 3:43 PM
To: 'Ryan Sleevi' <[email-masked]>, 'Stefan Santesson' <[email-masked]>
Cc: 'David von Oheimb' <[email-masked]>, 'Carl Wallace' <[email-masked]>, 'Russ Housley' <[email-masked]>, 'Mike Jenkins' <[email-masked]>, <[email-masked]>, 'Uri Blumenthal' <[email-masked]>
Subject: RE: [lamps] The problem with EKU for document signing demonstrated

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 1 Dec 2021 17:09:46 -0500

On Wed, Dec 1, 2021 at 3:57 PM Carl Wallace <[email-masked]>
wrote:

> This gets at a good point with regards to adoption. Given the unpublished
> (?) “Microsoft rules” are prevalent for EKU processing, it’ll be a while
> before this EKU is in any wide use, which may assuage some of Stefan’s
> concern. Though I’ve no dog in this fight, I also agree with Ryan’s read
> re: reading of EKU-related verbiage.
>

(For those following or searching the archives in 10 years), re: "Microsoft
rules", example past discussion at [1][2][3] provide more, and is something
shared by Microsoft, Netscape/Mozilla, Google and Apple products (although
only for TLS for Apple). From a 5280 perspective, it's "as if" the
client/RP has a policy requiring the presence of an EKU with a specific
value, just like RFC 5280 highlights as acceptable.

In practice, this means that the "ecosystem" adoption curve is the sum of:
1. The lifetime of existing (end-entity) certificates that don't conform to
this profile (e.g. existing legacy certificates)
2. The time it takes to issue a replacement intermediate (e.g. if
intermediates are burned into ROM/factory provisioned for smart cards,
which ... apparently some folks do) from an existing root
3. If a root store imposes restrictions on roots within its root store
(many do), the time for those root stores to update.

As a practical matter, this means that there's a lower bound of 1+2+3 to
enforce ubiquitously within clients/RPs, while there's a lower bound of 1+2
to deploy this incrementally for new certificates. However, that's not
something that I think inherently blocks the spec, and this is true for
virtually all work that LAMPS might envisage re: X.509 extensions and
profiles, so this shouldn't disqualify the change. For the use case that
originally motivated this document (in the context of the CA/Browser
Forum's set of members, often called "Publicly Trusted CAs" or "Web PKI"
CAs), 1+2 is often bounded at O(months), and based on discussions by the
S/MIME Certificate Working Group within that organization, and policies
from both Google and Apple, the time for 1 is bounded somewhere between 2-3
years. In PKI terms, that's quite rapid.

I do agree that Rich's change seems good, to address confusion that may
result from folks reading.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Dec 2021 22:23:27 +0000

*   I agree.  I would look at this RFC to define the OID and its processing rules for the RPs for the path as well as for end certificate and RP behavior when the extension is absent, has anyExtendedKeyUsage, has Adobe Document Signing, has Microsoft Document Signing, yada, yada, yada.

Not quite.  The processing rules for EKU are defined in RFC 5280. The draft should make that explicit to avoid this kind of confusion.

As for what EKU values are needed for various document-signing usages, that seems to me strictly up to the relying party. It would be nice if everyone moved to the common “document signing” EKU at some point, but that’s my opinion.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Dec 2021 12:31:58 -0500

Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
    > I’d either need a pile of new certs (rather unlikely, IMHO), or my new
    > one signature cert would include all of these new EKUs, to maintain the
    > workflows. Essentially, rendering these EKUs useless.

I don't agree that it would become useless.

Your personal (connected to your legal name, no SAN dNSName) certificate
would not have Web Server or Web Client set, would it?

Someone who wants to split up email signatures from mortgage signing could do
that.  If you don't want to that, fine.

If one said that "documentSignature" is a useless EKU, because really we
need:
   a) sick note signing EKU (for parents and doctors)
   b) mortgage signing EKU (for home owners and banks)
   c) book signing EKU (for writers)
   d) ...

then I might agree with that.  I don't think we are there yet.

    > One can say “What’s the big deal about storing a ton of new certs on
    > your computer? It doesn’t increase the risk, because they’re likely to
    > be in one place, so if you lose one, you probably lose all anyway”. The
    > answer is – it’s not a big deal, as long as it’s somebody else’s burden
    > to manage (issue, revoke, etc.) these certs, and/or you only place them
    > on a computer hard drive – but not on a token like PIV card (like we
    > do).

We also have subcerts.  That might be useful in some ways, but I suspect that
the document says that EKUs can't change. But maybe they can be subset.

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

---

From: Alan DeKok <[email-masked]>
Date: Fri, 3 Dec 2021 09:06:24 -0500

> then I might agree with that.  I don't think we are there yet.

  I don't see why not.  If the design is simple, people will find ways to use it.  If the design is complex, then people won't use it, even if it's standardized.

> the document says that EKUs can't change. But maybe they can be subset.

  This sounds to me like a problem I worked on a while ago, which was using certificates for delegated authentication / authorization.  Think "I have a company, and I want my accountant to be able to do payroll from the bank account, but he shouldn't be able to do arbitrary transfers".  The desire was to use local CAs / servers, and to give client certs to authorized users.  The client certs should ideally contain the policy information.

  The problem is that these kinds of policies are human oriented, and are impossible to represent programatically.  See various crypto-currency / contract vulnerabilities for a worked example.  Or, see the processes in place at any business.  Everything thinks they're special, and their processes are slightly different from everyone else's processes.  There's just no "one size fits all" category for this.

  The proposal was to divide the work into two pieces.  One is human oriented, "please give me a cert which has X permissions".  i.e. humanly described policies.  The response was a cert containing an opaque blob.  The issuer could internally correlate the blob with the policy, via whatever mechanism they used locally.  The user could just present the cert, and it would either work for a particular transaction, or not.

  Perhaps something similar could be done here.  Don't have only a document signing EKU.  Extend it via a vendor identity field, and a vendor token field.  Each vendor could issue their own tokens, with their own meanings.  This gives the utility of a document signing EKU, along with the flexibility of allowing any humanly-defined policies.

  To put it another way, what happens if we restate the problem?  i.e. let's say we have sick note EKU, mortgage EKU as you said above.  How do you tell that a particular document is a sick note, or a mortgage?  They're all bits, and they're all good.  There's no automated process for doing this *content* validation.  It's humans all the way down...

  In contrast, EKUs for automated processes are fine.  e.g. "TLS web server", where the computer validates everything (which is a very limited use-case), and just shows the user a pass / fail result.

  It doesn't seem useful to have use-specific EKUs for human processes.  Perhaps just allowing human extensions and punting on the problem would be simplest.

  Alan DeKok.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 3 Dec 2021 15:33:38 +0000

>   I don't agree that it would become useless.

We differ here. ;-)

To me, if adding an EKU means that the majority of the certs would "automatically" include it because otherwise it breaks the current workflows - thus providing little to none advantage over having just one Signature EKU and (therefore) cert.

>    would not have Web Server or Web Client set, would it?

It depends. It may... I'm thinking in terms of hardware tokens - US Gov't PIV cards, eID cards in Europe, and such. So, if my Web Server needs authentication by my legal identity - then yes, it better be present. And for Web Client - it is already present. Many government sites in US and Europe do require "that kind of ID", so, absolutely - certs on those gov't-issued tokens do have Client Authentication (which is accepted by Web Servers, in my experience).

>    that.  If you don't want to that, fine.

Again, we seem to be talking about different use cases. You seem to think about a "normal" person sitting at his computer, and probably preferring to sign his semi-junk email with a different cert than the one he signs his mortgage, will, etc.

I'm thinking of an "official" government-issued electronic ID - a smartcard or hardware token, with probably three certificates at most, more often - just two: one to authenticate to (government services) Web sites, and one to sign (all kinds of) various things. 

>   then I might agree with that.  I don't think we are there yet.

No, we aren't there YET. And I've nothing against "documentSignature" EKU. 

Just pointing out that all the Digital Signature certs I've dealt with (mostly, issued by corporations and government) included both: Email Protection and Document Signing. For obvious reasons - smartcard has only one Digital Signature slot, and whoever signs emails at work, usually also signs documents at work.

But with moving from a single "documentSignature" EKU to fine-grained "what kind of doc you're signing": one for PDF, one for MS Word, one for "pure" XML - because, e.g., we're afraid of cross-protocol attacks - we're firmly on the road to what you yourself depicted as undesirable. And I don't like that road, even if we haven't reached it's logical destination YET.

Thanks!

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Dec 2021 16:13:22 +0000

>   To me, if adding an EKU means that the majority of the certs would "automatically" include it because otherwise it breaks the current workflows - thus providing little to none advantage over havi…

For some transition period, not forever.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 3 Dec 2021 16:16:26 +0000

> > To me, if adding an EKU means that the majority of the certs would
> > "automatically" include it because otherwise it breaks the current
> > workflows - thus providing little to none advantage over having
> > just one Signature EKU and (therefore) cert.
>

I expect to *never* need to only sign emails, but not documents - or vs. versa. Thus, no transition here, ever. ;-)

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Dec 2021 16:22:26 +0000

>    I expect to *never* need to only sign emails, but not documents - or vs. versa. Thus, no transition here, ever. ;-)

You don't get issued new certificates, ever?

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 3 Dec 2021 16:29:55 +0000

On 12/3/21, 11:23, "Salz, Rich" <[email-masked]> wrote:
>  >    I expect to *never* need to only sign emails, but not
>  >    documents - or vs. versa. Thus, no transition here, ever. ;-)
>

About every one to three years. ;-)

The point is - those new certs will have to have the same EKUs, so my point stands: separating Email Signing* and Document Signing merely led to my single Digital Signature certificate having both EKUs included. And I expect it to keep including them for the foreseeable future. 

*: actually, it's Email Protection, so both Signature and Key Mgmt certs have to include that EKU. And that's not what I'm against - I'm trying to explain that making EKUs for signing too fine-grained is counterproductive, because the new certs will just include all of those "fine-grained" EKUs to maintain the current workflows.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 3 Dec 2021 13:43:27 -0700

On Fri, Dec 3, 2021 at 9:30 AM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> The point is - those new certs will have to have the same EKUs, so my
> point stands: separating Email Signing* and Document Signing merely led to
> my single Digital Signature certificate having both EKUs included. And I
> expect it to keep including them for the foreseeable future.

That sounds great - for your use case. However, a number of industry
participants, including root store operators, are looking to have these
separated, and ensure that for their programs, these are separate
certificates and capabilities.

You certainly can continue to include both in your PKI and use them with
your relying part applications. However, there is a benefit seen in
separating out both the policy _and_ the technical capability, to ensure
there is no ambiguity or confusion between these two very different acts.

Even if you object to that conclusion being achieved with EKU, it will be
achieved, one way or another. Examples include the previously discussed
organizational EKU, or of course, using certificatePolicies for this
purpose, along with policies for CAs prohibiting this new-policy from being
included with other policies.

I totally get that you don’t see the value or utility for your use cases,
but this originally started by vendors of S/MIME software, root stores, and
CAs recognizing that there are differences in policies, technical
capabilities, client agility, and signature format, and that it’s best to
split these two use cases and prevent the same certificate - in their PKIs
- from being used for both.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Dec 2021 17:42:24 -0500

Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
    > I'm thinking of an "official" government-issued electronic ID - a
    > smartcard or hardware token, with probably three certificates at most,
    > more often - just two: one to authenticate to (government services) Web
    > sites, and one to sign (all kinds of) various things.

I guess I am very very pessimistic that I'll have such a government-issue ID
anytime soon.    I see that this is occuring in the private sector.
(I have some experiences with the gc.ca efforts which provides some of my experience)

    > No, we aren't there YET. And I've nothing against "documentSignature" EKU.

Good to know.

I agree with you: in the short and medium term, we'll have certificates with
lots of EKUs on them.  I think that this is okay for now.

Later, we'll have things like Alan described.

we have precedent for doing things without EKU:
  https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-11#section-4.2

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 5 Dec 2021 01:54:29 +0000

>  I guess I am very very pessimistic that I'll have such a
>  government-issue ID anytime soon. 

In Europe it's already a reality. For government employees in US it's also a reality - though with more limited scope.

>  I see that this is occuring in the private sector.

Yep.

> (I have some experiences with the gc.ca efforts which provides some of my experience)

Would be interesting to hear about your experience, though probably offline.

> > No, we aren't there YET. And I've nothing against "documentSignature" EKU.

The problem I see is that some people are not happy with mere "documentSignature" EKU, and want to "fine-grain" it.

> I agree with you: in the short and medium term, we'll have certificates
> with lots of EKUs on them.  I think that this is okay for now.

I don't think it's OK, and personally hope this madness won't happen.

> Later, we'll have things like Alan described.

Possibly.

But given how the "big guns" screwed up certificate processing and attributes interpretation over and over again, I'm very pessimistic with the current road.

> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-11#section-4.2 

Yes.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 5 Dec 2021 02:02:13 +0000

That sounds great - for your use case. However, a number of industry participants, including root store operators, are looking to have these separated, and ensure that for their programs, these are separate certificates and capabilities.

And as long as we’re talking about less than a handful of “granular” EKUs, I don’t see a real problem. E.g., it’s OK to separate email and document signing into two EKUs – though I challenge you to find a workflow that would include one but not the other.

My problem is proliferation of EKUs (e.g., more than a handful), as I explained elsewhere.

You certainly can continue to include both in your PKI and use them with your relying part applications. However, there is a benefit seen in separating out both the policy _and_ the technical capability, to ensure there is no ambiguity or confusion between these two very different acts.

I hear you, but I don’t think I understand what the above is saying, sorry. What is it that you’re trying to separate?

Even if you object to that conclusion being achieved with EKU, it will be achieved, one way or another. Examples include the previously discussed organizational EKU, or of course, using certificatePolicies for this purpose, along with policies for CAs prohibiting this new-policy from being included with other policies.

See above: I hear you, but – sorry – don’t quite follow.

I totally get that you don’t see the value or utility for your use cases, but this originally started by vendors of S/MIME software, root stores, and CAs recognizing that there are differences in policies, technical capabilities, client agility, and signature format, and that it’s best to split these two use cases and prevent the same certificate - in their PKIs - from being used for both.

If this is about separating Email and Document signing – I’m OK with that (not to mention that it’s an already-existing fact). Once you start asking for different EKUs to, e.g., sign PDF vs. DOCX – we have a problem.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 4 Dec 2021 22:32:44 -0800

> As for what EKU values are needed for various document-signing usages, that seems to me strictly up to the relying party. It would be nice if everyone moved to the common “document signing” EKU at…

I think that touches on the core disconnect that's been happening in this
subthread -- Stefan is essentially pointing out that there already exist
deployed "protocols" for document signing, and that us specifying a new
protocol (and EKU) is not going to somehow retroactively apply to all those
existing "protocols" and cause them to reject signatures that lack the new
EKU.

Now, one might say that the management body for the PKI(s) involved in
those existing deployments could choose to adopt the new EKU and its
protocol, which is true.  But I'm not sure that there's anything that
specifically obligates those PKIs to adopt the new EKU -- the "it would
be nice if everyone moved to the common document signing EKU" that you
note.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 5 Dec 2021 17:58:47 +0000

>  But I'm not sure that there's anything that

I'm not aware of anything that the IETF does that obligates anyone, are you?

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 5 Dec 2021 20:00:17 +0000

It is my understanding that any implementation claiming conformance to an IETF RFC is obligated to follow what it says, is it not?

Regards,
Uri

> On Dec 5, 2021, at 13:00, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> 
>>

---

From: Russ Housley <[email-masked]>
Date: Sun, 5 Dec 2021 15:48:16 -0500

I think Rich's point is that IETF standards are voluntary to implement.  There is not enforcement by the "protocol police".

Russ

> On Dec 5, 2021, at 3:00 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
>

---

From: David von Oheimb <[email-masked]>
Date: Sun, 5 Dec 2021 22:15:24 +0100

Sure IETF RFCs do not imply legal obligations or the like,
but if implementors do not follow the MUSTs etc. given there, others 
cannot rely on the specified behavior.
Thus fitness for the desired purpose and interoperability are lost, and 
the standardization becomes pointless.

     David

On 05.12.21 21:48, Russ Housley wrote:
>> On Dec 5, 2021, at 3:00 PM, Blumenthal, Uri - 0553 - MITLL<[email-masked]>  wrote:
>>
>>> On Dec 5, 2021, at 13:00, Salz, Rich<rsalz=[email-masked]>  wrote:
>>>
>>>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 5 Dec 2021 21:39:31 +0000

Isn’t every standard  that way - nobody can be forced to implement it? 
But the buyer of the product (the implementation) can demand compliance as a condition of purchase?

Regards,
Uri

> On Dec 5, 2021, at 16:16, David von Oheimb <[email-masked]> wrote:
> 
> 
> but if implementors do not follow the MUSTs etc. given there, others cannot rely on the specified behavior.
> Thus fitness for the desired purpose and interoperability are lost, and the standardization becomes pointless.
> 
>     David
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 5 Dec 2021 22:07:20 +0000

*   Isn’t every standard  that way - nobody can be forced to implement it?

No.  Many will not let you use their trademark (USB, Wi-Fi, Unix, etc) without passing a conformance test.

  *   But the buyer of the product (the implementation) can demand compliance as a condition of purchase?
Yes, for IETF specifications the burden is on the buyer.  Which is why I think that, eventually, the proposed EKU for document signing will become widespread.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 5 Dec 2021 23:03:47 +0000

You mean - (e.g.) Wi-Fi group would sue a vendor falsely claiming conformance, but IETF wouldn’t…?

Re. Document Signing EKU - I think it’s already widespread. At least, all of my certs have it. As I explained - my concern is with “fragmentation” of the signing EKU beyond “sign document”.

Regards,
Uri

> On Dec 5, 2021, at 17:08, Salz, Rich <rsalz=[email-masked]> wrote:
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 6 Dec 2021 08:42:40 -0500

Yes.

  For example, the WiFi Alliance is not *just* a standards body.  They are a also *certification* body.  Any product you buy which has the WiFi logo *must* be certified, or they get sued for trademark infringement, and/or violation of the contract the vendor signed with the WiFi Alliance.

  The IETF has no such certification process.  If my product claims RFC compliance, the only thing preventing me from making false claims is public ridicule.

  The IETF has no such contract between members, either.  Anyone is free to participate and/or write a standard, the only thing they have to agree to is the "note well", and copyright assignment of the RFCs.

  Alan DeKok.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Dec 2021 14:25:22 +0000

*   You mean - (e.g.) Wi-Fi group would sue a vendor falsely claiming conformance, but IETF wouldn’t…?

Yes, for violation of trademark.  They don’t have a choice, in the US if you do not defend your trademark you can lose it (cf Kleenex and Aspirin), and if the terms of using the trademark are “conform to the standard” then there’s no choice. Trademark law (in the US, don’t know of other places) is very powerful.

The IETF, as far as I know, has never sued anyone because they didn’t comply with an RFC, even though they might have claimed that they did. It would be antithical to our stated public positions at a minimum. As Russ said, quoting a common aphorism, “we’re not the protocol police.”

Thank you for explaining your concern is about fragmentation.  Can you explain more?

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 6 Dec 2021 20:17:48 +0000

> Thank you for explaining your concern is about fragmentation.  Can you explain more?

Sure.

As I said before, the factors are:
Limited number of certificates (aka, certificate slots) on hardware tokens (e.g., smartcards);
Established workflows that the majority of users are likely to utilize.

There seems no reason for, or benefit of separating an EKU into multiple fragmentary ones, unless new certs would have only some of the (new) EKU set. I.e., different (new) EKUs <==> different certs. 

In my world, “true” identity proof requires hardware token, not something “soft” stored on a computer. 

Since we have only one Digital Signature cert (as there’s only one Signature slot on the PIV), it necessarily includes EKUs for both Email Protection (signing in this case) and Document Signing (which covers whatever type docs we sign). This is not ideal , but it works. Any more-fragmented EKUs most likely would be included in the new Signature certs, making the change mostly useless. Unless, outside of the space I’m familiar with, there’s a significant number of people that only sign email, but never – documents, and/or vs. versa.

Since EKUs do take space, and thus increase the size of a cert – at some point adding EKUs would become prohibitive, especially since PQ signatures already blow cert size to “almost-unacceptable”…

It’s been established that code-signing EKU should be separate from other signing (docs or email), and the majority of our users do not need to sign code – so far so good. However, those of us who do, cannot do it with our “main” “secure” IDs… That’s a long story.

In short – one concern with “Signature EKU fragmentation” is that the existing certs that now have, say, 2 EKUs – would be replaced with new one that have, say, 5-6 EKUs, accomplishing the same (because workflows do not and need not change).

Not sure how coherent the above sounds, and I’ve plenty to take care of now – so my concentration is not at its best… ☹

I’d be happy to answer specific questions.

Thanks!

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 6 Dec 2021 14:02:34 -0700

On Mon, Dec 6, 2021 at 1:18 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

>
> There seems no reason for, or benefit of separating an EKU into multiple
> fragmentary ones, unless new certs would have only some of the (new) EKU
> set. I.e., different (new) EKUs <==> different certs.
>
Yes. That is a goal.

> “soft” stored on a computer.
This doesn’t apply for situations such as proof of an email address, but
you’re not alone in taking this view when it comes to document signing in
the legal sense.

Thus, this separation helps reflect both the different protocols and the
different policies in play: both for identity proofing and for protocol
verification.

Any more-fragmented EKUs most likely would be included in the new Signature
> certs, making the change mostly useless. *Unless, outside of the space
> I’m familiar with, there’s a significant number of people that only sign
> email, but never – documents, and/or vs. versa.*
>
Yes, this is the existing reality for a number of use cases, which this
document is trying to better support. It sounds like it may be different
then the space you’re dealing with, but hopefully that also provides a
degree of assurance that this is trying to address a different set of
problems then your existing solutions are.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 6 Dec 2021 23:58:14 +0000

Yes. That is a goal.

I think I explained why I think this goal is impractical for many cases.

This doesn’t apply for situations such as proof of an email address, but you’re not alone in taking this view when it comes to document signing in the legal sense.

[Straying from the topic, but it’s my pet peeve] The purpose of the signature is supposed to be proving the sender identity, not necessarily her email address! I have a dozen email addresses, and only misinterpretation of the certificate processing by companies like MS and Apple prevents me from being able to sign emails send via any or all of them with the same certificate that has my DN.

But, even with the current “email address-proving reality”, it isn’t “proven”, unless the proof comes from a token. So, back to my point 1.

Thus, this separation helps reflect both the different protocols and the different policies in play: both for identity proofing and for protocol verification.

Any more-fragmented EKUs most likely would be included in the new Signature certs, making the change mostly useless. Unless, outside of the space I’m familiar with, there’s a significant number of people that only sign email, but never – documents, and/or vs. versa.

Yes, this is the existing reality for a number of use cases, which this document is trying to better support. It sounds like it may be different then the space you’re dealing with, but hopefully that also provides a degree of assurance that this is trying to address a different set of problems then your existing solutions are.

Do you mean “there is a significant number of people that only sign email, but never – documents, and/or vs. versa”?  If so, I’d like some details (if possible) on what kind of workflows they are a part of, and what’s their real-life use case.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 6 Dec 2021 19:40:42 -0700

> I think I explained why I think this goal is impractical for many cases.
I’m happy to say billions of people successfully use certificates without
tokens, so I’m not too worried here, although I can appreciate that your
specific use cases are different.

That is, while I understand you feel this system is impractical for your
legacy smartcard systems, that is not the only way to use these. Plus, of
course, technology can and does evolve, so given natural renewal cycles, we
shouldn’t assume it always being a limitation. We don’t have to solve
whether the chicken and egg came first in order to make an omelet today.

[Straying from the topic, but it’s my pet peeve] The purpose of the
> signature is supposed to be proving the *sender identity*, not
> necessarily her email address! I have a dozen email addresses, and only
> misinterpretation of the certificate processing by companies like MS and
> Apple prevents me from being able to sign emails send via any or all of
> them with the same certificate that has my DN.
>
>
>
> But, even with the current “email address-proving reality”, it isn’t
> “proven”, unless the proof comes from a token. So, back to my point 1.
>
Actually, this is pretty core. It seems you may be misunderstanding the use
case, based on your own experiences with certain PKIs, and in part
disagreeing with some of the other goals that other PKIs have. That’s
totally OK, I’m not going to try to convince you of the value here, but it
seems useful to at least reach a shared vocabulary.

In the least, it’s helped us establish that your disagreement is one based
on what people are doing today, which this proposal supports, rather than
this proposal itself.

Do you mean “*there is a significant number of people that only sign email,
> but never – documents, and/or vs. versa*”?  If so, I’d like some details
> (if possible) on what kind of workflows they are a part of, and what’s
> their real-life use case.
>
A few examples are:
* https://support.google.com/a/answer/6374496?hl=en
* https://www.globalsign.com/en/secure-email
*
https://support.apple.com/en-us/HT202345

S/MIME authentication acts as a compliment to DKIM, DMARC, and SPF in these
systems. Even without validating a natural or legal person, such systems
help the domain operators authenticate messages to their users.

For example, I’m given to understand that Apple uses such system - S/MIME
signatures without document signing - for their security relevant
notifications, like state-sponsored hacking notifications.

These systems all build on a widely deployed PKI ~roughly akin to the Web
PKI, in which a series of shared CAs act on behalf of several application
vendors, authenticating the domain information, while then allowing the
domain holder to communicate what other information (e.g. the “localpart”
and potentially other information which the organization self-attests to
add an RA acting on local policy, such as first and last name)