On Wed, 17 Nov 2021 14:06:00 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: > > check either KU_SIGNATURE or KU_NON_REPUDIATION Marked as reviewed by mullan (Reviewer). > _Mailing list message from [Michael StJohns](mailto:mstjo...@comcast.net) on > [security-dev](mailto:security-...@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
