I've got the x509 objects being parsed out of the certificate message,
and am starting down how to expose x509 certificates to the API. My
goal right now is to prevent exposure of the OpenSSL X509* type to the
users of Selene.
The most obvious use case is for validating a server certificate chain.
I've stubbed out a header with what I think the API should be like for
inspecting a single certificate:
<https://github.com/pquerna/selene/blob/master/include/selene_cert.h>
(Astute readers will notice that this is similiar to the certificate
API that Serf has.)
My question is, does this expose enough information? Is there ever a
reason to expose more?
Specifically I'd be interested in seeing what other fields are used in
validating Client Certificates?
I think i'll probably need to add fields for CRL / OCSP locations too,
but OCSP is a whole different beast of an API challenge that I'm not
quite willing to bit off yet.
Thanks,
Paul
Hallelujah.
>
> The most obvious use case is for validating a server certificate chain.
>
> I've stubbed out a header with what I think the API should be like for
> inspecting a single certificate:
> <https://github.com/pquerna/selene/blob/master/include/selene_cert.h>
>
> (Astute readers will notice that this is similiar to the certificate
> API that Serf has.)
>
> My question is, does this expose enough information? Is there ever a
> reason to expose more?
If you expose the same amount as serf, then I think you'll be fine. I
mean... if it's enough for Subversion, then it is probably enough for
any client application.
Can selene be used on the server side? Are there separate APIs needed
for verifying client certificates, or would this API be sufficient?
I might also suggest looking at Neon's certificate handling. It is
possible that Neon/ra_neon have some capabilities that we have
missed/forgotten to incorporate into serf/ra_serf.
> Specifically I'd be interested in seeing what other fields are used in
> validating Client Certificates?
Ah. You already asked the question :-P ... and I have no idea. Maybe
you can crawl through httpd's mod_ssl to look for its client cert
handling?
>...
Cheers,
-g
The problem with mod_ssl as an example, is the SSLRequires directive:
<http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslrequire>
Which is basically a DSL that lets you access any attribute of the
certificate :(
I guess the table under "SSL-related variables", does limit it, most
are just subject/issuers, but obvious missing ones are the serial,
algorithm, and version, which is a pretty short list to expand the API
with.
Thanks,
Paul