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