From jgh at wizmail.org Sun Nov 10 21:45:21 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 10 Nov 2019 20:45:21 +0000 Subject: [gnutls-help] full-chain ocsp stapling Message-ID: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org> GnuTLS 3.6.8 I'm testing $subject using a 3-layer cert chain, and stapled ocsp under TLS1.3 for which the middle item is non-valid. The client reports (using gnutls_ocsp_resp_print()) :- 20:23:20 18349 OCSP Response Information: 20:23:20 18349 Response Status: Successful 20:23:20 18349 Response Type: Basic OCSP Response 20:23:20 18349 Version: 1 20:23:20 18349 Responder ID: CN=clica CA rsa,O=example.com 20:23:20 18349 Produced At: Sun Nov 10 20:09:14 UTC 2019 20:23:20 18349 Responses: 20:23:20 18349 Certificate ID: 20:23:20 18349 Hash Algorithm: SHA256 20:23:20 18349 Issuer Name Hash: 5af082e51d62fe01fd706baebeb878db64e68f76e74a36f36d914297ddee24b8 20:23:20 18349 Issuer Key Hash: 333db14364b98e78a33dd8a4fae8d8378ea9b0f5fbca97b25685aa0d32116091 20:23:20 18349 Serial Number: 65 20:23:20 18349 Certificate Status: good 20:23:20 18349 This Update: Sun Nov 10 20:09:14 UTC 2019 20:23:20 18349 Next Update: Fri Nov 09 20:09:14 UTC 2029 20:23:20 18349 Certificate ID: 20:23:20 18349 Hash Algorithm: SHA256 20:23:20 18349 Issuer Name Hash: bfa7275a566efd4be2df82dbd9d1290d470186f6ff2acd8c16659f342ab56109 20:23:20 18349 Issuer Key Hash: 208f9d28c7c0bc914144dfa8c0be3d5b3bfcebb622c8a8dc27e865fc06ca0e12 20:23:20 18349 Serial Number: 42 20:23:20 18349 Certificate Status: revoked 20:23:20 18349 Revocation time: Mon Feb 01 14:27:09 UTC 2010 20:23:20 18349 This Update: Sun Nov 10 20:09:14 UTC 2019 20:23:20 18349 Next Update: Fri Nov 09 20:09:14 UTC 2029 20:23:20 18349 Certificate ID: 20:23:20 18349 Hash Algorithm: SHA256 20:23:20 18349 Issuer Name Hash: bfa7275a566efd4be2df82dbd9d1290d470186f6ff2acd8c16659f342ab56109 20:23:20 18349 Issuer Key Hash: 208f9d28c7c0bc914144dfa8c0be3d5b3bfcebb622c8a8dc27e865fc06ca0e12 20:23:20 18349 Certificate Status: good 20:23:20 18349 This Update: Sun Nov 10 20:09:14 UTC 2019 20:23:20 18349 Next Update: Fri Nov 09 20:09:14 UTC 2029 20:23:20 18349 Extensions: 20:23:20 18349 Signature Algorithm: RSA-SHA256 but gnutls_ocsp_status_request_is_checked(state->session, 0) returns nonzero (meaning "valid"). I'm not quite clear what level of validity is being described here. Should it be checking that the OCSP response indicates non-revoked certificates, for all cert-chain elements covered? Or is it only saying that the stapled information is well-constructed and signed (meaning that I should be taking more actions to validate the certs; if so, what)? -- Thanks, Jeremy From jgh at wizmail.org Sun Nov 10 22:48:09 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 10 Nov 2019 21:48:09 +0000 Subject: [gnutls-help] full-chain ocsp stapling In-Reply-To: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org> References: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org> Message-ID: <7c2fb02b-8194-b0d7-f3e9-cd675fd3e955@wizmail.org> On 10/11/2019 20:45, Jeremy Harris wrote: > GnuTLS 3.6.8 > > I'm testing $subject using a 3-layer cert chain, and stapled ocsp > under TLS1.3 for which the middle item is non-valid. (followup to myself...) I note that https://www.gnutls.org/manual/html_node/OCSP-stapling.html suggests cat'ing multiple ocsp respose PEMs. While GnuTLS is happy with that, it's not what I am doing since it results in a TLS wire-format which is incompatible with OpenSSL (and, I think, RFCs). The result of a file with several PEMs is (speaking from memory of wireshark sessions...) a Server Hello with a Certificates record having certificates interleaved with cert-status extensions. If you instead create an OCSP request for all the certs of the chain, and then an OCSP response from that, you get one "basicresponse" containing multiple "status" elements, all in one DER (or PEM). Either GnuTLS or OpenSSL is happy to swallow that on the server, and the wire format has a single "status" extension, placed between the first and second certificates, in the Server Hello. OpenSSL is happy with that wire format as the client. I'm wondering if GnuTLS, when validating certs, is not properly interpreting the multi-element basicresponse. -- Cheers, Jeremy From bshanks at codeweavers.com Fri Nov 22 02:36:03 2019 From: bshanks at codeweavers.com (Brendan Shanks) Date: Thu, 21 Nov 2019 17:36:03 -0800 Subject: [gnutls-help] Generating DH key pair with given parameters Message-ID: Hi everyone, The Wine project currently uses GnuTLS to implement the Windows bcrypt/CNG library. I?ve been looking at adding DH support but have had trouble finding the right APIs to use in GnuTLS. Does GnuTLS have a public API for generating a public/private key pair given a set of DH parameters (prime/generator)? Something equivalent to OpenSSL's DH_generate_key()? It seems like _gnutls_pk_generate_keys() is what I want to use, but I don?t see any public API that will call that with provided DH parameters. For example I can?t see any way to provide a gnutls_dh_params_t to gnutls_x509_privkey_generate2(), it always calls _gnutls_pk_generate_params() to generate new parameters. The kind of bcrypt API usage I?m looking to support is similar to this Windows sample code: >. Generate a public/private key pair with provided DH parameters, then export the key, import a different key, etc. Thanks for any advice, Brendan Shanks CodeWeavers -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Sat Nov 23 07:08:57 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 23 Nov 2019 07:08:57 +0100 Subject: [gnutls-help] Generating DH key pair with given parameters In-Reply-To: References: Message-ID: Hi, That's not an API exported operation. Diffie-Hellman is handled internally. The reason was that there was not much need for exporting as a supported API. What we have is APIs for testing this operation; which are: _gnutls_dh_compute_key; _gnutls_dh_generate_key; _gnutls_ecdh_generate_key; _gnutls_ecdh_compute_key; (and defined in lib/nettle/pk.c) If that's sufficient for your use-cases would you like to propose them (preferrably with an MR, or alternatively with opening an issue) to be exported in the normal APIs? You could use them even today, but unless we promote them to supported API they may break. regards, Nikos On Fri, Nov 22, 2019 at 2:37 AM Brendan Shanks wrote: > > Hi everyone, > > The Wine project currently uses GnuTLS to implement the Windows bcrypt/CNG library. I?ve been looking at adding DH support but have had trouble finding the right APIs to use in GnuTLS. > > Does GnuTLS have a public API for generating a public/private key pair given a set of DH parameters (prime/generator)? Something equivalent to OpenSSL's DH_generate_key()? > It seems like _gnutls_pk_generate_keys() is what I want to use, but I don?t see any public API that will call that with provided DH parameters. For example I can?t see any way to provide a gnutls_dh_params_t to gnutls_x509_privkey_generate2(), it always calls _gnutls_pk_generate_params() to generate new parameters. > > The kind of bcrypt API usage I?m looking to support is similar to this Windows sample code: . Generate a public/private key pair with provided DH parameters, then export the key, import a different key, etc. > > > Thanks for any advice, > > Brendan Shanks > CodeWeavers > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From jgh at wizmail.org Sun Nov 24 18:43:48 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 24 Nov 2019 17:43:48 +0000 Subject: [gnutls-help] full-chain ocsp stapling In-Reply-To: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org> References: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org> Message-ID: <7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org> On 10/11/2019 20:45, Jeremy Harris wrote: > GnuTLS 3.6.8 > > I'm testing $subject using a 3-layer cert chain, and stapled ocsp > under TLS1.3 for which the middle item is non-valid. ... > but gnutls_ocsp_status_request_is_checked(state->session, 0) returns > nonzero (meaning "valid"). > > I'm not quite clear what level of validity is being described here. > Should it be checking that the OCSP response indicates non-revoked > certificates, for all cert-chain elements covered? Or is it only > saying that the stapled information is well-constructed and signed > (meaning that I should be taking more actions to validate the > certs; if so, what)? No answers on this? -- Cheers, Jeremy