Also this might be useful for implementers: http://msdn.microsoft.com/en-us/library/windows/desktop/bb931395(v=vs.85).as px
-----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: Tuesday, March 19, 2013 12:07 PM To: openssl-users@openssl.org Subject: Re: Timestamp for Microsoft Authenticode? I have written a few posts about this timestamp format on this list before, here are my supplemental comments to your description and experiment: On 3/17/2013 6:14 PM, Walter H. wrote: > Hello, > > has anybody got an idea, how to programm/get such a timestamp server - > is not RFC 3161 conform - with using OpenSSL on Linux; > The RFC 3161 protocol postdates the MS format and produces responses that are useless as PKCS#7/CMS countersignatures (RFC2985#5.3.6), this may be a "feature" of RFC 3161 due to the horrible patent landscape it was created in. The parts of RFC2985/PKCS#9 used by this protocol seem to have been part of the original 1991 PKCS#9 v1.0. > attached are the ASN.1 dump of the received and sent package - in this > case the signtool.exe sends the query to > http://timestamp.verisign.com/scripts/timestamp.dll and receives from > there the reply; > - send (request): mssendts-asn1.text > - receive (reply): msrecvts-asn1.text > (these I recorded with wireshark) > > I thought of this: > > openssl smime -pk7out -in received.der -inform DER -sign -out > pkcs7reply.der -outform DER -md sha1 -signer cert.pem -inkey key.pem > -passin file:passphrase > Won't work (as you saw), this function doesn't take the actual ContentInfo structure as input, but data which it will (mis)treat as an e-mail and then wrap in its own ContentInfo. Notice how the messageDigest in your result is not the one in the result from the original RSADSI/VeriSign/Thawte/Symantec server. When the input specifies a content type of "data", you could use the bytes inside the inner OCTET STRING as input to cms like this openssl cms -sign -binary -content filewithrawdata.bin -outform DER to get something close to the right response, but this won't work if the request specifies a different content type. > but there I'm missing the original 256 bytes of the received query, > and the SECTION with OID 1.2.840.113549.1.9.15 (sMIMECapabilities) is > too much; > see the 3rd attachment: pkcs7reply-asn1.text > > below is the "spec" from MSDN; > > how can I achieve this? > I think there was a SourceForge project related to this (http://sf.net/projects/osslsigncode/) But I don't know its status. > Thanks, > Walter > > > Time Stamp Request > > The time stamp request is sent within an HTTP 1.1 POST message. In the > HTTP header, the CacheControl directive is set to no-cache, and the > Content-Type directive is set to application/octet-stream. The body of > the HTTP message is a base64 encoding of /Distinguished Encoding Rules/ > <http://msdn.microsoft.com/en-us/library/windows/desktop/ms721573%28v=vs.85% 29.aspx#_security_distinguished_encoding_rules_gly> > (DER) encoding of the time stamp request. > > Although not currently used, the Content-Length directive should also be > used in constructing the HTTP message because it helps the time stamp > server locate where the request is within the HTTP POST. > > Other HTTP headers may also be present and should be ignored if they are > not understood by the requestor or time stamp server. > > The time stamp request is an ASN.1 encoded message. The format of the > request is as follows. > > Copy > > TimeStampRequest ::= SEQUENCE { > countersignatureType OBJECT IDENTIFIER, > attributes Attributes OPTIONAL, > content ContentInfo > } > > The countersignatureType is the /object identifier/ > <http://msdn.microsoft.com/en-us/library/windows/desktop/ms721599%28v=vs.85% 29.aspx#_security_object_identifier_gly> > (OID) that identifies this as a time stamp countersignature and should > be the exact OID 1.3.6.1.4.1.311.3.2.1. > > No attributes are currently included in the time stamp request. > > The content is a ContentInfo as defined by PKCS #7. The content is the > data to be signed. For signature time stamping, the ContentType should > be Data, and the content should be the encryptedDigest (signature) from > the SignerInfo of the PKCS #7 content to be time stamped. > ContentInfo is defined in RFC2315#7 (PKCS#7) and in RFC5652#3 (CMS) SignerInfo is defined in RFC2315#9.2 (PKCS#7) and in RFC5652#5.3 (CMS) > > Time Stamp Response > > The time stamp response is also sent within an HTTP 1.1 message. In the > HTTP header, the Content-Type directive is also set to > application/octet-stream. The body of the HTTP message is a base64 > encoding of DER encoding of the time stamp response. > > The time stamp response is a PKCS #7 signed message signed by the time > stamper. The ContentInfo of the PKCS #7 message is identical to the > ContentInfo received in the time stamp. The PKCS #7 content contains the > signing time authenticated attribute (defined in PKCS #99, OID > 1.2.840.113549.9.5). This is RFC2985#5.3.3 signingTime, The OID in the MSDN spec is a misprint, it is 1.2.840.113549.1.9.5 according to both the RFC and my dumps of real signatures. This is also specified in RFC5652#11.3 (CMS). > > After Authenticode receives the time stamp from the server, Authenticode > incorporates the time stamp into the original PKCS #7 *SignedData* > <http://msdn.microsoft.com/en-us/library/windows/desktop/aa387722%28v=vs.85% 29.aspx> > as a countersignature. To accomplish this, the ContentInfo of the > returned PKCS #7 *SignedData* is discarded, and the SignerInfo of the > returned time stamp is copied as a countersignature into the SignerInfo > of the original PKCS #7 *SignedData*. The certificate chain of the time > stamper is also copied into Certificates in the original PKCS #7 > *SignedData* as an unauthenticated attribute of the original signer. > > This spec matches my observations and dumps, note that counterSignature is exactly as defined in RFC2985#5.3.6 and the MS timeStamping protocol is designed to return a signature that can be used for this. counterSignature is also specified in RFC5652#11.4 (CMS), however contrary to the text of RFC5652#11.4, it is acceptable for the counterSignature to specify a "ContentType" attribute with a value of "data" (1.2.840.113549.1.7.1), as would be caused by the time stamping server blindly complying with RFC5652#5.3 as its response is technically not a counterSignature attribute until after manipulation by the client. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, 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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
