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