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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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

 

You’re in a very good company! 😉

 

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

 

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

 

I guess that makes two things that worry me - 

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

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

 

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

 

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

 

Thanks

 

 

 

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

 

 

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