<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 11/16/2021 7:46 PM, Weijun Wang
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5gxBcuOJasvyy838GOcCzCqJWo-RJdeo4o9awoX2fZc=.efc8a35f-014e-40c5-9935-8e3a81009ce7@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="">
Really? The TSA is <a class="moz-txt-link-freetext" href="http://timestamp.digicert.com">http://timestamp.digicert.com</a> and the cert chain is
CN=DigiCert Timestamp 2021, O="DigiCert, Inc.", C=US
KeyUsage: DigitalSignature
ExtendedKeyUsages: timeStamping
CN=DigiCert SHA2 Assured ID Timestamping CA, OU=www.digicert.com, O=DigiCert Inc, C=US
KeyUsage: DigitalSignature, Key_CertSign, Crl_Sign
ExtendedKeyUsages: timeStamping
You mean this CA can be used for time stamping as well? I understand that when KU is using you can find out its usage in EKU (vice versa), but here it's a CA that can sign cert and CRLs. Does it really need to act as the end entity cert of a TSA server?
-------------
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>It doesn't need to act as an EE of a TSA server, but with those
markings it can. <br>
</p>
<p>Whoever issued these over marked them. I think their intent was
to say that this CA chain would issue time stamp issuing
certificates, but extendedKeyUsage contents are not transitive to
the subordinate certificates so that extension is pretty much
extraneous in a CA. That said, if you got a timestamp verifiable
by the public key in this CA certificate it would be valid (based
on the certificate only). The TSA RFC doesn't actually prohibit
having a basicConstraints ca=true extension. If I were verifying
a timestamp, I'd probably filter out any signatures from
certificates that are claiming to be CAs, but that's not strictly
according to standards.</p>
<p><br>
</p>
<p>If I were issuing this chain, there would be no extendedKeyUsage
extensions in the intermediate certificate(s), and the keyPurpose
would only be keyCertSign or keyCertSign,cRLSign depending. The
EE certificate would have eku {id-kp-timestamping} and ku {
digitalSignature } as I probably couldn't ensure non-repudiation
for the time stamp (not the data being wrapped by the timestamp
which is what the Rekor chain is trying to claim I think).<br>
</p>
<p><br>
</p>
<p>Hmm... while I was researching - I found this in RFC5280 -
4.2.1.12 defining extendedKeyUsage oids:</p>
<p>
<blockquote type="cite">
<pre class="newpage"> This extension indicates one or more purposes for which the certified
public key may be used, in addition to or in place of the basic
purposes indicated in the key usage extension. <u>In general, this
extension will appear only in end entity certificates.</u> This
extension is defined as follows</pre>
</blockquote>
</p>
<p>and <br>
</p>
<p>
<blockquote type="cite">
<pre class="newpage"> id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: <u>digitalSignature</u>
-- and/or <u>nonRepudiation</u></pre>
</blockquote>
</p>
<p>I hope that helps.</p>
<p><br>
</p>
<p>Mike</p>
<p><br>
</p>
</body>
</html>