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

[Ryan Sleevi <[e-mail]>]

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

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

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

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

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

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

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

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

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

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