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 [email protected]
Automated List Manager [email protected]
