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

[Deb Cooley <[e-mail]>]

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

I'm not sure that we (by this I mean US DOD) need this per se, at least
I've not heard it asked for.  I suspect we (again DOD) are doing this today
merely w/ the DS KU (and maybe a timestamp piece).

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

Deb Cooley
[e-mail]



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
>