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
