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

[Michael StJohns]

On 11/16/2021 7:46 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
> 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

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