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

[Carl Wallace <[e-mail]>]

<snip>

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.

 

[CW] Then write *that* spec so that we cut out the folklore stuff and all work from the same sheet of music. It’s not abstract spec “purism”, it’s what the spec says. Make it say something different.