async OCSP over DTLS RE: gnutls 3.0.10
Peter Williams
home_pw at msn.com
Sat Feb 18 15:46:33 CET 2012
has anyone considered doing asynch ocsp (over DTLS...).
Ie there are two class of connectionless channel, one of which (over which layer-7-unsigned OCSP itself passes) acts as an authorizer for tge completion of the other.
The IETF spec reallly doesnt capture the original art of what becmae OCSP. Originally, a nightly job pre-signed lots of daily status messages (almost acting as a 1 line CRL). This was then replicated, much like a DNS zone. SSL endpoints then used an access protocol to access the replicant of the zone, and would ping it for the certificate status bit of a given keyed cert. If there was trust (e.g. an DTLS channel) between certificate-using system and replicant (and the asusmption the replicant had authenticated each signed status message during repliction, or their replicator's source endpoint in a further act of trusting).
Another variant had replicants sending CRLs around to distribution points... the "last" of which creates a pool of individuall signed OCSP rsponse, ready to be quickly delivered over access protocols.
what folks were not supposed to do was ping a online status responder, doing real time layer-7 signing. That was always deemed a crypto no-no for RSA (but this is what folks do).
One can play with a large DTLS sesssion cache - where each sessionid is a surrogate for a cert's status.
More information about the Gnutls-devel
mailing list