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