possible Bug in OpenSSL - rfc 3161 - TSA service

[kapetr]

Hello,

My CA Authority (Europe Union qualified!) claims - there is Bug in OpenSSL => verifying digi. timestamp fails.

The CA says (my bad translation - sorry): "our timestamps contain in addition <Time Attribute Certificate - TAC> included according to RFC 3126. They are RFC 3161 according and other clients works OK, it must be bug of OpenSSL".

My knowledge is too low and I'm not programmer to debug and understand it. Can someone test it, please ?

The TSA testing service is described here:

http://www.postsignum.cz/testovaci_casova_razitka.html
(in Czech - you can use Google translate:
http://translate.google.cz/translate?sl=cs&tl=en&js=n&prev=_t&hl=cs&ie=UTF-8&eotf=1&u=http%3A%2F%2Fwww.postsignum.cz%2Ftestovaci_casova_razitka.html&act=url
)

-----------------------------
The command sequence:
------------------------------
openssl version OpenSSL 1.0.1 14 Mar 2012

$ openssl ts -query -data file.txt -sha256 -no_nonce >file.txt-nononce-sha256-nocert.tsq
$ curl -k -v -H "Content-Type: application/timestamp-query" --basic -u "demoTSA:demoTSA2010" --data-binary @file.txt-nononce-sha256-nocert.tsq "https://www.postsignum.cz/DEMOTSA/TSS_user/ " > file.txt-nononce-sha256-nocert-postsigDEMO.tsr
$ openssl ts -verify -queryfile file.txt-nononce-sha256-nocert.tsq -in file.txt-nononce-sha256-nocert.postsigDEMO.tsr -CAfile demo_root.pem -untrusted demo_TSA+Qualif.pem
Verification: FAILED
140477747164832:error:2F067065:time stamp routines:TS_CHECK_SIGNING_CERTS:ess signing certificate error:ts_rsp_verify.c:291:

Note:
demo_TSA+Qualif.pem == DEMO_TSA.pem + demo_Qualified.pem in one file == signer + intermediate certificates

All files - file, request, replay, certificates are in attachment.

--kapetr

[Jaroslav Imrich]

Hello,

thanks to your very detailed report I've managed to troubleshoot your
problem very fast. I've discovered that in TSA response
(file.txt-nononce-sha256-nocert.postsigDEMO.tsr) there is Signing
Certificate attribute (1.2.840.113549.1.9.16.2.12) that contains two
ESSCertIDs:
1st - 3CADA1A29AF6279454FFB22B96CD45E148C8AB6C (DEMO_TSA.pem)
2nd - 52EE29A7350304F894214872769F2478EB6CD7AC (Unknown certificate)

Certificates you attached (and that are published at postsignum.cz)
have following ESSCertIDs:
1st - 3cada1a29af6279454ffb22b96cd45e148c8ab6c (DEMO_TSA.pem)
2nd - 3721926ea67e877df5f4e35dd3c87397eef33d4f (demo_Qualified.pem)
3rd - aa9653baf834abb3e293aa96d78fc77a65a194be (demo_root.pem)

ESSCertID is SHA1 hash of DER encoded certificate and is defined in
section 5 of RFC 2634. Reply you got from TSA is saying that you
should verify signature using only two certificates that match
ESSCertIDs present in response. I believe this is misconfiguration at
the TSA side and imho you should contact service provider and ask him
to fix it. Postsignum can either remove second ESSCertID from
generated responses or fix ESSCertIDs to match the path they provide
on their website.

You can use following arguments:

RFC3161 page 7:
... The certificate identifier (ESSCertID) of the
TSA certificate MUST be included as a signerInfo attribute inside a
SigningCertificate attribute.

RFC3161 page 10:
... However, the actual identification of the entity
that signed the response will always occur through the use of the
certificate identifier (ESSCertID Attribute) inside a
SigningCertificate attribute which is part of the signerInfo (See
Section 5 of [ESS]).

RFC2634 page 47:
If more than one certificate is present in the sequence of
ESSCertIDs, the certificates after the first one limit the set of
authorization certificates that are used during signature validation.
Authorization certificates can be either attribute certificates or
normal certificates. The issuerSerial field (in the ESSCertID
structure) SHOULD be present for these certificates, unless the
client who is validating the signature is expected to have easy
access to all the certificates requred for validation. If only the
signing certificate is present in the sequence, there are no
restrictions on the set of authorization certificates used in
validating the signature.
--
Kind Regards / S pozdravom

Jaroslav Imrich
http://www.jimrich.sk

Post by kapetr
Hello,
My CA Authority (Europe Union qualified!) claims - there is Bug in OpenSSL => verifying digi. timestamp fails.
The CA says (my bad translation - sorry): "our timestamps contain in addition <Time Attribute Certificate - TAC> included according to RFC 3126. They are RFC 3161 according and other clients works OK, it must be bug of OpenSSL".
My knowledge is too low and I'm not programmer to debug and understand it. Can someone test it, please ?
http://www.postsignum.cz/testovaci_casova_razitka.html
http://translate.google.cz/translate?sl=cs&tl=en&js=n&prev=_t&hl=cs&ie=UTF-8&eotf=1&u=http%3A%2F%2Fwww.postsignum.cz%2Ftestovaci_casova_razitka.html&act=url
)
-----------------------------
------------------------------
openssl version OpenSSL 1.0.1 14 Mar 2012
$ openssl ts -query -data file.txt -sha256 -no_nonce >file.txt-nononce-sha256-nocert.tsq
$ openssl ts -verify -queryfile file.txt-nononce-sha256-nocert.tsq -in file.txt-nononce-sha256-nocert.postsigDEMO.tsr -CAfile demo_root.pem -untrusted demo_TSA+Qualif.pem
Verification: FAILED
demo_TSA+Qualif.pem == DEMO_TSA.pem + demo_Qualified.pem in one file == signer + intermediate certificates
All files - file, request, replay, certificates are in attachment.
--kapetr

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[Dragan Spasic]

Hello kapetr,

I have successfully time-stamped with TSA server
"https://www.postsignum.cz/DEMOTSA/TSS_user/" (u: demoTSA, p: demoTSA2010),
using 2 Time-stamp clients:
1. Adobe Reader 10.1.3
2. Serbian Post Time-stamp client:
http://www.ca.posta.rs/download/Time-Stamp%20klijent%20aplikacija%20Poste%20v1.2.zip

PostSignum TSA server is Thales (nCipher). Thales (nCipher) time stamp
server can be configured to choose three locations where TAC (Time Attribute
Certificate) V2 attribute certificate will be stored:

1. CertificateChoices1 with ESSCertID (compatibility mode)

The Time Attribute Certificate is encoded in the CHOICE [1] field in the
CertificateChoices and the SHA-1 hash of the TAC is stored in the ESSCertID.

2. CertificateChoices2 with ESSCertID (RFC3369 & 3852)

This option puts the Time Attribute certificate into the CHOICE [2] field in
the CertificateChoices and sets the CMS version of the Time Stamp Token to 4
(because a V2 attribute certificate is present).

Note: Adobe Acrobat time-stamping support rejects CMS V4 as a bad version
number. If you are using Adobe Acrobat time-stamping, Thales recommend
continuing to use an older option that is Acrobat-compatible until a fix
from Adobe is made available.

3. SignerAttribute (RFC3126 & ETSI)

This option puts the entire TAC into a signed attribute. In this case, the
hash of the TAC is not included in the ESSCertID because it would be
redundant and RFC3126 requires it not to be present. This option also adds
the SigningTime signed attribute (redundant but required by the RFC) and the
SignaturePolicyId signed attribute. The policy is NULL because a time-stamp
token already must include a PolicyID in the TSTInfo.

My conclusion is that PostSignum TSA server is configured with the first of
the above options "1. CertificateChoices1 with ESSCertID (compatibility
mode)". When Thales (nCipher) time-stamp server is configured that way,
OpenSSL is unable to read TSA response. For example:
-----------------------------------------------------------
C:\Program Files\OpenSSL-Win32\bin>openssl ts -reply -in
postsignum-Response.tsr
-text
Using configuration from C:\Program Files\OpenSSL-Win32\bin\openssl.cfg
608:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:.\crypto\asn
1\tasn_dec.c:1320:
608:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
error:.\c
rypto\asn1\tasn_dec.c:382:Type=X509
608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
asn1 er
ror:.\crypto\asn1\tasn_dec.c:712:Field=cert, Type=PKCS7_SIGNED
608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
asn1 er
ror:.\crypto\asn1\tasn_dec.c:752:
608:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1
error
:.\crypto\asn1\tasn_dec.c:580:Field=d.sign, Type=PKCS7
608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
asn1 er
ror:.\crypto\asn1\tasn_dec.c:752:Field=token, Type=TS_RESP

C:\Program Files\OpenSSL-Win32\bin>
-----------------------------------------------------------

Administrator of PostSignum TSA can solve the problem with OpenSSL in 2
ways:
1. To configure TAC: "3. SignerAttribute (RFC3126 & ETSI)", or
2. Exclude TAC from certificate list. He can use this option to support
time-stamp client software that cannot decode the TAC. This option is
required if you must support SUN jarsigner. SUN Jarsigner cannot decode the
TAC and cannot support time-stamp tokens that include the TAC in the
certificate list.

Useful link:
http://www.ietf.org/mail-archive/web/pkix/current/msg14787.html

Dragan



--
View this message in context: http://openssl.6102.n7.nabble.com/possible-Bug-in-OpenSSL-rfc-3161-TSA-service-tp43128p44380.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[k***@mizera.cz]

Thanks for great answer and explanation.

Without a deeper knowledge I had ask the TSA (as possible solution) to
move the ESSCertiId (or whatever) of TAC in signed attributes as
separate attribute (== out of certs list). Nice to see that was not so
bad Idea.

Unfortunately their conclusion was to do not make any changes in config.

Interesting is too, that java has the same problem with TAC as openssl.
They have their own TS client wrote in Java. Probably it uses some
another library (bouncycastle ?).

I will ask them once again, but see just little chance.

Thanks one more

--kapetr

Post by Dragan Spasic
Hello kapetr,
I have successfully time-stamped with TSA server
"https://www.postsignum.cz/DEMOTSA/TSS_user/" (u: demoTSA, p: demoTSA2010),
1. Adobe Reader 10.1.3
http://www.ca.posta.rs/download/Time-Stamp%20klijent%20aplikacija%20Poste%20v1.2.zip
PostSignum TSA server is Thales (nCipher). Thales (nCipher) time stamp
server can be configured to choose three locations where TAC (Time Attribute
1. CertificateChoices1 with ESSCertID (compatibility mode)
The Time Attribute Certificate is encoded in the CHOICE [1] field in the
CertificateChoices and the SHA-1 hash of the TAC is stored in the ESSCertID.
2. CertificateChoices2 with ESSCertID (RFC3369 & 3852)
This option puts the Time Attribute certificate into the CHOICE [2] field in
the CertificateChoices and sets the CMS version of the Time Stamp Token to 4
(because a V2 attribute certificate is present).
Note: Adobe Acrobat time-stamping support rejects CMS V4 as a bad version
number. If you are using Adobe Acrobat time-stamping, Thales recommend
continuing to use an older option that is Acrobat-compatible until a fix
from Adobe is made available.
3. SignerAttribute (RFC3126 & ETSI)
This option puts the entire TAC into a signed attribute. In this case, the
hash of the TAC is not included in the ESSCertID because it would be
redundant and RFC3126 requires it not to be present. This option also adds
the SigningTime signed attribute (redundant but required by the RFC) and the
SignaturePolicyId signed attribute. The policy is NULL because a time-stamp
token already must include a PolicyID in the TSTInfo.
My conclusion is that PostSignum TSA server is configured with the first of
the above options "1. CertificateChoices1 with ESSCertID (compatibility
mode)". When Thales (nCipher) time-stamp server is configured that way,
-----------------------------------------------------------
C:\Program Files\OpenSSL-Win32\bin>openssl ts -reply -in
postsignum-Response.tsr
-text
Using configuration from C:\Program Files\OpenSSL-Win32\bin\openssl.cfg
608:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:.\crypto\asn
608:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
error:.\c
rypto\asn1\tasn_dec.c:382:Type=X509
608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
asn1 er
ror:.\crypto\asn1\tasn_dec.c:712:Field=cert, Type=PKCS7_SIGNED
608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
asn1 er
608:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1
error
:.\crypto\asn1\tasn_dec.c:580:Field=d.sign, Type=PKCS7
608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
asn1 er
ror:.\crypto\asn1\tasn_dec.c:752:Field=token, Type=TS_RESP
C:\Program Files\OpenSSL-Win32\bin>
-----------------------------------------------------------
Administrator of PostSignum TSA can solve the problem with OpenSSL in 2
1. To configure TAC: "3. SignerAttribute (RFC3126 & ETSI)", or
2. Exclude TAC from certificate list. He can use this option to support
time-stamp client software that cannot decode the TAC. This option is
required if you must support SUN jarsigner. SUN Jarsigner cannot decode the
TAC and cannot support time-stamp tokens that include the TAC in the
certificate list.
http://www.ietf.org/mail-archive/web/pkix/current/msg14787.html
Dragan
--
View this message in context: http://openssl.6102.n7.nabble.com/possible-Bug-in-OpenSSL-rfc-3161-TSA-service-tp43128p44380.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org