Subject: [lamps] Document Signing EKU

From: Sean Turner <[email-masked]>
Date: Wed, 7 Jul 2021 23:02:55 -0400

Hi! Tadahiko ITO and Tomofumi Okubo created an I-D that defines a "document signing” EKU. They asked me to review and I think it is a fine idea. I am working on an ASN.1 module to add to the I-D (hope to get the -01 version in by the deadline Monday). Would there be 5min of time available on the agenda to discuss and gauge WG interest?

spt

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 09 Jul 2021 14:17:54 -0400

On Wed 2021-07-07 23:02:55 -0400, Sean Turner wrote:
> Hi! Tadahiko ITO and Tomofumi Okubo created an I-D that defines a
> "document signing” EKU. They asked me to review and I think it is a
> fine idea. I am working on an ASN.1 module to add to the I-D (hope to
> get the -01 version in by the deadline Monday). Would there be 5min of
> time available on the agenda to discuss and gauge WG interest?

fwiw, I'd be interested in hearing about the goals for this, whether it
happens in the synchronous LAMPS meeting or on the mailing list.

digitalSignature KU bit in combination with the id-kp-emailProtection
EKU offer at least one flavor of "document signing" semantics (for the
subset of documents that happen to be rfc822-style messages with
end-to-end cryptographic signatures on them), so i'm interested in
understanding how that would intersect with this new proposed EKU, since
there's a potential for overlap.

For example, should a MUA accept a signature on a message that has
digSig + this new "document signing" EKU but not id-kp-emailProtection?
What are the places where a verifier could/should reliably *reject* a
signature from a certificate that does *not* have the proposed "document
signing" EKU?

        --dkg

---

From: Eliot Lear <[email-masked]>
Date: Fri, 9 Jul 2021 20:23:43 +0200

> there's a potential for overlap.

Indeed this is what we did for MUD (RFC8520).

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 9 Jul 2021 20:29:45 +0200

Just to clarify- we do "digitalSignature" but not with 
id-kp-emailProtection.

Eliot

On 09.07.21 20:23, Eliot Lear wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 9 Jul 2021 19:37:02 +0000

KU gives the spectrum of acceptable usages for the given key. 

EKU narrows it down to the listed (included) applications.

Therefore, if EKU for a Signature key is specified – then, interpreting the rules strictly:
“EmailProtection” is necessary for email signature to validate successfully by email clients (e.g., Thunderbird, Outlook, Apple Mail);
“DocumentSigning” is necessary for a signature on document (e.g., on a PDF file or form) to validate successfully (by, e.g., Adobe Acrobat);
Both are necessary if the key is used to both sign documents and emails;
Neither of these allows using this key to authenticate to a web server or to login to a workstation.

In real life, I’ve seen all kinds of screw-ups with applications [mis-]interpreting the rules and making all kinds of crazy decisions from EKU…

--

Regards,

Uri

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

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

                                                                                                                                     -  C. A. R. Hoare

From: Spasm <[email-masked]> on behalf of Eliot Lear <[email-masked]>
Date: Friday, July 9, 2021 at 14:31
To: Daniel Kahn Gillmor <[email-masked]>, Sean Turner <[email-masked]>, LAMPS <[email-masked]>, Russ Housley <[email-masked]>, Tim Hollebeek <[email-masked]>
Subject: Re: [lamps] Document Signing EKU

Just to clarify- we do "digitalSignature" but not with id-kp-emailProtection.

Eliot

Eliot

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 9 Jul 2021 16:34:05 -0400

> digSig + this new "document signing" EKU but not id-kp-emailProtection?

Explicitly: No.

> signature from a certificate that does *not* have the proposed "document

So I'm not sure how best to answer this question, but hopefully, by
describing a little, we can see if it provides better insight, both to the
motivations and what is likely the answer.

As others have highlighted, keyUsage effectively encapsulates the "logical"
action - e.g. digitalSignature vs keyCertSign - while EKU, in practice,
serves as a form of protocol identifier to mitigate the risk of
cross-protocol attacks. In particular, you want to minimize the risk that
an operation performed with a key in one protocol (e.g. signing in protocol
X) is not misinterpreted within another protocol. TLS has a similar concept
at the protocol layer, namely ALPN, to ensure different encrypted protocols
are not conflated, and also further takes steps in the CertificateVerify
message to ensure padding of the data-to-be-signed [1] and this is
effectively the same concept, for key hygiene.

What is the right "measure" of a protocol is an interesting question: for
example, should all CMS messages be considered a singular EKU, or do
different CMS messages (e.g. Microsoft Authenticode signatures vs S/MIME
messages) deserve different treatment? This is an open question for this
draft: for example, it seeks to better distinguish keys used in CMS for
emails from keys used for CMS in documents; this is, conceptually, similar
to the CADeS vs PADeS differences within Europe, recognizing that there are
different technical expressions and needs.

One area that probably bears discussion is figuring out whether the
proposed document signing EKU would also extend to things such as XML
documents (e.g. using XML-DSIG rather than CMS), since both XML and PDF can
be considered "documents", or whether it's meant to better encapsulate the
protocol-level differences and relying-party semantic/capability
differences.

In the abstract theory of PKIX, policy identifiers are further used to
distinguish between different application/trust realms using the same
protocol; for example, different use cases using (and providing as input to
the RFC 5280 validation algorithm) different policy OIDs to express
different requirements, while still consistently expecting at the protocol
level a digitalSignature keyUsage and a id-kp-serverAuth extendedKeyUsage,
but this has not seen wide implementation in the majority of PKIX
implementations. This is a topic that's probably sore for past PKIX
participants, because it comes up every decade it seems, but many widely
used applications, including the core cryptographic libraries of Microsoft
Windows, Apple's {mac,watch,tv,i}OS, Google Android, and Linux (via Mozilla
NSS, which is part of the Linux Standard Base), instead use the EKU to
signal both "policy-and-protocol"; e.g. "id-kp-serverAuth" implies
"complies with OS policy expectations for TLS, usable for TLS". As it
relates to this suggested draft, that has further implications on what
exactly "documentSigning" is meant to convey policy wise, if anything; for
example, is it meant to encompass something broad, like "Complies with
{Adobe, PDF reader vendor} policy expectations for document signing, usable
for document signing", or is it meant to convey something more abstract.

[1] https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.3

---

From: David von Oheimb <[email-masked]>
Date: Sun, 11 Jul 2021 08:01:40 +0200

> EKU narrows it down to the listed (included) applications.
Not quite - EKU is in general not a refinement of KU.
As stated in RFC 5280:
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12
the EKUs are independent of the basic KUs and MUST be evaluated
independently of them:

   This extension indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the key usage extension.

   If a certificate contains both a key usage extension and an extended
   key usage extension, then both extensions MUST be processed
   independently and the certificate MUST only be used for a purpose
   consistent with both extensions. 

>  Therefore, _if_ EKU for a Signature key is specified – then,
> interpreting the rules strictly:
>
>   * “EmailProtection” is necessary for email signature to validate
>     successfully by email clients (e.g., Thunderbird, Outlook, Apple
>     Mail);
>   * “DocumentSigning” is necessary for a signature on document (e.g.,
>     on a PDF file or form) to validate successfully (by, e.g., Adobe
>     Acrobat);
>   * Both are necessary if the key is used to both sign documents and
>     emails;
>   * Neither of these allows using this key to authenticate to a web
>     server or to login to a workstation.
>
Right.

Yet note that EmailProtection meant not only for signature use (for the
cert of the email sender,
but also for encryption use (for the cert of the email recipient). See
the same section of RFC 5280:

   id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
   -- Email protection
   -- Key usage bits that may be consistent: digitalSignature,
   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)

>  In real life, I’ve seen all kinds of screw-ups with applications
> [mis-]interpreting the rules and making all kinds of crazy decisions
> from EKU…
>
Indeed.

On 09.07.21 22:34, Ryan Sleevi wrote:
>  As others have highlighted, keyUsage effectively encapsulates the
> "logical" action - e.g. digitalSignature vs keyCertSign - while EKU,
> in practice, serves as a form of protocol identifier to mitigate the
> risk of cross-protocol attacks.

EKU provides higher-level constraints on the key use (or the cert
holder) than basic KU.
It can be used to restrict application domains or protocol use or
anything else
or to express capabilities or permissions of the certificate holder, for
instance id-kp-cmcRA certifies authority to act as an RA.
An EKU semantics is entirely up to the party defining it.

> documents (e.g. using XML-DSIG rather than CMS), since both XML and
> PDF can be considered "documents", or whether it's meant to better
> encapsulate the protocol-level differences and relying-party
> semantic/capability differences.

Yes, such things should be clarified.

> This is a topic that's probably sore for past PKIX participants,
> because it comes up every decade it seems, but many widely used
> applications, including the core cryptographic libraries of Microsoft
> Windows, Apple's {mac,watch,tv,i}OS, Google Android, and Linux (via
> Mozilla NSS, which is part of the Linux Standard Base), instead use
> the EKU to signal both "policy-and-protocol"; e.g. "id-kp-serverAuth"
> implies "complies with OS policy expectations for TLS, usable for TLS".

The interpretation of id-kp-serverAuth and id-kp-clientAuth has become
particularly fuzzy.
According to RFC 5280 and its predecessors, their intended meaning was
specifically the used in WWW servers and clients:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

Although clearly restricted to WWW use, over the years, the
interpretation of id-kp-{serverAuth,clientAuth} has widened
to general HTTPS (in particular, secure web service connections) used
and even further to general to TLS server/client use.
Would have been good to updated the official interpretation of these
EKUs or provide more general EKUs (e.g., it-kp-TLS-server).

    David

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 11 Jul 2021 11:44:29 +0000

Not quite - EKU is in general not a refinement of KU.
As stated in RFC 5280: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12
the EKUs are independent of the basic KUs and MUST be evaluated independently of them:
   This extension indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the key usage extension.

Thank you for quoting the “offending” RFC.
 
So, a cert can be used only for a purpose that’s a conjunction of KU and EKU ranges – i.e., one narrows down the other.

·         “EmailProtection” is necessary for email signature to validate successfully by email clients (e.g., Thunderbird, Outlook, Apple Mail);

·         “DocumentSigning” is necessary for a signature on document (e.g., on a PDF file or form) to validate successfully (by, e.g., Adobe Acrobat);

·         Both are necessary if the key is used to both sign documents and emails;

·         Neither of these allows using this key to authenticate to a web server or to login to a workstation.

Right.

Yet note that EmailProtection meant not only for signature use (for the cert of the email sender,
but also for encryption use (for the cert of the email recipient). See the same section of RFC 5280:
   id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
   -- Email protection
   -- Key usage bits that may be consistent: digitalSignature,
   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)
 
Yes. So two certs with EKU=EmailProtection, one with KU=KeyEncipherment, and the other one with KU=DigitalSignature/NonRepudiation, can be used to correspondingly encrypt and sign email…
 
Are you aware of other similar cases, where KU further constrains what EKU specified, rather than the other way around?

 As others have highlighted, keyUsage effectively encapsulates the "logical" action - e.g. digitalSignature vs keyCertSign - while EKU, in practice, serves as a form of protocol identifier to mitigate the risk of cross-protocol attacks.

EKU provides higher-level constraints on the key use (or the cert holder) than basic KU.
It can be used to restrict application domains or protocol use or anything else 
or to express capabilities or permissions of the certificate holder, for instance id-kp-cmcRA certifies authority to act as an RA.
An EKU semantics is entirely up to the party defining it.

Yeah. I keep forgetting that one can define new EKUs at will…

One area that probably bears discussion is figuring out whether the proposed document signing EKU would also extend to things such as XML documents (e.g. using XML-DSIG rather than CMS), since both XML and PDF can be considered "documents", or whether it's meant to better encapsulate the protocol-level differences and relying-party semantic/capability differences.

Why wouldn’t “EKU=SignDocuments” (defined as-is) be good enough for any kind of document, XML, PDF, RTF, or whatever?

This is a topic that's probably sore for past PKIX participants, because it comes up every decade it seems, but many widely used applications, including the core cryptographic libraries of Microsoft Windows, Apple's {mac,watch,tv,i}OS, Google Android, and Linux (via Mozilla NSS, which is part of the Linux Standard Base), instead use the EKU to signal both "policy-and-protocol"; e.g. "id-kp-serverAuth" implies "complies with OS policy expectations for TLS, usable for TLS". 

The interpretation of id-kp-serverAuth and id-kp-clientAuth has become particularly fuzzy. .  .  .  .  .

Although clearly restricted to WWW use, over the years, the interpretation of id-kp-{serverAuth,clientAuth} has widened
to general HTTPS (in particular, secure web service connections) used and even further to general to TLS server/client use.
Would have been good to updated the official interpretation of these EKUs or provide more general EKUs (e.g., it-kp-TLS-server).

I would prefer updating the official interpretation of these EKUs to match their de-facto usage.

---

From: David von Oheimb <[email-masked]>
Date: Sun, 11 Jul 2021 16:36:57 +0200

On 11.07.21 13:44, Blumenthal, Uri - 0553 - MITLL wrote:
>    independently *and* *the certificate MUST only be used for a purpose*
> *   consistent with both extensions*. 
>  

I presume you meant: official :)

> So, a cert can be used only for a purpose that’s a conjunction of KU
> and EKU ranges – i.e., _one narrows down the other_.
Well, if one insists in using "narrow down", it must be seen/mentioned
in both directions.
It is misleading just to state that EKU narrows down KU because this
sounds like there is a semantic hierarchy between them,
for instance that KU=digitalSignature would only be fine with EKUs that
specialize this to digital signatures of certain things, like emails or
documents.
Yet this is not the case, which is also witnessed by
id-kp-emailProtection: it can be used also for certs that allow
non-signature operations.
IMO it's more straightforward and adequate to say that EKU and KU are in
general independent of each other (while  for many KUs and EKUs there
are certain connections).

>     ·         “EmailProtection” is necessary for email signature to
>     validate successfully by email clients (e.g., Thunderbird,
>     Outlook, Apple Mail);
>
>     ·         “DocumentSigning” is necessary for a signature on
>     document (e.g., on a PDF file or form) to validate successfully
>     (by, e.g., Adobe Acrobat);
>
>     ·         Neither of these allows using this key to authenticate
>     to a web server or to login to a workstation.
>
> Right.
>
> Yes. So two certs with EKU=EmailProtection, one with
> KU=KeyEncipherment, and the other one with
> KU=DigitalSignature/NonRepudiation, can be used to correspondingly
> encrypt and sign email…

Yes, though usually a cert that includes id-kp-emailProtection allows
for digitalSignature (plus maybe nonRepudiation) and (at least one of)
keyEncipherment or keyAgreement.
Note that such a cert could also contain arbitrary further EKUs, which
may require the inclusion of further KUs in order to make the cert
usable for extra purposes that they entail.

>  Are you aware of other similar cases, where KU further constrains
> what EKU specified, rather than the other way around?
For the specific case of id-kp-emailProtection, RFC 5280 appears to
constrain the set of KUs that can be used with it, but the wording "that
may be consistent" is rather vague.
Concerning the other direction, generic standards like RFC 5280 cannot
limit in advance which EKUs are allowed for which KU because there is
the freedom to defined arbitrary EKUs,
Yet there are certain KU values that semantically exclude certain EKUs.
For instance, encipherOnly+keyAgreement means that the subject public
key may be used *only* for enciphering data while performing key agreement,
which is not consistent with id-kp-codeSigning, id-kp-timeStamping,
id-kp-OCSPSigning (as also stated in that section),
and it certainly would not make sense with any document signing EKU,
neither.

>     "logical" action - e.g. digitalSignature vs keyCertSign - while
>     EKU, in practice, serves as a form of protocol identifier to
>     mitigate the risk of cross-protocol attacks.
>
> or to express capabilities or permissions of the certificate holder,
> for instance id-kp-cmcRA certifies authority to act as an RA.
>     One area that probably bears discussion is figuring out whether
>     the proposed document signing EKU would also extend to things such
>     as XML documents (e.g. using XML-DSIG rather than CMS), since both
>     XML and PDF can be considered "documents", or whether it's meant
>     to better encapsulate the protocol-level differences and
>     relying-party semantic/capability differences.
>
> Why wouldn’t “EKU=SignDocuments” (defined as-is) be good enough for
> _any_ kind of document, XML, PDF, RTF, or whatever?
>
I agree that an id-kp-documentSigning should cover all kinds of
"documents" (but it should be make clear what a document is meant to be,
e.g., an email likely does not count here, and certainly a certificate
does not count as a document) simply because the name is that general.
(Of course, if someone defined, e.g., id-kp-PDFSigning, this would cover
just PDFs).

>     applications, including the core cryptographic libraries of
>     Microsoft Windows, Apple's {mac,watch,tv,i}OS, Google Android, and
>     Linux (via Mozilla NSS, which is part of the Linux Standard Base),
>     instead use the EKU to signal both "policy-and-protocol"; e.g.
>     "id-kp-serverAuth" implies "complies with OS policy expectations
>     for TLS, usable for TLS".
>
> particularly fuzzy. .  .  .  .  .
>
> to general HTTPS (in particular, secure web service connections) use
> and even further to general TLS server/client use.
> Would have been good to update the official interpretation of these
Me too.  There is an erratum for exactly that:
https://www.rfc-editor.org/errata/eid5802
And in my view it is an omission that this was not done already long
ago, at the latest when bringing up RFC 5280, obsoleting 3280.

    David

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 11 Jul 2021 13:31:06 -0400

On Sun, Jul 11, 2021 at 7:44 AM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> Why wouldn’t “EKU=SignDocuments” (defined as-is) be good enough for *any*
> kind of document, XML, PDF, RTF, or whatever?
>
As my original message tried to convey, because you want to avoid
cross-protocol attacks: i.e. where Message Foo in protocol X is interpreted
as Message Bar in protocol Y.

The fact that these potentially use CMS detached signatures is irrelevant:
many file formats are ambiguous polyglots that can be contextually
interpreted as different things [1]. This is no different to, say, how you
can write C++ code that is valid PHP code through the use of pre-processor
macros.

The goal of the EKU is this context is to convey the logical file format
that is encapsulating the message, so that two messages meant to be
conveyed in different formats are not confused. And, as my previous message
tried to convey as well, that the EKU conveys any protocol-specific
assumptions, as Policy OIDs are widely unsuitable and unused for that task
vs EKU.

S/MIME can at least refer back to IETF RFCs somewhat unambiguously, but
“documents” is a very broad category (XML, PDF, Microsoft Word, etc), just
like “code signing” is (Microsoft Authenticode, Apple Gatekeeper, Linux
kernel modules), each with very different constraints. The goal in
providing an EKU, when these arguably came-and-should be
vendor-specific/application-specific EKUs, is to ensure interoperability
between client implementations, and that means explicitly specifying and
stating the priors for CAs, users, and relying parties to understand the
expectations for such certificates, and with sufficient detail as to
mitigate cross-protocol attacks.

[1]
https://github.com/corkami/docs/blob/master/talks.md

---

From: Eliot Lear <[email-masked]>
Date: Sun, 11 Jul 2021 19:34:40 +0200

EKUs are so poorly used that adding additional fine grain control seems 
sort of pointless.  This having been said, if we are going to go there, 
then we should talk about validation mechanisms.

Eliot

On 11.07.21 19:31, Ryan Sleevi wrote:
>
>
> On Sun, Jul 11, 2021 at 7:44 AM Blumenthal, Uri - 0553 - MITLL 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Why wouldn’t “EKU=SignDocuments” (defined as-is) be good enough
>     for _any_ kind of document, XML, PDF, RTF, or whatever?
>
> cross-protocol attacks: i.e. where Message Foo in protocol X is 
> interpreted as Message Bar in protocol Y.
>
> The fact that these potentially use CMS detached signatures is 
> irrelevant: many file formats are ambiguous polyglots that can be 
> contextually interpreted as different things [1]. This is no different 
> to, say, how you can write C++ code that is valid PHP code through the 
> use of pre-processor macros.
>
> The goal of the EKU is this context is to convey the logical file 
> format that is encapsulating the message, so that two messages meant 
> to be conveyed in different formats are not confused. And, as my 
> previous message tried to convey as well, that the EKU conveys any 
> protocol-specific assumptions, as Policy OIDs are widely unsuitable 
> and unused for that task vs EKU.
>
> S/MIME can at least refer back to IETF RFCs somewhat unambiguously, 
> but “documents” is a very broad category (XML, PDF, Microsoft Word, 
> etc), just like “code signing” is (Microsoft Authenticode, Apple 
> Gatekeeper, Linux kernel modules), each with very different 
> constraints. The goal in providing an EKU, when these arguably 
> came-and-should be vendor-specific/application-specific EKUs, is to 
> ensure interoperability between client implementations, and that means 
> explicitly specifying and stating the priors for CAs, users, and 
> relying parties to understand the expectations for such certificates, 
> and with sufficient detail as to mitigate cross-protocol attacks.
>
> [1]
> <https://github.com/corkami/docs/blob/master/talks.md>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 11 Jul 2021 13:38:11 -0400

> then we should talk about validation mechanisms.
I’m not really sure I see any actionable feedback there, nor am I familiar
with your concerns here. Can you perhaps provide something more concrete
and less anecdotal?

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 11 Jul 2021 20:57:44 +0000

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

From: Spasm <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Date: Sunday, July 11, 2021 at 13:31
To: Uri Blumenthal <[email-masked]>
Cc: LAMPS <[email-masked]>, Ryan Sleevi <[email-masked]>, David von Oheimb <[email-masked]>, Sean Turner <[email-masked]>, Russ Housley <[email-masked]>, Tim Hollebeek <[email-masked]>, Daniel Kahn Gillmor <[email-masked]>, Eliot Lear <[email-masked]>
Subject: Re: [lamps] Document Signing EKU

On Sun, Jul 11, 2021 at 7:44 AM Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote: 

As my original message tried to convey, because you want to avoid cross-protocol attacks: i.e. where Message Foo in protocol X is interpreted as Message Bar in protocol Y.

I respectfully disagree that this is a good or even valid use case for EKU.

The fact that these potentially use CMS detached signatures is irrelevant: many file formats are ambiguous polyglots that can be contextually interpreted as different things [1]. 

[1] 

Ref. [1] – TL;DR. 

This is no different to, say, how you can write C++ code that is valid PHP code through the use of pre-processor macros.

You either trust the signer, or you don’t. Are you trying to say that you’d trust the signer to provide valid C++ code but wouldn’t accept PHP from him? I don’t think I understand your point.

The goal of the EKU is this context is to convey the logical file format that is encapsulating the message, so that two messages meant to be conveyed in different formats are not confused. And, as my previous message tried to convey as well, that the EKU conveys any protocol-specific assumptions, as Policy OIDs are widely unsuitable and unused for that task vs EKU.

It's an admirable goal, but I do not believe it’s realistic, for practical reasons.

S/MIME can at least refer back to IETF RFCs somewhat unambiguously, but “documents” is a very broad category (XML, PDF, Microsoft Word, etc), just like “code signing” is (Microsoft Authenticode, Apple Gatekeeper, Linux kernel modules), each with very different constraints. The goal in providing an EKU, when these arguably came-and-should be vendor-specific/application-specific EKUs, is to ensure interoperability between client implementations, and that means explicitly specifying and stating the priors for CAs, users, and relying parties to understand the expectations for such certificates, and with sufficient detail as to mitigate cross-protocol attacks.

The likeliest result of multiplying EKUs would be (IMHO) exactly the opposite – breakdown in interoperability.

EKUs are so poorly used that adding additional fine grain control seems sort of pointless.  This having been said, if we are going to go there, then we should talk about validation mechanisms.

I’m not really sure I see any actionable feedback there, nor am I familiar with your concerns here. Can you perhaps provide something more concrete and less anecdotal?

The actionable feedback (IMHO) is avoiding proliferation of extra-fine-grained (excessively fine-grained, I’d say – but I guess our opinions differ here) EKUs, as they would probably bring more harm than good. As evidenced by the current use of the current EKUs.

My short summary:
You can absolutely use as many of vendor-specific/application-specific EKUs as you care to. 
E.g., defining them in an individually-submitted Informational RFC.
I highly doubt others would find them useful, but I speak only for myself.
If you define your “special” EKU as Critical – rest assured your certs won’t be usable outside of your administrative domain. But that’s your choice.
If you leave them non-Critical – most likely the majority of the software (and people) around would simply ignore them, but in this case at least your certs would be usable outside of your department or company.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 11 Jul 2021 23:10:36 +0200

My actionable feedback is that if you are going to get any more granular 
on then what is there with any new EKUs, before proceeding we should ask 
the question about how one should expect validation of a CSR to take place.

Eliot

On 11.07.21 19:38, Ryan Sleevi wrote:
>
>
> On Sun, Jul 11, 2021 at 1:34 PM Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     EKUs are so poorly used that adding additional fine grain control
>     seems sort of pointless.  This having been said, if we are going
>     to go there, then we should talk about validation mechanisms.
>
>     Eliot
>
> I’m not really sure I see any actionable feedback there, nor am I 
> familiar with your concerns here. Can you perhaps provide something 
> more concrete and less anecdotal?
>

---

From: Russ Housley <[email-masked]>
Date: Sun, 11 Jul 2021 17:33:50 -0400

Eliot:

For any of the EKU values, I would expect the CA to confirm that the subject or subjectAltName is appropriate for the associated application.  In the case of signing a PDF, what do you imagine?  If the PDF represents a legal transaction, there might be more significant identify requirements than for a PDF that contains say software documentation that is being signed for integrity purposes.  I do not see these distinctions being imposed on the EKU OID.

Russ

> On Jul 11, 2021, at 5:10 PM, Eliot Lear <[email-masked]> wrote:
> 
> My actionable feedback is that if you are going to get any more granular on then what is there with any new EKUs, before proceeding we should ask the question about how one should expect validation of a CSR to take place.
> 
> Eliot
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 11 Jul 2021 21:48:12 +0000

For any of the EKU values, I would expect the CA to confirm that the subject or subjectAltName is appropriate for the associated application.  

Yes, sure… So…?

In the case of signing a PDF, what do you imagine?  If the PDF represents a legal transaction, there might be more significant identify requirements than for a PDF that contains say software documentation that is being signed for integrity purposes.  I do not see these distinctions being imposed on the EKU OID.

Why should there be distinctions? It is merely the question of how well the CA validates the client before issuing the certificate, and, presumably, a request for certificate used for “more important” cases (e.g., legal transactions) would go through more scrutiny (and carry more trust!) than a request for a “junk” cert. But it’s the matter of CA, not of the individual attributes of that cert…

What is your preferred way of dealing with this?  Having EKU=”SignJunkDocuments”, EKU=”SignDocuments”, and EKU=”SignLegalDocsPDFOnly”?

---

From: Eliot Lear <[email-masked]>
Date: Sun, 11 Jul 2021 23:49:20 +0200

Hi Russ,

Yes, I slipped a step there.  I was thinking SANs not EKUs.

Eliot

On 11.07.21 23:33, Russ Housley wrote:
> Eliot:
>
> For any of the EKU values, I would expect the CA to confirm that the 
> subject or subjectAltName is appropriate for the associated 
> application.  In the case of signing a PDF, what do you imagine?  If 
> the PDF represents a legal transaction, there might be more 
> significant identify requirements than for a PDF that contains say 
> software documentation that is being signed for integrity purposes.  I 
> do not see these distinctions being imposed on the EKU OID.
>
> Russ
>
>
>> On Jul 11, 2021, at 5:10 PM, Eliot Lear <[email-masked] 
>> My actionable feedback is that if you are going to get any more 
>> granular on then what is there with any new EKUs, before proceeding 
>> we should ask the question about how one should expect validation of 
>> a CSR to take place.
>>
>> Eliot
>>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Jul 2021 16:13:32 -0400

> more concrete and less anecdotal?

I too would like that, particularly on:

    > interpreted as Message Bar in protocol Y.

I hear about such concerns, but I've never heard of a real example of this.

Maybe the EO about reporting attacks will help someone collect real world
examples of this.

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

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 12 Jul 2021 02:09:51 -0400

> Maybe the EO about reporting attacks will help someone collect real world

These are widely discussed within IETF and CFRG; perhaps you’re just
following different discussions?

The links I provided, both for TLS and corkami’s work, provided real world
examples. TLS 1.3’s design is specifically to mitigate these. If you
clicked the links further, you would have seen PoC|GTFO 0x14 as just one
example: a PDF that also functions as an NES ROM, which happens to… print
its own MD5.

Ignoring MD5, the many ways a PDF can be interpreted, and the many uses of
detached signatures, mean it would be fundamentally unwise and recklessly
insecure to simply introduce a “document signing” EKU. We can, should, and
need to do better.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 12 Jul 2021 02:21:00 -0400

> the question about how one should expect validation of a CSR to take place.
Thanks for clarifying. I would disagree that the validation or CSR at are
all relevant.

What is relevant, and where clearly there’s a lack of consensus on this
point, is figuring out what a client application is required to parse,
support, and understand. The semantics of the information conveyed is, for
the most part, irrelevant, and secondary at best.

What does matter is how to interpret the signed data - what the format is
and the semantics conveyed by the messages, and what relying parties need
to support. As a simple example, does AIA use rsync, like the RPKI, or does
it use HTTP, like web PKI? Does your protocol rely on online checking, like
OCSP, or offline checking, like CRLs? Do you use counter signatures like
timestamping? These are exactly the semantics that every modern PKIX
implementation attaches to the EKU, whether or not some folks finding that
unseemly.

We would probably agree that specifying these things, whether validation or
capabilities, is the role of a policy authority. After the boondoggles of
efforts like PEM, it’s clear policy is not the IETF’s strong suit. Combined
with the cross-protocol concerns, which are fundamentally security concerns
that must be addressed, is why I’m not supportive of a generic “document
signing” EKU without specifying the profile. Such a profile MUST consider
both the documents themselves, such as an unambiguous format or an input
that provides sufficient format context, and the capabilities of the PKI
clients, such as protocols supported or behaviours expected.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 12 Jul 2021 13:36:53 -0400

> On 11.07.21 13:44, Blumenthal, Uri - 0553 - MITLL wrote:
 […]
> usable for extra purposes that they entail.

I think it's worth reinforcing Uri's point here that the same X.509
certificate is generally *discouraged* from being used for both signing
and encryption or key agreement, for similar reasons as avoiding
overloading EKUs for a single key: you don't want to use the same
cryptographic key material for distinct protocols, to avoid possible
unfortunate interactions between one protocol and another.

The sample certificates in
https://datatracker.ietf.org/doc/draft-ietf-lamps-samples/ are
deliberately given only one usage, and the active correspondents are
expected to have multiple certificates if they are supposed to engage in
both signing/verification and encryption/decryption.

I recognize that there are a lot of S/MIME certificates out there that
aim to do both -- typically using a single RSA asymmetric key.  But at
least within LAMPS where we're providing some amount of guidance to
implementers and deployers we ought to be clear that the multi-use certs
described by David above are not best practice.

          --dkg

---

From: Eliot Lear <[email-masked]>
Date: Tue, 13 Jul 2021 06:45:54 +0200

Hi,

> unfortunate interactions between one protocol and another.

This has been discussed somewhat in EMU regarding resumption. For 
documents, it would be good to understand the risks a bit better.

Eliot

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 13 Jul 2021 16:41:32 -0400

> documents, it would be good to understand the risks a bit better.

I think you're talking about work in the EAP Method Update WG -- can you
point to the specific discussion?  Or, if you mean some other EMU, which
one?

If you're asking about the risks of reusing document signing keys for
encryption-capable keys, you might want to dig around in the references
of Paterson et al's "On the Joint Security of Encryption and Signature,
Revisited" from 2011: https://eprint.iacr.org/2011/486

that paper talks about the overall concerns about using the same key for
encryption and signature, and proposes schemes that are believed to be
secure in this joint use, but they are not the same as the range of
public key schemes typically used in a LAMPS context, using some
identity-based encryption constructs i'm not familiar with.

If you're talking about concerns with differentiating signatures over
documents vs. signatures in other contexts, i think the discussion is
different: is it possible to craft, say, a PDF that wants signing that
can itself be interpreted as an e-mail message body?

    --dkg

---

From: Alan DeKok <[email-masked]>
Date: Tue, 13 Jul 2021 17:35:09 -0400

On Jul 13, 2021, at 4:41 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> Signed PGP part

  EMU.  Partially addressed in https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-18

  The point there is that it doesn't make a lot of sense to have the same certificate for both EAP and HTTP.  I don't see any other cross-protocol issues, though,

  Alan DeKok.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 13 Jul 2021 22:00:03 +0000

> The point there is that it doesn't make a lot of sense to have
> the same certificate for both EAP and HTTP.

I find it very hard to assign a certificate to a "protocol" rather than to a "purpose". Purpose being "authenticate the client", "sign a document", etc. 

> I don't see any other cross-protocol issues, though

Likewise.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 13 Jul 2021 18:23:20 -0400

On Tue, Jul 13, 2021 at 6:00 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> I find it very hard to assign a certificate to a "protocol" rather than to
> a "purpose". Purpose being "authenticate the client", "sign a document",
> etc.

The point is that the protocol and the purpose are one and the same.

The concern is when one logical "purpose" (e.g. "authenticate a server")
can lead to ambiguous outputs due to cross-protocol attacks. We saw this,
for example, with early drafts of QUIC and TLS 1.3. The purpose
(authenticating a server) was thwarted by how the different protocols made
use of the key material. [1]

I'm not sure where the disconnect here is, given that it's widely
understood in the IETF that cross-protocol attacks are a matter of concern.
Similarly, the choice of formats is relevant: formats that rely on
variations of "content sniffing" to interpret the context of the message
are walking security disasters. Browsers widely suffered from an entire
class of attacks related to this, and still (to this day) are working to
better secure users against such issues [3]. PDFs are, for example, a
format extremely germane to polyglot interpretations, as previously
provided.

If "sign a document" means that {opaque series of bytes} is interpreted as
"Document A" in Format Foo, but "Document B" in Format Bar, then you've
failed to achieve the purpose of sign a document - because you've signed an
ambiguous series of bytes that can represent multiple documents, and it's
unclear which (or if both) were intended. As security professionals, we
know better in 2021, I would hope.

[1]
https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf
[2] https://en.wikipedia.org/wiki/Content_sniffing
[3]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 13 Jul 2021 22:31:11 +0000

> the same certificate for both EAP and HTTP.

I find it very hard to associate a certificate with a "protocol" rather than with a "purpose". Purpose being "authenticate the client", "sign a document", etc.

I’m afraid they aren’t. 

Consider my typical use case: a hardware token (e.g., PIV) with 4 slots:

Authentication – to authenticate me to a web site, or login to a workstation;
Digital Signature – to sign with non-repudiation whatever it is (PDF, Word document, email, etc.);
Encryption – encrypt emails, files and filesystems, whatever else;
Card Auth, like for badge reader on the door.

How do you propose I deal with this reality? Get a token with 50 certs in 50 slots, because there are that many different protocols, file formats, etc. etc.?

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 13 Jul 2021 18:55:25 -0400

On Tue, Jul 13, 2021 at 6:31 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

>    1. Authentication – to authenticate me to a web site, or login to a
>    workstation;
>    2. Digital Signature – to sign with non-repudiation whatever it is
>    (PDF, Word document, email, etc.);
>    3. Encryption – encrypt emails, files and filesystems, whatever else;
>    4. Card Auth, like for badge reader on the door.
>
>
>
> How do you propose I deal with this reality? Get a token with 50 certs in
> 50 slots, because there are that many different protocols, file formats,
> etc. etc.?
>

Yes.

If we have learned anything about this "typical use case" over the past 25
years, is that it's a reasonable, well-intentioned, but insecure approach.

This is why, when you look at modern approaches to key management and
secure hardware (e.g. FIDO), you see situations like "a unique key for
every security principal" (e.g. in the Web, a unique key for every
origin/site/domain boundary).

I understand that the religious differences on non-repudiation (nee content
commitment) may mean we aren't able to make progress, but having a document
signed that says both "Attack at dawn" and "Retreat" does not satisfy the
necessary conditions of document signing. The protocol and the purpose are
inextricably bound together; document signing needs to express both the
content and the context. EKUs are that context, even when CMS is that
content.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 14 Jul 2021 06:12:38 -0400

<snip>The protocol and the purpose are inextricably bound together; document signing needs to express both the content and the context. EKUs are that context, even when CMS is that content.

Where CMS is the content, there is a spec that defines (too granular) constraints – RFC 6010 CMS Content Constraints. Unlike EKU as defined in 5280, this was defined to be processed across a certification path. This mechanism is more concrete than EKU, but attribute constraints can get messy.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Jul 2021 09:25:46 -0400

> I find it very hard to assign a certificate to a "protocol" rather than to a "purpose". Purpose being "authenticate the client", "sign a document", etc. 

  I've been doing RADIUS for way too long now.  It's a "authentication" protocol.  But I don't know what you mean by "authenticate the client".

  This is not entirely being obtuse.  Your identity (or authenticity) means essentially nothing.  The context is important.

  As a practical example, I regularly work with people who want to allow employees VPN access, WiFi access, wired access, API access, etc.  All of these systems will "authenticate the client".  But that's only a tiny portion of the problem.  It's easy to authenticate someone.  The hard part is authorization.

  i.e. who is allowed to access the VPN?  How about "only critical people during business hours, but then everyone can get one hour the rest of the time".  Authentication is implied in that statement.  But while authentication is necessary, it's not sufficient.

  I remember discussing related issues in SECDIR years ago.  People were say "You have an identity".  I responded by pulling out my wallet with hotel key, credit cards, health insurance card, drivers license, etc.  Which one of those is my identity?

  The reality is that you have multiple identities or roles.  Your "authenticity" for each one is strongly tied to your authorization.

  I just submitted a document to EMU which discusses this issue, as part of addressing larger issues with EAP.  There's a section on multiple certs, and how authorization is tied to authentication:

https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-usability-00#section-7.3.3

  Back to RADIUS, we've increasing found it simple to just dump authorization information into certificates.  That way the design scales, and there's no back-end (slow) databases to check.  Instead, each user has a different certificate (identity) for each role (authorization).  They're all administratively tied back to the same person, but the protocols treat each role as a separate authentication.

  Alan DeKok.

---

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

On Wed, Jul 14, 2021 at 9:26 AM Alan DeKok <[email-masked]>
wrote:

>
>   Back to RADIUS, we've increasing found it simple to just dump
> authorization information into certificates.  That way the design scales,
> and there's no back-end (slow) databases to check.  Instead, each user has
> a different certificate (identity) for each role (authorization).  They're
> all administratively tied back to the same person, but the protocols treat
> each role as a separate authentication.

I agree with most of your message, but in any well-managed PKI, this
snipped part simply isn’t true. As an authentication mechanism, perhaps,
but not at all for authorization.

The use of certificates requires either that you design the authorization
system to be short-lived, which means your clients need to frequently
obtain new credentials (e.g. like Keberos), or you have to design in
revocation mechanisms such that your servers can check to ensure the
authorization is fresh. This is a closed system, zero-sum: the history of
PKI is that you can either “pay me now (issuance) or pay me later
(revocation)”, and designs are simply trying to optimize for steady case
and worst case, no different than any other algorithmic design.

Systems exist to try to shuffle the deck chairs - OCSP stapling to try to
push the cost of (slow) databases to the peer, long-lived CRLs that are
distributed out-of-band, automation of issuance for shorter lifetimes, but
it’s still the same system. Certificates do not escape these constraints;
the very design of X.509 has always been with the assumption of needing a
back-end database to check (The Global Directory then, “the repository”
now).

---

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

There is a little Radius-centricism here.  Radius largely (tho not 
entirely) focuses L2/L3 connectivity, for which access authorization is 
unlikely to change all that often (though it definitely does a bit).  
This also holds true for certain classes of IoT devices, where standards 
like IEC 62443-3 might be satisfied with certificate extensions for 
authorization.

But if you're deep into the app layer, the authorization model is 
considerably more complex than most certificate based approaches can 
handle.  We don't want a system to have to issue a new cert just because 
I shared a document with you.  The IETF has spent an awful lot of time 
on OAUTH.

Eliot

On 14.07.21 16:33, Ryan Sleevi wrote:
>
>
> On Wed, Jul 14, 2021 at 9:26 AM Alan DeKok <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     authorization information into certificates.  That way the design
>     scales, and there's no back-end (slow) databases to check. 
>     Instead, each user has a different certificate (identity) for each
>     role (authorization).  They're all administratively tied back to
>     the same person, but the protocols treat each role as a separate
>     authentication.
>
>
> snipped part simply isn’t true. As an authentication mechanism, 
> perhaps, but not at all for authorization.
>
> The use of certificates requires either that you design the 
> authorization system to be short-lived, which means your clients need 
> to frequently obtain new credentials (e.g. like Keberos), or you have 
> to design in revocation mechanisms such that your servers can check to 
> ensure the authorization is fresh. This is a closed system, zero-sum: 
> the history of PKI is that you can either “pay me now (issuance) or 
> pay me later (revocation)”, and designs are simply trying to optimize 
> for steady case and worst case, no different than any other 
> algorithmic design.
>
> Systems exist to try to shuffle the deck chairs - OCSP stapling to try 
> to push the cost of (slow) databases to the peer, long-lived CRLs that 
> are distributed out-of-band, automation of issuance for shorter 
> lifetimes, but it’s still the same system. Certificates do not escape 
> these constraints; the very design of X.509 has always been with the 
> assumption of needing a back-end database to check (The Global 
> Directory then, “the repository” now).
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 14 Jul 2021 15:28:18 +0000

>      I've been doing RADIUS for way too long now.  It's a "authentication" protocol.  But I don't know what you mean by "authenticate the client".

"Authenticate the client" means establish that the peer on the other end of this secure pipe is the entity you know about, either
 - "explicitly", e.g., finding its DN or SAN inside your "clients database", or
 - "implicitly", e.g., anybody whose certificate (with the appropriate KU and EKU) is issued by a specific CA - for example, a CA that my organization runs (that issues credentials only to validated employees).

>      This is not entirely being obtuse.  Your identity (or authenticity) means essentially nothing.  The context is important.

My identity is the only reasonable and secure way to enter the the Authorization process.

>      As a practical example, I regularly work with people who want to allow employees VPN access,
>      WiFi access, wired access, API access, etc.  All of these systems will "authenticate the client".
>      But that's only a tiny portion of the problem. 

Of course. But it happens to be the portion relevant to this discussion, is it not?

>     It's easy to authenticate someone.  The hard part is authorization.

Of course. Authenticating someone is necessary but insufficient for deciding what to allow that authenticated individual. 

If you think that certificates, or more specifically, EKU, are going to solve that hard problem for you, I'm afraid I have bad news... ;-)

>      I remember discussing related issues in SECDIR years ago.  People were say "You have an identity".
>      I responded by pulling out my wallet with hotel key, credit cards, health insurance card, drivers license, etc.
>      Which one of those is my identity?

Congratulations - you've been diagnosed with Multiple Personalities! __ 

Seriously, instead of having a single identity and several "authorization back-ends", you have multiple IDs with the implicit authorization policy: "if I can authenticate you within my stovepipe'd ecosystem, you are authorized". E.g., if your key matches the lock, you are allowed to open it... __   So...?

There are better ways to deal with this, than messing up the EKU.

>      The reality is that you have multiple identities or roles.  Your "authenticity" for each one is strongly tied to your authorization.

In general, yes - though not always. Today several Web sites do a better authorization job than "if I know you - aka, your cert chains back to one of my trusted root Cas and validates - you are allowed".

>      I just submitted a document to EMU which discusses this issue, as part of addressing larger issues with EAP.
>      There's a section on multiple certs, and how authorization is tied to authentication:

Your draft suggests encoding the authorization info int eh EKU. It does not make sense to me. You can have as many attributes in a certificate as you wish, so no need to pollute the EKU attribute.

NB: In general, the current cryptographic wisdom has been to keep authentication and authorization separate. 

>      Back to RADIUS, we've increasing found it simple to just dump authorization information into certificates.

This is normally done by adding attrubutes *other than EKU* to the certificate, and often works quite well. 
The hope behind this approach is that the authorization doesn't change faster than the certificate, i.e., that it's economical to re-issue the certificate when the authorization scope changes.

>     That way the design scales, and there's no back-end (slow) databases to check.  Instead, each user has a different
>     certificate (identity) for each role (authorization).  They're all administratively tied back to the same person, but
>     the protocols treat each role as a separate authentication.

No offense meant, but I find this approach insane from the practical point of view. Maintaining a ton of certificates is an unreasonable burden for an individual user, and infeasible to put on hardware tokens. Of course, if every user of yours has only one or two "roles" at most, then today's smartcards can accommodate.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Jul 2021 11:51:59 -0400

> My identity is the only reasonable and secure way to enter the the Authorization process.

  My point is that you have multiple ways of proving your identity.  And from a practical perspective, each method of proving your identity is generally tied to specific kinds of authorization.

> If you think that certificates, or more specifically, EKU, are going to solve that hard problem for you, I'm afraid I have bad news... ;-)

  They won't solve it, but they should help narrow the scope of the problem.

> In general, yes - though not always. Today several Web sites do a better authorization job than "if I know you - aka, your cert chains back to one of my trusted root Cas and validates - you are all…

  Yes, there's a lot more to authorization than that.  To be honest, I've found the authorization capabilities of web server to be bafflingly limited.  But I come from a background where people demand essentially infinite control over authorization decisions.

> Your draft suggests encoding the authorization info int eh EKU. It does not make sense to me. You can have as many attributes in a certificate as you wish, so no need to pollute the EKU attribute.

  I'm not sure how this is "polluting" the EKU.  The suggestions in the draft are there in large part because of claims that using certs with id-kp-serverAuth EKU for non-web purposes was forbidden.  The only possible solution then is to use a different EKU.

> The hope behind this approach is that the authorization doesn't change faster than the certificate, i.e., that it's economical to re-issue the certificate when the authorization scope changes.

  That is true for most network access methods, which is why the document suggests it.

  And note that the authorization in the document is *not* user authorization such as "assigning user to VLAN" or "time of day restrictions", or "bandwidth limits".  It's "can we use this certificate hierarchy for a particular purpose"

  There are huge problems with current use of certificates and CA stores.  CA stores are largely only WWW stores, and are global.  i.e. they are not application-specific.  This makes it difficult to use private CAs for specific purposes.  Which means then if an admin installs a new root CA on your device, that root CA can issue certs which claim to be Google.  And no one will notice.

  The draft gets into these issues in great detail.

> No offense meant, but I find this approach insane from the practical point of view. Maintaining a ton of certificates is an unreasonable burden for an individual user, and infeasible to put on hard…

  But this is exactly what we do today. People have many passwords.  If people don't remember these passwords, they use password managers.  These password managers typically also manage certificates.  It's proven to be at least adequate.

  My draft explains how it's possible to ease the burden of managing these certificates, by automating much of the process.  Which means that it's simpler, and very much likely to be more secure.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Jul 2021 11:58:40 -0400

On Jul 14, 2021, at 10:33 AM, Ryan Sleevi <[email-masked]> wrote:
> On Wed, Jul 14, 2021 at 9:26 AM Alan DeKok <[email-masked]> wrote:
> 
> I agree with most of your message, but in any well-managed PKI, this snipped part simply isn’t true. As an authentication mechanism, perhaps, but not at all for authorization.

  That model is widely deployed in EAP-TLS.  Without exaggerating too much, it's implemented on billions of devices.

> The use of certificates requires either that you design the authorization system to be short-lived, which means your clients need to frequently obtain new credentials (e.g. like Keberos), or you have to design in revocation mechanisms such that your servers can check to ensure the authorization is fresh.

  For EAP-TLS, this is discussed in https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

  Authorization checks are separate from checks for certificate validity.  The result is perhaps not a complete elimination of database queries.  But in practice there's a substantial reduction in them.

  Alan DeKok.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 14 Jul 2021 17:09:11 -0400

On Tue 2021-07-13 18:23:20 -0400, Ryan Sleevi wrote:
> unclear which (or if both) were intended.

The same is true even for the simplest signatures over text/plain
content that neglects to indicate the intended charset.  I documented a
simple example of this for "inline" OpenPGP signatures years ago:

  https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/#tampering

I'm sure there are more clever substitutions possible (especially if we
get to invent new character encodings after the bytestream is signed!),
but it took minimal effort to find the example there.

> As security professionals, we know better in 2021, I would hope.

Amen.  The lesson is that any signature verification needs to proceed in
a fully-specified and mutually-understood context, or else there's room
for shenanigans.

That's why we're having this discussion, i hope.

    --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 14 Jul 2021 17:57:28 -0400

> My identity is the only reasonable and secure way to enter the the Authorization process.

FWIW, this idea is actively challenged in several contexts, mostly over
concerns about privacy.

In particular, for things like government identities or even W3C's
verifiable credentials [0], "selective disclosure" of attributes is a
desirable feature, since it allows the credential holder to demonstrate
authorization without creating a linkable trail of usage.

[0] https://www.w3.org/TR/vc-data-model/

The classic American example of selective disclosure is for the
credential holder to prove that they are over 21 years old when
purchasing alcohol.  There is no reason to require the liquor store
owner to learn the identity of the purchaser (or even to be able to link
the purchaser to their previous purchases).

Other cryptographic schemes useful for authorization that don't require
identity information for the verifier include the venerable blind
signature [1] and more recent developments like privacypass [2].

[1] https://en.wikipedia.org/wiki/Blind_signature
[2] https://privacypass.github.io/

The ISO's recent proposed standard for mobile drivers licenses (ISO
18013-5 [3]) appears to contemplate using both X.509 certificates (for
document signer "DS") *and* selective disclosure of attributes for the
mDL holder, though the drafts i've been able to get my hands on don't
appear to contemplate doing selective disclosure directly over X.509
material. (it's not clear how that would even work even if they wanted
to; X.509 isn't friendly to anything but full credential disclosure)

[3] https://www.iso.org/standard/69084.html

(note that there is a designated EKU for mDL DS, which i think is
intended to be 1.0.18013.5.1.2)

I don't think selective disclosure of attributes, or blinded signatures
are immediately relevant in all LAMPS contexts, but i hope folks
desiging and deploying cryptographic systems that make authorization
decisions are thinking about the privacy impact.  We should definitely
not assume from the get-go that identity or authentication is the only
reasonable entry point for authorization.

      --dkg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 14 Jul 2021 22:17:22 +0000

The concern you're describing is real. The apparently-proposed solution, IMHO, is not. Are you proposing a separate cert for, e.g., signing every possible document format over every possible protocol that can carry it? N^2...?

On 7/14/21, 17:31, "Spasm on behalf of Daniel Kahn Gillmor" <[email-masked] on behalf of [email-masked]> wrote:

        --dkg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 14 Jul 2021 22:33:14 +0000

On 7/14/21, 17:58, "Spasm on behalf of Daniel Kahn Gillmor" <[email-masked] on behalf of [email-masked]> wrote:

>    > My identity is the only reasonable and secure way to enter the the Authorization process.

>    concerns about privacy.

Yes, that is true. There are many contexts, in which I want to authenticate as "anonymous me possessing this verifiable attribute".

Funny enough, I published a paper on this subject several years ago. It didn't seem to catch a lot of interest. ;-)

The basic observations were:

An "identity" is a set of attributes;
Different attributes are controlled by different entities or hierarchies, it does not make sense forcing a central point of control (or failure);
Often there is a need to present together more than one verifiable "attribute"; 
There's benefit in being able to prove that all the presented attributes belong to the same principal.

Proposed solution was to use Attribute Certificates:

Each hierarchy would issue its own attribute certificate, e.g.
Your telephone carrier would certify the attribute "phone number";
Your employer would certify (separate!) attributes "employed at ..." and "salary is ...";
Etc...
User would provide his public key – that would serve as a “stem” for all those attributes to tie to
This public key would change as frequently as the user wants;
The attributes update process should (in most cases) be automatic.

It seems to beat the SAML approach – you don’t need to have all the parties online and available when you’re verifying the “credential”.

It seems better than a large set of disjoint certificates, each for its own purpose.

It would burden the responsible entities (e.g., banks, employers) to maintain public-faced PKI...

Would be interesting to hear comments.

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 14 Jul 2021 18:56:25 -0400

On Wed, Jul 14, 2021 at 6:18 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> The concern you're describing is real. The apparently-proposed solution,
> IMHO, is not. Are you proposing a separate cert for, e.g., signing every
> possible document format over every possible protocol that can carry it?
> N^2...?

I certainly am proposing such for each logically distinct {format and trust
framework}. This is nothing new: this is how virtually every modern
protocol or format deploys certificates. Your Secure Boot UEFI certificates
are going to be different than your USB-C certificates, which may be for a
Qi charging device that has its own certificates, while also conveying a
“Made for iPhone” (MFi) certificate. Certs - and keys - are cheap, whether
they’re for meat people, legal people, or machine people.

I am not, for example, suggesting different certs for PDF-via-TLS vs
PDF-via-SMTP as being inherently necessary.

However, for situations like “PDF structured according to specification A”
and “PDF structured according to specification B”, or “PDF used with
technical-and-policy framework X” (including being designed around
assumptions provided via an online protocol like TLS) and “PDF used with
technical-and-policy framework Y” (including being designed around
assumptions for an offline protocol like SMTP-delivered messages), yes,
those can and should be separate certificates.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 15 Jul 2021 03:43:24 +0000

➢ Certs - and keys - are cheap, whether they’re for meat people, legal people, or machine people.

Certs are cheap. Managing them, unfortunately, is not.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Jul 2021 06:43:40 +0200

bingo.  That'd be a really good discussion to have.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 16 Jul 2021 09:42:02 -0400

> This public key would change as frequently as the user wants;

I see no reason why each attribute would need to share a public key in
this scheme -- a shared public key ends up creating a re-linkable
through-line that might not be an "identity" in the formal legal sense,
but is certainly enough to learn a lot about someone.

But by now i guess we're pretty far afield from LAMPS, so i'll drop this
fork of the thread.

    --dkg

---

From: David von Oheimb <[email-masked]>
Date: Fri, 16 Jul 2021 16:10:47 +0200

Hi Daniel, Uri, Russ, et al.,

On 12.07.21 19:36, Daniel Kahn Gillmor wrote under the subject "[lamps]
Document Signing EKU":
>>> Yet note that EmailProtection meant not only for signature use
>>> (for the cert of the email sender),
>>> Yes. So two certs with EKU=EmailProtection, 
>>> one with KU=KeyEncipherment, and 
>>> the other one with KU=DigitalSignature/NonRepudiation, 
>>> can be used to correspondingly encrypt and sign email…

Good that you mention this as a caveat - I know and agree that using
certs for multiple purposes is not recommendable.

Yet my point here was a different one, namely more fundamentally on the
semantics of EKUs vs. KUs,
and this brought in the possibility of having multiple EKUs in a single
cert as a side topic.

Being at this topic (and having adapted the subject of my email), here
is a related question:
In case an EKU extension contains multiple OIDs, are these to be
interpreted strictly independently?

I suppose the answer is "yes" because
one cannot expect that all users of such a cert know and handle all EKU
OID included.

In particular, one may wonder:
how should a user/verifier handle the case that a cert has an EKU
extension marked critical
which contains multiple EKU( OID)s and the user/verifier knows only part
of them?

RFC 5280 section 4.2
<https://datatracker.ietf.org/doc/html/rfc5280#section-4.2> (Certificate
Extensions) states the general semantics of "critical":

>    A certificate-using system MUST reject the certificate if it encounters
>    a critical extension it does not recognize or a critical extension
>    that contains information that it cannot process. 
RFC 5280 section 4.2.1.12
<https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12>
(Extended Key Usage) adds the following:

   This extension MAY, at the option of the certificate issuer, be
   either critical or non-critical.

   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.  If multiple purposes are
   indicated the application need not recognize all purposes indicated,
   as long as the intended purpose is present.

>From this one can infer that at least critical EKU extensions must not
influence each other.

On 11.07.21 22:57, Blumenthal, Uri - 0553 - MITLL wrote:

> If you define your “special” EKU as Critical – rest assured your certs
> won’t be
> usable outside of your administrative domain. But that’s your choice.
I suppose this remark was meant only for the case of having a single EKU
included.
In case a cert contains a critical EKU extension including both such a
"special" (private) EKU
and a well-known one, such as "id-kp-codeSigning", the cert should still
be fine in a code signing
use case, regardless whether any included further "special" EKUs can be
interpreted or not.

Does this independence hold also for non-critical EKUs, such that they
must not influence each other?
This semantic independence should also rule out that any EKU excludes
other purposes,
for example that a "special" EKU prohibits the use of the cert for, say,
code signing,
right?

    David

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 16 Jul 2021 12:21:26 -0400

On Fri, Jul 16, 2021 at 10:11 AM David von Oheimb <[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12> (Extended
> Key Usage) adds the following:
>
> EKU does not attach additional semantics to 'criticality' above and beyond
extensions.

That is, unlike say Name Constraints (RFC 5280, Section 4.2.1.10), which
includes the following language:

   If a name constraints extension that is marked as critical
   imposes constraints on a particular name form, and an instance of
   that name form appears in the subject field or subjectAltName
   extension of a subsequent certificate, then the application MUST
   either process the constraint or reject the certificate.

and

   However, if an application encounters a critical name
   constraints extension that specifies other values for minimum or
   maximum for a name form that appears in a subsequent certificate, the
   application MUST either process these fields or reject the
   certificate.

No such language exists with respect to EKU. The only requirement is that
anyExtendedKeyUsage being present means the extension SHOULD NOT be marked
critical. RFC 5280 doesn't even prohibit anyEKU from being present in
addition to other EKUs, for better or worse - and that's left to consumers
(such as the CA/Browser Forum) to further profile down.

> From this one can infer that at least critical EKU extensions must not
Yes, this is explicit in 4.2.1.12

   If multiple purposes are

> must not influence each other?
Yes

> for example that a "special" EKU prohibits the use of the cert for, say,
Yes

---

From: David von Oheimb <[email-masked]>
Date: Fri, 16 Jul 2021 18:47:41 +0200

Thanks Ryan for the confirmation!

    David

On 16.07.21 18:21, Ryan Sleevi wrote:
>
>     From this one can infer that at least critical EKU extensions must
>     not influence each other.
>
>     Does this independence hold also for non-critical EKUs, such that
>     they must not influence each other?
>
> Yes
>
>     This semantic independence should also rule out that any EKU
>     excludes other purposes,
>     for example that a "special" EKU prohibits the use of the cert
>     for, say, code signing,
>     right?
>
> Yes

---

From: Deb Cooley <[email-masked]>
Date: Mon, 26 Jul 2021 13:41:17 -0400

I'm ridiculously late to this thread, but I found it to be a super
interesting discussion.

And polite.  refreshing...

Deb Cooley
[email-masked]

On Thu, Jul 15, 2021 at 12:44 AM Eliot Lear <[email-masked]> wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Jul 2021 17:58:02 -0400

>> Certs are cheap. Managing them, unfortunately, is not.

If I may summarize my understanding:

1) some people say that we should never mix certificates for multiple uses.
   That EKUs are good, because they force people to mint new certificates
   for new uses.

2) other people point out that while integers are infinite, managing the
   certificates comes at a significant cost, and so allowing people to
   use the same certificate for multiple things is good.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 26 Jul 2021 22:09:59 +0000

Yes and no. In general, the fewer "uses" a certificate has - the better, _within the practical reason_.

Mixing purposes, like using the same cert for signing and encrypting - is not a good idea.

On the other hand, using the same cert for signing PDF documents, Word files, plaintext, XML files - it not that big a deal, and most sane people and organizations I know of fully approve of that practice. 
One reason - as you said, managing certificates comes at a (often significant) cost, especially when hardware tokens are involved.

A widely-deployed example - government PIV token that has room for 4 certificates: Auth (Web, workstation, whatever), Digital Signature (sign docs, emails, whatever), Encryption (encrypt files, keys, emails, whatever), (badge cert to unlock doors, etc). Seems to work fine...