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

From: Tadahiko Ito <[email-masked]>
Date: Tue, 27 Jul 2021 23:16:10 +0900

Thanks Sleevi

>>* id-kp-emailProtection corresponds to the use of CMS (RFC 5652) as used
by S/MIME (RFC 8551)
I love to see those correspondances in the real world.
If certs were for SMIME, OID should be id-kp-emailProtection.
However, Certs with id-kp emailProtection does not mean certs are used for
SMIME.
We might not able to make clear 100%, but should be able to make it better.
That was the starting point of our proposal.

I think we need a concept like Basket Clause that does not have a negative
impact on other OIDs.
I understand that this OID alone may not be that valuable, but I think that
this OID is valuable to ensure the soundness of other OIDs.

If after several years, other EKUs for protocol specific Document sign were
assigned (although that would not be our job at least at IETF) and used as
common practice,
it will be great, and we will be happy to obsolete this EKU.
However, in the meantime, we strongly believe that this would be a viable
option for those who want to limit the usage to document signing without
substituting the EKU with id-kp-emailProtection or id-kp-codesigning.

Regards Tadahiko Ito

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 27 Jul 2021 11:03:06 -0400

On Tue, Jul 27, 2021 at 10:16 AM Tadahiko Ito <[email-masked]>
wrote:

> I understand that this OID alone may not be that valuable, but I think
> that this OID is valuable to ensure the soundness of other OIDs.
>

This is conflating several problems, and unfortunately, seems to
misunderstand the concerns raised.

"That does not have a negative impact on OIDs" is not an expression of
positive value. It's a negative impact *in and of itself*, because it fails
to provide any insight into a relying party on the appropriate or
inappropriate uses of the private key, in terms of protocols or
capabilities. It unquestionably is a matter of local policy.

The second half - "this OID is valuable to ensure the soundness of other
OIDs" - is an example of misstating the problem. If your goal is to ensure,
for example, that id-kp-emailProtection is only used for certain protocols,
and you believe that in practice, the specifications are unclear about
this, then that's a problem that has multiple solutions.

> If after several years, other EKUs for protocol specific Document sign
> were assigned (although that would not be our job at least at IETF) and
> used as common practice,

The problem here is this is as close as we get to a problem statement, and
it's unclear what path forward there is for "rough consensus and running
code" with the draft as specified. This is something that we can and should
have clear before adopting the draft as a WG item - without understanding
not only who will read the draft, but who will implement it, is key. To
that end, some semblance of what relying party software is being targeted,
and what it is expected to do, is key to understanding the scope of the
document. The need for this is key: I do not believe this document is
within scope of our charter, and understanding this scope is key to
discussing whether we should recharter.

I don't disagree that the CA/Browser Forum S/MIME Chartered Working Group
is interested in this. This is primarily because relying party software
makes use of the EKU to distinguish technical capabilities and purposes
(e.g. TLS vs S/MIME), which software vendors then use in lieu of
certificate policies to supervise the scope of their trust programs. It's
quite clear that any adoption of this EKU is greenfield, and so it's
entirely reasonable to question whether EKU or certificatePolicies is more
appropriate, given that we're not beholden to past baggage. Even if we
presume that EKU is appropriate, however, we still need to distinguish what
the necessity for separation is: is it purely policy, or is it to ensure
that the cryptographic key material attested by the certificate is not used
to enable cross-protocol attacks through confused deputy. To effectively do
that, we need to identify what protocols we're imagining being used here.
However, in both cases, for the CA/Browser Forum, it's entirely within its
remit to specify a CA/Browser Forum specific OID to express this: there is
no gain in interoperability through the IETF doing so, and there is no harm
to interoperability through the CA/Browser Forum doing so, when the entire
point is "a group of software vendors/relying party applications detailing
what OIDs to use to interoperate with their specific relying party needs".