<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 11/16/2021 4:05 PM, Weijun Wang
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:jrBGUc1J-lr0yQHkpKF_QrHSecWH9brwWlC7H3iKWog=.515c2cff-6220-4baf-8186-52eca2b2327a@github.com">
<pre class="moz-quote-pre" wrap="">On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang <a class="moz-txt-link-rfc2396E" href="mailto:weijun@openjdk.org"><weijun@openjdk.org></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
clarify RFC requirement
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Hi Michael. Thanks for the comment. That was also our previous understanding but we are seeing timestamp returning by sigstore.dev (see the `rekor timestamp` command at <a class="moz-txt-link-freetext" href="https://github.com/sigstore/rekor">https://github.com/sigstore/rekor</a>) whose cert does not have the DigitialSignature bit set.
-----BEGIN CERTIFICATE-----
MIIBvzCCAWWgAwIBAgICBnowCgYIKoZIzj0EAwIwHzEdMBsGA1UEChMUaHR0cHM6
Ly9zaWdzdG9yZS5kZXYwHhcNMjExMTAyMTgxODI5WhcNMzExMTAyMTgxODI5WjAi
MSAwHgYDVQQKExdSZWtvciBUaW1lc3RhbXBpbmcgQ2VydDBZMBMGByqGSM49AgEG
CCqGSM49AwEHA0IABJIsOXOZUdgXhnNmvue9AAsxSYWdp+1HvEQQMYuZUsU0Ylf2
bKqIp3zVrc0a58pGJZvwGjyOHgY5lRevPP1huuOjgY0wgYowDgYDVR0PAQH/BAQD
AgZAMAwGA1UdEwEB/wQCMAAwDgYDVR0OBAcEBQECAwQGMB8GA1UdIwQYMBaAFIiV
AzEbE/rHgP3CA3x7tofqTtIcMCEGA1UdEQQaMBiHBH8AAAGHEAAAAAAAAAAAAAAA
AAAAAAEwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwgwCgYIKoZIzj0EAwIDSAAwRQIg
XdDBMPMTrtXiHmhFJOgQW8DDz/IaHkNZ+hXNL19dmuICIQCw3lE5+52F41kpY3B/
sJaPjuKmeIuEyYZDnMnlhHSusg==
-----END CERTIFICATE-----
-------------
PR: <a class="moz-txt-link-freetext" href="https://git.openjdk.java.net/jdk/pull/6416">https://git.openjdk.java.net/jdk/pull/6416</a>
</pre>
</blockquote>
<p>The certificate is either incorrect, or weird and correct. I
actually think its incorrect, but let's assume the latter and that
either of these two key purposes can be used. Change the check
to permit either of the two KUs in a KeyUsageExtension:</p>
<p><br>
</p>
<p>// insert around line 109.<br>
</p>
<p>private static final int KU_NON_REPUDIATION = 1; <br>
</p>
<p>// replace line 359.<br>
</p>
<p>if (checkKeyUsage (cert, KU_SIGNATURE) == false &&
checkKeyUsage(cert, KU_NON_REPUDATION) == false) {</p>
<p>From RFC5280: <br>
</p>
<p>
<blockquote type="cite">
<pre class="newpage">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.
The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures, other than signatures on
certificates (bit 5) and CRLs (bit 6), used to provide a non-
repudiation service that protects against the signing entity
falsely denying some action. In the case of later conflict, a
reliable third party may determine the authenticity of the signed
data. (Note that recent editions of X.509 have renamed the
nonRepudiation bit to contentCommitment.)</pre>
</blockquote>
<br>
</p>
<p>In any event, if you have a KU extension and it includes neither
of these bits, the certificate is invalid for timestamping. So
simply deleting the check is wrong.<br>
</p>
<p>I'll reach out again to my expert and let you know what I find
out.<br>
</p>
<p>Thanks - Mike<br>
</p>
<p><br>
</p>
</body>
</html>