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

[Ryan Sleevi <[e-mail]>]

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

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

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

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