SigningTime identified as RFC3161 encoded does not return in Get-AuthenticodeSignature type extension

[PatrickOnGit]

The type extension in PSPKI.PS5Types.ps1xml for Get-AuthenticodeSignature does not return SigningTime for some files signed using authenticode.

PS C:\Users\Patrick.SCZEPANSKI> Get-AuthenticodeSignature "C:\Temp\tphkcoinst.dll" | Select SigningTime, Status, SignatureType, IsOSBinary

SigningTime         Status SignatureType IsOSBinary
-----------         ------ ------------- ----------
10/16/2017 07:40:06  Valid  Authenticode      False

PS C:\Users\Patrick.SCZEPANSKI> Get-AuthenticodeSignature "C:\Temp\igfxCoIn_v4358.dll" | Select SigningTime, Status, SignatureType, IsOSBinary

SigningTime Status SignatureType IsOSBinary
----------- ------ ------------- ----------
             Valid  Authenticode      False

RFC3161 - TS fails - igfxCoIn_v4358.zip
RFC3161 - TS works - tphkcoinst.zip

[Crypt32]

Here is an update for this item. There are several issues (all of them are mine):

1. I found unexpected data in igfxCoIn_v4358.dll file which contains ExtendedCertificate type in PKCS7 certificates field. I never saw the use of extended certificate and didn't expect to see it. This requires additional research on how to deal and process this type. Currently, I silently skip it.
2. Signing time is stored in PKCS7 content, while we search for it only in signer infos
3. Signing time uses millisecond precision which I should properly handle, but it seems that my ASN parser isn't able to properly handle this.

Encoded time looks as this in ASCII view: 20151231003618.49Z. .49 component represents second fractions. For GeneralizedTime parser. I used this reference: https://www.obj-sys.com/asn1tutorial/node14.html, which claims that fraction must be a 3-digit value ([fff]) which stands for 1/1000 of a second (simply, milliseconds).

In a given case, encoded value uses only 2 digits. Further research suggests, that fraction can be of variable length. Here is a quote from Olivier Dubuisson book:

a) a string of the form "AAAAMMJJhh[mm[ss[(.|,)ffff]]]" standing for
a local time, four digits for the year, two for the month, two for
the day and two for the hour (the value 24 is forbidden), followed
by two digits for the minutes and two for the seconds if required,
then a dot (or a comma), and a number for the fractions of second
(the maximum precision depends on the application) [ISO8601]

he uses 4-digit fraction and says that fraction part can be of variable length. I believe, Dubuisson is more correct and clear than former reference. I need to debug the parser and see if it properly handles this and then update signing time retrieval method to lookup in PKCS7 content if it is a time-stamp token.