RFC 3161 says:
2.3. Identification of the TSA
The TSA MUST sign each time-stamp message with a key reserved
specifically for that purpose. A TSA MAY have distinct private keys,
e.g., to accommodate different policies, different algorithms,
different private key sizes or to increase the performance. The
corresponding certificate MUST contain only one instance of the
extended key usage field extension as defined in [RFC2459] Section
4.2.1.13 with KeyPurposeID having value:
id-kp-timeStamping. This extension MUST be critical.
The following object identifier identifies the KeyPurposeID having
value id-kp-timeStamping.
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
kp (3) timestamping (8)}
> On Jan 28, 2022, at 6:25 AM, weber@xxxxxxxxxxx wrote:
>
> Dear OpenSSL users,
>
> recently we checked an older timestamp using the OpenSSL Library version 1.1.1i.
> The check revealed, that the timestamp verification failed.
>
> Digging into the code we found that if an eku entry for timestamping is preset
> it is expected to be marked critical (see v3_purp.c:798 ff.).
>
> Thats's not the case for the timetamp cert in use.
>
> We couldn'f find any source that enforces the critical flag on eku timestamp entries.
> RFC 5280 says, that makring the EKU as critical is deliberate tu the issuer.
>
> Any thoughts or pointer to the mentioned requirement?
>
> Thanks in advance
> --
> Christian Weber
