RFR: 8277246: Check for NonRepudiation as well when validating a TSA certificate [v3]

[Sean Mullan]

On Wed, 17 Nov 2021 14:06:00 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:
> 
>   check either KU_SIGNATURE or KU_NON_REPUDIATION

Marked as reviewed by mullan (Reviewer).

> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
> 
> On 11/16/2021 7:46 PM, Weijun Wang wrote:
> 
> It doesn't need to act as an EE of a TSA server, but with those markings it can.
> 
> 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.

I agree that having a CA act as a TSA is probably a bad idea. However, I don't think this particular CA is acting as a TSA, just looks like they overmarked it as you say.

In any case, I agree we should allow the KU of a TSA cert to be absent or if present it must contain a non-repudiation and/or digitalSignature bit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6416