[gnutls-devel] OCSP / gnutls_ocsp_status_request_is_checked()

Tim Ruehsen tim.ruehsen at gmx.de
Mon Jan 19 17:06:46 CET 2015


On Monday 19 January 2015 15:49:24 Nikos Mavrogiannopoulos wrote:
> On Mon, Jan 19, 2015 at 2:36 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Hi,
> > 
> > for caching and user information purposes I would like to see
> > gnutls_ocsp_status_request_is_checked() (or a new function, see below)
> > return three states:
> > 
> > 1. no stapled OCSP response
> > 2. cert is valid
> > 3. cert has been revoked
> 
> Note that (2) and (3) you get already during the
> certificate_verify_peers() process. The
> gnutls_ocsp_status_request_is_checked() is to check for informative
> purposes whether the stapled OCSP response was taken into account in
> the certification. Since this gnutls_ocsp_status_request_is_checked()
> accepts flags, we could add a flag to modify its semantics if you
> think that some information is not yet available.

Ahh, thanks.
I didn't realize that GNUTLS_CERT_REVOKED is set via OCSP stapling.
Just tested it - works fine !
That is what I needed.

> > Since we have to check the whole cert chain (you already mentioned rfc
> > 6961), I suggest a new function that returns an array of result codes,
> > one for each cert in the chain. Similar to
> > gnutls_certificate_get_peers(). Each result code with e.g. Notavail,
> > Valid or Revoked.
> > This approach would work with the current state (one stapled response) and
> > with future implementations of rfc 6961 (without it, OCSP stapling seems
> > totally incomplete).
> > Maybe it's time to contact the Apache and Nginx people to think about rfc
> > 6961?
> 
> Well, I guess so. I've put in ocsp2 branch my experimental patch for
> gnutls supporting that:
> https://gitorious.org/gnutls/gnutls/commit/f24c5cdb73cf0e10cfe90d28e564e780b
> 36c0142 It most probably doesn't apply as it now, and will require some tool
> support (to combine the multiple ocsp responses into a file). Not sure if
> I'll have time to complete it sometime soon.

Apache is aware of the problem that RFC6961 addresses and mentions it the the 
docs. But it seems not implemented yet, neither in nginx.

Ivan Ristic says in his book (http://blog.ivanristic.com/2014/02/bulletproof-early-access-now-available.html): "... this improved version is not well 
supported in either client or server software"

I found a few posts from people requesting and/or waiting for multi-stapling 
to come.

Sounds like a hen/egg problem to me.
Since many web sites nowadays use intermediate CA certs, multi-stapling will 
have the same benefits as the introduction of OCSP stapling.

I don't quite understand "will require some tool support". How can I help ?
Let gnutls-cli use the ocsp2 code (e.g. new option --ocsp-multi) ?

With this, the apache and nginx people have a tool for testing and might start 
implementing multi-stapling on the server side.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150119/159c5499/attachment.sig>


More information about the Gnutls-devel mailing list