RFR: 8277246: No need to check about KeyUsage when validating a TSA certificate

Michael StJohns mstjohns at comcast.net
Tue Nov 16 20:52:01 UTC 2021


On 11/16/2021 2:43 PM, Weijun Wang wrote:
> There is no need to check for the KeyUsage extension when validating a TSA certificate.
>
> A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit.
>
> -------------
>
> Commit messages:
>   - 8277246: No need to check about KeyUsage when validating a TSA certificate
>
> Changes:https://git.openjdk.java.net/jdk/pull/6416/files
>   Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=6416&range=00
>    Issue:https://bugs.openjdk.java.net/browse/JDK-8277246
>    Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
>    Patch:https://git.openjdk.java.net/jdk/pull/6416.diff
>    Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/6416/head:pull/6416
>
> PR:https://git.openjdk.java.net/jdk/pull/6416

I just ran this by one of the PKIX folk and this fix isn't correct.   
Basically, if a certificate has both an Extended Key Usage and a Key 
Usage extension  then they both have to be consistent with the actual 
purpose and both have to be checked. The former for the specific use 
described in the TSA document, and the latter for general use (RFC3280 
and 5280).

In this case, checkKeyUsage attempts to find  keyUsageExtension and if 
it's not present returns true (e.g. key usage is acceptable).  Otherwise 
it checks to see if there's a digitalSignature bit set, and if it's not 
set checkKeyUsage returns false.   The code as written (before the 
change) is correct.  Here's the utility method in EndEntityChecker.java

>     /**
> 220      * Utility method checking if bit 'bit' is set in this certificates
> 221      * key usage extension.
> 222      * @throws CertificateException if not
> 223      */
> 224     private boolean checkKeyUsage(X509Certificate cert, int bit)
> 225             throws CertificateException {
> 226         boolean[] keyUsage = cert.getKeyUsage();
> 227         if (keyUsage == null) {
> 228             return true;
> 229         }
> 230         return (keyUsage.length > bit) && keyUsage[bit];
> 231     }


It would be acceptable to have a certificate without a 
keyUsageExtension, but if the KUE is present, then the digitalSignature 
bit needs to be set.

Recommend backing out the change and closing the bug report as mistaken.


Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20211116/8421e5e3/attachment.htm>


More information about the security-dev mailing list