On 11/16/2021 7:46 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
Really? The TSA ishttp://timestamp.digicert.com 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:https://git.openjdk.java.net/jdk/pull/6416
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.
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).
Hmm... while I was researching - I found this in RFC5280 - 4.2.1.12
defining extendedKeyUsage oids:
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._In general, this extension
will appear only in end entity certificates._ This
extension is defined as follows
and
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent:_digitalSignature_
-- and/or_nonRepudiation_
I hope that helps.
Mike
