Skip to main content
peterm59570637
peterm59570637
Participant
October 31, 2023
Question

Problem with signing with certificate without emailProtection EKU

  • October 31, 2023
  • 1 reply
  • 1021 views

we're having trouble to sign document in Adobe Acrobat Reader  (v. 2023 .006.20320) using a publicly trusted certificate with a key combination:

keyUsage=digitalSignature,keyEncipherment

extendKeyUsage = clientAuth

We see this certificate in Windows Digital IDs in Adobe Digital ID and Trusted Cerificate settings, but when we try to digitally sign the document, this certificate is not there in the "Sign with Digital ID" window to select the digital ID to use on signature.

 

If we use the same publicly trusted issuer and key combination:

keyUsage=digitalSignature, keyEncipherment

extendKeyUsage = clientAuth, emailProtection

everything works fine.

What is the reason for this behavior for Acrobat Reader which is not an email client application?

This topic has been closed for replies.

1 reply

MikelKlink
MikelKlink
Participating Frequently
October 31, 2023
quote

What is the reason for this behavior for Acrobat Reader which is not an email client application?

 

If you restrict EKU to clientAuth only, you shouldn't be surprised if software doesn't accept the certificate for document signing.

 

Generally, if you add keyUsage or extendedKeyUsage extensions to your certificates, you should expect that software decides whether or not your certificates are appropriate for a given usage based on those extension values.

 

Adobe Acrobat, for example, requires that (if the respective extension is present at all)

  • keyUsage shall have at least one of the values nonRepudiation and digitalSignature and
  • extendedKeyUsage shall have at least one of the values emailProtection, codeSigning, anyExtendedKeyUsage, and 1.2.840.113583.1.1.5 (Adobe Authentic Documents Trust)

to use a certificate for signing. See here for reference.

 

The selection of accepted EKU values may look a bit weird. It most likely developed because there is no commonly accepted EKU value for document signing (a number of institutions have introduced their own OIDs for that, e.g. Adobe and Microsoft, but neither is universally accepted). Thus, Adobe had to decide which common EKUs to accept and which not. One might not concur with their selection but it is reasonable to a degree. For example emails are not the same as PDF documents but they are similar enough.

peterm59570637
peterm59570637Author
Participant
November 7, 2023

Why do you think, that our certificate is restricted to the clientAuth only purpose?

 

In RFC 5280 (4.2.1.12 Extended Key Usage) is written:

"This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension.".

 

By my opinion this means that I can use this certificate:

1) for purpose which is set in Key Usage extension .e.g.  "digitalSignature" .

RFC 5280 in 4.2.1.3 states "The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), such as those used in an entity authentication service, a data origin authentication service, and/or an integrity service."

 

2) for additional purpose which is written in Extended Key Usage extension. e,g, for clientAuth, but no other Extended Key Usage for example id-kp-serverAuth; id-kp-codeSigning; id-kp-emailProtection; id-kp-timeStamping; id-kp-OCSPSigning etc.

 

There is no written in RFC 5280 that "Extended Key Usage" replace "Key Usage" extension. 

 

In 4.2.1.12. Extended Key Usage is also written:

"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." 

By my opinion this means that consistency is satisfied if I use this certificate only for the purpose  of "digitalSignature" or "clientAuth" and for nothing else. 

 

Adobe's approach to this is really strange, especially if it allows Key Usage to be combined with Extended Key Usage of the "digitalSignature type; anyExtendedKeyUsage" and does not allow the use of a stricter combination "digitalSignature; clientAuth" but allows the combination "digitalSignature; emailProtection" or "digitalSignature; codeSigning".

 

MikelKlink
MikelKlink
Participating Frequently
November 7, 2023
quote

In 4.2.1.12. Extended Key Usage is also written:

"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." 

By my opinion this means that consistency is satisfied if I use this certificate only for the purpose  of "digitalSignature" or "clientAuth" and for nothing else. 

 

Well, apparently Adobe has the opinion that the part after the one you bolded, "the certificate MUST only be used for a purpose consistent with both extensions," means that is does not suffice if the purpose is consistent with one extension but not the other one. That's also the interpretation I see in other software that cares about these extensions.

 

Also this interpretation has been documented by Adobe as represented in my previous answer for many years now, see the link there.

 

Whenever you issue or request a certificate for a new purpose, it makes sense to acquaint yourself with any restrictions existing for that purpose. You now have done so and can go ahead to issue or request certificates with appropriate properties.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices