Hello,
after long time and many communication with the Certification Authority,
they send me final conclusion:
The problem with verification of their timestamps in openssl is caused
by improper/none handling of ATTRIBUTE CERTIFICATEs in openssl.
Other apps, e.b. Adobe, have no problem with the TAC (Time Attribute
Certificate) of which ESSCertID is included in SigningCertificate->certs.
The TAC itself is included in TS reply in SignedData->certificates (if
TS query is generated without "-nocert" option, of course).
If is it true, opensll should add support of Attribute Certificates and
in the meantime opensll should e.g. ignore ESSCertIDs of TAC (generally
of any attribute certificate) in
SignedData->signerInfos->signedAttrs->SigningCertificate->certs.
-------
Repeat:
-------
the problem is, that openssl tries to verify the signature using this
TAC too, but this TAC is not a part of certificate chain to verify
signature (see RFC2634 page 47).
--kapetr
P.S: is this forum monitored by developers of openssl or should I report
it in devel forum?
Dne 12.1.2013 21:58, Jaroslav Imrich napsal(a):
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 On Sat,
Jan 12, 2013 at 7:23 PM, kapetr <kap...@mizera.cz> wrote:
> 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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
