Re: RFC 5280 Extended Key Usage - explanation

Yep, you're exactly right.  The vague definitions didn't help, and there was
also
quite a bit of drift and confusion about what exactly the scope of each EKU
was.

I don't know that starting over is feasible, though.  I think the best we
can do is
provide some of the missing EKUs, provide clear scopes and definitions for
them,
and encourage their use.  Like we are trying to do with kpDocumentSigning.
The 5G
NF EKUs that were newly allocated, instead of re-using and abusing existing
EKUs
is another great example of the right path forward, IMO.

If this means the older, less well-specified EKUs eventually go extinct, I
won't 
mourn their passing.

-Tim

> -----Original Message-----
> From: pkix <[email protected]> On Behalf Of Peter Gutmann
> Sent: Tuesday, November 21, 2023 1:28 AM
> To: Tim Hollebeek <[email protected]>; Russ
> Housley <[email protected]>; Peter Miškovič
> <[email protected]>
> Cc: IETF PKIX <[email protected]>
> Subject: Re: [pkix] RFC 5280 Extended Key Usage - explanation
> 
> Tim Hollebeek <[email protected]> writes:
> 
> >In theory, there should be separate EKUs for documents, client certs,
> >and email certs.  In practice, reuse of either emailProtection or
> >clientAuth for all three is embarrassingly common.
> 
> It's also because historically the eKU values have been hopelessly vague
(and
> they still are, at least up till 5280), so everyone made up their own
semantics.
> For example an SMTPS server could have id-kp-emailProtection set, an
> S/MIME app could have id-kp-emailProtection set, anti-malware software
> could have id-kp-emailProtection set (say to sign incoming messages that
had
> been scanned), and there are probably several more applications all of
which
> implement some form of email protection that could legitimately set id-kp-
> emailProtection for TLS, S/MIME, and digital signing.  I'd have to go
through a
> ton of old email to check all the unexpected but logical once explained
ways in
> which the eKUs can be applied.
> 
> Possibly a better option, given the hopeless cause of getting everyone to
> change the way they use the existing eKUs, is to define a new extension
with
> well-defined, narrow semantics for each key usage/purpose/whatever.  For
> example newEmailProtection would be for encrypting or signing email
> messages and nothing else.
> 
> Peter.
> 
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix