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

[Ryan Sleevi <[e-mail]>]

On Thu, Jul 29, 2021 at 2:18 PM Carl Wallace <[e-mail]>
wrote:

> Do you share the same concerns regarding certificatePolicies?
>
> [CW] Isn’t this apples and oranges given there is nothing like
> user-initial-policy-set for EKU? Maybe there should have been, but there
> wasn’t.
>

No.

It's a fair comparison for two points:

1) The concern about multiple certificates (with different EKUs) is just as
applicable to multiple certificates (with different certificate policies).
That is, if we accept certificatePolicies as designed (e.g. with
user-initial-policy-set used by relying parties), then we're implicitly
saying we accept multiple certificates. I'm aware of policyMappings as a
way to try to reduce that, but that doesn't remove the multiple
certificates risk. So if that's the angst for Uri, then it's an entirely
unreasonable position to hold in light of RFC 5280.

2) The point is that, as widely implemented (e.g. in virtually every modern
OSS library, as well as the widely used OS libraries), EKU functionally
behaves as the user-initial-policy-set for the relying party application.
That is, the industry has *not* widely adopted certificatePolicies for this
purpose, and has long used EKU - predating the work of PKIX itself,
initially through custom vendor-specific extensions (Netscape and
Microsoft, respectively), and then through EKU. The "rough consensus and
running code", as it were, already uses EKU as this set.

So that's why the comparison here: We can disagree on abstract spec purism,
but that doesn't reflect the implemented reality, and an argument against
EKUs for fear of multiple certificates is logically inconsistent with the
very design of RFC 5280, and so is equally irrational. If
certificatePolicies are accepted as a RP-specific community attribute, then
EKU poses no further additional risk for proliferation than
certificatePolicies. And if they're somehow rejected, that's logically
consistent a position, but inconsistent with the specification and reality.