Re: possible Bug in OpenSSL - rfc 3161 - TSA service
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=cstl=enjs=nprev=_thl=csie=UTF-8eotf=1u=http%3A%2F%2Fwww.postsignum.cz%2Ftestovaci_casova_razitka.htmlact=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
FIPS mode of OpenSSL .NET shared library on fixed position
Hello openssl users, We are planning to use OpenSSL library because of FIPS 140-2 support and AES encryption/decryption in CFB128 mode. One of the requirement for FIPS mode is self check which is performing calculation of hash on particular memory address on which must be libeay32.dll loaded otherwise check fails.Our code is written in .NET and so is not easily possible to 100% ensure that particular memory address will be always free. .NET runtime is dynamically loading assemblies to not predictable memory addresses because od ASLR and turning of this is security risk. Has anyone face this problem? Why selfcheck requires predefined DLL load address?Is there any cheap solution? I hope there is solution for such problem, because otherwise is OpenSSL without FIPS mode use-less for our needs. Thank you Tomas Pospisil __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Need help on importing the signed certificate
Hi All, We are using Solaris box installed IBM http service. We created CSR request and submitted to CA authority and got signed certificate also. but we are not sure how to import the singed certificates into the key DB. previously we were using ikeyman, as it was not able to generate the keysize of 2048 with the current version we are using Opensssl. Can anyone help on the same?. Regards, Selva -- View this message in context: http://openssl.6102.n7.nabble.com/Need-help-on-importing-the-signed-certificate-tp44186.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Am 11.03.2013 13:01, schrieb kap...@mizera.cz: P.S: is this forum monitored by developers of openssl or should I report it in devel forum? At least Stephen Henson answers regularily in this mailing list (as you can see by looking into a couple of threads), therefore i would stay in this list until it is clear that there is a problem with OpenSSL itself. Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On Mon, Mar 11, 2013, Richard Knning wrote: Am 11.03.2013 13:01, schrieb kap...@mizera.cz: P.S: is this forum monitored by developers of openssl or should I report it in devel forum? At least Stephen Henson answers regularily in this mailing list (as you can see by looking into a couple of threads), therefore i would stay in this list until it is clear that there is a problem with OpenSSL itself. Though I can't spend as much time on here as I would like... as you might imagine I get ridiculously busy at times. As to the OP query. I'm not that familiar with the timestamping code. OpenSSL doesn't support attribute certificates and adding support is not trivial. However full suppor isn't always required: the CMS code just treats and it finds as an opaque blob which it keeps in encoded form. That means it can parse messages containing attribute certificates without choking. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Hello, Dne 11.3.2013 17:33, Dr. Stephen Henson napsal(a): As to the OP query. I'm not that familiar with the timestamping code. OpenSSL doesn't support attribute certificates and adding support is not trivial. The attribute certificates are common possible in CMS, not just in TS = attr. cert. (in the SigningCertificate-certs) will kill any CMS verification. The TAC ESSCertId I thing makes the verification impossible in OpenSSL while OpenSSL (without attr. cert. support) only applies the first sentence in 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. But the TAC is not part of verify chain = these 2 ESSCertId-s: 1. are not correct and 2. do not build whole cert. chain within the meaning of that first sentence. That is the point. However full suppor isn't always required: the CMS code just treats and it finds as an opaque blob which it keeps in encoded form. That means it can parse messages containing attribute certificates without choking. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Parsing is one thing and verification another one. If the verification fails - is it one of greatest possible problems. As I know, the attr. certs are not very necessary = that is why I mean, that temporary solution would be to ignore them in verification process. At least in TS it would solve the problem. --kapetr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/11/2013 06:43 PM, kap...@mizera.cz wrote: Hello, ... As I know, the attr. certs are not very necessary = that is why I mean, that temporary solution would be to ignore them in verification process. At least in TS it would solve the problem. Just for info: converting te stuff to pkcs7 and verifying with smime works fine. --kapetr __ 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Could you please explain it in detail ? Commands sentence as example ? INPUT: - timestamp reply - certificates (whole chain) COMMANDS: OUTPUT: successful verification Thanks --kapetr Dne 11.3.2013 19:39, Peter Sylvester napsal(a): On 03/11/2013 06:43 PM, kap...@mizera.cz wrote: Hello, ... As I know, the attr. certs are not very necessary = that is why I mean, that temporary solution would be to ignore them in verification process. At least in TS it would solve the problem. Just for info: converting te stuff to pkcs7 and verifying with smime works fine. --kapetr __ 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On Mon, Mar 11, 2013, kap...@mizera.cz wrote: Hello, Dne 11.3.2013 17:33, Dr. Stephen Henson napsal(a): As to the OP query. I'm not that familiar with the timestamping code. OpenSSL doesn't support attribute certificates and adding support is not trivial. The attribute certificates are common possible in CMS, not just in TS = attr. cert. (in the SigningCertificate-certs) will kill any CMS verification. Do you have an example of a CMS message where that happens? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Of course YES. Timestamp reply is nothing else as CMS SignedData structure. --kapetr Dne 11.3.2013 19:51, Dr. Stephen Henson napsal(a): On Mon, Mar 11, 2013, kap...@mizera.cz wrote: Hello, Dne 11.3.2013 17:33, Dr. Stephen Henson napsal(a): As to the OP query. I'm not that familiar with the timestamping code. OpenSSL doesn't support attribute certificates and adding support is not trivial. The attribute certificates are common possible in CMS, not just in TS = attr. cert. (in the SigningCertificate-certs) will kill any CMS verification. Do you have an example of a CMS message where that happens? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Hello, try this for generating the TSA-reply openssl ts -reply -config openssl.cnf -section tsa_timestamp -queryfile TSA-query -inkey ts.key -signer ts.crt -out TSA-reply where ts.crt and ts.key are the timestamping certificate and private key (without passphrase) and TSA-query is the time stamp query TSA-reply is your time stamp reply I'm using this in a CGI skript and created a timestamp server this way ... I tested this with my certificates with just Adobe Standard and this worked. the openssl.cnf contains this: oid_section = new_oids [ new_oids ] tsaPolicy = 1.2.3.4.5 [ tsa ] default_tsa = tsa_timestamp [ tsa_timestamp ] accuracy = secs:1, millisecs:500, microsecs:100 digests = md5, sha1 serial = serialnmbr-timestamp.text default_policy = tsaPolicy On 11.03.2013 20:01, kap...@mizera.cz wrote: Of course YES. Timestamp reply is nothing else as CMS SignedData structure. --kapetr Dne 11.3.2013 19:51, Dr. Stephen Henson napsal(a): On Mon, Mar 11, 2013, kap...@mizera.cz wrote: Hello, Dne 11.3.2013 17:33, Dr. Stephen Henson napsal(a): As to the OP query. I'm not that familiar with the timestamping code. OpenSSL doesn't support attribute certificates and adding support is not trivial. The attribute certificates are common possible in CMS, not just in TS = attr. cert. (in the SigningCertificate-certs) will kill any CMS verification. smime.p7s Description: S/MIME Cryptographic Signature
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
the second ess certid says
SEQUENCE {
OCTET STRING
52 EE 29 A7 35 03 04 F8 94 21 48 72 76 9F 24 78
EB 6C D7 AC
}
by 3721926ea67e877df5f4e35dd3c87397eef33d4f
is the hash of the der version of te intermediate cert.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/11/2013 08:01 PM, kap...@mizera.cz wrote: Of course YES. Timestamp reply is nothing else as CMS SignedData structure. not quite but ts -reply -tokenout converts it to such a thing __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Thank you, but this thread is about TS from real Certification Authority and problem with attribute certificates. --kapetr Dne 11.3.2013 21:16, Walter H. napsal(a): Hello, try this for generating the TSA-reply openssl ts -reply -config openssl.cnf -section tsa_timestamp -queryfile TSA-query -inkey ts.key -signer ts.crt -out TSA-reply where ts.crt and ts.key are the timestamping certificate and private key (without passphrase) and TSA-query is the time stamp query TSA-reply is your time stamp reply I'm using this in a CGI skript and created a timestamp server this way ... I tested this with my certificates with just Adobe Standard and this worked. the openssl.cnf contains this: oid_section = new_oids [ new_oids ] tsaPolicy = 1.2.3.4.5 [ tsa ] default_tsa = tsa_timestamp [ tsa_timestamp ] accuracy = secs:1, millisecs:500, microsecs:100 digests = md5, sha1 serial = serialnmbr-timestamp.text default_policy = tsaPolicy On 11.03.2013 20:01, kap...@mizera.cz wrote: Of course YES. Timestamp reply is nothing else as CMS SignedData structure. --kapetr Dne 11.3.2013 19:51, Dr. Stephen Henson napsal(a): On Mon, Mar 11, 2013, kap...@mizera.cz wrote: Hello, Dne 11.3.2013 17:33, Dr. Stephen Henson napsal(a): As to the OP query. I'm not that familiar with the timestamping code. OpenSSL doesn't support attribute certificates and adding support is not trivial. The attribute certificates are common possible in CMS, not just in TS = attr. cert. (in the SigningCertificate-certs) will kill any CMS verification. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Dne 11.3.2013 21:42, Peter Sylvester napsal(a):
the second ess certid says
SEQUENCE {
OCTET STRING
52 EE 29 A7 35 03 04 F8 94 21 48 72 76 9F 24 78
EB 6C D7 AC
}
by 3721926ea67e877df5f4e35dd3c87397eef33d4f
is the hash of the der version of te intermediate cert.
???
it is the sha1 hash itself and it is NOT hash of any cert in
verification chain.
52EE29A7350304F894214872769F2478EB6CD7AC is hash of the TAC (attribute
certificate)
$ asn1 -inform pem -in DEMO_TSA.pem -noout -out /dev/stdout|sha1sum
3cada1a29af6279454ffb22b96cd45e148c8ab6c -
$ asn1 -inform pem -in demo_Qualified.pem -noout -out /dev/stdout|sha1sum
3721926ea67e877df5f4e35dd3c87397eef33d4f -
$ asn1 -inform pem -in demo_root.pem -noout -out /dev/stdout|sha1sum
aa9653baf834abb3e293aa96d78fc77a65a194be -
the first one (3cada1a29af6279454ffb22b96cd45e148c8ab6c)
is the hash in previous ESSCertID.
See:
http://2i.cz/dcc5b69c4f
--kapetr
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 03/11/2013 10:31 PM, kap...@mizera.cz wrote:
Dne 11.3.2013 21:42, Peter Sylvester napsal(a):
the second ess certid says
SEQUENCE {
OCTET STRING
52 EE 29 A7 35 03 04 F8 94 21 48 72 76 9F 24 78
EB 6C D7 AC
}
by 3721926ea67e877df5f4e35dd3c87397eef33d4f
is the hash of the der version of te intermediate cert.
it is the sha1 hash itself and it is NOT hash of any cert in verification chain.
openssl ts does not support attribute certs AFAIR
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
That is what we talk about here.
Try to check previous posts in this thread.
--kapetr
Dne 11.3.2013 22:51, Peter Sylvester napsal(a):
On 03/11/2013 10:31 PM, kap...@mizera.cz wrote:
Dne 11.3.2013 21:42, Peter Sylvester napsal(a):
the second ess certid says
SEQUENCE {
OCTET STRING
52 EE 29 A7 35 03 04 F8 94 21 48 72 76 9F 24 78
EB 6C D7 AC
}
by 3721926ea67e877df5f4e35dd3c87397eef33d4f
is the hash of the der version of te intermediate cert.
it is the sha1 hash itself and it is NOT hash of any cert in
verification chain.
openssl ts does not support attribute certs AFAIR
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Just note. I accidentally deleted: http://2i.cz/dcc5b69c4f Here is new copy: http://2i.cz/0f81f2d80b __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Do you think OpenSSL is a game? On 11.03.2013 22:02, kap...@mizera.cz wrote: Thank you, but this thread is about TS from real Certification Authority and problem with attribute certificates. --kapetr Dne 11.3.2013 21:16, Walter H. napsal(a): Hello, try this for generating the TSA-reply openssl ts -reply -config openssl.cnf -section tsa_timestamp -queryfile TSA-query -inkey ts.key -signer ts.crt -out TSA-reply where ts.crt and ts.key are the timestamping certificate and private key (without passphrase) and TSA-query is the time stamp query TSA-reply is your time stamp reply I'm using this in a CGI skript and created a timestamp server this way ... I tested this with my certificates with just Adobe Standard and this worked. the openssl.cnf contains this: oid_section = new_oids [ new_oids ] tsaPolicy = 1.2.3.4.5 [ tsa ] default_tsa = tsa_timestamp [ tsa_timestamp ] accuracy = secs:1, millisecs:500, microsecs:100 digests = md5, sha1 serial = serialnmbr-timestamp.text default_policy = tsaPolicy smime.p7s Description: S/MIME Cryptographic Signature
