From thomas2.klute at uni-dortmund.de Mon Dec 4 22:34:53 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Mon, 4 Dec 2017 22:34:53 +0100 Subject: [gnutls-devel] Fwd: support of stapled OCSP responses under TLS1.3 In-Reply-To: References: Message-ID: <11489cb3-b623-f0c1-0268-e16a56f1506b@uni-dortmund.de> Am 29.11.2017 um 13:56 schrieb Nikos Mavrogiannopoulos: > On Tue, Nov 28, 2017 at 7:53 AM, Thomas Klute > wrote: >> Am 27.11.2017 um 14:35 schrieb Nikos Mavrogiannopoulos: >>>> 2) The certificate is passed to the callback as a gnutls_pcert_st. I'd >>>> need to call gnutls_pcert_export_x509 during each run of the callback to >>>> get a gnutls_x509_crt_t and access things like fingerprint (used for the >>>> cache key) or OCSP responder URL. I'm not sure if that might hurt >>>> performance. >>> >>> If you are storing the certificate as a gnutls_pcert_st internally, >>> I'd also store the OCSP response in the same structure. E.g. >>> struct int_store_st { >>> gnutls_pcert_st *certs[]; >>> gnutls_datum_t ocsp_responses[]; >>> } >>> >>> where each response corresponds to each cert. When the callback from >>> gnutls_certificate_set_ocsp_status_request_function3 is set, you'll >>> get a gnutls_cert_info_st which has an index indicating the positioni >>> n the chain the OCSP is asked for. With such a setup no additional >>> parsing will be required. If I misread what you were describing, >>> please let me know. >> >> I was referring to how I might use the new API, not the current >> implementation. The current mod_gnutls implementation keeps certificate >> chains as both gnutls_pcert_st and gnutls_x509_crt_t arrays, and the >> OCSP responses in a key/value cache. > > So is the existing information sufficient to figure the key, or is > there something else we should add in gnutls_cert_info_st? I think it's sufficient for any static chains case, and for the retrieve callback case as long as the right certificate chain is obvious (one per virtual host). Otherwise I'd have to implement some way to find the right chain based on the gnutls_pcert_st, but that might be a non-issue as far as mod_gnutls is concerned (see below). However, I think a gnutls_x509_crt_t* instead of (or in addition to) the gnutls_pcert_st* would make it more convenient to access needed certificate information (e.g. using gnutls_x509_crt_get_authority_info_access). Of course that only makes sense if that certificate structure already exists internally, not if it'd have to be created on each call. >> Another approach could be to add a certificate retrieve callback type >> that can return OCSP responses along with selected certificates, but >> that's also fairly complex. > > That could also be. I think the main reason a separate callback was > used for the multiple OCSP responses is because there was already such > a callback in place. Would that approach be simpler for mod_gnutls? I think that would be easier to implement, yes. The retrieve callback must find the right certificate chain anyway, and at that point it already has all the information needed to get the matching OCSP response(s) too. On the other hand, after looking at the mod_gnutls code again I think I should be able to switch from a retrieve callback to static certificate chains as soon as I get around to removing all code for PGP authentication. That would also make it much easier to add support for multiple X.509 certificate chains per virtual host (e.g. to support both RSA and ECDSA authentication). Side question about that: Is it safe to assume that when adding multiple certificate chains to one gnutls_certificate_credentials_t their indices will be array indices in the order they are added? By the way, another thing that would be a simplification and performance optimization for mod_gnutls: Let applications configure GnuTLS to *not* call gnutls_free() on the returned buffer, e.g. with a flag for gnutls_certificate_set_ocsp_status_request_function3(). The APR cache retrieve functions allocate memory for OCSP responses from a memory pool bound to the connection lifetime, so having to return memory allocated with gnutls_malloc() requires an extra memory copy. Best regards, Thomas From n.mavrogiannopoulos at gmail.com Fri Dec 8 17:43:11 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 8 Dec 2017 17:43:11 +0100 Subject: [gnutls-devel] Fwd: support of stapled OCSP responses under TLS1.3 In-Reply-To: <11489cb3-b623-f0c1-0268-e16a56f1506b@uni-dortmund.de> References: <11489cb3-b623-f0c1-0268-e16a56f1506b@uni-dortmund.de> Message-ID: On Mon, Dec 4, 2017 at 10:34 PM, Thomas Klute wrote: >>> I was referring to how I might use the new API, not the current >>> implementation. The current mod_gnutls implementation keeps certificate >>> chains as both gnutls_pcert_st and gnutls_x509_crt_t arrays, and the >>> OCSP responses in a key/value cache. >> >> So is the existing information sufficient to figure the key, or is >> there something else we should add in gnutls_cert_info_st? > > I think it's sufficient for any static chains case, and for the retrieve > callback case as long as the right certificate chain is obvious (one per > virtual host). Otherwise I'd have to implement some way to find the > right chain based on the gnutls_pcert_st, but that might be a non-issue > as far as mod_gnutls is concerned (see below). > > However, I think a gnutls_x509_crt_t* instead of (or in addition to) the > gnutls_pcert_st* would make it more convenient to access needed > certificate information (e.g. using > gnutls_x509_crt_get_authority_info_access). Of course that only makes > sense if that certificate structure already exists internally, not if > it'd have to be created on each call. > >>> Another approach could be to add a certificate retrieve callback type >>> that can return OCSP responses along with selected certificates, but >>> that's also fairly complex. >> >> That could also be. I think the main reason a separate callback was >> used for the multiple OCSP responses is because there was already such >> a callback in place. Would that approach be simpler for mod_gnutls? > > I think that would be easier to implement, yes. The retrieve callback > must find the right certificate chain anyway, and at that point it > already has all the information needed to get the matching OCSP > response(s) too. I've made a 3rd attempt at (still in progress): https://gitlab.com/gnutls/gnutls/merge_requests/566 which introduces an new callback for setting certificate + OCSP responses. > On the other hand, after looking at the mod_gnutls code again I think I > should be able to switch from a retrieve callback to static certificate > chains as soon as I get around to removing all code for PGP > authentication. That would also make it much easier to add support for > multiple X.509 certificate chains per virtual host (e.g. to support both > RSA and ECDSA authentication). Side question about that: Is it safe to > assume that when adding multiple certificate chains to one > gnutls_certificate_credentials_t their indices will be array indices in > the order they are added? Don't do that. You can get the indexes from the certificate set functions. You only need to set the flag GNUTLS_CERTIFICATE_API_V2 with gnutls_certificate_set_flags. > By the way, another thing that would be a simplification and performance > optimization for mod_gnutls: Let applications configure GnuTLS to *not* > call gnutls_free() on the returned buffer, e.g. with a flag for > gnutls_certificate_set_ocsp_status_request_function3(). The APR cache > retrieve functions allocate memory for OCSP responses from a memory pool > bound to the connection lifetime, so having to return memory allocated > with gnutls_malloc() requires an extra memory copy. Good idea. The new callback set with gnutls_certificate_set_retrieve_function3 allows that. I need to test it more thoroughly though. regards, Nikos From n.mavrogiannopoulos at gmail.com Thu Dec 21 14:45:19 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 21 Dec 2017 14:45:19 +0100 Subject: [gnutls-devel] update on TLS1.3 effort Message-ID: Hi, A short status update on the TLS 1.3 effort. At this point, we have a resonably functioning branch 'tmp-draft-ietf-tls-tls13-21' which as its name indicates implements draft-ietf-tls-tls13-21. The major missing feature is now session resumption. Once that is complete, the plan is to merge to master (without enabling the protocol by default), and then plan to include support for the latest draft. I've moved optional items to another milestone ([1]). Hopefully the TLS WG doesn't make that into some kind of sisyphian task. You can find more detailed information on the progress on gitlab [0]. regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/milestones/8 [1]. https://gitlab.com/gnutls/gnutls/milestones/13