RFR: 8277246: No need to check about KeyUsage when validating a TSA certificate [v2]

[Michael StJohns]

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<weijun at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20211116/166139c0/attachment.htm>