gpg4win expired code signing cert; please renew.

[Jakob Bohm]

On 17/10/2025 22:06, Ingo Klöcker wrote:
> ...
>
> $ osslsigncode extract-signature -pem -in gpg4win-5.0.0-beta369.exe \
> -out gpg4win-5.0.0-beta369.exe.pem
> PE checksum   : 028F186B
> Succeeded
Unless the above command also verifies the signature itself
besides extracting it, the command belowwill probably not
check that the certificate printed was actually used for
signing, nor will it check thatthe signature is countersigned
within the main certificate lifetime by a time-stamp
certificate that isstil valid at the time of checking.

Implementing support for time stamp countersignatures and
archival trusted timstamps in gpgsmare key features for
both authenticode and checking signed e-mails that have
been sitting in a trusted inbox or mail archive since they
were valid.

FYI, Authenticode uses two types of counter signatures
(From my own research notes):

1 RFC2985 form Timestamp countersignature Attribute
===================================================

This is a counter signature exactly as described in RFC2985 section
5.3.6 (OID 1.2.840.113549.1.9.6) with the following additional
constraints:

- The countersigning certificate MUST specify the timestamping
  extended key usage (OID 1.3.6.1.5.5.7.3.8)
- The countersigning SignerInfo MUST include a signingTime attribute
  (as defined in RFC2985 section 5.3.3, OID 1.2.840.113549.1.9.5)
- It seems that at least one time stamping authority (the one that
  had been operational the longest) was using a non-standard signature
  calculation.  Specifically, the RSA signature while tagged as if it
  was a PKCS#1 version 1.5 signature contains the bare hash value where
  PKCS#1 version 1.5 and PKCS#7/CMS require that it contains a
  DER encoded DigestInfo holding the hash algorithm OID and the hash
  value itself.  For this format, the hash algorithm can be identified
  from its length: 20 bytes for SHA-1 and 16 bytes for MD5, with no
  other hash algorirhm permitted for this signature format.


2 RFC3161 form Timestamp countersignature Attribute
===================================================

   spcTimeStampRFC3161 = 1.3.6.1.4.1.311.3.3.1

   SpcTimeStampRFC3161 ::= SET OF TimeStampToken -- See RFC3161

The TimeStampToken must specify a messageImprint computed over the
content octets of the encryptedDigest field in the SignerInfo having
the attribute.

This is similar to the SignatureTimeStampToken attribute specified in
RFC3161 Appendix A, except that the OID differs and the value must be
as SET OF TimeStampToken, not just a TimeStampToken directly.

This form is understood only by those Microsoft validation programs
that support SHA-2 or later hash algorithms.

Therefore SPC signatures using the SHA-1 hash algorithm SHOULD use the
RFC2985 timestamp countersignature format.  SPC signatures not inside
an SpcNestedSignature attribute and made using the SHA-1 or MD5
hash algorithm SHOULD AVOID using the RFC3161 timestamp counter
signature format.


> $ openssl pkcs7 -in gpg4win-5.0.0-beta369.exe.pem -print_certs -text
> Certificate:
>      Data:
>          Version: 3 (0x2)
>          Serial Number:
>              27:1d:f9:34:50:4f:8e:38:3b:33:bc:e5
>          Signature Algorithm: sha256WithRSAEncryption
>          Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign GCC R45 CodeSigning CA
> 2020
>          Validity
>              Not Before: Jun  5 12:43:59 2025 GMT
>              Not After : Jun  5 12:43:59 2028 GMT
>          Subject: C=DE, ST=Nordrhein-Westfalen, L=Erkrath, O=g10 Code GmbH,
> CN=g10 Code GmbH/emailAddress=code at g10code.com
>
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded