On Fri, 31 Mar 2017 13:03:44 -0700 William Ahern <[email protected]> wrote: > On Thu, Mar 30, 2017 at 10:31:06PM +1030, Jack Burton wrote: > <snip> > > Personally, I'm leaning towards either local CRL file checking in > > httpd (with minimal changes to libtls), or passing through enough > > data to the let the fastcgi responders take whichever approach they > > want. <...> > My $0.02: client certificates aren't particularly useful unless the > certificate itself is made available to the application. Knowing that > a certificate has a valid signature is only part of the equation, and > not even the most useful part. Unlike server certificates, however, > there's no single authorization check (i.e. matching the embedded > domain name to the queried URL) that can be implemented by > middle-ware. The semantics of embedded data are specific to a service > and often ad hoc. > > Basically, anything short of passing through the entire certificate > is going to be severely limiting and frustrating, to the point of > uselessness. And as a practical matter, parsing out and passing > through a subset of certificate data is likely going to require more > complex code than just passing the entire certificate to the > application.
Thanks William. That's an interesting idea. Yes, I can see how having the raw client certificate available to fastcgi responders would be useful. That would solve a few more problems for my use case too and would provide the ultimate in flexibility. And it's not difficult to implement. My initial gut feeling was that adding a tls_peer_serial() function to libtls would be less intrusive (and more in keeping with the rest of the tls_peer_* functions) than adding a tls_peer_cert() along the lines you're suggesting. But on reflection, adding a tls_peer_cert() would drastically reduce the likelihood of needing to add anything else to the tls_peer_* family again in future -- which I'd think would be a big advantage. Given your point about needing to access the whole cert (I assume by that you mean you're using some of the less common x509 extensions) for authorisation (cf. just authentication), it may well be worth doing that *regardless* of whether or not any common approach to revocation status checking gets added that far down the stack. Unless there are any better ideas in the meantime (or someone else does it first), I'll propose a diff that does just that towards the end of next week (sorry, will travelling for the next few days & probably won't have time to site down & write it until then).
