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

From: Stefan Santesson <[email-masked]>
Date: Thu, 25 Nov 2021 23:09:10 +0100

Hi,

First a short apology for jumping in late in this discussion. I know
much has been said about this already and I may have missed some of that.

But still, some of my fears with this proposal was recently clearly
demonstrated at a recent ETSI meeting.

At this meeting it was brought up on the agenda a proposal to update
ETSI signature validation procedures and standards based on the new EKU
for document signing proposed by IETF.

I then asked the person proposing this what a verifier should do when
validating a signed document using a certificate that does not contain
this EKU.

The answer was - to fail signature validation.

This time I was there to say NOOO as firmly as I could. But I'm afraid
that there are many other similar meetings and committees where such
proposals may be approved and written into requirements specifications
and even legal text. This is my fear, demonstrated.

If this EKU is created it should come with a firm warning like:

"Signature validation MUST NOT fail to validate a signature based the
absence or presence of this EKU unless document signature validation is
done in a completely local context where the verifier knows with
certainty that any valid signer is represented by a signer certificate
containing this EKU."

And perhaps also "This EKU only provides a positive indication .Absence
of this EKU does not indicate that the subject public key is not
suitable for verifying signatures on documents"

(These are not literal text proposals)

I still do not understand fully what purpose that EKU serves and in
particular how relying parties are supposed to react to the presence or
absence of this EKU. I think this should be explained more clearly in
the draft.

-- 
________________
Stefan Santesson

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 25 Nov 2021 23:13:31 +0000

I couldn't agree more with Stefan. Concur 100%.

Regards,
Uri

> On Nov 25, 2021, at 17:10, Stefan Santesson <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 26 Nov 2021 15:03:41 -0500

> and even legal text. This is my fear, demonstrated.

Could you explain what problems you see?

This absolutely sounds like the correct approach, to treat such absence as
a lack of affirmative opting in to that trust framework, so perhaps you can
elaborate.

My hope is that the objection doesn’t have to do with already extant
certificates, since these should be a non-issue.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 26 Nov 2021 23:10:50 +0100

I'm a bit puzzled by the question. In my world the problem is obvious.

I suspect that we are looking on fundamentally different use cases.

But basically, since there are literally millions of existing
certificates used to sign documents out there, some certificates issued
for the purpose of document signing will include this EKU, while others
won't.

Just under the EU Trusted List program, 1500 issuers of Qualified
Certificates are listed (see: http://tlbrowser.tsl.website). I guess
only a fraction of those will change their operation to include this EKU
in foreseeable time.

Many EU CA services rely on ETSI EN 319 412-2 for their certificates for
signing, this standard does not mandate this EKU. So if you are looking
at the general open use case, then this is a potential mess where the
meaning of the absence of this EKU is almost impossible to understand. 

Finally, the whole idea of limiting signature validity on certificate
content is fundamentally flawed. The reason is that when you validate a
signature on a document, the primary purpose is not to validate the
singature as such. The primary purpose is to validate the contractual
agreement represented by the signed document. If you sign a document
with any certificate with the intent to enter into an agreement, then
you are bound by that agreement. No contractual agreement can be
invalidated because the signing certificate did not have non-repudiation
key usage, or any specific EKU. This is fundamentally written into the
EU eIDAS legal framework basically saying that no court can deny a
signature legal value just because it does not have a certain shape or form.

If you submit your financial report and sign that with your TLS client
certificate, you are still bound by that financial report as long as you
used it with that intent.

I want to reverse the question. What is the purpose of this EKU and
exactly how am I as implementer of validation code supposed to treat
presence and absence of this EKU.

/Stefan

On 2021-11-26 21:03, Ryan Sleevi wrote:
> This absolutely sounds like the correct approach, to treat such
> absence as a lack of affirmative opting in to that trust framework, so
> perhaps you can elaborate.
>

---

From: Carl Wallace <[email-masked]>
Date: Fri, 26 Nov 2021 17:46:05 -0500

Inline…

From: Spasm <[email-masked]> on behalf of Stefan Santesson <[email-masked]>
Organization: 3xA Security AB
Date: Friday, November 26, 2021 at 5:11 PM
To: Ryan Sleevi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [lamps] The problem with EKU for document signing demonstrated

<snip>

Finally, the whole idea of limiting signature validity on certificate content is fundamentally flawed. The reason is that when you validate a signature on a document, the primary purpose is not to validate the singature as such. The primary purpose is to validate the contractual agreement represented by the signed document. If you sign a document with any certificate with the intent to enter into an agreement, then you are bound by that agreement. 

[CW] This statement begs the question “what happens when someone verifies a document with a valid signature that someone other than you generated using a key associated with you”. At least in some environments, most of the point of key usages with regard to document signing and similar is to functionally keep escrowed keys separate from non-escrowed keys. Given that, I don’t see how you claim usage values should not matter when validating the signature on a document. 

No contractual agreement can be invalidated because the signing certificate did not have non-repudiation key usage, or any specific EKU. This is fundamentally written into the EU eIDAS legal framework basically saying that no court can deny a signature legal value just because it does not have a certain shape or form.

If you submit your financial report and sign that with your TLS client certificate, you are still bound by that financial report as long as you used it with that intent.

I want to reverse the question. What is the purpose of this EKU and exactly how am I as implementer of validation code supposed to treat presence and absence of this EKU.

/Stefan

 

Hi,

This absolutely sounds like the correct approach, to treat such absence as a lack of affirmative opting in to that trust framework, so perhaps you can elaborate.

My hope is that the objection doesn’t have to do with already extant certificates, since these should be a non-issue.

-- 
________________
Stefan Santesson

_______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 26 Nov 2021 19:42:51 -0500

On Fri, Nov 26, 2021 at 4:11 PM Stefan Santesson <[email-masked]> wrote:

> But basically, since there are literally millions of existing certificates
> used to sign documents out there, some certificates issued for the purpose
> of document signing will include this EKU, while others won't.
>

> Certificates are listed (see: http://tlbrowser.tsl.website). I guess only
> a fraction of those will change their operation to include this EKU in
> foreseeable time.
>
So what?

I don’t mean this glibly - I mean what does it matter whether or not 319
412-2 uses this EKU or not? What bearing does that have on the IETF, or
more generally, the protocols themselves?

You seem to be describing a situation about transition or comparability,
but that doesn’t have any bearing whatsoever on the utility of the EKU, and
the PKI operators of that trust framework can deal with that scenario in a
myriad of ways (e.g. requiring the EKU for all new certificates). The fact
that something did it an old way doesn’t mean the ecosystem is forever
locked into that method, especially since such certificates naturally have
validity periods and lifetimes.

A document signing PKI can be just as dynamic as any other PKI, and we’ve
seen ample change from the Web PKI and RPKI, so I fail to see why change
should be inconceivable here.

> signing, this standard does not mandate this EKU. So if you are looking at
> the general open use case, then this is a potential mess where the meaning
> of the absence of this EKU is almost impossible to understand.
>
I don’t see how this follows. The meaning of the EKU doesn’t change based
on these facts. There’s zero issue here for those that want to provide it,
and zero issue for those that want to enforce it for probative value.

> content is fundamentally flawed.
>
This may be the core of the disagreement. There’s no such flaw: indeed,
part of the restriction on EKU is to assert the probative value in
non-repudiation, by ensuring that the intent is actually reflected in the
signature. The IETF is no stranger to cross-protocol attacks, even in
highly related protocols (e.g. TLS record protocol versions), and it’s
elements such as restrictions on the certificate that ensure the necessary
intent is conveyed.

Put differently: if a signature is ambiguous, that uncertainty undermines
any derived legal value

The reason is that when you validate a signature on a document, the primary
> purpose is not to validate the singature as such. The primary purpose is to
> validate the contractual agreement represented by the signed document. If
> you sign a document with any certificate with the intent to enter into an
> agreement, then you are bound by that agreement.
>
Only in some jurisdictions.

> No contractual agreement can be invalidated because the signing
> certificate did not have non-repudiation key usage, or any specific EKU.
>
This isn’t true, to the degree of reasonable doubt as to who entered the
signature (e.g. by malware or protocol confusion).

> This is fundamentally written into the EU eIDAS legal framework basically
> saying that no court can deny a signature legal value just because it does
> not have a certain shape or form.
>
This isn’t quite accurate as well; there’s an obligation to meet certain
shapes or forms in order to have the legal presumption. It’s not as if any
and every electronic signature is granted the same presumption.

> used it with that intent.
and cross-protocol attacks reasonably call in to doubt whether the
signature reflects that intention.

> presence and absence of this EKU.
Since the beginning of PKIX, the IETF has discussed the EKU as the means of
distinguishing between protocols to ensure unambiguous representations of
signatures and what they’re binding to.

---

From: Michael Jenkins <[email-masked]>
Date: Fri, 26 Nov 2021 20:45:51 -0500

Aren't EKUs input to an authorization decision?

So no, I would not fail the validation if it adequately chains to a trust
anchor I have. Now I know who signed it.

Now I can look to the cert for more information about the signature or
signer, because that's a convenient place to carry such information
(although the authority of a CA to assert such things has always seemed odd
to me). And I can access non-certificate information, perhaps based on the
identity I have validated, and feed that all into my authorization decision
engine, based on /my/ policy - not what's asserted by the signer or the CA.

I suspect the implementation logic used for all of this isn't so
complicated as I imagine, for good reason  :)  But overlaying "signature
validity" with so much meaning seems like a bad idea.

Mike

-- 
Mike Jenkins
[email-masked] <[email-masked]> - if you want me to read it only
at my desk
[email-masked] - to read everywhere
443-634-3951

---

From: David von Oheimb <[email-masked]>
Date: Mon, 29 Nov 2021 07:53:42 +0100

I fully share Stefan's concern and agree that the problem should be obvious.
To put it in most simple terms: the approach is not backward compatible.

The dilemma is:
Either a verifier insists in expecting the new EKU, then it will reject 
all signed documents that do not (yet) have the new EKU, ruling out 
existing signatures and practice.
Or the verifier does not insist in the presence of the new EKU, but then 
the EKU becomes optional and its value questionable.

The only general cure that I see here (apart from having some ad-hoc 
local policy whether or not to require that EKU)
is to introduce into the specification a threshold for requiring the 
existence of the EKU,
such as: the EKU presence is expected only for signatures done after, 
say, 2024, or for signer certs having X.509 version 4.

     David

On 26.11.21 23:10, Stefan Santesson wrote:
> certificates used to sign documents out there, some certificates 
> issued for the purpose of document signing will include this EKU, 
> while others won't.
>
> only a fraction of those will change their operation to include this 
> EKU in foreseeable time.
>
> Many EU CA services rely on ETSI EN 319 412-2 for their certificates 
> for signing, this standard does not mandate this EKU. So if you are 
> looking at the general open use case, then this is a potential mess 
> where the meaning of the absence of this EKU is almost impossible to 
> understand.
>
>
> content is fundamentally flawed. The reason is that when you validate 
> a signature on a document, the primary purpose is not to validate the 
> invalidated because the signing certificate did not have 
> non-repudiation key usage, or any specific EKU. This is fundamentally 
> written into the EU eIDAS legal framework basically saying that no 
> court can deny a signature legal value just because it does not have a 
> certain shape or form.
>
> certificate, you are still bound by that financial report as long as 
> you used it with that intent.
>
>
>> absence as a lack of affirmative opting in to that trust framework, 
>> so perhaps you can elaborate.
>>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 29 Nov 2021 10:29:12 +0100

Made a new thread:

On 2021-11-26 23:46, Carl Wallace wrote:
>
> Inline…
>
>  
>
> *From: *Spasm <[email-masked]> on behalf of Stefan Santesson
> <[email-masked]>
> *Organization: *3xA Security AB
> *Date: *Friday, November 26, 2021 at 5:11 PM
> *To: *Ryan Sleevi <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [lamps] The problem with EKU for document signing
> demonstrated
>
>  
>
> <snip>
>
> [CW] This statement begs the question “what happens when someone
> verifies a document with a valid signature that someone other than you
> generated using a key associated with you”. At least in some
> environments, most of the point of key usages with regard to document
> signing and similar is to functionally keep escrowed keys separate
> from non-escrowed keys. Given that, I don’t see how you claim usage
> values should not matter when validating the signature on a document.

We have 2 situations of interest.

1) Validation of this signature by the relying party when deciding to
accept/rely on this signed document. Here the RP can do whatever the RP
think is right. The RP can deny or allow certificates with or without
this EKU. The consequence here is at most interop problems by rejecting
valid signed documents if the EKU is required in all signed documents.

2) Determination of the validity of the signature at court, when the
parties disagree if the signed agreement is valid or not.

What happens in this case is that I will say to the court that I did not
sign this "document/contract". If the technical setup and the legal
system work, the court will agree with me and dismiss this signature as
evidence for this claimed agreement.

I can imagine that the court will take many aspects int considerations
when reaching this conclusion like (Was my IP adress used when signing,
was my sercurity breached, did I revoke my credentials, did I protect my
PIN, what contractual agreements are in place regarding the use of my
signing key, have I acted as if I entered into this agreement (payed
bills etc).

Somewhere in the very bottom on that list EKU and KU bits may be of
marginal interest.

/Stefan

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Nov 2021 08:56:15 -0500

> To put it in most simple terms: the approach is not backward

There are a many more mid-points which just serve to make this more complex.

1) If there is no EKU extension, then there were no restrictions, so accept.

2) If the CA signing the certificate says they don't or didn't do EKU-digitalSignature prior
   to some date, then that take that into account.

3) If the parties involved in the contract say that they don't care, then
   don't care.
   There are many other parameters that the parties will need to agree upon.

This notion that random signatures from random CAs will be accepted by
random RPs is, while wistful, is alas wrong.

Each community of bankers will set forth their own requirements.
Some of them will benefit from local government involvement in setting up
profiles, validating CAs, and determining what will be verified by CAs.
Some won't.  Alas, that's why I spent $250 in October fedexing contract documents
to/from customers, rather than digitally signing the PDF.

My recommendation is that we allocate the EKU bit.  Some will want to use it.
Some won't care.  Some will want to care as of some date.

    > The only general cure that I see here (apart from having some ad-hoc local
    > policy whether or not to require that EKU)
    > such as: the EKU presence is expected only for signatures done after, say,
    > 2024, or for signer certs having X.509 version 4.

It's a good idea, but not one that we in LAMPS are going to be able to
specify, our community is illdefined and too large.

--
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: Mon, 29 Nov 2021 14:41:36 +0000

The problem I see is proliferation of EKUs and corresponding certificates – particularly when the user/signer is likely to perform all the activities those individual separate EKUs permit. For example, I regularly sign emails, and I regularly sign documents/forms – in various formats. Usually, a signed doc would be PDF, but they also happen to be DOCX, XLSX, etc. If “EKU galore” approach is accepted – 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. 

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

--

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: David von Oheimb <[email-masked]>
Date: Monday, November 29, 2021 at 01:55
To: Stefan Santesson <[email-masked]>, Ryan Sleevi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Uri Blumenthal <[email-masked]>, Michael Jenkins <[email-masked]>, Carl Wallace <[email-masked]>
Subject: Re: [lamps] The problem with EKU for document signing demonstrated

The dilemma is:
Either a verifier insists in expecting the new EKU, then it will reject all signed documents that do not (yet) have the new EKU, ruling out existing signatures and practice.
Or the verifier does not insist in the presence of the new EKU, but then the EKU becomes optional and its value questionable.

The only general cure that I see here (apart from having some ad-hoc local policy whether or not to require that EKU)
is to introduce into the specification a threshold for requiring the existence of the EKU,
such as: the EKU presence is expected only for signatures done after, say, 2024, or for signer certs having X.509 version 4.

    David

But basically, since there are literally millions of existing certificates used to sign documents out there, some certificates issued for the purpose of document signing will include this EKU, while others won't.

Just under the EU Trusted List program, 1500 issuers of Qualified Certificates are listed (see: http://tlbrowser.tsl.website). I guess only a fraction of those will change their operation to include this EKU in foreseeable time.

Many EU CA services rely on ETSI EN 319 412-2 for their certificates for signing, this standard does not mandate this EKU. So if you are looking at the general open use case, then this is a potential mess where the meaning of the absence of this EKU is almost impossible to understand.  

Finally, the whole idea of limiting signature validity on certificate content is fundamentally flawed. The reason is that when you validate a signature on a document, the primary purpose is not to validate the singature as such. The primary purpose is to validate the contractual agreement represented by the signed document. If you sign a document with any certificate with the intent to enter into an agreement, then you are bound by that agreement. No contractual agreement can be invalidated because the signing certificate did not have non-repudiation key usage, or any specific EKU. This is fundamentally written into the EU eIDAS legal framework basically saying that no court can deny a signature legal value just because it does not have a certain shape or form.

/Stefan

 

Hi,

-- 
________________
Stefan Santesson

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Nov 2021 10:19:18 -0500

David:

<without any hats>

I agree that there is a backwards compatibility issues to address.  That said, delay in specifying the OID for the EKU will prolong the transition.  Several people have expressed a real desire for this EKU,  I think we should assign it so that we can start the transition.

Russ

> On Nov 29, 2021, at 1:53 AM, David von Oheimb <[email-masked]> wrote:
> 
>> Just under the EU Trusted List program, 1500 issuers of Qualified Certificates are listed (see: http://tlbrowser.tsl.website <http://tlbrowser.tsl.website/>). I guess only a fraction of those will change their operation to include this EKU in foreseeable time.
>> 
>>> On Thu, Nov 25, 2021 at 2:09 PM Stefan Santesson <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi,
>>>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Nov 2021 15:31:49 +0000

*   I agree that there is a backwards compatibility issues to address.  That said, delay in specifying the OID for the EKU will prolong the transition.  Several people have expressed a real desire for this EKU,  I think we should assign it so that we can start the transition.

I think the EKU document, once adopted, should add text about “for compatibility with existing deployment, verifiers that are using the this OID should only start requiring it after they are sure that the CA’s used by their application support it” or something.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 30 Nov 2021 00:09:00 +0100

Russ,

Without (or before) making any objections, I would like to understand
what "transition" this is.

If this is a transition towards -> Documents signed with a cert where
this EKU is not present, MUST be rejected, then I would be worried.

If this is a transition towards -> Documents signed with a cert where
this EKU is present have a positive indication that the key was intended
to be used for document signing (But this says nothing about certs
without this EKU), then I have no problems.

But of course, the latter case is not much of a transition. Or?

/Stefan

On 2021-11-29 16:19, Russ Housley wrote:
> David:
>
> <without any hats>
>
> I agree that there is a backwards compatibility issues to address.
>  That said, delay in specifying the OID for the EKU will prolong the
> transition.  Several people have expressed a real desire for this EKU,
>  I think we should assign it so that we can start the transition.
>
> Russ
>
>
>> Either a verifier insists in expecting the new EKU, then it will
>> reject all signed documents that do not (yet) have the new EKU,
>> ruling out existing signatures and practice.
>> Or the verifier does not insist in the presence of the new EKU, but
>> then the EKU becomes optional and its value questionable.
>>
>>> Finally, the whole idea of limiting signature validity on
>>> certificate content is fundamentally flawed. The reason is that when
>>> you validate a signature on a document, the primary purpose is not
>>> to validate the singature as such. The primary purpose is to
>>> validate the contractual agreement represented by the signed
>>> document. If you sign a document with any certificate with the
>>> intent to enter into an agreement, then you are bound by that
>>> agreement. No contractual agreement can be invalidated because the
>>> signing certificate did not have non-repudiation key usage, or any
>>> specific EKU. This is fundamentally written into the EU eIDAS legal
>>> framework basically saying that no court can deny a signature legal
>>> value just because it does not have a certain shape or form.
>>>
>>> If you submit your financial report and sign that with your TLS
>>> client certificate, you are still bound by that financial report as
>>> long as you used it with that intent.
>>>
>>>
>>>> My hope is that the objection doesn’t have to do with already
>>>> extant certificates, since these should be a non-issue.
>>>>
>>>>
>>>>
>>>>

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 29 Nov 2021 18:23:01 -0500

On Mon, Nov 29, 2021 at 6:09 PM Stefan Santesson <[email-masked]> wrote:

> Russ,
>
> Without (or before) making any objections, I would like to understand what
> "transition" this is.
>
> If this is a transition towards -> Documents signed with a cert where this
> EKU is not present, MUST be rejected, then I would be worried.
>
It's unclear why this is problematic, and hopefully you can be more
explicit here.

The scenarios boil down to:
- X controls the issuing pipeline (e.g. the CA)
- Y controls the validation pipeline (e.g. the software vendor)
- Z controls the signing pipeline (e.g. you, the document signer)

The certificates that Z is using have a lifetime dictated by X, and a
profile dictated by Y. X and Y are free to change their requirements at any
time; we see this regularly, whether a software vendor requiring
conformance to a particular profile, or a policy authority dictating such
certificates conform to a profile. This is generally done independent of Z,
and the certificates that Z uses have natural replacement cycles, in
addition to any unusual replacements.

Why should Z have any bearing on X or Y?

If Y decides to reject such signatures, and X doesn't issue certificates
with the EKU, isn't that primarily an issue between X and Y? It doesn't
impact how Z functions at all.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 30 Nov 2021 00:34:10 +0100

Ryan,

You say the same as I:

"Y are free to change their requirements at any time"

In other words, the standard will not mandate that Y MUST reject the
signature.

This is fine with me.

/Stefan

On 2021-11-30 00:23, Ryan Sleevi wrote:
>     Without (or before) making any objections, I would like to
>     understand what "transition" this is.
>
>     If this is a transition towards -> Documents signed with a cert
>     where this EKU is not present, MUST be rejected, then I would be
>     worried.
>
> profile dictated by Y. X and Y are free to change their requirements
> at any time; we see this regularly, whether a software vendor
> requiring conformance to a particular profile, or a policy authority
> dictating such certificates conform to a profile. This is generally
> done independent of Z, and the certificates that Z uses have natural
> replacement cycles, in addition to any unusual replacements.
>
> If Y decides to reject such signatures, and X doesn't issue
> certificates with the EKU, isn't that primarily an issue between X and
> Y? It doesn't impact how Z functions at all.
>

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 29 Nov 2021 19:04:42 -0500

Then I’m not sure the point you’re making?

Russ highlighted that the sooner we can specify, the sooner that relying
party applications can look to transition. Rich pointed out that this
transition is predominantly for X and Y to sort out - the CAs issuing the
certificates and the software verifying it.

There’s good reason to require the EKU present, and it’s precisely what EKU
was designed for. There doesn’t seem anything inherently wrong in the spec
spelling out the transition - that is, that clients MUST reject documents
signed by certificates without this EKU, except if being operated in a
legacy-compatibility mode.

We certainly don’t need the spec to detail what, exactly, that legacy date
is - the UTF8String transition failures of PKIX show that - but that
doesn’t seem to be an argument against.

This is why I’m struggling to follow your concern: it’s unclear if you
oppose any transition at all, based on the reply to Russ, if you only
oppose the draft mentioning any transition (e.g. as part of security
considerations or as outlined above), or something else entirely. It’s
still possible to write a MUST (with one exception), without resorting to a
SHOULD (with unbounded exceptions), and it’s still possible to have a MUST
with a transition.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 30 Nov 2021 01:38:23 +0100

"Clients MUST reject documents signed by certificates without this EKU,
except if being operated in a legacy-compatibility mode."

That would be fundamentally in conflict with the definition of the EKU
extension. A certificate without EKU extension is not restricted and a
standard defining an EKU can only define its meaning withing the context
defined by the EKU extension itself.

It certainly has no mandate to regulate the behavior of implementations
that do not implement this standard (don't use this EKU).

/Stefan

On 2021-11-30 01:04, Ryan Sleevi wrote:
> Russ highlighted that the sooner we can specify, the sooner that
> relying party applications can look to transition. Rich pointed out
> that this transition is predominantly for X and Y to sort out - the
> CAs issuing the certificates and the software verifying it.
>
> There’s good reason to require the EKU present, and it’s precisely
> what EKU was designed for. There doesn’t seem anything inherently
> wrong in the spec spelling out the transition - that is, that clients
> MUST reject documents signed by certificates without this EKU, except
> if being operated in a legacy-compatibility mode.
>
> We certainly don’t need the spec to detail what, exactly, that legacy
> date is - the UTF8String transition failures of PKIX show that - but
> that doesn’t seem to be an argument against.
>
> still possible to write a MUST (with one exception), without resorting
> to a SHOULD (with unbounded exceptions), and it’s still possible to
> have a MUST with a transition.
>
>     In other words, the standard will not mandate that Y MUST reject
>     the signature.
>
>     This is fine with me.
>
>     /Stefan
>
>
>>         If this is a transition towards -> Documents signed with a
>>         cert where this EKU is not present, MUST be rejected, then I
>>         would be worried.
>>
>>     It's unclear why this is problematic, and hopefully you can be
>>     more explicit here.
>>
>>     The certificates that Z is using have a lifetime dictated by X,
>>     and a profile dictated by Y. X and Y are free to change their
>>     requirements at any time; we see this regularly, whether a
>>     software vendor requiring conformance to a particular profile, or
>>     a policy authority dictating such certificates conform to a
>>     profile. This is generally done independent of Z, and the
>>     certificates that Z uses have natural replacement cycles, in
>>     certificates with the EKU, isn't that primarily an issue between
>>     X and Y? It doesn't impact how Z functions at all.
>>

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 29 Nov 2021 19:50:06 -0500

That description seems to be in direct conflict with RFC 5280’s definition
of EKU:

https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12

> Certificate using applications MAY require that the extended key usage
extension be present and that a particular purpose be indicated in order
for the certificate to be acceptable to that application.

And
> Applications that require the presence of a particular purpose MAY reject
certificates that include the anyExtendedKeyUsage OID but not the
particular OID expected for the application.

This matches the rough consensus of the IETF, such as RFC 6960 [1], and
running code [2][3], so perhaps this explains my difficulty in
understanding the concern/position/objection.

[1]
https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2
[2]
https://support.apple.com/en-us/HT210176
[3]
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements

On Mon, Nov 29, 2021 at 7:38 PM Stefan Santesson <[email-masked]> wrote:

> There’s good reason to require the EKU present, and it’s precisely what
> EKU was designed for. There doesn’t seem anything inherently wrong in the
> spec spelling out the transition - that is, that clients MUST reject
> documents signed by certificates without this EKU, except if being operated
> in a legacy-compatibility mode.
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 30 Nov 2021 08:16:44 +0100

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.

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

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

/Stefan

On 2021-11-30 01:50, Ryan Sleevi wrote:
> That description seems to be in direct conflict with RFC 5280’s
> definition of EKU:
>
> > Certificate using applications MAY require that the extended key
> usage extension be present and that a particular purpose be indicated
> in order for the certificate to be acceptable to that application.
>
> And
> > Applications that require the presence of a particular purpose MAY
> reject certificates that include the anyExtendedKeyUsage OID but not
> the particular OID expected for the application.
>
> This matches the rough consensus of the IETF, such as RFC 6960 [1],
> and running code [2][3], so perhaps this explains my difficulty in
>     "Clients MUST reject documents signed by certificates without this
>     EKU, except if being operated in a legacy-compatibility mode."
>
>
>     That would be fundamentally in conflict with the definition of the
>     EKU extension. A certificate without EKU extension is not
>     restricted and a standard defining an EKU can only define its
>     meaning withing the context defined by the EKU extension itself.
>
>     It certainly has no mandate to regulate the behavior of
>     implementations that do not implement this standard (don't use
>     this EKU).
>
>     /Stefan
>
>
>
>>     relying party applications can look to transition. Rich pointed
>>     out that this transition is predominantly for X and Y to sort out
>>     - the CAs issuing the certificates and the software verifying it.
>>
>>     There’s good reason to require the EKU present, and it’s
>>     precisely what EKU was designed for. There doesn’t seem anything
>>     inherently wrong in the spec spelling out the transition - that
>>     is, that clients MUST reject documents signed by certificates
>>     without this EKU, except if being operated in a
>>     We certainly don’t need the spec to detail what, exactly, that
>>     legacy date is - the UTF8String transition failures of PKIX show
>>     that - but that doesn’t seem to be an argument against.
>>
>>     This is why I’m struggling to follow your concern: it’s unclear
>>     if you oppose any transition at all, based on the reply to Russ,
>>     if you only oppose the draft mentioning any transition (e.g. as
>>     part of security considerations or as outlined above), or
>>     something else entirely. It’s still possible to write a MUST
>>     (with one exception), without resorting to a SHOULD (with
>>     unbounded exceptions), and it’s still possible to have a MUST
>>     with a transition.
>>
>>         In other words, the standard will not mandate that Y MUST
>>         reject the signature.
>>
>>         This is fine with me.
>>
>>         /Stefan
>>
>>
>>>             Without (or before) making any objections, I would like
>>>             to understand what "transition" this is.
>>>
>>>             If this is a transition towards -> Documents signed with
>>>             a cert where this EKU is not present, MUST be rejected,
>>>             then I would be worried.
>>>
>>>         It's unclear why this is problematic, and hopefully you can
>>>         be more explicit here.
>>>
>>>         The certificates that Z is using have a lifetime dictated by
>>>         X, and a profile dictated by Y. X and Y are free to change
>>>         their requirements at any time; we see this regularly,
>>>         whether a software vendor requiring conformance to a
>>>         particular profile, or a policy authority dictating such
>>>         certificates conform to a profile. This is generally done
>>>         independent of Z, and the certificates that Z uses have
>>>         natural replacement cycles, in addition to any unusual
>>>         replacements.
>>>
>>>         certificates with the EKU, isn't that primarily an issue
>>>         between X and Y? It doesn't impact how Z functions at all.
>>>
>

---

From: "Tom Gindin" <[email-masked]>
Date: Mon, 29 Nov 2021 20:12:18 -0400

Rich:

        Even if we assume that RP's should enforce this value's presence, 
I think the transition needs to be longer than that.  If a CA (call them 
EverTrust) puts in support for this feature on 4/1/23, you can't assume 
that a certificate issued by that CA on 12/1/22 without the EKU isn't 
valid for document signing.  A certificate whose issuance date is later 
than the CA's support date might be appropriately subject to an inference 
that it isn't valid for document signing, but not one issued before that 
date.

Tom Gindin
PS      The opinions above are mine, and not necessarily those of my 
employer.

From:   "Salz, Rich" <rsalz=[email-masked]>
To:     "Russ Housley" <[email-masked]>, "David von Oheimb" 
<[email-masked]>
Cc:     "Ryan Sleevi" <[email-masked]>, "Stefan Santesson" 
<[email-masked]>, "Carl Wallace" <[email-masked]>, "Mike 
Jenkins" <[email-masked]>, "[email-masked]" <[email-masked]>, 
"Uri Blumenthal" <[email-masked]>
Date:   11/29/2021 10:32 AM
Subject:        [EXTERNAL] Re: [lamps] The problem with EKU for document 
signing demonstrated
Sent by:        "Spasm" <[email-masked]>

I agree that there is a backwards compatibility issues to address. That 
said, delay in specifying the OID for the EKU will prolong the transition. 
Several people have expressed a real desire for this EKU, I think we 
should assign it so that ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender 
This message came from outside your organization. 
ZjQcmQRYFpfptBannerEnd
I agree that there is a backwards compatibility issues to address.  That 
said, delay in specifying the OID for the EKU will prolong the transition. 
 Several people have expressed a real desire for this EKU,  I think we 
should assign it so that we can start the transition.
 
I think the EKU document, once adopted, should add text about ?for 
compatibility with existing deployment, verifiers that are using the this 
OID should only start requiring it after they are sure that the CA?s used 
by their application support it? or something.
 _______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 30 Nov 2021 14:09:43 +0000

>        Even if we assume that RP's should enforce this value's presence, I think the transition needs to be longer than that.  If a CA (call them EverTrust) puts in support for this feature on 4/1/23, you can't assume that a certificate issued by that CA on 12/1/22 without the EKU isn't valid for document signing.  A certificate whose issuance date is later than the CA's support date might be appropriately subject to an inference that it isn't valid for document signing, but not one issued before that date.

Sure.  I wasn’t trying to suggest specific dates or timelines, but rather that potential RP’s need to be aware of some issues when setting their compliance requirements and timelines.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 30 Nov 2021 14:13:44 -0500

On Tue, Nov 30, 2021 at 2:16 AM Stefan Santesson <[email-masked]> wrote:

> 2) One or more EKU + anyExtendedKeyUsage = Suitable for the listed usages
> but MAY be used for any purpose
>
> 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.

> 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