On 11/16/2021 5:58 PM, Michael StJohns wrote:
On 11/16/2021 4:05 PM, Weijun Wang wrote:
On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang<wei...@openjdk.org> 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.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
clarify RFC requirement
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 athttps://github.com/sigstore/rekor) 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:https://git.openjdk.java.net/jdk/pull/6416
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:
// insert around line 109.
private static final int KU_NON_REPUDIATION = 1;
// replace line 359.
if (checkKeyUsage (cert, KU_SIGNATURE) == false && checkKeyUsage(cert,
KU_NON_REPUDATION) == false) {
From RFC5280:
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.)
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.
I'll reach out again to my expert and let you know what I find out.
Thanks - Mike
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.
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.
Mike
