<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 11/16/2021 5:58 PM, Michael StJohns
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:88b0f16a-1ab4-8cc2-f092-c3cb1c2d2d6b@comcast.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true"><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" moz-do-not-send="true">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" moz-do-not-send="true">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> </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>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>
</blockquote>
<p>According to the guy who wrote RFC5280, nonRepudiation (aka
contentCommitment) is a valid alternative for a keyUsage that
pairs with an extended key usage of id-kp-timestamping. I'd add a
check that requires one or the other or both if a KeyUsage
extension exists.</p>
<p>I added a note to the Rekor CA repository, hopefully at the
correct location suggesting they set both bits going forward.
This was code they published only back in May.</p>
<p>Mike</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>