Re: [pkix] RFC 5280 Extended Key Usage - explanation

[Tim Hollebeek <[e-mail]>]

This is true, but the docSigning EKU is new and not widely adopted yet.  I would encourage its rapid adoption where practical, for exactly this sort of reason.  Existing practices for key separation in the industry fall well short of what RFC 5280 anticipated and desired.

 

Here’s what’s going on.  The “must be processed independently” is referring to KUs and EKUs.  Since your KU is digitalSignature and all of your use cases (documents, www client, email) are all signature use cases, that KU is fine for all three cases.  You have verified that the KU (digitalSignature) matches the use (one of three digital signature use cases).  Everything is fine.

 

Then you examine the EKUs, _independent_ of the chosen KU.  This is where existing practice gets dicey.

 

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.  This happens because the document signing EKU never existed (we just fixed that very recently), and the relying party software for the other two uses cases either picked one or both and ran with them.  Strict compliance with RFC 5280 has not previously been a strong focus in either the client or email certificate markets, which is one of the things that has made the transition to the S/MIME BRs very challenging.

 

Trying to disentangle the mess between clientAuth and emailProtection is one of the reasons why the S/MIME BRs very intentionally restrict themselves to EKU=emailProtection *and* an email address appears in the certificate.  There’s some annoying legacy use cases that need to be allowed to continue for a bit.  Part of the problem is clientAuth is often confusingly entangled with serverAuth, which is also unhelpful.  This will probably be addressed at CABF at some point, probably by kicking clientAuth out of public trust.  That’s at least directionally what the browsers (e.g. Google) seem to be saying recently.

 

But anyway, this is mostly just historical context about why this is a mess, and the work that is being done to clean it up.  If people could start coalescing around using clientAuth, emailProtection, and documentSigning correctly, it would help clean up the industry a bit and make all three certificate ecosystems a bit less of a mess.

 

-Tim

 

From: pkix <[e-mail]> On Behalf Of Russ Housley
Sent: Monday, November 20, 2023 2:00 PM
To: Peter Miškovič <Peter.Miskovic=[e-mail]>
Cc: IETF PKIX <[e-mail]>
Subject: Re: [pkix] RFC 5280 Extended Key Usage - explanation

 

There is a document-signing extended key usage defined in RFC 9336 to resolve this ambiguity.

 

Russ

 





On Nov 13, 2023, at 2:27 AM, Peter Miškovič <Peter.Miskovic=[e-mail] <mailto:Peter.Miskovic=[e-mail]> > wrote:

 

Hello

 

I want to ask you for an explanation of this part of RFC5280:

 

4.2.1.12. Extended use of the key

 

"If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions."

 

Means this that if I have the "digitalSignature" extension in the Key Usage certificate and the "id-kp-clientAuth" extension in the Extended Key Usage extension, I can use such certificate for TLS WWW client authentication only and not for digitally signing documents, for example PDF?

 

Or it can be understood that I can use such certificate only for digitally signing or TLS WWW client authentication, but not for anything else, e.g. Email protection, code signing?

 

What does "then both extensions MUST be processed independently" mean, if I should take into account their common connection as a result?

 

Thank you in advance.

 

Regards

Peter Miskovic

---------------------------------

Peter Miskovic

CA Chief Operating Officer

 

Disig, a.s.

Zahradnicka 151, 821 08 Bratislava 2, Slovakia

 

phone  [phone]

cell phone [phone]

[e-mail] <mailto:[e-mail]> 

www.disig.sk <https://url.avanan.click/v2/___http:/www.disig.sk/___.YXAzOmRpZ2ljZXJ0OmE6bzozYTY3MmJjODNjMzgwMDFlN2UyZWQ2MGI4MjA1ZWIyODo2OmIyMjM6OGM4OWQ1OTQzZDVhMzc0M2Q0MzJkMjAzYTM2MzMyY2FhN2ZjZjk4NmM3NjZlNzdmMTNjOGY2MmY1MTI0NWZhOTpoOkY> 

_______________________________________________
pkix mailing list
 <mailto:[e-mail]> [e-mail]
 <https://url.avanan.click/v2/___https:/www.ietf.org/mailman/listinfo/pkix___.YXAzOmRpZ2ljZXJ0OmE6bzozYTY3MmJjODNjMzgwMDFlN2UyZWQ2MGI4MjA1ZWIyODo2OjM5ZWU6MWUyNGI0OTA1MzU1MTJmNWJmZDU4NDI1MTZiOTM1ZmI5MDBkNmYwMzBiM2Y0MjM0ZmE3MTUyNjkxZjAxODRlZjpoOkY> https://www.ietf.org/mailman/listinfo/pkix