Time-Stamp Protocol client
As a part of improved support of PKCS#7 messages, we added a .NET-compatible RFC 3161 Time-Stamp Protocol implementation. There are two common use cases for this protocol:
- Provide a current date and time for devices that don’t have built-in clocks;
- Certify that particular data existed at certain time point.
Second aspect is used in digital signatures: simply speaking, to certify that data was signed within signing certificate’s validity. This allows to extend the trust to signed content beyond to signing certificate’s validity. You can read details on how timestamps affect the signature trust in my blog post: Digital signatures and timestamps. In digital signatures, the timestamped data is digital signature, not hash of data being signed. By timestamping data hash, you prove that data existed at certain point in time. But to prove that signature was created at certain point – we timestamp the signature value itself. This indirectly proves the existence of data at certain point.
Unfortunately, SignedCms class in .NET Framework don’t have direct way to timestamp the signature, you have to use 3rd party timestamping libraries. We now support a RFC 3161 TSP client which is implemented in following classes:
- TspRequest – is the abstract class for different request type implementations;
- TspRfc3161Request – is a RFC 3161 request type implementation;
- TspAuthenticodeRequest – is a Microsoft Authenticode timestamp request format;
- TspResponse – represents a Time-Stamp Response class.
Using these classes you can submit requests to RFC 3161-compliant Time-Stamping Authorities (TSA) and get response.
PKCS#7 Message builder
We’ve added a SignedCmsBuilder class to build PKCS#7 message with arbitrary user-supplied content. You can modify different aspects of desired PKCS message, embed certificates, CRLs. In the end, you can sign message using private key. Additionally, you can add a timestamp to signature using AddTimestamp method. In next blog post I will show samples how you can do that.
Certificate Trust List decoder
As a part of cryptographic message move from CryptoAPI to open code, I completely rebuilt classes to work with certificate trust lists (CTL). Older classes that utilize native CryptoAPI functionality to decode CTLs are marked obsolete:
Instead, they are replaced with new classes with some extra functionality:
new classes use only native CLR code. They don’t use any calls to unmanaged CryptoAPI functions. A Get-CertificateTrustList and Show-CertificateTrustList are already updated to use new classes to work with CTLs in PowerShell.
In addition, we added an ability to create and sign custom CTL.
Certificate Trust List builder
With the availability of PKCS#7 builder, we have added an ability to create and sign new CTL for your needs. This functionality is implemented in X509CertificateTrustListBuilder class.
Another good improvement in ASN.1 library. In the past, arbitrary ASN.1 binary encoder was very basic and its use wasn’t developer-friendly and resulted code couldn’t easily tell how produced structure looks like. Now, you can generate arbitrary ASN structure using builder pattern. I will write about this in next posts.
You can download the module from: