Timestamp validation checks critical flag on EKU

[Russ Housley]

Christian:

No, RFC 5280 does not obsolete RFC 3161.  RFC 5280 obsoletes RFCs 3280, 4325, and 4630.

Anyway, RFC 5280 and RFC 3161 are consistent.

RFC 5280 says that the certificate issuer can make the EKU extension critical or non-critical.

RFC 3161 says that for use with the Time-Stamp Protocol, the certificate issuer MUST make the EKU extension critical, and it MUST contain id-kp-timeStamping.

Russ



> On Jan 28, 2022, at 9:56 AM, weber at infotech.de wrote:
> 
> Dear Russ,
> 
> thanks for your reply.
> 
> OK, i got it, but RFC 5280 obsoletes RFC 3161 and says:
> 
> 4.2.1.12 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12>.  Extended Key Usage
> 
>    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:
> 
>    id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
> 
>    ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
> 
>    KeyPurposeId ::= OBJECT IDENTIFIER
> 
>    Key purposes may be defined by any organization with a need.  Object
>    identifiers used to identify key purposes MUST be assigned in
>    accordance with IANA or ITU-T Recommendation X.660 [X.660 <https://datatracker.ietf.org/doc/html/rfc5280#ref-X.660>].
> 
>    This extension MAY, at the option of the certificate issuer, be
>    either critical or non-critical.
> 
>    If the extension is present, then the certificate MUST only be used
>    for one of the purposes indicated.  If multiple purposes are
>    indicated the application need not recognize all purposes indicated,
>    as long as the intended purpose is present.  Certificate using
>    applications MAY require that the extended key usage extension be
>    present and that a particular purpose be indicated in order for the
>    certificate to be acceptable to that application.
> 
> So what?
> 
> BTW: The further obsoletions RFC i.e. Updated by: 6818 <https://datatracker.ietf.org/doc/html/rfc6818>, 8398 <https://datatracker.ietf.org/doc/html/rfc8398>, 8399 <https://datatracker.ietf.org/doc/html/rfc8399>
> do not affect RCF 5280 in this matter.
> 
> The main question remains: How to handle this issue?
> 
> Thanks In Advance
> --
> Christian Weber
> Am 28.01.2022 um 13:58 schrieb Russ Housley:
>> 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 at infotech.de <mailto:weber at infotech.de> 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
> 
> --
> Christian Weber
> Entwicklung - Verteilte Systeme
> mailto:Weber at InfoTech.de <mailto:Weber at InfoTech.de>
> -- 
> Infotech Gesellschaft für
> Informations- und Datentechnik mbH
> Tel. +49-2361-9130-0
> Fax +49-2361-9130-105
> 
> Geschäftsführer
> Rainer Hans
> 
> Gerichtsstand Recklinghausen
> Amtsgericht Recklinghausen HRB 1912
> USt.-IdNr. DE-811565628

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220128/a90e6fe3/attachment-0001.htm>