Ubuntu
openssl package

PKCS7: Message signed outside of X.509 validity window

Bug #2003701 reported by Dimitri John Ledkov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openssl (Ubuntu)
New
Undecided
Unassigned
sbsigntool (Ubuntu)
New
Undecided
Unassigned

Bug Description

When signing UEFI applications, the signature includes signing timestamp.

Kernels, upon kexec, check that message signature is within the validity of the X.509 signing certificate.

When using original canonical kernel team test key, I no longer can kexec kernels, as the test key has expired.

UEFI specifications in general ignore signing time.

IMHO we should remove / not include signing timestamp in the UEFI signatures to avoid this.

---

i guess openssl needs to provide ability to create signatures without signingtime attribute.

See original description
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

setting PKCS7_NOATTR is not enough, as that only removes the smime capabilities signed attribute, whilst signature timestamp remains.

--- ./regular.text 2023-01-23 11:42:49.992929526 +0000
+++ noattr.text 2023-01-23 11:42:59.288981639 +0000
@@ -128,7 +128,7 @@

             object: signingTime (1.2.840.113549.1.9.5)
             set:
- UTCTIME:Jan 23 11:41:20 2023 GMT
+ UTCTIME:Jan 23 11:41:53 2023 GMT

             object: messageDigest (1.2.840.113549.1.9.4)
             set:
@@ -136,56 +136,32 @@
                 0000 - f8 cf 89 70 c1 6c 14 26-6d 56 c1 25 96 ...p.l.&mV.%.
                 000d - ce 74 11 77 a0 36 47 4d-3b 28 bf 7f 5b .t.w.6GM;(..[
                 001a - 1e b6 04 ed 21 f8 ....!.
-
- object: S/MIME Capabilities (1.2.840.113549.1.9.15)
- set:
- SEQUENCE:
- 0:d=0 hl=2 l= 106 cons: SEQUENCE
- 2:d=1 hl=2 l= 11 cons: SEQUENCE
- 4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc
- 15:d=1 hl=2 l= 11 cons: SEQUENCE
- 17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc
- 28:d=1 hl=2 l= 11 cons: SEQUENCE
- 30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc
- 41:d=1 hl=2 l= 10 cons: SEQUENCE
- 43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
- 53:d=1 hl=2 l= 14 cons: SEQUENCE
- 55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
- 65:d=2 hl=2 l= 2 prim: INTEGER :80
- 69:d=1 hl=2 l= 13 cons: SEQUENCE
- 71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
- 81:d=2 hl=2 l= 1 prim: INTEGER :40
- 84:d=1 hl=2 l= 7 cons: SEQUENCE
- 86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc
- 93:d=1 hl=2 l= 13 cons: SEQUENCE
- 95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
- 105:d=2 hl=2 l= 1 prim: INTEGER :28
         digest_enc_alg:

description: updated
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

The best we can do, is to take notAfter time of the signing certificate and add that as the signingTime, which will then be used by the Sign command as given.

This will ensure the signature is within valid time-series.

I don't see an easy openssl API to sign things without any signature timestamp.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 2003701] [NEW] PKCS7: Message signed outside of X.509 validity window

On Mon, Jan 23, 2023 at 11:19:56AM -0000, Dimitri John Ledkov wrote:
> UEFI specifications in general ignore signing time.

> IMHO we should remove / not include signing timestamp in the UEFI
> signatures to avoid this.

Doesn't this suggest it's actually a kernel bug for enforcing something here
that UEFI does not expect to be enforced?

Not including timestamps in signatures doesn't sound ideal to me.

Revision history for this message
Adrien Nader (adrien-n) wrote :

In addition to what Steve has said, I'm wondering if you can work around this by using faketime when signing.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.