From thulasi.goriparthi at gmail.com Mon Feb 1 07:52:02 2021 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Mon, 1 Feb 2021 13:22:02 +0530 Subject: OCSP Responder app Message-ID: OCSP responder app is trying to read OCSP_RESPONSE instead of OCSP_REQUEST in do_responder function. Created https://github.com/openssl/openssl/issues/13904 Thanks, Thulasi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gorhas at raditex.nu Tue Feb 2 11:58:21 2021 From: gorhas at raditex.nu (Goran Hasse) Date: Tue, 2 Feb 2021 12:58:21 +0100 Subject: Many packets slow down the server Message-ID: Hi, I have written a "simple" openssl server and a client. I just do SSL_write and SSL_read to send binary data from the client to the server. This seems to work well. I get no read or write error during the transfer. All bytes sent are received. But the file is quite large about 2.000.000 bytes (It is a wav file). After about 1000 packets the transfer begins to go _realy_ slow. Sometimes it comes to a halt. I have tried all kind of buffersize, but the symtoms are about the same. Any ideas? // GH -- G?ran Hasse Raditex Control AB email: gorhas at raditex.nu Mob: 070 5530148 From doctor at doctor.nl2k.ab.ca Wed Feb 3 15:48:54 2021 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 3 Feb 2021 08:48:54 -0700 Subject: Openssl 3.0 Aplha daily snap test locks up Message-ID: Anyone knows why 04-test_encoder_decode_legacy.t is spinning its wheels? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b NFLD on 13 Feb vote Liberal ! From weber at infotech.de Thu Feb 4 12:08:49 2021 From: weber at infotech.de (weber at infotech.de) Date: Thu, 4 Feb 2021 13:08:49 +0100 Subject: Chain building fails in version 1.1.1i if CA uses RSASSA-PSS for signing EE cert Message-ID: <31147cb9-5ea9-e6af-ba79-ba583ead89c6@infotech.de> Dear OpenSSL users, we just bumped into a case we assume as a bug in version 1.1.1i. Building a (partial) chain fails if an enduser cert is signed by a ca using RSASSA-PSS algorithm. Chain building works with version 1.1.1g. Tracing the issue down, we found that the check_issued (source x509_vfy.c) is changed. The method is extended to compare the X509_NAMEs, AKIDs and algorithms match. The latter fails in check_sig_alg_match (source v3_purp.c) returning X509_V_ERR_SIGNATURE_ALGORITHM_MISMATCH, which is wrong. Is this issue and / or the proper solution known? Thanks in advance -- Christian Weber From tomas at openssl.org Thu Feb 4 12:22:01 2021 From: tomas at openssl.org (Tomas Mraz) Date: Thu, 04 Feb 2021 13:22:01 +0100 Subject: Chain building fails in version 1.1.1i if CA uses RSASSA-PSS for signing EE cert In-Reply-To: <31147cb9-5ea9-e6af-ba79-ba583ead89c6@infotech.de> References: <31147cb9-5ea9-e6af-ba79-ba583ead89c6@infotech.de> Message-ID: Hi, yes, this is a known regression in 1.1.1i that is fixed in the git repo already with commit c2fc1115eac53d2043e09bfa43ac5407f87fe417 Tomas On Thu, 2021-02-04 at 13:08 +0100, weber at infotech.de wrote: > Dear OpenSSL users, > > we just bumped into a case we assume as a bug in version 1.1.1i. > > Building a (partial) chain fails if an enduser cert is signed by a > ca > using RSASSA-PSS algorithm. > Chain building works with version 1.1.1g. > > Tracing the issue down, we found that the check_issued (source > x509_vfy.c) is changed. > The method is extended to compare the X509_NAMEs, AKIDs and > algorithms > match. > The latter fails in check_sig_alg_match (source v3_purp.c) returning > X509_V_ERR_SIGNATURE_ALGORITHM_MISMATCH, which is wrong. > > Is this issue and / or the proper solution known? > > Thanks in advance > -- > Christian Weber > From 1nagarjun1 at gmail.com Fri Feb 5 09:48:44 2021 From: 1nagarjun1 at gmail.com (Nagarjun J) Date: Fri, 5 Feb 2021 15:18:44 +0530 Subject: Openssl-3.0.0 POST Message-ID: Hello, Can any one tell , how to run POST tests in openssl-3.0.0. Regards, N -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Fri Feb 5 10:08:33 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Fri, 5 Feb 2021 20:08:33 +1000 Subject: Openssl-3.0.0 POST In-Reply-To: References: Message-ID: <945b4314-9173-cf7f-ef50-fb444a1b5cb3@openssl.org> Have a look at the openssl-fipsinstall manual page. The self tests are run when the FIPS provider is installed. You can run the install manually using: openssl fipsinstall -module ./fips.so -out fips.cnf -provider_name fips I think that a verify command will also run them: openssl fipsinstall -module ./fips.so -in fips.cnf -provider_name fips -verify The normal "make test" runs the FIPS self tests. They run very quickly when compared to the old FOM, NIST hasrelaxed the rules significantly. To run them on demand, have a look at the OSSL_PROVIDER-FIPS and OSSL_SELF_TEST_new manual pages. It's easiest to run them from the command line. Pauli On 5/2/21 7:48 pm, Nagarjun J wrote: > Hello, > > Can any one tell , how to run POST tests in openssl-3.0.0. > > Regards, > N From harishvk27 at gmail.com Sun Feb 7 21:19:46 2021 From: harishvk27 at gmail.com (Harish Kulkarni) Date: Mon, 8 Feb 2021 02:49:46 +0530 Subject: Default value of a session resumption timeout (300 seconds vs 7200 seconds) In-Reply-To: References: <8c5d46e5-4ead-ed3b-1671-3929db78df9d@openssl.org> <3bcaee40-5bbe-fa3c-d95f-d1e637d59509@openssl.org> Message-ID: Hi, Got over this issue.. of memory leak.. it's because of inappropriate usage of openssl library API's by glib-openssl library. ( https://mail.gnome.org/archives/commits-list/2018-September/msg06774.html ) This issue was fixed in glib-openssl libraries earlier itself.. but in our code base we didn't had this fix.. Any way. thanks you all. have a nice week ahead. -thanks harish On Sun, Jan 31, 2021 at 10:06 AM Harish Kulkarni wrote: > I am using heaptrack memory analyzer tool to track some memory leak on an > application which is using openssl as CLIENT. > One of the observations is we see constant leak with below backtrace. My > analysis has been this is to do with local caching of sessions, or some > free which we are not doing from applicable layer. > > I am doing current code changes to replace reference CRYPTO_ADD with > actually replicating the object which we can referring counting.. so that i > can know at which location we are actually referring to object(s) and then > later not freeing it up. > > Is there a easy way in OPENSSL source code to replace reference counts > with actual multiple objects allocation so that it's easy to track memory > usages.. otherwise the code is so complex for newbies to understand and fix > anything. > > > CRYPTO_malloc in mem.c:350 (libcrypto.so.1.0.0) > > asn1_enc_save in tasn_utl.c:179 (libcrypto.so.1.0.0) > > asn1_item_ex_d2i in tasn_dec.c:507 (libcrypto.so.1.0.0) > > asn1_template_noexp_d2i in tasn_dec.c:719 (libcrypto.so.1.0.0) > > asn1_template_ex_d2i in tasn_dec.c:604 (libcrypto.so.1.0.0) > > asn1_item_ex_d2i in tasn_dec.c:461 (libcrypto.so.1.0.0) > > ASN1_item_ex_d2i in tasn_dec.c:534 (libcrypto.so.1.0.0) > > ASN1_item_d2i in tasn_dec.c:154 (libcrypto.so.1.0.0) > > ssl3_get_server_certificate in s3_clnt.c:1245 (libssl.so.1.0.0) > > ssl3_connect in s3_clnt.c:351 (libssl.so.1.0.0) > > ssl23_get_server_hello in s23_clnt.c:832 (libssl.so.1.0.0) > > ssl23_connect in s23_clnt.c:231 (libssl.so.1.0.0) > > in ?? (libgioopenssl.so) > > in ?? (libgioopenssl.so) > > in ?? (libgioopenssl.so) > > in ?? (libgio-2.0.so.0) > > On Thu, Jan 28, 2021 at 10:46 PM Harish Kulkarni > wrote: > >> Hi, >> >> I keep seeing growth in memory usage.. suspecting a leak. Want to disable >> reference counting as well as stop caches so that i can isolate the issue. >> >> It's all happening on client side. I will try disabling cache.. >> >> Mean while if any other inputs/pointers would be helpful. >> >> -thanks >> harish >> >> >> On Wed, Jan 27, 2021 at 3:32 PM Matt Caswell wrote: >> >>> >>> >>> On 26/01/2021 18:13, Harish Kulkarni wrote: >>> > Thank you both for bringing this to my attention, your points are >>> > invaluable. >>> > >>> > If this is something which gets set from server on client side. can >>> > client override this?. Can i change this to something less and try?. >>> Has >>> > anyone tried?. >>> > >>> > Whats the option in openssl.conf or some other place?. >>> >>> The session timeout is something entirely controlled by the server. The >>> client has no influence on this*. If the server is using session tickets >>> for its sessions then it provides a lifetime hint to the client to say >>> how long the client can expect the session to be good for. The client >>> can query this using SSL_SESSION_get_ticket_lifetime_hint(). >>> >>> On the server the timeout can be configured using SSL_CTX_set_timeout(). >>> I don't think this is possible to change via openssl.conf. >>> >>> Matt >>> >>> >>> * Note that the client may be managing a cache of sessions provided by >>> servers. That's not something that happens by default in OpenSSL but can >>> be configured using SSL_CTX_set_session_cache_mode(). In that case there >>> will be separate timeouts associated with the life of the session in the >>> client cache. Those timeouts may not be the same as the server's >>> timeouts. >>> >>> > >>> > -thanks >>> > harish >>> > >>> > >>> > On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell >> > > wrote: >>> > >>> > >>> > >>> > On 23/01/2021 15:22, John Thoe wrote: >>> > > Hi list, >>> > > >>> > > The session reuse question posted on the mailing list earlier >>> > > >>> > ( >>> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html >>> ) >>> > > reminded of a somewhat similar question I have. >>> > > >>> > > As per the docs, >>> > > >>> > >>> https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html, >>> > > it says the default value is 300 seconds for which a session >>> resuse >>> > > will be accepted. The docs say that it is the same for all >>> > > protocols. >>> > > >>> > > However I tried it with my setup where I didn't explicitly set >>> the >>> > > timeout and I am getting 7200 seconds as the default value. >>> s_client >>> > > output: TLS session ticket lifetime hint: 7200 (seconds). My >>> client >>> > > openssl.conf has no setting override (not that it should matter >>> > > because this is a server preference). No OpenSSL settings on the >>> > > server have been modified as well. >>> > >>> > Looks to me like the docs are wrong. They probably should say 7200. >>> > >>> > >>> > > >>> > > In ssl/ssl_sess.c#L80, the code matches the document: >>> ss->timeout = >>> > > 60 * 5 + 4; /* 5 minute timeout by default */ ... (with >>> additional >>> > > four seconds?) >>> > >>> > >>> > This gets set during construction and then later overwritten when >>> we >>> > actually get a new session via "ssl_get_new_session": >>> > >>> > /* If the context has a default timeout, use it */ >>> > if (s->session_ctx->session_timeout == 0) >>> > ss->timeout = SSL_get_default_timeout(s); >>> > else >>> > ss->timeout = s->session_ctx->session_timeout; >>> > >>> > In most cases SSL_get_default_timeout() calls >>> tls1_default_timeout() (it >>> > can end up somewhere different for certain protocol versions - but >>> all >>> > the different variants are the same!): >>> > >>> > long tls1_default_timeout(void) >>> > { >>> > /* >>> > * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too >>> > long for >>> > * http, the cache would over fill >>> > */ >>> > return (60 * 60 * 2); >>> > } >>> > >>> > 60 * 60 * 2 = 7200 >>> > >>> > >>> > Matt >>> > >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1nagarjun1 at gmail.com Mon Feb 8 15:33:25 2021 From: 1nagarjun1 at gmail.com (Nagarjun J) Date: Mon, 8 Feb 2021 21:03:25 +0530 Subject: SP800-56A REV3 Message-ID: Hi , What is this SP800-56A REV3 new FIPS requirement, How it affects ECDH , how it is different from openssl-2.0.16 ECDH implication. Which all functions that affects. Regards Nagarjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Mon Feb 8 17:49:01 2021 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 8 Feb 2021 17:49:01 +0000 Subject: SP800-56A REV3 In-Reply-To: References: Message-ID: > From: openssl-users On Behalf Of Nagarjun J > Sent: Monday, 8 February, 2021 10:33 > What is this SP800-56A REV3 new FIPS requirement, Well, one thing it isn't is "new". Published April 2018, so nearly 3 years ago. See: https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final > How it affects ECDH , I believe it mostly affects which curves are permitted, and which are required for security strength > 112 bits. See this description: https://www.doncio.navy.mil/chips/ArticleDetails.aspx?ID=9667 > how it is different from openssl-2.0.16 ECDH implication. Presumably you're referring to the version of the OpenSSL FOM, since OpenSSL itself went from 1.1.1 to 3.0. FOM 2.0.16 was completed before SP800-56A Rev.3 was published, so obviously it doesn't meet the Rev.3 specification. So the curves which are allowed in FIPS mode are different - and in particular, more restricted - in OpenSSL than they would be if it followed Rev.3. > Which all functions that affects. All of the ECDH ones, in FIPS mode, since it affects which curves are allowed. Outside of FIPS mode, it's irrelevant. The OpenSSL FOM's validation has historical status anyway, so I don't see the lack of SP800-56A Rev.3 compliance as making much of a difference in terms of validation. I suppose it might create issues for interoperability, if a peer system using a different implementation in FIPS mode insisted on using a curve allowed by Rev.3 but not by earlier SP800-56A revisions. But I generally don't work with FIPS mode. -- Michael Wojcik From matt at openssl.org Tue Feb 9 17:33:54 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 9 Feb 2021 17:33:54 +0000 Subject: Forthcoming OpenSSL Release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1j. This release will be made available on Tuesday 16th February 2021 between 1300-1700 UTC. OpenSSL 1.1.1j is a security-fix release. The highest severity issue fixed in this release is MODERATE: https://www.openssl.org/policies/secpolicy.html#moderate Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAix4IACgkQ2cTSbQ5g RJEObwgAkM5/Nx3KjqX1Uj69C6b+8Cxx2ijdfei4wQjkVhLqZLteZpKDE0QBAHsV wGc3cwv1AyPnNfgWvfUwj0k5mRr67fYkz+iAJiNisLc40k0+xPd9F2F804TvKQh2 6HPRY2+AEpQD6nuxJejIOBZruDbFaXRzh1rloQggE9tqUoLslQbYhkrR6BRiePqN zQarux5yBZDfkQzkaYTDqFH5M6RLrb3w5hlJiJ4uJ1lLz4FNyeUtADofluiIrJuj zDRZxocOVoyUt2wIZZ+2xhMY894hlilwnBE+fXvWu5d4HakdZkHe4p+HFvP/O0IY AGn/qXIQfYGt9jH93jCPFdrgO/jvWA== =ZcL6 -----END PGP SIGNATURE----- From dirkx at webweaving.org Thu Feb 11 09:38:39 2021 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Thu, 11 Feb 2021 10:38:39 +0100 Subject: odd segfault / must be something obvious Message-ID: <84B0713E-6960-4ACE-82A0-F9BCBDD0E08B@webweaving.org> I am hitting a head end and must be missing something obvious. Below is the code - it verifies a signature. And it segfaults regularly on the PKCS7_free(p7); And I fail to understand why - and suspect it is very obvious ! Any and all help appreciated. Dw #define EXITOUT(args...) { EOUT(args); goto errit; } int result = NO; BIO *signatureBlob = NULL, *contentBlob = NULL, *certificateBlob = NULL; X509_VERIFY_PARAM *verifyParameters = NULL; STACK_OF(X509) *signers = NULL; X509_STORE *store = NULL; X509 *signingCert = NULL; PKCS7 *p7 = NULL; if (NULL == (signatureBlob = BIO_new_mem_buf(sig.bytes, (int)sig.length))) EXITOUT("invalid signatureBlob"); if (NULL == (contentBlob = BIO_new_mem_buf(cont.bytes, (int)cont.length))) EXITOUT("invalid contentBlob"); if (NULL == (certificateBlob = BIO_new_mem_buf(cert.bytes, (int)cert.length))) EXITOUT("invalid certificateBlob"); if (NULL == (p7 = d2i_PKCS7_bio(signatureBlob, NULL))) EXITOUT("invalid PKCS#7 structure in signatureBlob"); if (NULL == (signers = PKCS7_get0_signers(p7, NULL, 0))) EXITOUT("No signers in PCKS#7 signatureBlob"); if (sk_X509_num(signers) == 1) EXITOUT("Not signer exactly one signer in PCKS#7 signatureBlob"); // do various validations/comparisons on signingCert = sk_X509_value(signers, 0); if ((NULL == (store = X509_STORE_new()))) EXITOUT("store"); for(X509 *cert = NULL;;cnt++) { if (NULL == (cert = PEM_read_bio_X509(certificateBlob, NULL, 0, NULL))) break; if (X509_STORE_add_cert(store, cert) != 1) EXITOUT("Could not add cert %d to chain.",1+cnt); #ifdef __DEBUG print_certificate(cert); #endif X509_free(cert); }; ERR_clear_error(); if (cnt == 0) EXITOUT("no trust chain of any length"); if (NULL == (verifyParameters = X509_VERIFY_PARAM_new())) EXITOUT("Could create verifyParameters"); // setup verifyParameters .. result = PKCS7_verify(p7, NULL, store, contentBlob, NULL, PKCS7_BINARY); // error handling / printing errit: if (verifyParameters) X509_VERIFY_PARAM_free(verifyParameters); if (store) X509_STORE_free(store); if (p7) PKCS7_free(p7); // <----- **********************. segfault if (signatureBlob) BIO_free(signatureBlob); if (contentBlob) BIO_free(contentBlob); if (certificateBlob) BIO_free(certificateBlob); return result == 1; } From alon.barlev at gmail.com Sat Feb 13 21:23:13 2021 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 13 Feb 2021 23:23:13 +0200 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) Message-ID: Hello, I am trying to resign a CMS using the openssl tool. When I use RSA-PKCS1 everything is working fine. When I use RSA-PSS it seems like the asn1 is produced corrupted, I do not see the signature in asn1dump. I prepared a demo[1] to help people reproduce the issue, tested with openssl-1.1.1i. The script output pasted below shows that CMS resign without PSS works correctly, while the same sequence with PSS produces a corrupted CMS file. What am I doing wrong? Regards, Alon Bar-Lev [1] https://github.com/alonbl/openssl-cms-pss --- =============== CMS without PSS =============== cms -sign 1.cms cms -verify 1.cms hello world Verification successful cms -resign 1.cms to 2.cms cms -verify 2.cms hello world Verification successful =============== CMS with PSS =============== cms -sign 1.cms cms -verify 1.cms hello world Verification successful cms -resign 1.cms to 2.cms cms -verify 2.cms Error reading S/MIME message 140438977062208:error:0D078079:asn1 encoding routines:asn1_item_embed_d2i:field missing:../crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR 140438977062208:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, Type=CMS_SignerInfo 140438977062208:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:614:Field=signerInfos, Type=CMS_SignedData 140438977062208:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:646: 140438977062208:error:0D08403A:asn1 encoding routines:asn1_template_ex_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo FATAL: verify 2.cms failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From quanah at symas.com Sat Feb 13 21:34:27 2021 From: quanah at symas.com (Quanah Gibson-Mount) Date: Sat, 13 Feb 2021 13:34:27 -0800 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: <27358FEF64D0698FD398209A@[192.168.1.156]> --On Saturday, February 13, 2021 11:23 PM +0200 Alon Bar-Lev wrote: > I prepared a demo[1] to help people reproduce the issue, tested with > openssl-1.1.1i. Maybe ? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From alon.barlev at gmail.com Sat Feb 13 22:00:35 2021 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 14 Feb 2021 00:00:35 +0200 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: <27358FEF64D0698FD398209A@192.168.1.156> References: <27358FEF64D0698FD398209A@192.168.1.156> Message-ID: On Sat, Feb 13, 2021 at 11:34 PM Quanah Gibson-Mount wrote: > --On Saturday, February 13, 2021 11:23 PM +0200 Alon Bar-Lev > wrote: > > > I prepared a demo[1] to help people reproduce the issue, tested with > > openssl-1.1.1i. > > Maybe ? > Thanks Quanah, I tested OpenSSL_1_1_1-stable branch which should have fixed the issue, the result is the same. Regards, Alon From doctor at doctor.nl2k.ab.ca Sun Feb 14 12:33:51 2021 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 14 Feb 2021 05:33:51 -0700 Subject: OpenSSL 3.0 daily snapshot Message-ID: Anyome running tests running into an infinite loop on 04-test_encoder_decoder_legacy.t ? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b NFLD on 13 Feb vote Liberal ! From levitte at openssl.org Mon Feb 15 13:06:17 2021 From: levitte at openssl.org (Richard Levitte) Date: Mon, 15 Feb 2021 14:06:17 +0100 Subject: OpenSSL 3.0 daily snapshot In-Reply-To: References: Message-ID: <78C905E0-0C79-4538-849E-2E5755F3B886@openssl.org> Hmmm, I have never seen that (apart from in one of my own development branches, but that never reached the main source). If you want anyone to look into it, it would be a good idea to show us what your configuration is. The output from this command is recommended: perl configdata.pm -d Cheers Richard The Doctor skrev: (14 februari 2021 13:33:51 CET) >Anyome running tests running into an infinite loop >on 04-test_encoder_decoder_legacy.t ? -- Richard by mobile From doctor at doctor.nl2k.ab.ca Mon Feb 15 15:29:16 2021 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 15 Feb 2021 08:29:16 -0700 Subject: OpenSSL 3.0 daily snapshot In-Reply-To: <78C905E0-0C79-4538-849E-2E5755F3B886@openssl.org> References: <78C905E0-0C79-4538-849E-2E5755F3B886@openssl.org> Message-ID: On Mon, Feb 15, 2021 at 02:06:17PM +0100, Richard Levitte wrote: > Hmmm, I have never seen that (apart from in one of my own development branches, but that never reached the main source). > > If you want anyone to look into it, it would be a good idea to show us what your configuration is. The output from this command is recommended: > > perl configdata.pm -d > > Cheers > Richard > > > The Doctor skrev: (14 februari 2021 13:33:51 CET) > >Anyome running tests running into an infinite loop > >on 04-test_encoder_decoder_legacy.t ? > Will do. Command line (with current working directory = .): /usr/local/bin/perl ./Configure --prefix=/usr/local/ BSD-x86_64 enable-ec_nistp_64_gcc_128 enable-sctp enable-fips no-crypto-mdebug no-crypto-mdebug-backtrace no-asan no-fuzz-afl no-fuzz-libfuzzer no-heartbeats no-idea no-md2 no-md4 no-msan no-rc5 no-sm2 no-sm3 enable-rfc3779 enable-shared zlib-dynamic enable-rc4 no-ssl3 no-ssl3-method no-ubsan no-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test Perl information: /usr/local/bin/perl 5.30.3 for amd64-freebsd-thread-multi Enabled features: acvp_tests aria asm async autoalginit autoerrinit autoload-config bf blake2 bulk cached-fetch camellia capieng cast chacha cmac cmp cms comp ct deprecated des devcryptoeng dgram dh dsa dso dtls dynamic-engine ec ec2m ecdh ecdsa ec_nistp_64_gcc_128 engine err filenames fips fips-securitychecks gost legacy makedepend mdc2 module multiblock nextprotoneg pinshared ocb ocsp padlockeng pic poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt sctp secure-memory seed shared siphash siv sm4 sock srp srtp sse2 ssl ssl-trace static-engine stdio tests threads tls ts ui-console unit-test whirlpool zlib zlib-dynamic tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: afalgeng [not-linux] OPENSSL_NO_AFALGENG asan [option] OPENSSL_NO_ASAN buildtest-c++ [default] crypto-mdebug [option] OPENSSL_NO_CRYPTO_MDEBUG egd [default] OPENSSL_NO_EGD external-tests [default] OPENSSL_NO_EXTERNAL_TESTS fuzz-libfuzzer [option] OPENSSL_NO_FUZZ_LIBFUZZER fuzz-afl [option] OPENSSL_NO_FUZZ_AFL idea [option] OPENSSL_NO_IDEA (skip crypto/idea) ktls [default] OPENSSL_NO_KTLS md2 [option] OPENSSL_NO_MD2 (skip crypto/md2) md4 [option] OPENSSL_NO_MD4 (skip crypto/md4) msan [option] OPENSSL_NO_MSAN rc5 [option] OPENSSL_NO_RC5 (skip crypto/rc5) sm2 [option] OPENSSL_NO_SM2 (skip crypto/sm2) sm3 [option] OPENSSL_NO_SM3 (skip crypto/sm3) trace [default] OPENSSL_NO_TRACE ubsan [option] OPENSSL_NO_UBSAN uplink [no uplink_arch] OPENSSL_NO_UPLINK weak-ssl-ciphers [option] OPENSSL_NO_WEAK_SSL_CIPHERS ssl3 [option(ssl3-method)] OPENSSL_NO_SSL3 ssl3-method [option] OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "ar", ARFLAGS => "qc", CC => "cc", CFLAGS => "-Wall -O3", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", asm_arch => "x86_64", bn_ops => "SIXTY_FOUR_BIT_LONG", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cflags => "-pthread", cppflags => "-D_THREAD_SAFE -D_REENTRANT", defines => [ "OPENSSL_BUILDING_OPENSSL", "ZLIB", "ZLIB_SHARED" ], disable => [ ], dso_ldflags => "-Wl,-z,defs", dso_scheme => "dlfcn", enable => [ "devcryptoeng" ], ex_libs => "-pthread", includes => [ ], lflags => "", lib_cflags => "", lib_cppflags => "-DL_ENDIAN", lib_defines => [ ], module_cflags => "-fPIC", module_cxxflags => undef, module_ldflags => "-shared -Wl,-Bsymbolic", perl_platform => "Unix", perlasm_scheme => "elf", shared_cflag => "-fPIC", shared_defflag => "-Wl,--version-script=", shared_defines => [ ], shared_ldflag => "-shared -Wl,-Bsymbolic", shared_rcflag => "", shared_sonameflag => "-Wl,-soname=", shared_target => "bsd-gcc-shared", thread_defines => [ ], thread_scheme => "pthreads", unistd => "", Recorded environment: AR = ARFLAGS = AS = ASFLAGS = BUILDFILE = CC = /usr/local/bin/clang11 CFLAGS = CPP = CPPDEFINES = CPPFLAGS = CPPINCLUDES = CROSS_COMPILE = CXX = CXXFLAGS = HASHBANGPERL = LD = LDFLAGS = LDLIBS = MT = MTFLAGS = OPENSSL_LOCAL_CONFIG_DIR = PERL = RANLIB = RC = RCFLAGS = RM = WINDRES = __CNF_CFLAGS = __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = ar ARFLAGS = qc CC = /usr/local/bin/clang11 CFLAGS = -Wall -O3 CPPDEFINES = CPPFLAGS = CPPINCLUDES = CXXFLAGS = HASHBANGPERL = /usr/bin/env perl LDFLAGS = LDLIBS = PERL = /usr/local/bin/perl RANLIB = ranlib RC = windres RCFLAGS = NOTE: These variables only represent the configuration view. The build file template may have processed these variables further, please have a look at the build file for more exact data: Makefile build file: Makefile build file templates: Configurations/common0.tmpl Configurations/unix-Makefile.tmpl Configurations/common.tmpl > -- > Richard by mobile -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b NFLD on 13 Feb vote Liberal ! From thulasi.goriparthi at gmail.com Mon Feb 15 21:03:44 2021 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Tue, 16 Feb 2021 02:33:44 +0530 Subject: encoding/decoding ECX private key with optional public key Message-ID: Hello, Is there any option either in 1.1.1 or 3.0.0 to encode ECX(x25519, x448, ed25519, ed448) private keys along with optional/implicit public key as specified in https://tools.ietf.org/html/rfc8410#page-7 Is there any plan to provide this support in future? I ask this as I have come across an h/w which generates ecx (private) key, returns reference to the private key and the corresponding public key(octet string). Private key reference instead of actual private key is encoded while storing the key persistently. Public key derived by s/w from this "dummy" private key wouldn't be the correct public key and h/w doesn't have the ability/support to take in the private key reference to generate the public key. This makes saving public key along with private key (reference) unavoidable at the time of key generation. I would like to know how other h/w engines/providers supporting ecx keygen are handling this situation. Thanks, Thulasi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Tue Feb 16 00:32:46 2021 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Tue, 16 Feb 2021 06:02:46 +0530 Subject: ./CA.pl -newreq specify servername Message-ID: Hi, I am running CentOS Linux release 7.9.2009 (Core). #rpm -qa | grep openssl openssl-devel-1.0.2k-21.el7_9.x86_64 openssl-libs-1.0.2k-21.el7_9.x86_64 openssl-1.0.2k-21.el7_9.x86_64 openssl-perl-1.0.2k-21.el7_9.x86_64 cd /etc/pki/tls/misc [root at basheerdevops misc]# ll total 64 -rwxr-xr-x. 1 root root 5178 Dec 17 02:53 CA -rwxr-xr-x 1 root root 5691 Dec 17 02:53 CA.pl -rwxr-xr-x. 1 root root 119 Dec 17 02:53 c_hash -rwxr-xr-x. 1 root root 152 Dec 17 02:53 c_info -rwxr-xr-x. 1 root root 112 Dec 17 02:53 c_issuer -rwxr-xr-x. 1 root root 110 Dec 17 02:53 c_name -rw-r--r-- 1 root root 4837 Feb 16 05:51 newcert.pem -rw-r--r-- 1 root root 1834 Feb 16 05:49 newkey.pem -rw-r--r-- 1 root root 1115 Feb 16 05:49 newreq.pem -rwxr-xr-x 1 root root 6419 Dec 17 02:53 target #./CA.pl -newreq --> is there a way to specify server name? For example gitlabinternal. By default, it saves in file *newcert.pem* #./CA.pl -sign I ran the below command to copy #cp newcert.pem gitlabinternal.pem #openssl x509 -in gitlabinternal.pem -noout -text Is there a way to specify servername in ./CA.pl -newreq command ? Please suggest further. Thanks in advance. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.Buehlmann at mabulous.com Tue Feb 16 02:35:32 2021 From: Matthias.Buehlmann at mabulous.com (Matthias Buehlmann) Date: Tue, 16 Feb 2021 03:35:32 +0100 Subject: What does 'openssl ts -verify' verify exactly? Message-ID: If openssl ts -verify is used, what exactly is verified? For example, while the [-crl_check] [-crl_check_all] and [-extended_crl] verify options are supported, there is no way to pass CRLs to the call. So, is anything checked for revocation? How are timestamps verified for which the signing certificate has expired or has been revoked? If I understand correctly, to verify the validity of a timestamp token at the current time, one must - Check that the singing certificate was valid at the time of timestamp (for this either current or historical CRLs for the entire trust chain must be checked) - If the certificate is not valid anymore at the current time, one must show that none of the certificates in the trust chain have been revoked, or that those that have been revoked have the reasonCode extension and that this reasonCode extension shows one of the following revocation reasons: unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5), in which case the timestamp token is still valid (section 4 off https://www.ietf.org/rfc/rfc3161.txt) Can openssl ts -verify do that? If not, how is a timestamp token properly verified using OpenSSL? From hkario at redhat.com Tue Feb 16 13:48:46 2021 From: hkario at redhat.com (Hubert Kario) Date: Tue, 16 Feb 2021 14:48:46 +0100 Subject: What does 'openssl ts -verify' verify =?iso-8859-1?Q?exactly=3F?= In-Reply-To: References: Message-ID: On Tuesday, 16 February 2021 03:35:32 CET, Matthias Buehlmann wrote: > If openssl ts -verify is used, what exactly is verified? > > For example, while the [-crl_check] [-crl_check_all] and > [-extended_crl] verify options are supported, there is no way to pass > CRLs to the call. So, is anything checked for revocation? > > How are timestamps verified for which the signing certificate has > expired or has been revoked? > > If I understand correctly, to verify the validity of a timestamp token > at the current time, one must > - Check that the singing certificate was valid at the time of > timestamp (for this either current or historical CRLs for the entire > trust chain must be checked) that's not correct, the timestamp is only valid as long as the singing certificate is valid if you want to retain validity of a timestamp, you need to timestamp the timestamp with a new TSA, and then keep on applying additional timestamps as TSA certs lose validity see XAdES-A, PAdES-A, or CAdES-A standards for practical implementaiton of this > - If the certificate is not valid anymore at the current time, one > must show that none of the certificates in the trust chain have been > revoked, or that those that have been revoked have the reasonCode > extension and that this reasonCode extension shows one of the > following revocation reasons: unspecified (0), affiliationChanged (3), > superseded (4) or cessationOfOperation (5), in which case the > timestamp token is still valid (section 4 off > https://www.ietf.org/rfc/rfc3161.txt) if the certificate is not valid any more and you have no newer timestamp proving that the original timestamp was created before the certificate lost validity, then the original timestamp is useless now, to verify a certificate in the past you need to have a CRL or an OCSP _from the time it was still valid._ CAs have no obligation to retain a certificate in the CRL after it lost validity. But at the same time you can't have a CRL or OCSP response from similar time as the timestamp, as the CAs have a grace period to issue revocation information, so you need to have a saved CRL or OCSP response likely from a day later to few weeks later. I can only recommend reading one of the standards I mentioned above, it goes into much more detail about all of it > Can openssl ts -verify do that? If not, how is a timestamp token > properly verified using OpenSSL? no, ts -verify just does simple check at *now,* it has no support for CAdES-A, if you need it, you need to implement it yourself -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From Matthias.Buehlmann at mabulous.com Tue Feb 16 14:54:24 2021 From: Matthias.Buehlmann at mabulous.com (Matthias Buehlmann) Date: Tue, 16 Feb 2021 15:54:24 +0100 Subject: What does 'openssl ts -verify' verify exactly? In-Reply-To: References: Message-ID: Hello Hubert (sorry, replied to your e-mail address directly before instead of the mailing list), thank you for your reply, but I don't think you're correct that timestamp tokens expire together with the signing certificate! Timestamp tokens CAN stay valid beyond the validity of the signing certificate, otherwise PAdES LTV (Long Term Validity) wouldn't make much sense. Check RFC3161 specification chapter 4.1: When a TSA shall not be used anymore, but the TSA private key has not been compromised, the authority's certificate SHALL be revoked. When the reasonCode extension relative to the revoked certificate from the TSA is present in the CRL entry extensions, it SHALL be set either to unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5). In that case, at any future time, the tokens signed with the corresponding key will be considered as invalid, but tokens generated before the revocation time will remain valid. When the reasonCode extension relative to the revoked certificate from the TSA is not present in the CRL entry extensions, then all the tokens that have been signed with the corresponding key SHALL be considered as invalid. For that reason, it is recommended to use the reasonCode extension. Chapter 4.3 DOES talk about key lifetime and renewing trust in issued tokens by restamping, however the term "lifetime" used here is in relation to key-length (longer key-length = longer lifetime, finite key-length = finite lifetime), NOT validity period of TSA certificate: The TSA signing key MUST be of a sufficient length to allow for a sufficiently long lifetime. Even if this is done, the key will have a finite lifetime. Thus, any token signed by the TSA SHOULD be time-stamped again (if authentic copies of old CRLs are available) or notarized (if they aren't) at a later date to renew the trust that exists in the TSA's signature. time-stamp tokens could also be kept with an Evidence Recording Authority to maintain this trust. It doesn't make sense that a token could retain its validity beyond the validity of the TSA certificate in a revocation scenario (when key or CA hasn't been compromised) but not in an expiration scenario. All TSA certificates I encountered so far have very short lifetimes (1-3 years). If it was true that tokens would only remain valid within that period without being restamped, the whole point of PAdES LTV would be moot. Cheers and thank you for your help, Matthias On Tue, Feb 16, 2021 at 2:49 PM Hubert Kario wrote: > On Tuesday, 16 February 2021 03:35:32 CET, Matthias Buehlmann wrote: > > If openssl ts -verify is used, what exactly is verified? > > > > For example, while the [-crl_check] [-crl_check_all] and > > [-extended_crl] verify options are supported, there is no way to pass > > CRLs to the call. So, is anything checked for revocation? > > > > How are timestamps verified for which the signing certificate has > > expired or has been revoked? > > > > If I understand correctly, to verify the validity of a timestamp token > > at the current time, one must > > - Check that the singing certificate was valid at the time of > > timestamp (for this either current or historical CRLs for the entire > > trust chain must be checked) > > that's not correct, the timestamp is only valid as long as the singing > certificate is valid > > if you want to retain validity of a timestamp, you need to timestamp the > timestamp with a new TSA, and then keep on applying additional timestamps > as > TSA certs lose validity > > see XAdES-A, PAdES-A, or CAdES-A standards for practical implementaiton of > this > > > - If the certificate is not valid anymore at the current time, one > > must show that none of the certificates in the trust chain have been > > revoked, or that those that have been revoked have the reasonCode > > extension and that this reasonCode extension shows one of the > > following revocation reasons: unspecified (0), affiliationChanged (3), > > superseded (4) or cessationOfOperation (5), in which case the > > timestamp token is still valid (section 4 off > > https://www.ietf.org/rfc/rfc3161.txt) > > if the certificate is not valid any more and you have no newer timestamp > proving that the original timestamp was created before the certificate lost > validity, then the original timestamp is useless > > now, to verify a certificate in the past you need to have a CRL or an OCSP > _from the time it was still valid._ CAs have no obligation to retain a > certificate in the CRL after it lost validity. But at the same time you > can't have a CRL or OCSP response from similar time as the timestamp, as > the CAs have a grace period to issue revocation information, so you need to > have a saved CRL or OCSP response likely from a day later to few weeks > later. > > I can only recommend reading one of the standards I mentioned above, it > goes into much more detail about all of it > > > Can openssl ts -verify do that? If not, how is a timestamp token > > properly verified using OpenSSL? > > no, ts -verify just does simple check at *now,* it has no support for > CAdES-A, > if you need it, you need to implement it yourself > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Tue Feb 16 15:34:11 2021 From: hkario at redhat.com (Hubert Kario) Date: Tue, 16 Feb 2021 16:34:11 +0100 Subject: What does 'openssl ts -verify' verify =?iso-8859-1?Q?exactly=3F?= In-Reply-To: References: Message-ID: <77cfba15-be19-463b-8875-00dd26ada934@redhat.com> On Tuesday, 16 February 2021 15:54:24 CET, Matthias Buehlmann wrote: > Hello Hubert (sorry, replied to your e-mail address directly before instead > of the mailing list), > > thank you for your reply, but I don't think you're correct that timestamp > tokens expire together with the signing certificate! Timestamp tokens CAN > stay valid beyond the validity of the signing certificate, otherwise PAdES > LTV (Long Term Validity) wouldn't make much sense. Check RFC3161 > specification chapter 4.1: > > When a TSA shall not be used anymore, but the TSA private key has > not been compromised, the authority's certificate SHALL be > revoked. When the reasonCode extension relative to the revoked > certificate from the TSA is present in the CRL entry extensions, > it SHALL be set either to unspecified (0), affiliationChanged (3), > superseded (4) or cessationOfOperation (5). In that case, at any > future time, the tokens signed with the corresponding key will be > considered as invalid, but tokens generated before the revocation > time will remain valid. When the reasonCode extension relative to > the revoked certificate from the TSA is not present in the CRL > entry extensions, then all the tokens that have been signed with > the corresponding key SHALL be considered as invalid. For that > reason, it is recommended to use the reasonCode extension. not necessarily, it does not talk about the notAfter date at all, only about "not used anymore", that may (and actually should) happen at least a year before notAfter date but the details I remember may be from Qualified Signature requirements, not the IETF standards I do know that the BSI has a different policy still, so you need to know under which policy you need to perform the verification > Chapter 4.3 DOES talk about key lifetime and renewing trust in issued > tokens by restamping, however the term "lifetime" used here is in relation > to key-length (longer key-length = longer lifetime, finite key-length = > finite lifetime), NOT validity period of TSA certificate: > > The TSA signing key MUST be of a sufficient length to allow for a > sufficiently long lifetime. Even if this is done, the key will > have a finite lifetime. Thus, any token signed by the TSA SHOULD > be time-stamped again (if authentic copies of old CRLs are > available) or notarized (if they aren't) at a later date to renew > the trust that exists in the TSA's signature. time-stamp tokens > could also be kept with an Evidence Recording Authority to > maintain this trust. > > It doesn't make sense that a token could retain its validity beyond the > validity of the TSA certificate in a revocation scenario (when key or CA > hasn't been compromised) but not in an expiration scenario. > All TSA certificates I encountered so far have very short lifetimes (1-3 > years). If it was true that tokens would only remain valid within that > period without being restamped, the whole point of PAdES LTV would be moot. the whole problem is that if you trust the date in the timestamp as the date the timestamp was created, attacker can compromise the TSA key years after it was last used and then create timestamps that look like they have been created while the TSA key was still valid -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From openssl at openssl.org Tue Feb 16 16:12:43 2021 From: openssl at openssl.org (OpenSSL) Date: Tue, 16 Feb 2021 16:12:43 +0000 Subject: OpenSSL version 1.1.1j published Message-ID: <20210216161243.GA15166@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1j released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1j of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1j is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1j.tar.gz Size: 9823161 SHA1 checksum: 04c340b086828eecff9df06dceff196790bb9268 SHA256 checksum: aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1j.tar.gz openssl sha256 openssl-1.1.1j.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAr45gACgkQ2cTSbQ5g RJFhXAf7BMbLDUqKxw1YnGpUTXRTKe1TSzrOPI/m/yfyn3YHm64HYwTxNy8Idm9Y V+78djXqhs3VMDDu9ZOmopSLEOOOHvpKE89kj7pHrYnOJcmPE+HNmS0qneOyQZtb slvYbDhqeyEqNxy/jVlz6Bm/BV57HdbszpAzhv9zTP6hf6aYvNwIFJoPpHznu028 Knn+qrlkcHizKPY9zG1h8zfK9m6CWGV+S8qeKHERgvlKBz6hAOYC/3f6sZumRr7K m7jEEjkEvjVzcojXKoY2+C9yeRwJdj8GM2Haa+kdwcW34o4uCOrP+mW+MeBg+4qM id26+r6cNtTdv7jE4gPWLCKoOZ7CsA== =baPF -----END PGP SIGNATURE----- From openssl at openssl.org Tue Feb 16 16:27:22 2021 From: openssl at openssl.org (OpenSSL) Date: Tue, 16 Feb 2021 16:27:22 +0000 Subject: OpenSSL Security Advisory Message-ID: <20210216162722.GA18992@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [16 February 2021] ============================================ Null pointer deref in X509_issuer_and_serial_hash() (CVE-2021-23841) ==================================================================== Severity: Moderate The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 15th December 2020 by Tavis Ormandy from Google. The fix was developed by Matt Caswell. Incorrect SSLv2 rollback protection (CVE-2021-23839) ==================================================== Severity: Low OpenSSL 1.0.2 supports SSLv2. If a client attempts to negotiate SSLv2 with a server that is configured to support both SSLv2 and more recent SSL and TLS versions then a check is made for a version rollback attack when unpadding an RSA signature. Clients that support SSL or TLS versions greater than SSLv2 are supposed to use a special form of padding. A server that supports greater than SSLv2 is supposed to reject connection attempts from a client where this special form of padding is present, because this indicates that a version rollback has occurred (i.e. both client and server support greater than SSLv2, and yet this is the version that is being requested). The implementation of this padding check inverted the logic so that the connection attempt is accepted if the padding is present, and rejected if it is absent. This means that such as server will accept a connection if a version rollback attack has occurred. Further the server will erroneously reject a connection if a normal SSLv2 connection attempt is made. Only OpenSSL 1.0.2 servers from version 1.0.2s to 1.0.2x are affected by this issue. In order to be vulnerable a 1.0.2 server must: 1) have configured SSLv2 support at compile time (this is off by default), 2) have configured SSLv2 support at runtime (this is off by default), 3) have configured SSLv2 ciphersuites (these are not in the default ciphersuite list) OpenSSL 1.1.1 does not have SSLv2 support and therefore is not vulnerable to this issue. The underlying error is in the implementation of the RSA_padding_check_SSLv23() function. This also affects the RSA_SSLV23_PADDING padding mode used by various other functions. Although 1.1.1 does not support SSLv2 the RSA_padding_check_SSLv23() function still exists, as does the RSA_SSLV23_PADDING padding mode. Applications that directly call that function or use that padding mode will encounter this issue. However since there is no support for the SSLv2 protocol in 1.1.1 this is considered a bug and not a security issue in that version. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 21st January 2021 by D. Katz and Joel Luellwitz from Trustwave. The fix was developed by Matt Caswell. Integer overflow in CipherUpdate (CVE-2021-23840) ================================================= Severity: Low Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 13th December 2020 by Paul Kehrer. The fix was developed by Matt Caswell. Note ==== OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20210216.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAr8gYACgkQ2cTSbQ5g RJFzowf/UF+mnAAOuOEO+aNIsMSnuzeylkAtKXnSHEa1uKeLd1udlLls75WUCW0R d8PfDrAMuYn7XQdQ/NalQ52teES0+XNGG6+s8FukmAiaCYIzu4Ko0C0VJK0BuaJk fa5DCPec+XzudqqLAgxzfV+lRakCf/ARfBoT1/JRXHXv3VIUXFN/QEonjbpxmH3C czWqOiPyZ+gY7MKlGer8AohQtc+GjQRSJKpUzW76Itr0MlzUlitnLs4VK16Tu1pc b6sruEl4/ukAodvTUkVLaDDNqEgtYK676ABJ8h2L+Muy7s+ZY34sKSbhN76E4I1h YGqcOFFEerFiZivfyqdbrLNUxKLMkA== =NAqk -----END PGP SIGNATURE----- From Matthias.Buehlmann at mabulous.com Tue Feb 16 16:35:35 2021 From: Matthias.Buehlmann at mabulous.com (Matthias Buehlmann) Date: Tue, 16 Feb 2021 17:35:35 +0100 Subject: What does 'openssl ts -verify' verify exactly? In-Reply-To: <77cfba15-be19-463b-8875-00dd26ada934@redhat.com> References: <77cfba15-be19-463b-8875-00dd26ada934@redhat.com> Message-ID: On Tue, Feb 16, 2021 at 4:34 PM Hubert Kario wrote: > On Tuesday, 16 February 2021 15:54:24 CET, Matthias Buehlmann wrote: > > Hello Hubert (sorry, replied to your e-mail address directly before > instead > > of the mailing list), > > > > thank you for your reply, but I don't think you're correct that timestamp > > tokens expire together with the signing certificate! Timestamp tokens CAN > > stay valid beyond the validity of the signing certificate, otherwise > PAdES > > LTV (Long Term Validity) wouldn't make much sense. Check RFC3161 > > specification chapter 4.1: > > > > When a TSA shall not be used anymore, but the TSA private key has > > not been compromised, the authority's certificate SHALL be > > revoked. When the reasonCode extension relative to the revoked > > certificate from the TSA is present in the CRL entry extensions, > > it SHALL be set either to unspecified (0), affiliationChanged (3), > > superseded (4) or cessationOfOperation (5). In that case, at any > > future time, the tokens signed with the corresponding key will be > > considered as invalid, but tokens generated before the revocation > > time will remain valid. When the reasonCode extension relative to > > the revoked certificate from the TSA is not present in the CRL > > entry extensions, then all the tokens that have been signed with > > the corresponding key SHALL be considered as invalid. For that > > reason, it is recommended to use the reasonCode extension. > > not necessarily, it does not talk about the notAfter date at all, only > about > "not used anymore", that may (and actually should) happen at least a year > before > notAfter date > That's correct, the entire specification (unfortunately) doesn't explicitly mention notAfter/notBefore/expiration, but since this paragraph shows that while revocation invalidates a certificate this doesn't necessarily invalidate already issued token, this therefore means that one also can't assume that expiry of the certificate (which is another form of invalidation) would dictate invalidation of the already issued token. Cryptographically it makes sense that timestamps in issued token can be trusted so long as one can trust: 1. the self-signed RootCA 2. that the hashing algorithm used for the digest in the token is still cryptographically secure 3. that the key-length and algorithm of the signatures in the trust chain are still cryptographically secure 4. that none of the private keys in the trust chain have been compromised 5. that the issuing certificate was valid at the time of timestamping If these things can be trusted, then it's not possible that the token was forged. Point 1 is an a-priori choice Points 2 & 3 boil down to the mentioned cryptographic "lifetime" and depend on current policy at the time of evaluation. Point 4 is a crucial one. If I have a copy of currently valid CRLs for all certificates in the chain and none of them shows that a key was compromised, then I can trust in this point. My question is whether there is any way of also trusting that no keys have been leaked if one doesn't have CRLs that are valid at the time of validation (for example, if one would have an older CRL that is not valid anymore but which shows that the certificate has been revoked for one of the accepted reasons, can one then also safely assume that the key hasn't been leaked at a later date? Is there for example a way one can establish trust that a private key has been properly destroyed in such a revocation scenario?). For Point 5 one needs CRLs or OSCPs of the time of timestamping (or, as you point out correctly, maybe better of a day later - however AFAIK a rfc5280 CRL is not timestamped beyond the notBefore-notAfter validity period, so one couldn't say when these CRLs were obtained anyway other than by relying on the timestamp of the token that one wants to verify). Is it even possible to validate a token without having historic CRLs or OSCPs that were valid at the time of timestamping? (because any of the certificates in the chain may have been in "Hold" status (or can this be ignored since any "Hold" status that does not turn into a "Revoked" status can be ignored for token validity?) > > but the details I remember may be from Qualified Signature requirements, > not > the IETF standards > > I do know that the BSI has a different policy still, so you need to know > under > which policy you need to perform the verification > > > Chapter 4.3 DOES talk about key lifetime and renewing trust in issued > > tokens by restamping, however the term "lifetime" used here is in > relation > > to key-length (longer key-length = longer lifetime, finite key-length = > > finite lifetime), NOT validity period of TSA certificate: > > > > The TSA signing key MUST be of a sufficient length to allow for a > > sufficiently long lifetime. Even if this is done, the key will > > have a finite lifetime. Thus, any token signed by the TSA SHOULD > > be time-stamped again (if authentic copies of old CRLs are > > available) or notarized (if they aren't) at a later date to renew > > the trust that exists in the TSA's signature. time-stamp tokens > > could also be kept with an Evidence Recording Authority to > > maintain this trust. > > > > It doesn't make sense that a token could retain its validity beyond the > > validity of the TSA certificate in a revocation scenario (when key or CA > > hasn't been compromised) but not in an expiration scenario. > > All TSA certificates I encountered so far have very short lifetimes (1-3 > > years). If it was true that tokens would only remain valid within that > > period without being restamped, the whole point of PAdES LTV would be > moot. > > the whole problem is that if you trust the date in the timestamp as the > date the timestamp was created, attacker can compromise the TSA key years > after > it was last used and then create timestamps that look like they have been > created while the TSA key was still valid > Correct, that's the problem and that's why I guess the CRLs (historic and current) are crucial. If I have CRLs that are currently valid for all the certificates in the trust chain that show that none of the keys has been compromised (either due to the certificates not being revoked or the revocationCode being one of the accepted ones of chapter 4.1), then I should be able to consider the token being valid since it's not possible that it was forged. The question then is whether there's a way to show a token could not have been forged if no currently valid CRLs are available (maybe because they're not issued anymore). For example, if a historic CRL is available, which was valid after the timestamp has been issued but is however not valid anymore at the time of validation, but which shows that the certificate was revoked for one of the accepted revocation reasons, can the token then be considered valid. Are there any standardized policy definitions specific to RFC3161 (or RFC5816) validation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From guerinp at talasi.fr Tue Feb 16 18:39:14 2021 From: guerinp at talasi.fr (=?UTF-8?Q?Patrice_Gu=c3=a9rin?=) Date: Tue, 16 Feb 2021 19:39:14 +0100 Subject: Cheking public or private key Message-ID: Dear All, Is there a way to check if a EVP_PKEY is a public or private key ? In the case of use of EVP_Sign or EVP_DigestSign functions, an application leads to crash with SIGSEGV if an incorrect key is given when finalizing process. Thanks in advance for your answers. Kind regards, Patrice. From 1nagarjun1 at gmail.com Tue Feb 16 19:40:41 2021 From: 1nagarjun1 at gmail.com (Nagarjun J) Date: Wed, 17 Feb 2021 01:10:41 +0530 Subject: No subject Message-ID: Hi, How to verify if the application is using fips provider from openssl-3.0.0 ( similar to fips_mode() api in openssl-fips-2.0.16) and does fips provider do run time check and through error if application using non fips ciphers. Regards, Nagarjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Feb 16 19:49:07 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Feb 2021 17:49:07 -0200 Subject: What does 'openssl ts -verify' verify exactly? In-Reply-To: <77cfba15-be19-463b-8875-00dd26ada934@redhat.com> References: <77cfba15-be19-463b-8875-00dd26ada934@redhat.com> Message-ID: <3F566B8C-7467-4B1E-B471-1BCA8610E80A@dukhovni.org> > On Feb 16, 2021, at 1:34 PM, Hubert Kario wrote: > > the whole problem is that if you trust the date in the timestamp as the date the timestamp was created, attacker can compromise the TSA key years after > it was last used and then create timestamps that look like they have been > created while the TSA key was still valid Timestamps can only be deemed authentic if they are part of a Merkle chain that validates all past timestamps signed with a *currently* still trusted key. The trusted key can change from time to time, but the Merkle chain needs to be append-only. Once a given Merkle chain is abandoned, and no longer has an active signer attesting to the validity of long-ago events, at some point it becomes impossible to say anything meaningful about the integrity of past signatures. -- Viktor. From Matthias.Buehlmann at mabulous.com Tue Feb 16 22:07:25 2021 From: Matthias.Buehlmann at mabulous.com (Matthias Buehlmann) Date: Tue, 16 Feb 2021 23:07:25 +0100 Subject: What does 'openssl ts -verify' verify exactly? In-Reply-To: <3F566B8C-7467-4B1E-B471-1BCA8610E80A@dukhovni.org> References: <77cfba15-be19-463b-8875-00dd26ada934@redhat.com> <3F566B8C-7467-4B1E-B471-1BCA8610E80A@dukhovni.org> Message-ID: On Tue, Feb 16, 2021 at 8:56 PM Viktor Dukhovni wrote: > > On Feb 16, 2021, at 1:34 PM, Hubert Kario wrote: > > > > the whole problem is that if you trust the date in the timestamp as the > date the timestamp was created, attacker can compromise the TSA key years > after > > it was last used and then create timestamps that look like they have been > > created while the TSA key was still valid > > Timestamps can only be deemed authentic if they are part of a Merkle > chain that validates all past timestamps signed with a *currently* > still trusted key. The trusted key can change from time to time, > but the Merkle chain needs to be append-only. > > Once a given Merkle chain is abandoned, and no longer has an active > signer attesting to the validity of long-ago events, at some point > it becomes impossible to say anything meaningful about the integrity > of past signatures. While I do in fact use a Merkle Tree in my case as well as chained timestamps, I don't think the claim "Timestamps can only be deemed authentic if they are part of a Merkle chain that validates all past timestamps signed with a *currently* still trusted key" is correct, since the specification in no way talks about Merkle Trees and only indirectly of Merkle Chains (suggesting that existing timestamp tokens should be time-stamped again in the future, however, this is in respect to a finite-length encryption key having finite lifetime - but this can well mean 1000 years in the future). It's true though that if one has such a chain AND one can show that at the time a newer timestamp was added the existing keys were still trusted, the timestamps can be trusted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Feb 16 22:26:19 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Feb 2021 22:26:19 +0000 Subject: In-Reply-To: References: Message-ID: <697cec44-99f0-91af-aa5b-087d3ffa6c87@openssl.org> On 16/02/2021 19:40, Nagarjun J wrote: > How to verify if the application is using fips provider from > openssl-3.0.0 ( similar to fips_mode() api in openssl-fips-2.0.16) Using the FIPS provider in Openssl 3.0 works quite differently to the old FIPS module. There isn't a one-to-one correspondence to the old APIs. I suggest you make sure you read the 3.0 wiki page to get a good understand about how it works: https://wiki.openssl.org/index.php/OpenSSL_3.0 There are a number of ways to ensure that you are always using the FIPS provider (for example by ensuring that that is the only provider that is loaded). It's also possible to have multiple providers loaded but using properties to ensure that only FIPS algorithms are ever selected. If you use properties to control this then you can use EVP_default_properties_enable_fips() to set the default global properties to "fips=yes". You can then also use EVP_default_properties_is_fips_enabled() to check whether the default properties are set to "fips=yes". > and > does fips provider do run time check and through error if application > using non fips ciphers. When you attempt to use a cipher then libcrypto will attempt to find a suitable one from the available providers that have been loaded based on any property query string that is being used. As long as you configure things in the right way (as per the various options described in the wiki page above) then you will only have fips validated ciphers loaded and that match the property query. If you attempt to use some other non-validated cipher then libcrypto would throw and error because it is unable to find a matching cipher. Matt From kaushalshriyan at gmail.com Wed Feb 17 02:22:53 2021 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Wed, 17 Feb 2021 07:52:53 +0530 Subject: ./CA.pl -newreq specify servername In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 at 6:02 AM, Kaushal Shriyan wrote: > Hi, > > I am running CentOS Linux release 7.9.2009 (Core). > > #rpm -qa | grep openssl > openssl-devel-1.0.2k-21.el7_9.x86_64 > openssl-libs-1.0.2k-21.el7_9.x86_64 > openssl-1.0.2k-21.el7_9.x86_64 > openssl-perl-1.0.2k-21.el7_9.x86_64 > > cd /etc/pki/tls/misc > [root at basheerdevops misc]# ll > total 64 > -rwxr-xr-x. 1 root root 5178 Dec 17 02:53 CA > -rwxr-xr-x 1 root root 5691 Dec 17 02:53 CA.pl > -rwxr-xr-x. 1 root root 119 Dec 17 02:53 c_hash > -rwxr-xr-x. 1 root root 152 Dec 17 02:53 c_info > -rwxr-xr-x. 1 root root 112 Dec 17 02:53 c_issuer > -rwxr-xr-x. 1 root root 110 Dec 17 02:53 c_name > -rw-r--r-- 1 root root 4837 Feb 16 05:51 newcert.pem > -rw-r--r-- 1 root root 1834 Feb 16 05:49 newkey.pem > -rw-r--r-- 1 root root 1115 Feb 16 05:49 newreq.pem > -rwxr-xr-x 1 root root 6419 Dec 17 02:53 target > > #./CA.pl -newreq --> is there a way to specify server name? For example > gitlabinternal. By default, it saves in file *newcert.pem* > #./CA.pl -sign > > I ran the below command to copy > #cp newcert.pem gitlabinternal.pem > #openssl x509 -in gitlabinternal.pem -noout -text > > Is there a way to specify servername in ./CA.pl -newreq command ? Please > suggest further. Thanks in advance. > > Best Regards, > > Kaushal > Hi, I will appreciate if someone can pitch in for my earlier email post to this mailing list. Thanks in Advance. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1nagarjun1 at gmail.com Wed Feb 17 09:28:41 2021 From: 1nagarjun1 at gmail.com (Nagarjun J) Date: Wed, 17 Feb 2021 14:58:41 +0530 Subject: Openssl_3.0.0 stable release Message-ID: Hi, Any one have idea when openssl-3.0.0 stable version can be expected? -Nagarjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Feb 17 10:07:45 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 17 Feb 2021 10:07:45 +0000 Subject: Openssl_3.0.0 stable release In-Reply-To: References: Message-ID: On 17/02/2021 09:28, Nagarjun J wrote: > Any one have idea when openssl-3.0.0 stable version can be expected? We don't have a definitive date at the moment. IMO we are still some months away from beta1. Matt From 1nagarjun1 at gmail.com Wed Feb 17 16:26:26 2021 From: 1nagarjun1 at gmail.com (Nagarjun J) Date: Wed, 17 Feb 2021 21:56:26 +0530 Subject: No subject Message-ID: Hi, I am building Nginx application with openssl-3.0.0, i have added below code in main function of nginx application to load fips provider, OSSL_PROVIDER *fips; OSSL_PROVIDER *base; fips = OSSL_PROVIDER_load(NULL, "fips"); if (fips == NULL) { printf("Failed to load FIPS provider\n"); exit(EXIT_FAILURE); } base = OSSL_PROVIDER_load(NULL, "base"); if (base == NULL) { OSSL_PROVIDER_unload(fips); printf("Failed to load base provider\n"); exit(EXIT_FAILURE); } but when I start the application it's giving *Failed to load FIPS provider *error , with initial debugging I found SELF_TEST_post is failing in below code st->module_checksum_data in null and returning error. if (st == NULL || st->module_checksum_data == NULL) { ERR_raise(ERR_LIB_PROV, PROV_R_MISSING_CONFIG_DATA); goto end; } Anything I am missing here? Regards, Nagarjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelson at openssl.org Wed Feb 17 16:47:03 2021 From: nelson at openssl.org (Paul Nelson) Date: Wed, 17 Feb 2021 10:47:03 -0600 Subject: In-Reply-To: References: Message-ID: You may have not run the openssl fipsinstall command. You should be able to perform ?make install_fips? after you do a make install. Then check your openssl.conf file and make sure it has the proper fipsmodule.cnf filename and loads the providers you want. > On Feb 17, 2021, at 10:26 AM, Nagarjun J <1nagarjun1 at gmail.com> wrote: > > Hi, > > I am building Nginx application with openssl-3.0.0, i have added below code in main function of nginx application to load fips provider, > > OSSL_PROVIDER *fips; > OSSL_PROVIDER *base; > > fips = OSSL_PROVIDER_load(NULL, "fips"); > if (fips == NULL) { > printf("Failed to load FIPS provider\n"); > exit(EXIT_FAILURE); > } > base = OSSL_PROVIDER_load(NULL, "base"); > if (base == NULL) { > OSSL_PROVIDER_unload(fips); > printf("Failed to load base provider\n"); > exit(EXIT_FAILURE); > } > > but when I start the application it's giving Failed to load FIPS provider error , with initial debugging I found SELF_TEST_post is failing in below code st->module_checksum_data in null and returning error. > > if (st == NULL > || st->module_checksum_data == NULL) { > ERR_raise(ERR_LIB_PROV, PROV_R_MISSING_CONFIG_DATA); > goto end; > } > > Anything I am missing here? > > Regards, > Nagarjun > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zagadeesh at gmail.com Thu Feb 18 09:55:44 2021 From: zagadeesh at gmail.com (zagadeesh Teegala) Date: Thu, 18 Feb 2021 15:25:44 +0530 Subject: OCSP engine support Message-ID: OpenSSL as a ocsp responder can?t be configured with engine (HSM based keys)? -- Thanks Jagadeesh T, CISSP-ISSAP, ISSMP, CISM +91 984 985 7085 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Feb 18 15:37:49 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 18 Feb 2021 15:37:49 +0000 Subject: OpenSSL version 3.0.0-alpha12 published Message-ID: <20210218153749.GA15169@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 12 released ===================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 12 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha12.tar.gz Size: 14142492 SHA1 checksum: fbcb255c1bf11928f4bd52b8cf68ab8341238d4f SHA256 checksum: 8d78239be66af578b969441252e7c125aa134ef3b9bac6179d84275cfe01950c The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha12.tar.gz openssl sha256 openssl-3.0.0-alpha12.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAugwwACgkQ2cTSbQ5g RJHuyQgApX0LV7z8tmxqPNyMIfLMMnlFfV7m4YcblXN6YO+wDwFiX3KgnopGvfim 0B8pGPxkwJjPhLQxGyZ4fUkTMEJ3jtp+ncVf7+ccF7JfKkh1bjBmmSBZ0GhJPqhB HGxdb+cNe0rQFxXoWU5s8YmV4ImmPzUOhMKMP3b/lUJZpzlmriMw5QxbTc/dk96J 5wVf36sHbMPbAQlVrzRXLDWSacUXLVk4D4C9KJ1xt3Ri6RsWdlx6Z4N+dzhxOwP3 kyIzJAckQ8x3f8cAYu9CEgncLquUVO9vnC3CsbK6rfqNuGu6FzhDGYRzf5nn6NVd 4AAM/zKCkUlyufNVGQa7O96mkG6fsQ== =BcMo -----END PGP SIGNATURE----- From alon.barlev at gmail.com Fri Feb 19 07:45:31 2021 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 19 Feb 2021 09:45:31 +0200 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: Hello OpenSSL masters, Can someone please try to reproduce the below issue? Thanks, Alon On Sat, 13 Feb 2021 at 23:23 Alon Bar-Lev wrote: > Hello, > > I am trying to resign a CMS using the openssl tool. > > When I use RSA-PKCS1 everything is working fine. > > When I use RSA-PSS it seems like the asn1 is produced corrupted, I do not > see the signature in asn1dump. > > I prepared a demo[1] to help people reproduce the issue, tested with > openssl-1.1.1i. > > The script output pasted below shows that CMS resign without PSS works > correctly, while the same sequence with PSS produces a corrupted CMS file. > > What am I doing wrong? > > Regards, > Alon Bar-Lev > > [1] https://github.com/alonbl/openssl-cms-pss > > --- > > =============== > CMS without PSS > =============== > cms -sign 1.cms > cms -verify 1.cms > hello world > Verification successful > cms -resign 1.cms to 2.cms > cms -verify 2.cms > hello world > Verification successful > =============== > CMS with PSS > =============== > cms -sign 1.cms > cms -verify 1.cms > hello world > Verification successful > cms -resign 1.cms to 2.cms > cms -verify 2.cms > Error reading S/MIME message > 140438977062208:error:0D078079:asn1 encoding > routines:asn1_item_embed_d2i:field > missing:../crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR > 140438977062208:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:../crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, > Type=CMS_SignerInfo > 140438977062208:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:../crypto/asn1/tasn_dec.c:614:Field=signerInfos, Type=CMS_SignedData > 140438977062208:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:../crypto/asn1/tasn_dec.c:646: > 140438977062208:error:0D08403A:asn1 encoding > routines:asn1_template_ex_d2i:nested asn1 > error:../crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo > FATAL: verify 2.cms failed > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thulasi.goriparthi at gmail.com Fri Feb 19 17:49:42 2021 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Fri, 19 Feb 2021 23:19:42 +0530 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: Hi Alon, I am able to reproduce this issue with 1.1.1i echo "hello world" > msg /* pkcs1 */ openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms openssl cms -verify -in 1.cms -CAfile ca.pem openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms openssl cms -verify -in 2.cms -CAfile ca.pem /* pss */ openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms -keyopt rsa_padding_mode:pss openssl cms -verify -in 1.cms -CAfile ca.pem openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms -keyopt rsa_padding_mode:pss openssl cms -verify -in 2.cms -CAfile ca.pem Thanks, Thulasi. On Fri, 19 Feb 2021 at 13:16, Alon Bar-Lev wrote: > Hello OpenSSL masters, > > Can someone please try to reproduce the below issue? > > Thanks, > Alon > > On Sat, 13 Feb 2021 at 23:23 Alon Bar-Lev wrote: > >> Hello, >> >> I am trying to resign a CMS using the openssl tool. >> >> When I use RSA-PKCS1 everything is working fine. >> >> When I use RSA-PSS it seems like the asn1 is produced corrupted, I do not >> see the signature in asn1dump. >> >> I prepared a demo[1] to help people reproduce the issue, tested with >> openssl-1.1.1i. >> >> The script output pasted below shows that CMS resign without PSS works >> correctly, while the same sequence with PSS produces a corrupted CMS file. >> >> What am I doing wrong? >> >> Regards, >> Alon Bar-Lev >> >> [1] https://github.com/alonbl/openssl-cms-pss >> >> --- >> >> =============== >> CMS without PSS >> =============== >> cms -sign 1.cms >> cms -verify 1.cms >> hello world >> Verification successful >> cms -resign 1.cms to 2.cms >> cms -verify 2.cms >> hello world >> Verification successful >> =============== >> CMS with PSS >> =============== >> cms -sign 1.cms >> cms -verify 1.cms >> hello world >> Verification successful >> cms -resign 1.cms to 2.cms >> cms -verify 2.cms >> Error reading S/MIME message >> 140438977062208:error:0D078079:asn1 encoding >> routines:asn1_item_embed_d2i:field >> missing:../crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR >> 140438977062208:error:0D08303A:asn1 encoding >> routines:asn1_template_noexp_d2i:nested asn1 >> error:../crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, >> Type=CMS_SignerInfo >> 140438977062208:error:0D08303A:asn1 encoding >> routines:asn1_template_noexp_d2i:nested asn1 >> error:../crypto/asn1/tasn_dec.c:614:Field=signerInfos, Type=CMS_SignedData >> 140438977062208:error:0D08303A:asn1 encoding >> routines:asn1_template_noexp_d2i:nested asn1 >> error:../crypto/asn1/tasn_dec.c:646: >> 140438977062208:error:0D08403A:asn1 encoding >> routines:asn1_template_ex_d2i:nested asn1 >> error:../crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo >> FATAL: verify 2.cms failed >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelson at openssl.org Fri Feb 19 18:17:52 2021 From: nelson at openssl.org (Paul Nelson) Date: Fri, 19 Feb 2021 12:17:52 -0600 Subject: ./CA.pl -newreq specify servername In-Reply-To: References: Message-ID: <9FF19C2D-495A-41B3-982A-17601E8B8A72@openssl.org> For OpenSSL 1.0.2: Are you asking how to get a DNS Subject Alternative Name extension into the certificate? You would need to edit an openssl.cnf file and add the proper stuff to get this extension. Check the man page for x509v3_config. The item you want to put in the config file is subjectAltName=DNS:myserver.mydom.com Also see the man page for ca and config You may need to run the openssl ca command directly instead of using CA.pl so you can use the -extensions argument. > On Feb 16, 2021, at 8:22 PM, Kaushal Shriyan wrote: > > > > On Tue, 16 Feb 2021 at 6:02 AM, Kaushal Shriyan > wrote: > Hi, > > I am running CentOS Linux release 7.9.2009 (Core). > > #rpm -qa | grep openssl > openssl-devel-1.0.2k-21.el7_9.x86_64 > openssl-libs-1.0.2k-21.el7_9.x86_64 > openssl-1.0.2k-21.el7_9.x86_64 > openssl-perl-1.0.2k-21.el7_9.x86_64 > > cd /etc/pki/tls/misc > [root at basheerdevops misc]# ll > total 64 > -rwxr-xr-x. 1 root root 5178 Dec 17 02:53 CA > -rwxr-xr-x 1 root root 5691 Dec 17 02:53 CA.pl > -rwxr-xr-x. 1 root root 119 Dec 17 02:53 c_hash > -rwxr-xr-x. 1 root root 152 Dec 17 02:53 c_info > -rwxr-xr-x. 1 root root 112 Dec 17 02:53 c_issuer > -rwxr-xr-x. 1 root root 110 Dec 17 02:53 c_name > -rw-r--r-- 1 root root 4837 Feb 16 05:51 newcert.pem > -rw-r--r-- 1 root root 1834 Feb 16 05:49 newkey.pem > -rw-r--r-- 1 root root 1115 Feb 16 05:49 newreq.pem > -rwxr-xr-x 1 root root 6419 Dec 17 02:53 target > > #./CA.pl -newreq --> is there a way to specify server name? For example gitlabinternal. By default, it saves in file newcert.pem > #./CA.pl -sign > > I ran the below command to copy > #cp newcert.pem gitlabinternal.pem > #openssl x509 -in gitlabinternal.pem -noout -text > > Is there a way to specify servername in ./CA.pl -newreq command ? Please suggest further. Thanks in advance. > > Best Regards, > > Kaushal > > Hi, > > I will appreciate if someone can pitch in for my earlier email post to this mailing list. > > Thanks in Advance. > > Best Regards, > > Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Feb 19 18:32:10 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Feb 2021 13:32:10 -0500 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: On Fri, Feb 19, 2021 at 11:19:42PM +0530, Thulasi Goriparthi wrote: > I am able to reproduce this issue with 1.1.1i OpenSSL 1.1.1j has been released. Do you still see the problem with 1.1.1j? -- Viktor. From thulasi.goriparthi at gmail.com Fri Feb 19 19:04:06 2021 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Sat, 20 Feb 2021 00:34:06 +0530 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: I am able to reproduce this issue with 1.1.1j too. openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Fri Feb 19 18:56:06 2021 UTC platform: darwin64-x86_64-cc options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) compiler: cc -fPIC -arch x86_64 -g -Wall -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG OPENSSLDIR: "/usr/local/ssl" ENGINESDIR: "/usr/local/lib/engines-1.1" Seeding source: os-specific openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms -keyopt rsa_padding_mode:pss openssl cms -verify -in 1.cms -CAfile ca.pem Content-Type: text/plain hello world Verification successful openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms -keyopt rsa_padding_mode:pss openssl cms -verify -in 2.cms -CAfile ca.pem Error reading S/MIME message 4757167552:error:0D078079:asn1 encoding routines:asn1_item_embed_d2i:field missing:crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, Type=CMS_SignerInfo 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:615:Field=signerInfos, Type=CMS_SignedData 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646: 4757167552:error:0D08403A:asn1 encoding routines:asn1_template_ex_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo 4757167552:error:0D0D106E:asn1 encoding routines:b64_read_asn1:decode error:crypto/asn1/asn_mime.c:143: 4757167552:error:0D0D40CC:asn1 encoding routines:SMIME_read_ASN1:asn1 sig parse error:crypto/asn1/asn_mime.c:451: Thanks, Thulasi. On Sat, 20 Feb 2021 at 00:09, Viktor Dukhovni wrote: > On Fri, Feb 19, 2021 at 11:19:42PM +0530, Thulasi Goriparthi wrote: > > > I am able to reproduce this issue with 1.1.1i > > OpenSSL 1.1.1j has been released. Do you still see the problem with > 1.1.1j? > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alon.barlev at gmail.com Fri Feb 19 19:10:02 2021 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 19 Feb 2021 21:10:02 +0200 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: Thanks! Was about to write... I tested both 1.1 and master branches and result is the same. On Fri, 19 Feb 2021 at 21:04 Thulasi Goriparthi < thulasi.goriparthi at gmail.com> wrote: > I am able to reproduce this issue with 1.1.1j too. > > openssl version -a > > OpenSSL 1.1.1j 16 Feb 2021 > > built on: Fri Feb 19 18:56:06 2021 UTC > > platform: darwin64-x86_64-cc > > options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) > > compiler: cc -fPIC -arch x86_64 -g -Wall -DL_ENDIAN -DOPENSSL_PIC > -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM > -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT > -DNDEBUG > > OPENSSLDIR: "/usr/local/ssl" > > ENGINESDIR: "/usr/local/lib/engines-1.1" > > Seeding source: os-specific > > openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms -keyopt > rsa_padding_mode:pss > > openssl cms -verify -in 1.cms -CAfile ca.pem > > Content-Type: text/plain > > > hello world > > Verification successful > > openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms -keyopt > rsa_padding_mode:pss > > openssl cms -verify -in 2.cms -CAfile ca.pem > > Error reading S/MIME message > > 4757167552:error:0D078079:asn1 encoding routines:asn1_item_embed_d2i:field > missing:crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR > > 4757167552:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, > Type=CMS_SignerInfo > > 4757167552:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:crypto/asn1/tasn_dec.c:615:Field=signerInfos, Type=CMS_SignedData > > 4757167552:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:crypto/asn1/tasn_dec.c:646: > > 4757167552:error:0D08403A:asn1 encoding > routines:asn1_template_ex_d2i:nested asn1 > error:crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo > > 4757167552:error:0D0D106E:asn1 encoding routines:b64_read_asn1:decode > error:crypto/asn1/asn_mime.c:143: > > 4757167552:error:0D0D40CC:asn1 encoding routines:SMIME_read_ASN1:asn1 sig > parse error:crypto/asn1/asn_mime.c:451: > > > Thanks, > > Thulasi. > > On Sat, 20 Feb 2021 at 00:09, Viktor Dukhovni > wrote: > >> On Fri, Feb 19, 2021 at 11:19:42PM +0530, Thulasi Goriparthi wrote: >> >> > I am able to reproduce this issue with 1.1.1i >> >> OpenSSL 1.1.1j has been released. Do you still see the problem with >> 1.1.1j? >> >> -- >> Viktor. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thulasi.goriparthi at gmail.com Fri Feb 19 20:02:51 2021 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Sat, 20 Feb 2021 01:32:51 +0530 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: With PSS, for the first signature, PSS alg ID and params are encoded correctly, but not for the second signature(resign). 2542:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities 2553:d=7 hl=2 l= 108 cons: SET 2555:d=8 hl=2 l= 106 cons: SEQUENCE 2557:d=9 hl=2 l= 11 cons: SEQUENCE 2559:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 2570:d=9 hl=2 l= 11 cons: SEQUENCE 2572:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 2583:d=9 hl=2 l= 11 cons: SEQUENCE 2585:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 2596:d=9 hl=2 l= 10 cons: SEQUENCE 2598:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 2608:d=9 hl=2 l= 14 cons: SEQUENCE 2610:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 2620:d=10 hl=2 l= 2 prim: INTEGER :80 2624:d=9 hl=2 l= 13 cons: SEQUENCE 2626:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 2636:d=10 hl=2 l= 1 prim: INTEGER :40 2639:d=9 hl=2 l= 7 cons: SEQUENCE 2641:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 2648:d=9 hl=2 l= 13 cons: SEQUENCE 2650:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 2660:d=10 hl=2 l= 1 prim: INTEGER :28 2663:d=5 hl=2 l= 0 cons: SEQUENCE 2665:d=5 hl=2 l= 0 prim: OCTET STRING 2667:d=4 hl=4 l= 723 cons: SEQUENCE 2671:d=5 hl=2 l= 1 prim: INTEGER :01 2674:d=5 hl=3 l= 149 cons: SEQUENCE 2677:d=6 hl=3 l= 143 cons: SEQUENCE 2680:d=7 hl=2 l= 11 cons: SET 2682:d=8 hl=2 l= 9 cons: SEQUENCE 2684:d=9 hl=2 l= 3 prim: OBJECT :countryName 2689:d=9 hl=2 l= 2 prim: PRINTABLESTRING :IN 2693:d=7 hl=2 l= 11 cons: SET ==multiple lines truncated== 2949:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities 2960:d=7 hl=2 l= 108 cons: SET 2962:d=8 hl=2 l= 106 cons: SEQUENCE 2964:d=9 hl=2 l= 11 cons: SEQUENCE 2966:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 2977:d=9 hl=2 l= 11 cons: SEQUENCE 2979:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 2990:d=9 hl=2 l= 11 cons: SEQUENCE 2992:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 3003:d=9 hl=2 l= 10 cons: SEQUENCE 3005:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 3015:d=9 hl=2 l= 14 cons: SEQUENCE 3017:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3027:d=10 hl=2 l= 2 prim: INTEGER :80 3031:d=9 hl=2 l= 13 cons: SEQUENCE 3033:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3043:d=10 hl=2 l= 1 prim: INTEGER :40 3046:d=9 hl=2 l= 7 cons: SEQUENCE 3048:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 3055:d=9 hl=2 l= 13 cons: SEQUENCE 3057:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3067:d=10 hl=2 l= 1 prim: INTEGER :28 3070:d=5 hl=2 l= 62 cons: SEQUENCE 3072:d=6 hl=2 l= 9 prim: OBJECT :rsassaPss 3083:d=6 hl=2 l= 49 cons: SEQUENCE 3085:d=7 hl=2 l= 13 cons: cont [ 0 ] 3087:d=8 hl=2 l= 11 cons: SEQUENCE 3089:d=9 hl=2 l= 9 prim: OBJECT :sha256 3100:d=7 hl=2 l= 26 cons: cont [ 1 ] 3102:d=8 hl=2 l= 24 cons: SEQUENCE 3104:d=9 hl=2 l= 9 prim: OBJECT :mgf1 3115:d=9 hl=2 l= 11 cons: SEQUENCE 3117:d=10 hl=2 l= 9 prim: OBJECT :sha256 3128:d=7 hl=2 l= 4 cons: cont [ 2 ] 3130:d=8 hl=2 l= 2 prim: INTEGER :DE 3134:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:66C7A406905E0BEF3BE8A55B8BA05915020B6960BDE4700C3C3FB2F115FE5BA60B453EFF39BA37E4D16CA3A86582B3057D05875766BE99C51BC5BEC9CD1AAE3BEC34943160BB06784209F1A3773E07A101BA3E2231FDF85FAB91872A081E37410905A09DAF530600BF9099B054B1DF869826E864A95F5D55DAE84A0CEC43E52F6D13574E1EF66A4E3A65883788E265D6C174211ADBCFEA96A9DD186887BFE040D6D0B59547D8763157D322F0307D7AF31 23B0ECFB11E1E7EA228861F4363DBA8D478A7E44F1DEB77A3904FBD90CAA41E291A2E094ABCBD5134146FB1C0F42BC8D7B4829DEFEE7BACDFC024FB8B9FAF16F225EB3C96D866C535B2A06E83DCF007 Thanks, Thulasi. On Sat, 20 Feb 2021 at 00:40, Alon Bar-Lev wrote: > Thanks! > Was about to write... I tested both 1.1 and master branches and result is > the same. > > > On Fri, 19 Feb 2021 at 21:04 Thulasi Goriparthi < > thulasi.goriparthi at gmail.com> wrote: > >> I am able to reproduce this issue with 1.1.1j too. >> >> openssl version -a >> >> OpenSSL 1.1.1j 16 Feb 2021 >> >> built on: Fri Feb 19 18:56:06 2021 UTC >> >> platform: darwin64-x86_64-cc >> >> options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) >> >> compiler: cc -fPIC -arch x86_64 -g -Wall -DL_ENDIAN -DOPENSSL_PIC >> -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT >> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM >> -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM >> -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT >> -DNDEBUG >> >> OPENSSLDIR: "/usr/local/ssl" >> >> ENGINESDIR: "/usr/local/lib/engines-1.1" >> >> Seeding source: os-specific >> >> openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms -keyopt >> rsa_padding_mode:pss >> >> openssl cms -verify -in 1.cms -CAfile ca.pem >> >> Content-Type: text/plain >> >> >> hello world >> >> Verification successful >> >> openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms -keyopt >> rsa_padding_mode:pss >> >> openssl cms -verify -in 2.cms -CAfile ca.pem >> >> Error reading S/MIME message >> >> 4757167552:error:0D078079:asn1 encoding >> routines:asn1_item_embed_d2i:field >> missing:crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR >> >> 4757167552:error:0D08303A:asn1 encoding >> routines:asn1_template_noexp_d2i:nested asn1 >> error:crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, >> Type=CMS_SignerInfo >> >> 4757167552:error:0D08303A:asn1 encoding >> routines:asn1_template_noexp_d2i:nested asn1 >> error:crypto/asn1/tasn_dec.c:615:Field=signerInfos, Type=CMS_SignedData >> >> 4757167552:error:0D08303A:asn1 encoding >> routines:asn1_template_noexp_d2i:nested asn1 >> error:crypto/asn1/tasn_dec.c:646: >> >> 4757167552:error:0D08403A:asn1 encoding >> routines:asn1_template_ex_d2i:nested asn1 >> error:crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo >> >> 4757167552:error:0D0D106E:asn1 encoding routines:b64_read_asn1:decode >> error:crypto/asn1/asn_mime.c:143: >> >> 4757167552:error:0D0D40CC:asn1 encoding routines:SMIME_read_ASN1:asn1 sig >> parse error:crypto/asn1/asn_mime.c:451: >> >> >> Thanks, >> >> Thulasi. >> >> On Sat, 20 Feb 2021 at 00:09, Viktor Dukhovni >> wrote: >> >>> On Fri, Feb 19, 2021 at 11:19:42PM +0530, Thulasi Goriparthi wrote: >>> >>> > I am able to reproduce this issue with 1.1.1i >>> >>> OpenSSL 1.1.1j has been released. Do you still see the problem with >>> 1.1.1j? >>> >>> -- >>> Viktor. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alon.barlev at gmail.com Fri Feb 19 20:06:59 2021 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 19 Feb 2021 22:06:59 +0200 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: Thanks. I managed to narrow this, it is not related to pss also if I pass pkcs1 I can reproduce. It has something to do with CMS_KEY_PARAM flag and add signer. On Fri, 19 Feb 2021 at 22:03 Thulasi Goriparthi < thulasi.goriparthi at gmail.com> wrote: > With PSS, for the first signature, PSS alg ID and params are encoded > correctly, but not for the second signature(resign). > > 2542:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities > > 2553:d=7 hl=2 l= 108 cons: SET > > 2555:d=8 hl=2 l= 106 cons: SEQUENCE > > 2557:d=9 hl=2 l= 11 cons: SEQUENCE > > 2559:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc > > 2570:d=9 hl=2 l= 11 cons: SEQUENCE > > 2572:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc > > 2583:d=9 hl=2 l= 11 cons: SEQUENCE > > 2585:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc > > 2596:d=9 hl=2 l= 10 cons: SEQUENCE > > 2598:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc > > 2608:d=9 hl=2 l= 14 cons: SEQUENCE > > 2610:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > > 2620:d=10 hl=2 l= 2 prim: INTEGER :80 > > 2624:d=9 hl=2 l= 13 cons: SEQUENCE > > 2626:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > > 2636:d=10 hl=2 l= 1 prim: INTEGER :40 > > 2639:d=9 hl=2 l= 7 cons: SEQUENCE > > 2641:d=10 hl=2 l= 5 prim: OBJECT :des-cbc > > 2648:d=9 hl=2 l= 13 cons: SEQUENCE > > 2650:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > > 2660:d=10 hl=2 l= 1 prim: INTEGER :28 > > 2663:d=5 hl=2 l= 0 cons: SEQUENCE > > 2665:d=5 hl=2 l= 0 prim: OCTET STRING > > 2667:d=4 hl=4 l= 723 cons: SEQUENCE > > 2671:d=5 hl=2 l= 1 prim: INTEGER :01 > > 2674:d=5 hl=3 l= 149 cons: SEQUENCE > > 2677:d=6 hl=3 l= 143 cons: SEQUENCE > > 2680:d=7 hl=2 l= 11 cons: SET > > 2682:d=8 hl=2 l= 9 cons: SEQUENCE > > 2684:d=9 hl=2 l= 3 prim: OBJECT :countryName > > 2689:d=9 hl=2 l= 2 prim: PRINTABLESTRING :IN > > 2693:d=7 hl=2 l= 11 cons: SET > ==multiple lines truncated== > > 2949:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities > > 2960:d=7 hl=2 l= 108 cons: SET > > 2962:d=8 hl=2 l= 106 cons: SEQUENCE > > 2964:d=9 hl=2 l= 11 cons: SEQUENCE > > 2966:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc > > 2977:d=9 hl=2 l= 11 cons: SEQUENCE > > 2979:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc > > 2990:d=9 hl=2 l= 11 cons: SEQUENCE > > 2992:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc > > 3003:d=9 hl=2 l= 10 cons: SEQUENCE > > 3005:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc > > 3015:d=9 hl=2 l= 14 cons: SEQUENCE > > 3017:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > > 3027:d=10 hl=2 l= 2 prim: INTEGER :80 > > 3031:d=9 hl=2 l= 13 cons: SEQUENCE > > 3033:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > > 3043:d=10 hl=2 l= 1 prim: INTEGER :40 > > 3046:d=9 hl=2 l= 7 cons: SEQUENCE > > 3048:d=10 hl=2 l= 5 prim: OBJECT :des-cbc > > 3055:d=9 hl=2 l= 13 cons: SEQUENCE > > 3057:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > > 3067:d=10 hl=2 l= 1 prim: INTEGER :28 > > 3070:d=5 hl=2 l= 62 cons: SEQUENCE > > 3072:d=6 hl=2 l= 9 prim: OBJECT :rsassaPss > > 3083:d=6 hl=2 l= 49 cons: SEQUENCE > > 3085:d=7 hl=2 l= 13 cons: cont [ 0 ] > > 3087:d=8 hl=2 l= 11 cons: SEQUENCE > > 3089:d=9 hl=2 l= 9 prim: OBJECT :sha256 > > 3100:d=7 hl=2 l= 26 cons: cont [ 1 ] > > 3102:d=8 hl=2 l= 24 cons: SEQUENCE > > 3104:d=9 hl=2 l= 9 prim: OBJECT :mgf1 > > 3115:d=9 hl=2 l= 11 cons: SEQUENCE > > 3117:d=10 hl=2 l= 9 prim: OBJECT :sha256 > > 3128:d=7 hl=2 l= 4 cons: cont [ 2 ] > > 3130:d=8 hl=2 l= 2 prim: INTEGER :DE > > 3134:d=5 hl=4 l= 256 prim: OCTET STRING [HEX > DUMP]:66C7A406905E0BEF3BE8A55B8BA05915020B6960BDE4700C3C3FB2F115FE5BA60B453EFF39BA37E4D16CA3A86582B3057D05875766BE99C51BC5BEC9CD1AAE3BEC34943160BB06784209F1A3773E07A101BA3E2231FDF85FAB91872A081E37410905A09DAF530600BF9099B054B1DF869826E864A95F5D55DAE84A0CEC43E52F6D13574E1EF66A4E3A65883788E265D6C174211ADBCFEA96A9DD186887BFE040D6D0B59547D8763157D322F0307D7AF31 > 23B0ECFB11E1E7EA228861F4363DBA8D478A7E44F1DEB77A3904FBD90CAA41E291A2E094ABCBD5134146FB1C0F42BC8D7B4829DEFEE7BACDFC024FB8B9FAF16F225EB3C96D866C535B2A06E83DCF007 > > > Thanks, > > Thulasi. > > > On Sat, 20 Feb 2021 at 00:40, Alon Bar-Lev wrote: > >> Thanks! >> Was about to write... I tested both 1.1 and master branches and result is >> the same. >> >> >> On Fri, 19 Feb 2021 at 21:04 Thulasi Goriparthi < >> thulasi.goriparthi at gmail.com> wrote: >> >>> I am able to reproduce this issue with 1.1.1j too. >>> >>> openssl version -a >>> >>> OpenSSL 1.1.1j 16 Feb 2021 >>> >>> built on: Fri Feb 19 18:56:06 2021 UTC >>> >>> platform: darwin64-x86_64-cc >>> >>> options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) >>> >>> compiler: cc -fPIC -arch x86_64 -g -Wall -DL_ENDIAN -DOPENSSL_PIC >>> -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT >>> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM >>> -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM >>> -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT >>> -DNDEBUG >>> >>> OPENSSLDIR: "/usr/local/ssl" >>> >>> ENGINESDIR: "/usr/local/lib/engines-1.1" >>> >>> Seeding source: os-specific >>> >>> openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms -keyopt >>> rsa_padding_mode:pss >>> >>> openssl cms -verify -in 1.cms -CAfile ca.pem >>> >>> Content-Type: text/plain >>> >>> >>> hello world >>> >>> Verification successful >>> >>> openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms -keyopt >>> rsa_padding_mode:pss >>> >>> openssl cms -verify -in 2.cms -CAfile ca.pem >>> >>> Error reading S/MIME message >>> >>> 4757167552:error:0D078079:asn1 encoding >>> routines:asn1_item_embed_d2i:field >>> missing:crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR >>> >>> 4757167552:error:0D08303A:asn1 encoding >>> routines:asn1_template_noexp_d2i:nested asn1 >>> error:crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, >>> Type=CMS_SignerInfo >>> >>> 4757167552:error:0D08303A:asn1 encoding >>> routines:asn1_template_noexp_d2i:nested asn1 >>> error:crypto/asn1/tasn_dec.c:615:Field=signerInfos, Type=CMS_SignedData >>> >>> 4757167552:error:0D08303A:asn1 encoding >>> routines:asn1_template_noexp_d2i:nested asn1 >>> error:crypto/asn1/tasn_dec.c:646: >>> >>> 4757167552:error:0D08403A:asn1 encoding >>> routines:asn1_template_ex_d2i:nested asn1 >>> error:crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo >>> >>> 4757167552:error:0D0D106E:asn1 encoding routines:b64_read_asn1:decode >>> error:crypto/asn1/asn_mime.c:143: >>> >>> 4757167552:error:0D0D40CC:asn1 encoding routines:SMIME_read_ASN1:asn1 >>> sig parse error:crypto/asn1/asn_mime.c:451: >>> >>> >>> Thanks, >>> >>> Thulasi. >>> >>> On Sat, 20 Feb 2021 at 00:09, Viktor Dukhovni < >>> openssl-users at dukhovni.org> wrote: >>> >>>> On Fri, Feb 19, 2021 at 11:19:42PM +0530, Thulasi Goriparthi wrote: >>>> >>>> > I am able to reproduce this issue with 1.1.1i >>>> >>>> OpenSSL 1.1.1j has been released. Do you still see the problem with >>>> 1.1.1j? >>>> >>>> -- >>>> Viktor. >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alon.barlev at gmail.com Fri Feb 19 20:44:07 2021 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 19 Feb 2021 22:44:07 +0200 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: Hi, I am trying to analyze openssl sources, and it looks like the resign is implemented in an naive path that does not handle all cases. In other words, the CMS resign is not working in any case other than the default execution path. For example the -noattr is also not working. I updated my reproduction project[1] to show all cases of resign that do not work CMS_NO_ATTR, CMS_KEY_PARAM. I believe the root cause is that when resign is executed the CMS_final() is not called and instead the i2d_CMS_bio() is called, while its logic is incomplete. I hope this will ring a bell to people who are maintaining the crypto/cms/* implementation. Tested [fails] with: OpenSSL_1_1_1-stable master Regards, Alon [1] https://github.com/alonbl/openssl-cms-pss On Fri, Feb 19, 2021 at 10:06 PM Alon Bar-Lev wrote: > > Thanks. > I managed to narrow this, it is not related to pss also if I pass pkcs1 I can reproduce. It has something to do with CMS_KEY_PARAM flag and add signer. > > On Fri, 19 Feb 2021 at 22:03 Thulasi Goriparthi wrote: >> >> With PSS, for the first signature, PSS alg ID and params are encoded correctly, but not for the second signature(resign). >> >> 2542:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities >> >> 2553:d=7 hl=2 l= 108 cons: SET >> >> 2555:d=8 hl=2 l= 106 cons: SEQUENCE >> >> 2557:d=9 hl=2 l= 11 cons: SEQUENCE >> >> 2559:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc >> >> 2570:d=9 hl=2 l= 11 cons: SEQUENCE >> >> 2572:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc >> >> 2583:d=9 hl=2 l= 11 cons: SEQUENCE >> >> 2585:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc >> >> 2596:d=9 hl=2 l= 10 cons: SEQUENCE >> >> 2598:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc >> >> 2608:d=9 hl=2 l= 14 cons: SEQUENCE >> >> 2610:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> 2620:d=10 hl=2 l= 2 prim: INTEGER :80 >> >> 2624:d=9 hl=2 l= 13 cons: SEQUENCE >> >> 2626:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> 2636:d=10 hl=2 l= 1 prim: INTEGER :40 >> >> 2639:d=9 hl=2 l= 7 cons: SEQUENCE >> >> 2641:d=10 hl=2 l= 5 prim: OBJECT :des-cbc >> >> 2648:d=9 hl=2 l= 13 cons: SEQUENCE >> >> 2650:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> 2660:d=10 hl=2 l= 1 prim: INTEGER :28 >> >> 2663:d=5 hl=2 l= 0 cons: SEQUENCE >> >> 2665:d=5 hl=2 l= 0 prim: OCTET STRING >> >> 2667:d=4 hl=4 l= 723 cons: SEQUENCE >> >> 2671:d=5 hl=2 l= 1 prim: INTEGER :01 >> >> 2674:d=5 hl=3 l= 149 cons: SEQUENCE >> >> 2677:d=6 hl=3 l= 143 cons: SEQUENCE >> >> 2680:d=7 hl=2 l= 11 cons: SET >> >> 2682:d=8 hl=2 l= 9 cons: SEQUENCE >> >> 2684:d=9 hl=2 l= 3 prim: OBJECT :countryName >> >> 2689:d=9 hl=2 l= 2 prim: PRINTABLESTRING :IN >> >> 2693:d=7 hl=2 l= 11 cons: SET >> >> ==multiple lines truncated== >> >> 2949:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities >> >> 2960:d=7 hl=2 l= 108 cons: SET >> >> 2962:d=8 hl=2 l= 106 cons: SEQUENCE >> >> 2964:d=9 hl=2 l= 11 cons: SEQUENCE >> >> 2966:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc >> >> 2977:d=9 hl=2 l= 11 cons: SEQUENCE >> >> 2979:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc >> >> 2990:d=9 hl=2 l= 11 cons: SEQUENCE >> >> 2992:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc >> >> 3003:d=9 hl=2 l= 10 cons: SEQUENCE >> >> 3005:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc >> >> 3015:d=9 hl=2 l= 14 cons: SEQUENCE >> >> 3017:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> 3027:d=10 hl=2 l= 2 prim: INTEGER :80 >> >> 3031:d=9 hl=2 l= 13 cons: SEQUENCE >> >> 3033:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> 3043:d=10 hl=2 l= 1 prim: INTEGER :40 >> >> 3046:d=9 hl=2 l= 7 cons: SEQUENCE >> >> 3048:d=10 hl=2 l= 5 prim: OBJECT :des-cbc >> >> 3055:d=9 hl=2 l= 13 cons: SEQUENCE >> >> 3057:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> 3067:d=10 hl=2 l= 1 prim: INTEGER :28 >> >> 3070:d=5 hl=2 l= 62 cons: SEQUENCE >> >> 3072:d=6 hl=2 l= 9 prim: OBJECT :rsassaPss >> >> 3083:d=6 hl=2 l= 49 cons: SEQUENCE >> >> 3085:d=7 hl=2 l= 13 cons: cont [ 0 ] >> >> 3087:d=8 hl=2 l= 11 cons: SEQUENCE >> >> 3089:d=9 hl=2 l= 9 prim: OBJECT :sha256 >> >> 3100:d=7 hl=2 l= 26 cons: cont [ 1 ] >> >> 3102:d=8 hl=2 l= 24 cons: SEQUENCE >> >> 3104:d=9 hl=2 l= 9 prim: OBJECT :mgf1 >> >> 3115:d=9 hl=2 l= 11 cons: SEQUENCE >> >> 3117:d=10 hl=2 l= 9 prim: OBJECT :sha256 >> >> 3128:d=7 hl=2 l= 4 cons: cont [ 2 ] >> >> 3130:d=8 hl=2 l= 2 prim: INTEGER :DE >> >> 3134:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:66C7A406905E0BEF3BE8A55B8BA05915020B6960BDE4700C3C3FB2F115FE5BA60B453EFF39BA37E4D16CA3A86582B3057D05875766BE99C51BC5BEC9CD1AAE3BEC34943160BB06784209F1A3773E07A101BA3E2231FDF85FAB91872A081E37410905A09DAF530600BF9099B054B1DF869826E864A95F5D55DAE84A0CEC43E52F6D13574E1EF66A4E3A65883788E265D6C174211ADBCFEA96A9DD186887BFE040D6D0B59547D8763157D322F0307D7AF3123B0ECFB11E1E7EA228861F4363DBA8D478A7E44F1DEB77A3904FBD90CAA41E291A2E094ABCBD5134146FB1C0F42BC8D7B4829DEFEE7BACDFC024FB8B9FAF16F225EB3C96D866C535B2A06E83DCF007 >> >> >> Thanks, >> >> Thulasi. >> >> >> >> On Sat, 20 Feb 2021 at 00:40, Alon Bar-Lev wrote: >>> >>> Thanks! >>> Was about to write... I tested both 1.1 and master branches and result is the same. >>> >>> >>> On Fri, 19 Feb 2021 at 21:04 Thulasi Goriparthi wrote: >>>> >>>> I am able to reproduce this issue with 1.1.1j too. >>>> >>>> openssl version -a >>>> >>>> OpenSSL 1.1.1j 16 Feb 2021 >>>> >>>> built on: Fri Feb 19 18:56:06 2021 UTC >>>> >>>> platform: darwin64-x86_64-cc >>>> >>>> options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) >>>> >>>> compiler: cc -fPIC -arch x86_64 -g -Wall -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG >>>> >>>> OPENSSLDIR: "/usr/local/ssl" >>>> >>>> ENGINESDIR: "/usr/local/lib/engines-1.1" >>>> >>>> Seeding source: os-specific >>>> >>>> >>>> openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms -keyopt rsa_padding_mode:pss >>>> >>>> openssl cms -verify -in 1.cms -CAfile ca.pem >>>> >>>> Content-Type: text/plain >>>> >>>> >>>> hello world >>>> >>>> Verification successful >>>> >>>> openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms -keyopt rsa_padding_mode:pss >>>> >>>> openssl cms -verify -in 2.cms -CAfile ca.pem >>>> >>>> Error reading S/MIME message >>>> >>>> 4757167552:error:0D078079:asn1 encoding routines:asn1_item_embed_d2i:field missing:crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR >>>> >>>> 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, Type=CMS_SignerInfo >>>> >>>> 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:615:Field=signerInfos, Type=CMS_SignedData >>>> >>>> 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646: >>>> >>>> 4757167552:error:0D08403A:asn1 encoding routines:asn1_template_ex_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo >>>> >>>> 4757167552:error:0D0D106E:asn1 encoding routines:b64_read_asn1:decode error:crypto/asn1/asn_mime.c:143: >>>> >>>> 4757167552:error:0D0D40CC:asn1 encoding routines:SMIME_read_ASN1:asn1 sig parse error:crypto/asn1/asn_mime.c:451: >>>> >>>> >>>> Thanks, >>>> >>>> Thulasi. >>>> >>>> >>>> On Sat, 20 Feb 2021 at 00:09, Viktor Dukhovni wrote: >>>>> >>>>> On Fri, Feb 19, 2021 at 11:19:42PM +0530, Thulasi Goriparthi wrote: >>>>> >>>>> > I am able to reproduce this issue with 1.1.1i >>>>> >>>>> OpenSSL 1.1.1j has been released. Do you still see the problem with >>>>> 1.1.1j? >>>>> >>>>> -- >>>>> Viktor. From beldmit at gmail.com Fri Feb 19 21:09:06 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 19 Feb 2021 22:09:06 +0100 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: Would you mind to raise the issue on GitHub with the reproduction? On Fri, 19 Feb 2021, 21:44 Alon Bar-Lev, wrote: > Hi, > > I am trying to analyze openssl sources, and it looks like the resign > is implemented in an naive path that does not handle all cases. > > In other words, the CMS resign is not working in any case other than > the default execution path. > > For example the -noattr is also not working. > > I updated my reproduction project[1] to show all cases of resign that > do not work CMS_NO_ATTR, CMS_KEY_PARAM. > > I believe the root cause is that when resign is executed the > CMS_final() is not called and instead the i2d_CMS_bio() is called, > while its logic is incomplete. > > I hope this will ring a bell to people who are maintaining the > crypto/cms/* implementation. > > Tested [fails] with: > OpenSSL_1_1_1-stable > master > > Regards, > Alon > > [1] https://github.com/alonbl/openssl-cms-pss > > On Fri, Feb 19, 2021 at 10:06 PM Alon Bar-Lev > wrote: > > > > Thanks. > > I managed to narrow this, it is not related to pss also if I pass pkcs1 > I can reproduce. It has something to do with CMS_KEY_PARAM flag and add > signer. > > > > On Fri, 19 Feb 2021 at 22:03 Thulasi Goriparthi < > thulasi.goriparthi at gmail.com> wrote: > >> > >> With PSS, for the first signature, PSS alg ID and params are encoded > correctly, but not for the second signature(resign). > >> > >> 2542:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities > >> > >> 2553:d=7 hl=2 l= 108 cons: SET > >> > >> 2555:d=8 hl=2 l= 106 cons: SEQUENCE > >> > >> 2557:d=9 hl=2 l= 11 cons: SEQUENCE > >> > >> 2559:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc > >> > >> 2570:d=9 hl=2 l= 11 cons: SEQUENCE > >> > >> 2572:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc > >> > >> 2583:d=9 hl=2 l= 11 cons: SEQUENCE > >> > >> 2585:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc > >> > >> 2596:d=9 hl=2 l= 10 cons: SEQUENCE > >> > >> 2598:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc > >> > >> 2608:d=9 hl=2 l= 14 cons: SEQUENCE > >> > >> 2610:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > >> > >> 2620:d=10 hl=2 l= 2 prim: INTEGER :80 > >> > >> 2624:d=9 hl=2 l= 13 cons: SEQUENCE > >> > >> 2626:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > >> > >> 2636:d=10 hl=2 l= 1 prim: INTEGER :40 > >> > >> 2639:d=9 hl=2 l= 7 cons: SEQUENCE > >> > >> 2641:d=10 hl=2 l= 5 prim: OBJECT :des-cbc > >> > >> 2648:d=9 hl=2 l= 13 cons: SEQUENCE > >> > >> 2650:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > >> > >> 2660:d=10 hl=2 l= 1 prim: INTEGER :28 > >> > >> 2663:d=5 hl=2 l= 0 cons: SEQUENCE > >> > >> 2665:d=5 hl=2 l= 0 prim: OCTET STRING > >> > >> 2667:d=4 hl=4 l= 723 cons: SEQUENCE > >> > >> 2671:d=5 hl=2 l= 1 prim: INTEGER :01 > >> > >> 2674:d=5 hl=3 l= 149 cons: SEQUENCE > >> > >> 2677:d=6 hl=3 l= 143 cons: SEQUENCE > >> > >> 2680:d=7 hl=2 l= 11 cons: SET > >> > >> 2682:d=8 hl=2 l= 9 cons: SEQUENCE > >> > >> 2684:d=9 hl=2 l= 3 prim: OBJECT :countryName > >> > >> 2689:d=9 hl=2 l= 2 prim: PRINTABLESTRING :IN > >> > >> 2693:d=7 hl=2 l= 11 cons: SET > >> > >> ==multiple lines truncated== > >> > >> 2949:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities > >> > >> 2960:d=7 hl=2 l= 108 cons: SET > >> > >> 2962:d=8 hl=2 l= 106 cons: SEQUENCE > >> > >> 2964:d=9 hl=2 l= 11 cons: SEQUENCE > >> > >> 2966:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc > >> > >> 2977:d=9 hl=2 l= 11 cons: SEQUENCE > >> > >> 2979:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc > >> > >> 2990:d=9 hl=2 l= 11 cons: SEQUENCE > >> > >> 2992:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc > >> > >> 3003:d=9 hl=2 l= 10 cons: SEQUENCE > >> > >> 3005:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc > >> > >> 3015:d=9 hl=2 l= 14 cons: SEQUENCE > >> > >> 3017:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > >> > >> 3027:d=10 hl=2 l= 2 prim: INTEGER :80 > >> > >> 3031:d=9 hl=2 l= 13 cons: SEQUENCE > >> > >> 3033:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > >> > >> 3043:d=10 hl=2 l= 1 prim: INTEGER :40 > >> > >> 3046:d=9 hl=2 l= 7 cons: SEQUENCE > >> > >> 3048:d=10 hl=2 l= 5 prim: OBJECT :des-cbc > >> > >> 3055:d=9 hl=2 l= 13 cons: SEQUENCE > >> > >> 3057:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc > >> > >> 3067:d=10 hl=2 l= 1 prim: INTEGER :28 > >> > >> 3070:d=5 hl=2 l= 62 cons: SEQUENCE > >> > >> 3072:d=6 hl=2 l= 9 prim: OBJECT :rsassaPss > >> > >> 3083:d=6 hl=2 l= 49 cons: SEQUENCE > >> > >> 3085:d=7 hl=2 l= 13 cons: cont [ 0 ] > >> > >> 3087:d=8 hl=2 l= 11 cons: SEQUENCE > >> > >> 3089:d=9 hl=2 l= 9 prim: OBJECT :sha256 > >> > >> 3100:d=7 hl=2 l= 26 cons: cont [ 1 ] > >> > >> 3102:d=8 hl=2 l= 24 cons: SEQUENCE > >> > >> 3104:d=9 hl=2 l= 9 prim: OBJECT :mgf1 > >> > >> 3115:d=9 hl=2 l= 11 cons: SEQUENCE > >> > >> 3117:d=10 hl=2 l= 9 prim: OBJECT :sha256 > >> > >> 3128:d=7 hl=2 l= 4 cons: cont [ 2 ] > >> > >> 3130:d=8 hl=2 l= 2 prim: INTEGER :DE > >> > >> 3134:d=5 hl=4 l= 256 prim: OCTET STRING [HEX > DUMP]:66C7A406905E0BEF3BE8A55B8BA05915020B6960BDE4700C3C3FB2F115FE5BA60B453EFF39BA37E4D16CA3A86582B3057D05875766BE99C51BC5BEC9CD1AAE3BEC34943160BB06784209F1A3773E07A101BA3E2231FDF85FAB91872A081E37410905A09DAF530600BF9099B054B1DF869826E864A95F5D55DAE84A0CEC43E52F6D13574E1EF66A4E3A65883788E265D6C174211ADBCFEA96A9DD186887BFE040D6D0B59547D8763157D322F0307D7AF3123B0ECFB11E1E7EA228861F4363DBA8D478A7E44F1DEB77A3904FBD90CAA41E291A2E094ABCBD5134146FB1C0F42BC8D7B4829DEFEE7BACDFC024FB8B9FAF16F225EB3C96D866C535B2A06E83DCF007 > >> > >> > >> Thanks, > >> > >> Thulasi. > >> > >> > >> > >> On Sat, 20 Feb 2021 at 00:40, Alon Bar-Lev > wrote: > >>> > >>> Thanks! > >>> Was about to write... I tested both 1.1 and master branches and result > is the same. > >>> > >>> > >>> On Fri, 19 Feb 2021 at 21:04 Thulasi Goriparthi < > thulasi.goriparthi at gmail.com> wrote: > >>>> > >>>> I am able to reproduce this issue with 1.1.1j too. > >>>> > >>>> openssl version -a > >>>> > >>>> OpenSSL 1.1.1j 16 Feb 2021 > >>>> > >>>> built on: Fri Feb 19 18:56:06 2021 UTC > >>>> > >>>> platform: darwin64-x86_64-cc > >>>> > >>>> options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) > >>>> > >>>> compiler: cc -fPIC -arch x86_64 -g -Wall -DL_ENDIAN -DOPENSSL_PIC > -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM > -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT > -DNDEBUG > >>>> > >>>> OPENSSLDIR: "/usr/local/ssl" > >>>> > >>>> ENGINESDIR: "/usr/local/lib/engines-1.1" > >>>> > >>>> Seeding source: os-specific > >>>> > >>>> > >>>> openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms -keyopt > rsa_padding_mode:pss > >>>> > >>>> openssl cms -verify -in 1.cms -CAfile ca.pem > >>>> > >>>> Content-Type: text/plain > >>>> > >>>> > >>>> hello world > >>>> > >>>> Verification successful > >>>> > >>>> openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms -keyopt > rsa_padding_mode:pss > >>>> > >>>> openssl cms -verify -in 2.cms -CAfile ca.pem > >>>> > >>>> Error reading S/MIME message > >>>> > >>>> 4757167552:error:0D078079:asn1 encoding > routines:asn1_item_embed_d2i:field > missing:crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR > >>>> > >>>> 4757167552:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, > Type=CMS_SignerInfo > >>>> > >>>> 4757167552:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:crypto/asn1/tasn_dec.c:615:Field=signerInfos, Type=CMS_SignedData > >>>> > >>>> 4757167552:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:crypto/asn1/tasn_dec.c:646: > >>>> > >>>> 4757167552:error:0D08403A:asn1 encoding > routines:asn1_template_ex_d2i:nested asn1 > error:crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo > >>>> > >>>> 4757167552:error:0D0D106E:asn1 encoding routines:b64_read_asn1:decode > error:crypto/asn1/asn_mime.c:143: > >>>> > >>>> 4757167552:error:0D0D40CC:asn1 encoding routines:SMIME_read_ASN1:asn1 > sig parse error:crypto/asn1/asn_mime.c:451: > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Thulasi. > >>>> > >>>> > >>>> On Sat, 20 Feb 2021 at 00:09, Viktor Dukhovni < > openssl-users at dukhovni.org> wrote: > >>>>> > >>>>> On Fri, Feb 19, 2021 at 11:19:42PM +0530, Thulasi Goriparthi wrote: > >>>>> > >>>>> > I am able to reproduce this issue with 1.1.1i > >>>>> > >>>>> OpenSSL 1.1.1j has been released. Do you still see the problem with > >>>>> 1.1.1j? > >>>>> > >>>>> -- > >>>>> Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alon.barlev at gmail.com Fri Feb 19 21:32:42 2021 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 19 Feb 2021 23:32:42 +0200 Subject: openssl cms resign with RSA-PSS corrupts the CMS(?) In-Reply-To: References: Message-ID: Done[1] [1] https://github.com/openssl/openssl/issues/14257 On Fri, Feb 19, 2021 at 11:09 PM Dmitry Belyavsky wrote: > > Would you mind to raise the issue on GitHub with the reproduction? > > On Fri, 19 Feb 2021, 21:44 Alon Bar-Lev, wrote: >> >> Hi, >> >> I am trying to analyze openssl sources, and it looks like the resign >> is implemented in an naive path that does not handle all cases. >> >> In other words, the CMS resign is not working in any case other than >> the default execution path. >> >> For example the -noattr is also not working. >> >> I updated my reproduction project[1] to show all cases of resign that >> do not work CMS_NO_ATTR, CMS_KEY_PARAM. >> >> I believe the root cause is that when resign is executed the >> CMS_final() is not called and instead the i2d_CMS_bio() is called, >> while its logic is incomplete. >> >> I hope this will ring a bell to people who are maintaining the >> crypto/cms/* implementation. >> >> Tested [fails] with: >> OpenSSL_1_1_1-stable >> master >> >> Regards, >> Alon >> >> [1] https://github.com/alonbl/openssl-cms-pss >> >> On Fri, Feb 19, 2021 at 10:06 PM Alon Bar-Lev wrote: >> > >> > Thanks. >> > I managed to narrow this, it is not related to pss also if I pass pkcs1 I can reproduce. It has something to do with CMS_KEY_PARAM flag and add signer. >> > >> > On Fri, 19 Feb 2021 at 22:03 Thulasi Goriparthi wrote: >> >> >> >> With PSS, for the first signature, PSS alg ID and params are encoded correctly, but not for the second signature(resign). >> >> >> >> 2542:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities >> >> >> >> 2553:d=7 hl=2 l= 108 cons: SET >> >> >> >> 2555:d=8 hl=2 l= 106 cons: SEQUENCE >> >> >> >> 2557:d=9 hl=2 l= 11 cons: SEQUENCE >> >> >> >> 2559:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc >> >> >> >> 2570:d=9 hl=2 l= 11 cons: SEQUENCE >> >> >> >> 2572:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc >> >> >> >> 2583:d=9 hl=2 l= 11 cons: SEQUENCE >> >> >> >> 2585:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc >> >> >> >> 2596:d=9 hl=2 l= 10 cons: SEQUENCE >> >> >> >> 2598:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc >> >> >> >> 2608:d=9 hl=2 l= 14 cons: SEQUENCE >> >> >> >> 2610:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> >> >> 2620:d=10 hl=2 l= 2 prim: INTEGER :80 >> >> >> >> 2624:d=9 hl=2 l= 13 cons: SEQUENCE >> >> >> >> 2626:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> >> >> 2636:d=10 hl=2 l= 1 prim: INTEGER :40 >> >> >> >> 2639:d=9 hl=2 l= 7 cons: SEQUENCE >> >> >> >> 2641:d=10 hl=2 l= 5 prim: OBJECT :des-cbc >> >> >> >> 2648:d=9 hl=2 l= 13 cons: SEQUENCE >> >> >> >> 2650:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> >> >> 2660:d=10 hl=2 l= 1 prim: INTEGER :28 >> >> >> >> 2663:d=5 hl=2 l= 0 cons: SEQUENCE >> >> >> >> 2665:d=5 hl=2 l= 0 prim: OCTET STRING >> >> >> >> 2667:d=4 hl=4 l= 723 cons: SEQUENCE >> >> >> >> 2671:d=5 hl=2 l= 1 prim: INTEGER :01 >> >> >> >> 2674:d=5 hl=3 l= 149 cons: SEQUENCE >> >> >> >> 2677:d=6 hl=3 l= 143 cons: SEQUENCE >> >> >> >> 2680:d=7 hl=2 l= 11 cons: SET >> >> >> >> 2682:d=8 hl=2 l= 9 cons: SEQUENCE >> >> >> >> 2684:d=9 hl=2 l= 3 prim: OBJECT :countryName >> >> >> >> 2689:d=9 hl=2 l= 2 prim: PRINTABLESTRING :IN >> >> >> >> 2693:d=7 hl=2 l= 11 cons: SET >> >> >> >> ==multiple lines truncated== >> >> >> >> 2949:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities >> >> >> >> 2960:d=7 hl=2 l= 108 cons: SET >> >> >> >> 2962:d=8 hl=2 l= 106 cons: SEQUENCE >> >> >> >> 2964:d=9 hl=2 l= 11 cons: SEQUENCE >> >> >> >> 2966:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc >> >> >> >> 2977:d=9 hl=2 l= 11 cons: SEQUENCE >> >> >> >> 2979:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc >> >> >> >> 2990:d=9 hl=2 l= 11 cons: SEQUENCE >> >> >> >> 2992:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc >> >> >> >> 3003:d=9 hl=2 l= 10 cons: SEQUENCE >> >> >> >> 3005:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc >> >> >> >> 3015:d=9 hl=2 l= 14 cons: SEQUENCE >> >> >> >> 3017:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> >> >> 3027:d=10 hl=2 l= 2 prim: INTEGER :80 >> >> >> >> 3031:d=9 hl=2 l= 13 cons: SEQUENCE >> >> >> >> 3033:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> >> >> 3043:d=10 hl=2 l= 1 prim: INTEGER :40 >> >> >> >> 3046:d=9 hl=2 l= 7 cons: SEQUENCE >> >> >> >> 3048:d=10 hl=2 l= 5 prim: OBJECT :des-cbc >> >> >> >> 3055:d=9 hl=2 l= 13 cons: SEQUENCE >> >> >> >> 3057:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc >> >> >> >> 3067:d=10 hl=2 l= 1 prim: INTEGER :28 >> >> >> >> 3070:d=5 hl=2 l= 62 cons: SEQUENCE >> >> >> >> 3072:d=6 hl=2 l= 9 prim: OBJECT :rsassaPss >> >> >> >> 3083:d=6 hl=2 l= 49 cons: SEQUENCE >> >> >> >> 3085:d=7 hl=2 l= 13 cons: cont [ 0 ] >> >> >> >> 3087:d=8 hl=2 l= 11 cons: SEQUENCE >> >> >> >> 3089:d=9 hl=2 l= 9 prim: OBJECT :sha256 >> >> >> >> 3100:d=7 hl=2 l= 26 cons: cont [ 1 ] >> >> >> >> 3102:d=8 hl=2 l= 24 cons: SEQUENCE >> >> >> >> 3104:d=9 hl=2 l= 9 prim: OBJECT :mgf1 >> >> >> >> 3115:d=9 hl=2 l= 11 cons: SEQUENCE >> >> >> >> 3117:d=10 hl=2 l= 9 prim: OBJECT :sha256 >> >> >> >> 3128:d=7 hl=2 l= 4 cons: cont [ 2 ] >> >> >> >> 3130:d=8 hl=2 l= 2 prim: INTEGER :DE >> >> >> >> 3134:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:66C7A406905E0BEF3BE8A55B8BA05915020B6960BDE4700C3C3FB2F115FE5BA60B453EFF39BA37E4D16CA3A86582B3057D05875766BE99C51BC5BEC9CD1AAE3BEC34943160BB06784209F1A3773E07A101BA3E2231FDF85FAB91872A081E37410905A09DAF530600BF9099B054B1DF869826E864A95F5D55DAE84A0CEC43E52F6D13574E1EF66A4E3A65883788E265D6C174211ADBCFEA96A9DD186887BFE040D6D0B59547D8763157D322F0307D7AF3123B0ECFB11E1E7EA228861F4363DBA8D478A7E44F1DEB77A3904FBD90CAA41E291A2E094ABCBD5134146FB1C0F42BC8D7B4829DEFEE7BACDFC024FB8B9FAF16F225EB3C96D866C535B2A06E83DCF007 >> >> >> >> >> >> Thanks, >> >> >> >> Thulasi. >> >> >> >> >> >> >> >> On Sat, 20 Feb 2021 at 00:40, Alon Bar-Lev wrote: >> >>> >> >>> Thanks! >> >>> Was about to write... I tested both 1.1 and master branches and result is the same. >> >>> >> >>> >> >>> On Fri, 19 Feb 2021 at 21:04 Thulasi Goriparthi wrote: >> >>>> >> >>>> I am able to reproduce this issue with 1.1.1j too. >> >>>> >> >>>> openssl version -a >> >>>> >> >>>> OpenSSL 1.1.1j 16 Feb 2021 >> >>>> >> >>>> built on: Fri Feb 19 18:56:06 2021 UTC >> >>>> >> >>>> platform: darwin64-x86_64-cc >> >>>> >> >>>> options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) >> >>>> >> >>>> compiler: cc -fPIC -arch x86_64 -g -Wall -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG >> >>>> >> >>>> OPENSSLDIR: "/usr/local/ssl" >> >>>> >> >>>> ENGINESDIR: "/usr/local/lib/engines-1.1" >> >>>> >> >>>> Seeding source: os-specific >> >>>> >> >>>> >> >>>> openssl cms -sign -in msg -text -signer cert1.pem -out 1.cms -keyopt rsa_padding_mode:pss >> >>>> >> >>>> openssl cms -verify -in 1.cms -CAfile ca.pem >> >>>> >> >>>> Content-Type: text/plain >> >>>> >> >>>> >> >>>> hello world >> >>>> >> >>>> Verification successful >> >>>> >> >>>> openssl cms -resign -in 1.cms -signer cert2.pem -out 2.cms -keyopt rsa_padding_mode:pss >> >>>> >> >>>> openssl cms -verify -in 2.cms -CAfile ca.pem >> >>>> >> >>>> Error reading S/MIME message >> >>>> >> >>>> 4757167552:error:0D078079:asn1 encoding routines:asn1_item_embed_d2i:field missing:crypto/asn1/tasn_dec.c:425:Field=algorithm, Type=X509_ALGOR >> >>>> >> >>>> 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=signatureAlgorithm, Type=CMS_SignerInfo >> >>>> >> >>>> 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:615:Field=signerInfos, Type=CMS_SignedData >> >>>> >> >>>> 4757167552:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646: >> >>>> >> >>>> 4757167552:error:0D08403A:asn1 encoding routines:asn1_template_ex_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:496:Field=d.signedData, Type=CMS_ContentInfo >> >>>> >> >>>> 4757167552:error:0D0D106E:asn1 encoding routines:b64_read_asn1:decode error:crypto/asn1/asn_mime.c:143: >> >>>> >> >>>> 4757167552:error:0D0D40CC:asn1 encoding routines:SMIME_read_ASN1:asn1 sig parse error:crypto/asn1/asn_mime.c:451: >> >>>> >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Thulasi. >> >>>> >> >>>> >> >>>> On Sat, 20 Feb 2021 at 00:09, Viktor Dukhovni wrote: >> >>>>> >> >>>>> On Fri, Feb 19, 2021 at 11:19:42PM +0530, Thulasi Goriparthi wrote: >> >>>>> >> >>>>> > I am able to reproduce this issue with 1.1.1i >> >>>>> >> >>>>> OpenSSL 1.1.1j has been released. Do you still see the problem with >> >>>>> 1.1.1j? >> >>>>> >> >>>>> -- >> >>>>> Viktor. From guerinp at talasi.fr Sat Feb 20 08:49:48 2021 From: guerinp at talasi.fr (=?UTF-8?Q?Patrice_Gu=c3=a9rin?=) Date: Sat, 20 Feb 2021 09:49:48 +0100 Subject: Useable digest algorithms with signature Message-ID: <263748e5-75bd-8f39-8bc4-55cb61b828ce@talasi.fr> Dear All, Which digest algorithms can be used for signature with a RSA key ? sha and ripemd160 work well, but - whirlpool that works in 1.0.2o, doesn't anymore (1.1.1j) - the same applies to blake, shake Error setting context 6116:error:0408C09D:rsa routines:check_padding_md:invalid digest:crypto\rsa\rsa_pmeth.c:390: What is the reason ? (intellectual curiosity ?) Thanks. Patrice. From john.hughes at secid.co.uk Sat Feb 20 12:44:00 2021 From: john.hughes at secid.co.uk (john.hughes at secid.co.uk) Date: Sat, 20 Feb 2021 12:44:00 -0000 Subject: Edwards and public key validation Message-ID: <01b301d70786$0fbf8220$2f3e8660$@secid.co.uk> I want to implement a function that validates a public key produced by either ed25519 or ed448 - according to the tests in NIST SP 800-186 appendix D.1.3 There doesn't appear to be any helper functions to assist in this - at least for Edwards curves. I have implemented something for Weierstrass curves - and have used helper functions to obtain the curve/group, domain parameters, EC_POINT_is_at_infinity() etc etc - but nothing for Edwards. All I can see is EVCP_PKEY_new_raw_public_key() and EVCP_PKEY_get_raw_public_key() - and that does really help in what I'm trying to do. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michal.Trojnara at stunnel.org Sat Feb 20 21:46:31 2021 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Sat, 20 Feb 2021 22:46:31 +0100 Subject: stunnel 5.58 released Message-ID: <04a92b38-679b-88af-3bed-29499d93bcd1@stunnel.org> Dear Users, I have released version 5.58 of stunnel. This release fixes another security bug in the "redirect" option. ### Version 5.58, 2021.02.20, urgency: HIGH * Security bugfixes ? - The "redirect" option was fixed to properly handle ??? unauthenticated requests (thx to Martin Stein). ? - Fixed a double free with OpenSSL older than 1.1.0 (thx to ??? Petr Strukov). ? - OpenSSL DLLs updated to version 1.1.1j. * New features ? - New 'protocolHeader' service-level option to insert custom ??? 'connect' protocol negotiation headers.? This feature can ??? be used to impersonate other software (e.g. web browsers). ? - 'protocolHost' can also be used to control the client SMTP ??? protocol negotiation HELO/EHLO value. ? - Initial FIPS 3.0 support. * Bugfixes ? - X.509v3 extensions required by modern versions of OpenSSL ??? are added to generated self-signed test certificates. ? - Fixed a tiny memory leak in configuration file reload ??? error handling (thx to Richard K?nning). ? - Merged Debian 05-typos.patch (thx to Peter Pentchev). ? - Merged with minor changes Debian 06-hup-separate.patch ??? (thx to Peter Pentchev). ? - Merged Debian 07-imap-capabilities.patch (thx to Ansgar). ? - Merged Debian 08-addrconfig-workaround.patch (thx to Peter ??? Pentchev). ? - Fixed tests on the WSL2 platform. ? - NSIS installer updated to version 3.06 to fix a multiuser ??? installation bug on some platforms, including 64-bit XP. ? - Fixed engine initialization (thx to Petr Strukov). ? - FIPS TLS feature is reported when a provider or container ??? is available, and not when FIPS control API is available. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: d4c14cc096577edca3f6a2a59c2f51869e35350b3988018ddf808c88e5973b79 stunnel-5.58.tar.gz 92055a006a0d178a25cc29ef681ae32d4cea3075c096abc893c92ba6285d6908 stunnel-5.58-win64-installer.exe 57c313ee8b42da42265b33fb91555a58c1f1b94f5e93a389c310e37a87f2013c stunnel-5.58-android.zip Best regards, ??? Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From bbrumley at gmail.com Sun Feb 21 12:05:39 2021 From: bbrumley at gmail.com (Billy Brumley) Date: Sun, 21 Feb 2021 14:05:39 +0200 Subject: Edwards and public key validation In-Reply-To: <01b301d70786$0fbf8220$2f3e8660$@secid.co.uk> References: <01b301d70786$0fbf8220$2f3e8660$@secid.co.uk> Message-ID: Hey John, > I want to implement a function that validates a public key produced by either ed25519 or ed448 ? according to the tests in NIST SP 800-186 appendix D.1.3 > > > > There doesn?t appear to be any helper functions to assist in this ? at least for Edwards curves. > > > > I have implemented something for Weierstrass curves ? and have used helper functions to obtain the curve/group, domain parameters, EC_POINT_is_at_infinity() etc etc ? but nothing for Edwards. I don't believe you actually have to do that for Weierstrass curves. That is why EVP_PKEY_check and EVP_PKEY_public_check exist, and aren't even legacy EC specific -- thrown any PKEY at them (I cannot say 110% it is doing all the validation you want, but check it in the debugger). You can reach it even from the CLI openssl pkey -in key.pem -check I will reiterate what I wrote recently on the IETF CFRG mailing list regarding OpenSSL's (EC) API, after which many armchair engineers either replied on the list or directly to me, telling me how wrong I was: BBB: "If you (=application developer) are dealing with points directly in OpenSSL, you are probably already doing it wrong." So your message (at least, about Weierstrass curves) is a good example of what I said -- you've apparently rolled your own key validation, when the library is perfectly capable of doing that for you, off the shelf. (John I am not trying to knock on your or any other well-intentioned developer. I am just saying, with OpenSSL, developers should avoid jumping straight to the lowest level API, and consider first what the high level APIs can/should provide you.) For ed25519 and ed448, your message (AFAICT, attaching a debugger to openssl pkey ... -check) indicates those function pointers are not set in the ed25519 and ed449 ameths: https://github.com/openssl/openssl/blob/master/crypto/ec/ecx_meth.c#L726 (you can see, they are NULL here.) I am going to guess part of the reason is because FIPS186-5 is only draft status therefore OpenSSL has not mainlined anything, with the possibility the standard will (and should, IMO) shift before being finalized. In that sense when you write "NIST SP 800-186 appendix D.1.3" I think it is very misleading because that is not actually a standard -- only a draft as of this writing. At least in the context of ed25519 and ed448, the D.1.3 validation doesn't really make any sense. This is generally the problem when NIST tries to backport modern cryptography to legacy standards. With these modern curves, the whole idea is you don't have to validate like that -- at least not the computational aspects of legacy EC key validation. Having said that, I see no harm in discussing to add support for this kind of validation. Would you please raise an issue on GH? Thanks, BBB From john.hughes at secid.co.uk Sun Feb 21 13:40:29 2021 From: john.hughes at secid.co.uk (john.hughes at secid.co.uk) Date: Sun, 21 Feb 2021 13:40:29 -0000 Subject: Edwards and public key validation In-Reply-To: References: <01b301d70786$0fbf8220$2f3e8660$@secid.co.uk> Message-ID: <01d101d70857$1eb67550$5c235ff0$@secid.co.uk> Thanks Billy for getting back to me. The bigger picture on this is that I have a very comprehensive test harness for testing PKCS#11 devices. I already have developed and successfully run tests that test Weierstrass curves. I have successfully tested many PKCS#11 tokens for their implementation of NIST P-* and Brainpool curves against the 4 tests specified in X9.62 (and now in NIST SP 800-186 (yes the draft one). I use some of the OpenSSL functions to assist this - especially the BN functionality. Because my test harness doesn't currently support Edwards curves - and OpenSSL and SoftHSMv2 supports them - I thought it would be useful to add Edward testing functionality into my harness. I can successfully generate ed25519 keypairs using SoftHSMv2 via the PKCS#11 interface - but now adding in tests to validate the generated public keys - according to NIST SP 800-186. I thought I would look at what OpenSSL does internally - including it tests. That is where I noticed that the Edwards support is not as rich as the support for "normal" EC curves. In fact to do the four tests in 800-186 I don?t actually need any more functionality - as the BN functions will (I think) do what I need. Having, said that I can't get the "public key on the curve" test working as yet given the RFC 8032 test vectors. Hopefully, I will sort it out soon! Regards John >>-----Original Message----- >>From: Billy Brumley >>Sent: 21 February 2021 12:06 >>To: john.hughes at secid.co.uk >>Cc: openssl-users at openssl.org >>Subject: Re: Edwards and public key validation >> >>Hey John, >> >>> I want to implement a function that validates a public key produced by >>> either ed25519 or ed448 ? according to the tests in NIST SP 800-186 >>> appendix D.1.3 >>> >>> >>> >>> There doesn?t appear to be any helper functions to assist in this ? at least for >>Edwards curves. >>> >>> >>> >>> I have implemented something for Weierstrass curves ? and have used helper >>functions to obtain the curve/group, domain parameters, >>EC_POINT_is_at_infinity() etc etc ? but nothing for Edwards. >> >>I don't believe you actually have to do that for Weierstrass curves. >>That is why EVP_PKEY_check and EVP_PKEY_public_check exist, and aren't even >>legacy EC specific -- thrown any PKEY at them (I cannot say 110% it is doing all >>the validation you want, but check it in the debugger). You can reach it even >>from the CLI >> >>openssl pkey -in key.pem -check >> >> >>I will reiterate what I wrote recently on the IETF CFRG mailing list regarding >>OpenSSL's (EC) API, after which many armchair engineers either replied on the >>list or directly to me, telling me how wrong I >>was: >> >>BBB: "If you (=application developer) are dealing with points directly in OpenSSL, >>you are probably already doing it wrong." >> >>So your message (at least, about Weierstrass curves) is a good example of what >>I said -- you've apparently rolled your own key validation, when the library is >>perfectly capable of doing that for you, off the shelf. >> >>(John I am not trying to knock on your or any other well-intentioned developer. I >>am just saying, with OpenSSL, developers should avoid jumping straight to the >>lowest level API, and consider first what the high level APIs can/should provide >>you.) >> >>For ed25519 and ed448, your message (AFAICT, attaching a debugger to openssl >>pkey ... -check) indicates those function pointers are not set in the ed25519 and >>ed449 ameths: >> >>https://github.com/openssl/openssl/blob/master/crypto/ec/ecx_meth.c#L726 >> >>(you can see, they are NULL here.) >> >>I am going to guess part of the reason is because FIPS186-5 is only draft status >>therefore OpenSSL has not mainlined anything, with the possibility the standard >>will (and should, IMO) shift before being finalized. In that sense when you write >>"NIST SP 800-186 appendix D.1.3" I think it is very misleading because that is not >>actually a standard -- only a draft as of this writing. >> >> >>At least in the context of ed25519 and ed448, the D.1.3 validation doesn't really >>make any sense. This is generally the problem when NIST tries to backport >>modern cryptography to legacy standards. With these modern curves, the whole >>idea is you don't have to validate like that >>-- at least not the computational aspects of legacy EC key validation. >> >> >>Having said that, I see no harm in discussing to add support for this kind of >>validation. >> >>Would you please raise an issue on GH? >> >>Thanks, >> >>BBB From ivanogiancaterina at gmail.com Mon Feb 22 13:58:48 2021 From: ivanogiancaterina at gmail.com (ivano giancaterina) Date: Mon, 22 Feb 2021 14:58:48 +0100 Subject: Problem with upgrade to 3.0 - d2i_ASN1_SET bad class Message-ID: Hello, I'm currently performing an upgrade from 1.0.2 to 3.0 and I'm having some difficulties. Our code is very old and some assumptions could have changed during time. Anyway the problem I have right now is about d2i_ASN1_SET and i2d_ASN1_SET functions that in OpenSSL 3 are not available anymore. In particular I have the function i2d_ASN1_SET_OF_X509_CRL( stack, &position, reinterpret_cast< int(*)(X509_CRL*,unsigned char**) >( i2d_X509_CRL ), 1, V_ASN1_CONTEXT_SPECIFIC, IS_SET ) ); In version 3 of my code I did the following: ASN1_ITEM_TEMPLATE(X509_CRLStack) = ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SET_ORDER, 0, X509_CRLStack, X509_CRL) ASN1_ITEM_TEMPLATE_END(X509_CRLStack); IMPLEMENT_ASN1_FUNCTIONS(X509_CRLStack); I replaced i2d_ASN1_SET_OF_X509_CRL with i2d_X509_CRLStack( stack, &position ) The problem arises when I save the result and try to read with version 1.0.2 of my code. I have to be sure to garante legacy compatibility In d2i_X509_CRLStack I get error bad class Can you please help me to understand what I'm doing wrong? Regards Ivano -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfulger at gmx.com Mon Feb 22 14:17:21 2021 From: dfulger at gmx.com (Dan Fulger) Date: Mon, 22 Feb 2021 15:17:21 +0100 Subject: An idiosyncratic port of OpenSSL 1.1.1j to OS/400 ILE Message-ID: This port is for ILE (native OS/400)?not PASE (PASE is almost like Unix, and already comes with OpenSSL). ? The idiosyncrasies are explained in the README.as400 file in AS400patch.tar.gz. ? AS400patch.tar.gz (large patch for OpenSSL and other files): https://drive.google.com/file/d/1gAKV6X1xpNxlLX9FOYA20iErlKTrdWaN/view?usp=sharing ? AS400_GNU.tar.gz (source for GNU/IBM tools required to build OpenSSL in ILE environment): https://drive.google.com/open?id=1DeKIE32nmUpvk7fvrcSYlflUn_k1CBso[https://drive.google.com/open?id=1DeKIE32nmUpvk7fvrcSYlflUn_k1CBso][https://drive.google.com/open?id=1DeKIE32nmUpvk7fvrcSYlflUn_k1CBso[https://drive.google.com/open?id=1DeKIE32nmUpvk7fvrcSYlflUn_k1CBso]] From bbrumley at gmail.com Tue Feb 23 13:41:49 2021 From: bbrumley at gmail.com (Billy Brumley) Date: Tue, 23 Feb 2021 15:41:49 +0200 Subject: Edwards and public key validation In-Reply-To: <01d101d70857$1eb67550$5c235ff0$@secid.co.uk> References: <01b301d70786$0fbf8220$2f3e8660$@secid.co.uk> <01d101d70857$1eb67550$5c235ff0$@secid.co.uk> Message-ID: Hey John, (Apologies I missed the reply all.) Your Weierstrass tests are likely redundant with what EVP_PKEY_check etc are doing under the hood. You should also be aware, with Weierstrass curves, it is impossible to get a point that is not on the curve through the OpenSSL API. (As far as I know.) If you really want those Edwards tests, that functionality does not exist yet in the library. Even if you roll your own at the application level with BN functions, I would still suggest opening an issue on GH because the missing function pointers I mentioned are library deficiencies. When those get properly populated, you can eventually throw away any application level code doing validation. (If you are saying, your application exists solely for the purpose of direct low level testing of PKCS11 devices / generating test vectors, and does not pass this PKCS11 functionality through e.g. an OpenSSL engine, then please just ignore me. Although in that case I would kindly suggest OpenSSL might not really be the best tool for you. Unless you are doing some kind of differential testing.) Hope it helps, BBB On Sun, Feb 21, 2021 at 3:40 PM wrote: > > Thanks Billy for getting back to me. > > The bigger picture on this is that I have a very comprehensive test harness for testing PKCS#11 devices. I already have developed and successfully run tests that test Weierstrass curves. I have successfully tested many PKCS#11 tokens for their implementation of NIST P-* and Brainpool curves against the 4 tests specified in X9.62 (and now in NIST SP 800-186 (yes the draft one). I use some of the OpenSSL functions to assist this - especially the BN functionality. > > Because my test harness doesn't currently support Edwards curves - and OpenSSL and SoftHSMv2 supports them - I thought it would be useful to add Edward testing functionality into my harness. > > I can successfully generate ed25519 keypairs using SoftHSMv2 via the PKCS#11 interface - but now adding in tests to validate the generated public keys - according to NIST SP 800-186. > > I thought I would look at what OpenSSL does internally - including it tests. That is where I noticed that the Edwards support is not as rich as the support for "normal" EC curves. > > In fact to do the four tests in 800-186 I don?t actually need any more functionality - as the BN functions will (I think) do what I need. Having, said that I can't get the "public key on the curve" test working as yet given the RFC 8032 test vectors. Hopefully, I will sort it out soon! > > > Regards > > John > > >>-----Original Message----- > >>From: Billy Brumley > >>Sent: 21 February 2021 12:06 > >>To: john.hughes at secid.co.uk > >>Cc: openssl-users at openssl.org > >>Subject: Re: Edwards and public key validation > >> > >>Hey John, > >> > >>> I want to implement a function that validates a public key produced by > >>> either ed25519 or ed448 ? according to the tests in NIST SP 800-186 > >>> appendix D.1.3 > >>> > >>> > >>> > >>> There doesn?t appear to be any helper functions to assist in this ? at least for > >>Edwards curves. > >>> > >>> > >>> > >>> I have implemented something for Weierstrass curves ? and have used helper > >>functions to obtain the curve/group, domain parameters, > >>EC_POINT_is_at_infinity() etc etc ? but nothing for Edwards. > >> > >>I don't believe you actually have to do that for Weierstrass curves. > >>That is why EVP_PKEY_check and EVP_PKEY_public_check exist, and aren't even > >>legacy EC specific -- thrown any PKEY at them (I cannot say 110% it is doing all > >>the validation you want, but check it in the debugger). You can reach it even > >>from the CLI > >> > >>openssl pkey -in key.pem -check > >> > >> > >>I will reiterate what I wrote recently on the IETF CFRG mailing list regarding > >>OpenSSL's (EC) API, after which many armchair engineers either replied on the > >>list or directly to me, telling me how wrong I > >>was: > >> > >>BBB: "If you (=application developer) are dealing with points directly in OpenSSL, > >>you are probably already doing it wrong." > >> > >>So your message (at least, about Weierstrass curves) is a good example of what > >>I said -- you've apparently rolled your own key validation, when the library is > >>perfectly capable of doing that for you, off the shelf. > >> > >>(John I am not trying to knock on your or any other well-intentioned developer. I > >>am just saying, with OpenSSL, developers should avoid jumping straight to the > >>lowest level API, and consider first what the high level APIs can/should provide > >>you.) > >> > >>For ed25519 and ed448, your message (AFAICT, attaching a debugger to openssl > >>pkey ... -check) indicates those function pointers are not set in the ed25519 and > >>ed449 ameths: > >> > >>https://github.com/openssl/openssl/blob/master/crypto/ec/ecx_meth.c#L726 > >> > >>(you can see, they are NULL here.) > >> > >>I am going to guess part of the reason is because FIPS186-5 is only draft status > >>therefore OpenSSL has not mainlined anything, with the possibility the standard > >>will (and should, IMO) shift before being finalized. In that sense when you write > >>"NIST SP 800-186 appendix D.1.3" I think it is very misleading because that is not > >>actually a standard -- only a draft as of this writing. > >> > >> > >>At least in the context of ed25519 and ed448, the D.1.3 validation doesn't really > >>make any sense. This is generally the problem when NIST tries to backport > >>modern cryptography to legacy standards. With these modern curves, the whole > >>idea is you don't have to validate like that > >>-- at least not the computational aspects of legacy EC key validation. > >> > >> > >>Having said that, I see no harm in discussing to add support for this kind of > >>validation. > >> > >>Would you please raise an issue on GH? > >> > >>Thanks, > >> > >>BBB > From john.hughes at secid.co.uk Tue Feb 23 13:45:28 2021 From: john.hughes at secid.co.uk (john.hughes at secid.co.uk) Date: Tue, 23 Feb 2021 13:45:28 -0000 Subject: Edwards and public key validation In-Reply-To: References: <01b301d70786$0fbf8220$2f3e8660$@secid.co.uk> <01d101d70857$1eb67550$5c235ff0$@secid.co.uk> Message-ID: <027501d709ea$259dba10$70d92e30$@secid.co.uk> Billy You are correct - this is for low level testing of PKCS#11 devices/tokens. Hence just looking at OpenSSL to see if there are any helper functions for Edwards. There are not. So I have nearly completed development of my own level functions . Now just in the process of testing against some test vectors Regard Johns >>-----Original Message----- >>From: Billy Brumley >>Sent: 23 February 2021 13:42 >>To: john.hughes at secid.co.uk >>Cc: openssl-users at openssl.org >>Subject: Re: Edwards and public key validation >> >>Hey John, >> >>(Apologies I missed the reply all.) >> >>Your Weierstrass tests are likely redundant with what EVP_PKEY_check etc are >>doing under the hood. You should also be aware, with Weierstrass curves, it is >>impossible to get a point that is not on the curve through the OpenSSL API. (As >>far as I know.) >> >>If you really want those Edwards tests, that functionality does not exist yet in >>the library. Even if you roll your own at the application level with BN functions, I >>would still suggest opening an issue on GH because the missing function pointers >>I mentioned are library deficiencies. When those get properly populated, you >>can eventually throw away any application level code doing validation. >> >>(If you are saying, your application exists solely for the purpose of direct low >>level testing of PKCS11 devices / generating test vectors, and does not pass this >>PKCS11 functionality through e.g. an OpenSSL engine, then please just ignore >>me. Although in that case I would kindly suggest OpenSSL might not really be the >>best tool for you. >>Unless you are doing some kind of differential testing.) >> >>Hope it helps, >> >>BBB >> >>On Sun, Feb 21, 2021 at 3:40 PM wrote: >>> >>> Thanks Billy for getting back to me. >>> >>> The bigger picture on this is that I have a very comprehensive test harness for >>testing PKCS#11 devices. I already have developed and successfully run tests >>that test Weierstrass curves. I have successfully tested many PKCS#11 tokens >>for their implementation of NIST P-* and Brainpool curves against the 4 tests >>specified in X9.62 (and now in NIST SP 800-186 (yes the draft one). I use some of >>the OpenSSL functions to assist this - especially the BN functionality. >>> >>> Because my test harness doesn't currently support Edwards curves - and >>OpenSSL and SoftHSMv2 supports them - I thought it would be useful to add >>Edward testing functionality into my harness. >>> >>> I can successfully generate ed25519 keypairs using SoftHSMv2 via the PKCS#11 >>interface - but now adding in tests to validate the generated public keys - >>according to NIST SP 800-186. >>> >>> I thought I would look at what OpenSSL does internally - including it tests. >>That is where I noticed that the Edwards support is not as rich as the support for >>"normal" EC curves. >>> >>> In fact to do the four tests in 800-186 I don?t actually need any more >>functionality - as the BN functions will (I think) do what I need. Having, said that >>I can't get the "public key on the curve" test working as yet given the RFC 8032 >>test vectors. Hopefully, I will sort it out soon! >>> >>> >>> Regards >>> >>> John >>> >>> >>-----Original Message----- >>> >>From: Billy Brumley >>> >>Sent: 21 February 2021 12:06 >>> >>To: john.hughes at secid.co.uk >>> >>Cc: openssl-users at openssl.org >>> >>Subject: Re: Edwards and public key validation >>> >> >>> >>Hey John, >>> >> >>> >>> I want to implement a function that validates a public key >>> >>> produced by either ed25519 or ed448 ? according to the tests in >>> >>> NIST SP 800-186 appendix D.1.3 >>> >>> >>> >>> >>> >>> >>> >>> There doesn?t appear to be any helper functions to assist in this >>> >>> ? at least for >>> >>Edwards curves. >>> >>> >>> >>> >>> >>> >>> >>> I have implemented something for Weierstrass curves ? and have >>> >>> used helper >>> >>functions to obtain the curve/group, domain parameters, >>> >>EC_POINT_is_at_infinity() etc etc ? but nothing for Edwards. >>> >> >>> >>I don't believe you actually have to do that for Weierstrass curves. >>> >>That is why EVP_PKEY_check and EVP_PKEY_public_check exist, and >>> >>aren't even legacy EC specific -- thrown any PKEY at them (I cannot >>> >>say 110% it is doing all the validation you want, but check it in >>> >>the debugger). You can reach it even from the CLI >>> >> >>> >>openssl pkey -in key.pem -check >>> >> >>> >> >>> >>I will reiterate what I wrote recently on the IETF CFRG mailing list >>> >>regarding OpenSSL's (EC) API, after which many armchair engineers >>> >>either replied on the list or directly to me, telling me how wrong I >>> >>was: >>> >> >>> >>BBB: "If you (=application developer) are dealing with points >>> >>directly in OpenSSL, you are probably already doing it wrong." >>> >> >>> >>So your message (at least, about Weierstrass curves) is a good >>> >>example of what I said -- you've apparently rolled your own key >>> >>validation, when the library is perfectly capable of doing that for you, off >>the shelf. >>> >> >>> >>(John I am not trying to knock on your or any other well-intentioned >>> >>developer. I am just saying, with OpenSSL, developers should avoid >>> >>jumping straight to the lowest level API, and consider first what >>> >>the high level APIs can/should provide >>> >>you.) >>> >> >>> >>For ed25519 and ed448, your message (AFAICT, attaching a debugger to >>> >>openssl pkey ... -check) indicates those function pointers are not >>> >>set in the ed25519 and >>> >>ed449 ameths: >>> >> >>> >>https://github.com/openssl/openssl/blob/master/crypto/ec/ecx_meth.c# >>> >>L726 >>> >> >>> >>(you can see, they are NULL here.) >>> >> >>> >>I am going to guess part of the reason is because FIPS186-5 is only >>> >>draft status therefore OpenSSL has not mainlined anything, with the >>> >>possibility the standard will (and should, IMO) shift before being >>> >>finalized. In that sense when you write "NIST SP 800-186 appendix >>> >>D.1.3" I think it is very misleading because that is not actually a standard -- >>only a draft as of this writing. >>> >> >>> >> >>> >>At least in the context of ed25519 and ed448, the D.1.3 validation >>> >>doesn't really make any sense. This is generally the problem when >>> >>NIST tries to backport modern cryptography to legacy standards. With >>> >>these modern curves, the whole idea is you don't have to validate >>> >>like that >>> >>-- at least not the computational aspects of legacy EC key validation. >>> >> >>> >> >>> >>Having said that, I see no harm in discussing to add support for >>> >>this kind of validation. >>> >> >>> >>Would you please raise an issue on GH? >>> >> >>> >>Thanks, >>> >> >>> >>BBB >>> From gfrankliu at gmail.com Wed Feb 24 19:20:31 2021 From: gfrankliu at gmail.com (Frank Liu) Date: Wed, 24 Feb 2021 11:20:31 -0800 Subject: PEM file line size Message-ID: Hi, I noticed openssl 1.0.1 and 1.0.2 can't read a certificate PEM file with base64 line size of multiples of 1265. Any other line size seems to be fine, even though rfc7468 says "exactly 64 characters except for the final line". The same pem file can be read fine with latest openssl 1.1.1j. Does anybody know the bug or PR when that was fixed? Thanks! Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From romain at viau.dev Thu Feb 25 10:14:38 2021 From: romain at viau.dev (Romain Viau) Date: Thu, 25 Feb 2021 11:14:38 +0100 Subject: Support of Indirect CRL and How to? Message-ID: Hi everybody, I am trying to implement a complex PKI and some parts are based on a Indirect CRL issued by a specific certificate. I found that the "openssl verify" command works fine if I had the CRL issuer as "-untrusted" argument. But this check doesn't work if I only add the CRLIssuer cert in the CApath (with `openssl rehash` operation). The CA issuing the User certificate is offline, so I coudn't manage its CRL and my final use case is to implement the CRL verification by a server like Nginx or Apache. So, can I make it work with SSL_CONF_cmd and with which parameters? Regards, Romain -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.Buehlmann at mabulous.com Thu Feb 25 10:57:25 2021 From: Matthias.Buehlmann at mabulous.com (Matthias Buehlmann) Date: Thu, 25 Feb 2021 11:57:25 +0100 Subject: PEM file line size In-Reply-To: References: Message-ID: ?Parsers MAYhandle other line sizes.These requirements are consistent with PEM [RFC1421 ].? It?s not a bug, it?s undefined behaviour. On Wed, 24 Feb 2021 at 20:20 Frank Liu wrote: > Hi, > > I noticed openssl 1.0.1 and 1.0.2 can't read a certificate PEM file with > base64 line size of multiples of 1265. Any other line size seems to be > fine, even though rfc7468 says "exactly 64 characters except for the final > line". > > The same pem file can be read fine with latest openssl 1.1.1j. Does > anybody know the bug or PR when that was fixed? > > Thanks! > Frank > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gfrankliu at gmail.com Thu Feb 25 17:14:25 2021 From: gfrankliu at gmail.com (Frank Liu) Date: Thu, 25 Feb 2021 09:14:25 -0800 Subject: PEM file line size In-Reply-To: References: Message-ID: Hi, Since this is undefined behavior, I guess it was accidentally fixed without a bug or being noticed. BTW, I found this openssl bug and pull request fix , but that only fixed PEM line length of 254 (or a multiple), not 1265. On Thu, Feb 25, 2021 at 2:57 AM Matthias Buehlmann < Matthias.Buehlmann at mabulous.com> wrote: > ?Parsers MAYhandle other line sizes.These requirements are consistent with PEM [RFC1421 ].? > > > It?s not a bug, it?s undefined behaviour. > > On Wed, 24 Feb 2021 at 20:20 Frank Liu wrote: > >> Hi, >> >> I noticed openssl 1.0.1 and 1.0.2 can't read a certificate PEM file with >> base64 line size of multiples of 1265. Any other line size seems to be >> fine, even though rfc7468 says "exactly 64 characters except for the final >> line". >> >> The same pem file can be read fine with latest openssl 1.1.1j. Does >> anybody know the bug or PR when that was fixed? >> >> Thanks! >> Frank >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrobson at zenoss.com Thu Feb 25 17:19:32 2021 From: jrobson at zenoss.com (John Robson) Date: Thu, 25 Feb 2021 17:19:32 +0000 Subject: ASN.1 encoding error Message-ID: Hi all, I'm encountering an error connecting to a device which as far as I can see has a reasonable certificate... The error coming back (through twisted and python) is: > twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding > routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines', > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', > 'tls_process_server_certificate', 'ASN1 lib')] However if I run the following: # openssl s_client -connect : /dev/null | openssl x509 | openssl asn1parse 0:d=0 hl=4 l= 733 cons: SEQUENCE 4:d=1 hl=4 l= 453 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 4 prim: INTEGER :000000 19:d=2 hl=2 l= 13 cons: SEQUENCE 21:d=3 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption ... (continues) ...then OpenSSL seems to handle the whole certificate without problem, the thing that looks "off" to me is the serial number being defined as "000000", rather than "00" (which I see on the self signed certificates from other devices of this type). Is that likely to be causing the issue? It's ~20 years since I last had to deal with ASN.1 properly, so I can't remember if using unnecessarily long representations of integers is actually valid. The raw ASN.1 looks ok I *think* (although I note that it has four bytes specified) "02 04 00 00 00 00" I'm at the point where I might just try to get it to generate a new certificate and see if it does that with a single byte zero (as per the other similar device I've been looking at) Am I completely barking up the wrong tree, is there something else that I can use other than the asn1parse option to figure out where the error might be coming from? Cheers, John -- *John Robson* -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Thu Feb 25 17:28:50 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 25 Feb 2021 09:28:50 -0800 Subject: ASN.1 encoding error In-Reply-To: References: Message-ID: <20210225172850.GK25665@akamai.com> That sounds like the certificate is encoded using ASN.1 BER rules, that openssl accepts, but the python library is insisting on DER encoding (per the spec). -Ben On Thu, Feb 25, 2021 at 05:19:32PM +0000, John Robson via openssl-users wrote: > Hi all, > > I'm encountering an error connecting to a device which as far as I can see > has a reasonable certificate... > > The error coming back (through twisted and python) is: > > > twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding > > routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', > > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines', > > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', > > 'tls_process_server_certificate', 'ASN1 lib')] > > > However if I run the following: > # openssl s_client -connect : /dev/null | openssl > x509 | openssl asn1parse > 0:d=0 hl=4 l= 733 cons: SEQUENCE > 4:d=1 hl=4 l= 453 cons: SEQUENCE > 8:d=2 hl=2 l= 3 cons: cont [ 0 ] > 10:d=3 hl=2 l= 1 prim: INTEGER :02 > 13:d=2 hl=2 l= 4 prim: INTEGER :000000 > 19:d=2 hl=2 l= 13 cons: SEQUENCE > 21:d=3 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption > ... (continues) > > ...then OpenSSL seems to handle the whole certificate without problem, the > thing that looks "off" to me is the serial number being defined as > "000000", rather than "00" (which I see on the self signed certificates > from other devices of this type). > > Is that likely to be causing the issue? It's ~20 years since I last had to > deal with ASN.1 properly, so I can't remember if using unnecessarily long > representations of integers is actually valid. > > The raw ASN.1 looks ok I *think* (although I note that it has four bytes > specified) "02 04 00 00 00 00" > > > I'm at the point where I might just try to get it to generate a new > certificate and see if it does that with a single byte zero (as per the > other similar device I've been looking at) > > Am I completely barking up the wrong tree, is there something else that I > can use other than the asn1parse option to figure out where the error might > be coming from? > > Cheers, > > John > > -- > > *John Robson* From jrobson at zenoss.com Thu Feb 25 17:51:42 2021 From: jrobson at zenoss.com (John Robson) Date: Thu, 25 Feb 2021 17:51:42 +0000 Subject: ASN.1 encoding error In-Reply-To: <20210225172850.GK25665@akamai.com> References: <20210225172850.GK25665@akamai.com> Message-ID: That's plausible - although it would be odd that the other similar device hasn't done the same (i.e. BER vs DER). I think I'm going to get some new certs generated, preferably not on the device itself. At least there is a possible explanation of the difference in behaviour that I am seeing. Thanks, John On Thu, 25 Feb 2021 at 17:29, Benjamin Kaduk wrote: > That sounds like the certificate is encoded using ASN.1 BER rules, that > openssl > accepts, but the python library is insisting on DER encoding (per the > spec). > > -Ben > > On Thu, Feb 25, 2021 at 05:19:32PM +0000, John Robson via openssl-users > wrote: > > Hi all, > > > > I'm encountering an error connecting to a device which as far as I can > see > > has a reasonable certificate... > > > > The error coming back (through twisted and python) is: > > > > > twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding > > > routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', > > > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding > routines', > > > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', > > > 'tls_process_server_certificate', 'ASN1 lib')] > > > > > > However if I run the following: > > # openssl s_client -connect : /dev/null | > openssl > > x509 | openssl asn1parse > > 0:d=0 hl=4 l= 733 cons: SEQUENCE > > 4:d=1 hl=4 l= 453 cons: SEQUENCE > > 8:d=2 hl=2 l= 3 cons: cont [ 0 ] > > 10:d=3 hl=2 l= 1 prim: INTEGER :02 > > 13:d=2 hl=2 l= 4 prim: INTEGER :000000 > > 19:d=2 hl=2 l= 13 cons: SEQUENCE > > 21:d=3 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption > > ... (continues) > > > > ...then OpenSSL seems to handle the whole certificate without problem, > the > > thing that looks "off" to me is the serial number being defined as > > "000000", rather than "00" (which I see on the self signed certificates > > from other devices of this type). > > > > Is that likely to be causing the issue? It's ~20 years since I last had > to > > deal with ASN.1 properly, so I can't remember if using unnecessarily long > > representations of integers is actually valid. > > > > The raw ASN.1 looks ok I *think* (although I note that it has four bytes > > specified) "02 04 00 00 00 00" > > > > > > I'm at the point where I might just try to get it to generate a new > > certificate and see if it does that with a single byte zero (as per the > > other similar device I've been looking at) > > > > Am I completely barking up the wrong tree, is there something else that I > > can use other than the asn1parse option to figure out where the error > might > > be coming from? > > > > Cheers, > > > > John > > > > -- > > > > *John Robson* > -- *John Robson* -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.sylvester at gmail.com Thu Feb 25 18:37:39 2021 From: peter.sylvester at gmail.com (Peter Sylvester) Date: Thu, 25 Feb 2021 19:37:39 +0100 Subject: ASN.1 encoding error In-Reply-To: <20210225172850.GK25665@akamai.com> References: <20210225172850.GK25665@akamai.com> Message-ID: <3265696d-5a6a-fe90-7ec3-4d5743511b7a@gmail.com> Even with sound this would not be BER. i:-) Integers can have 9 or more leading zero bits in BERnot ISO/IEC 8825-1:2008 (E) ITU-T Rec. X.690 (11/2008) 7 8.3 Encoding of an integer value 8.3.1The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets. 8.3.2If? the? contents? octets? of? an? integer? value? encoding consist? of? more? than? one? octet,? then? the? bits? of? the first? octet and bit 8 of the second octet: a)???? shall not all be ones; and b)???? shall not all be zero. NOTE ? These rules ensure that an integer value is always encoded in the smallest possible number of octets. 8.3.3The contents octets shall be a two's complement binary number equal to the integer value, and consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed by bits 8 to 1 of each octet in turn up to and including the last octet of the contents octets. NOTE ? The value of a two's complement binary number is derived by numbering the bits in the contents octets, starting with bit1 of the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of 2N, where? N? is? its? position? in? the? above? numbering? sequence. The? value? of? the? two's? complement? binary? number? is obtained? by? summing the numerical values assigned to each bit for those bits which are set to one, excluding bit 8 of the first octet, and then reducing this value by the numerical value assigned to bit 8 of the first octet if that bit is set to one. On 25/02/2021 18:28, Benjamin Kaduk via openssl-users wrote: > That sounds like the certificate is encoded using ASN.1 BER rules, that openssl > accepts, but the python library is insisting on DER encoding (per the spec). > > -Ben > > On Thu, Feb 25, 2021 at 05:19:32PM +0000, John Robson via openssl-users wrote: >> Hi all, >> >> I'm encountering an error connecting to a device which as far as I can see >> has a reasonable certificate... >> >> The error coming back (through twisted and python) is: >> >>> twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding >>> routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines', >>> 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines', >>> 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines', >>> 'tls_process_server_certificate', 'ASN1 lib')] >> However if I run the following: >> # openssl s_client -connect : /dev/null | openssl >> x509 | openssl asn1parse >> 0:d=0 hl=4 l= 733 cons: SEQUENCE >> 4:d=1 hl=4 l= 453 cons: SEQUENCE >> 8:d=2 hl=2 l= 3 cons: cont [ 0 ] >> 10:d=3 hl=2 l= 1 prim: INTEGER :02 >> 13:d=2 hl=2 l= 4 prim: INTEGER :000000 >> 19:d=2 hl=2 l= 13 cons: SEQUENCE >> 21:d=3 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption >> ... (continues) >> >> ...then OpenSSL seems to handle the whole certificate without problem, the >> thing that looks "off" to me is the serial number being defined as >> "000000", rather than "00" (which I see on the self signed certificates >> from other devices of this type). >> >> Is that likely to be causing the issue? It's ~20 years since I last had to >> deal with ASN.1 properly, so I can't remember if using unnecessarily long >> representations of integers is actually valid. >> >> The raw ASN.1 looks ok I *think* (although I note that it has four bytes >> specified) "02 04 00 00 00 00" >> >> >> I'm at the point where I might just try to get it to generate a new >> certificate and see if it does that with a single byte zero (as per the >> other similar device I've been looking at) >> >> Am I completely barking up the wrong tree, is there something else that I >> can use other than the asn1parse option to figure out where the error might >> be coming from? >> >> Cheers, >> >> John >> >> -- >> >> *John Robson* From gfrankliu at gmail.com Thu Feb 25 23:30:43 2021 From: gfrankliu at gmail.com (Frank Liu) Date: Thu, 25 Feb 2021 15:30:43 -0800 Subject: PEM file line size In-Reply-To: References: Message-ID: Looking at test cases https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/test/recipes/04-test_pem.t , openssl indeed is a parser that can handle other line sizes than 64 chars. If we were to strictly follow RFC, shouldn't we error out none 64 line size (except last line which could be equal or less than 64)? Leaving it "undefined behavior" would invite issues. On Thu, Feb 25, 2021 at 2:57 AM Matthias Buehlmann < Matthias.Buehlmann at mabulous.com> wrote: > ?Parsers MAYhandle other line sizes.These requirements are consistent with PEM [RFC1421 ].? > > > It?s not a bug, it?s undefined behaviour. > > On Wed, 24 Feb 2021 at 20:20 Frank Liu wrote: > >> Hi, >> >> I noticed openssl 1.0.1 and 1.0.2 can't read a certificate PEM file with >> base64 line size of multiples of 1265. Any other line size seems to be >> fine, even though rfc7468 says "exactly 64 characters except for the final >> line". >> >> The same pem file can be read fine with latest openssl 1.1.1j. Does >> anybody know the bug or PR when that was fixed? >> >> Thanks! >> Frank >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Fri Feb 26 00:02:19 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 25 Feb 2021 16:02:19 -0800 Subject: PEM file line size In-Reply-To: References: Message-ID: <20210226000219.GL25665@akamai.com> On Thu, Feb 25, 2021 at 03:30:43PM -0800, Frank Liu wrote: > Looking at test cases > https://urldefense.com/v3/__https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/test/recipes/04-test_pem.t__;!!GjvTz_vk!A42D2c2brOwptas6T1iBt9i7pMWhwehkKAmeCuILgR-6iv5n0TQPQ6tkkVgG9A$ > , openssl indeed is a parser that can handle other line sizes than 64 > chars. If we were to strictly follow RFC, shouldn't we error out none 64 > line size (except last line which could be equal or less than 64)? Leaving > it "undefined behavior" would invite issues. If you read RFC 1421 carefully (the ABNF, and the first line of Section 4.3.2.4), the 64 characters per line limitation only applies for encrypted (or MIC-ONLY) messages. Other messages can use arbitrary length lines for base64 content. -Ben From michal.sledz at swmansion.com Fri Feb 26 13:20:07 2021 From: michal.sledz at swmansion.com (Michal Sledz) Date: Fri, 26 Feb 2021 14:20:07 +0100 Subject: Passing the same data to SSL_do_handshake multiple times Message-ID: Hi, I am trying to perform DTLS handshake with web browsers. At this moment connecting with Firefox works well but I have a small problem with Google Chrome. The flow is as follows. Chrome sends ClientHello My server receives ClientHello and passes it to SSL_do_handshake. SSL_do_handshake generates ServerHello. I try to send ServerHello but because I use ICE my connection is not ready to send yet and the process fails. Chrome doesn't see a response for its ClientHello so it performs retransmission of ClientHello. My server receives retransmitted ClientHello and passes it to SSL_do_handshake. In the meantime ICE is ready to send messages to Chrome. SSL_do_handshake receives retransmitted ClientHello but this time it doesn't generate ServerHello. The situation continues to happen and finally after passing ClientHello for the 3rd or 4th time SSL_do_handshake generates once again ServerHello which now I can send to Chrome. My question is: should I cache the ServerHello generated at first time and then after receiving retransmission of ClientHello just send cached ServerHello or I should pass retransmitted ClientHello to SSL_do_handshake (as I am doing it now) and hope it will generate ServerHello once again? Is it expected behaviour that SSL_do_handshake after receiving exactly the same ClientHello doesn't generate ServerHello once again? Best regards, Micha? -------------- next part -------------- An HTML attachment was scrubbed... URL: