Ian,
Thanks for this info, very interesting to see deployment experience for
successful client PK key pairs.
ianG wrote:
On 27/04/12 03:34 AM, Thierry Moreau wrote:
Here is the rationale for the question:
If an end-user has a certificate, he (more or less consciously) controls
a private key. Suppose one deploys a web server that cares *only* about
end-user public keys, e.g. it keeps track of end-user reputation and
that's it for trust management. Then any type of certificate is good
enough (self-signed, auto-issued, issued by a regular
"client-cert-issuing CA").
Yes, this is what I do with a site of mine. Anyone with a client-cert
can connect and play. That's it. You can read some sort of intro about
the background here:
http://wiki.cacert.org/Technology/KnowledgeBase/ClientCerts/theOldNewThing
But what we lack is a how-to of all the decisions.
The how-to guide is not needed for me, I figured out the (beta) Apache
server configuration in the internal proof of concept for similar thing.
This web server can have an immediate potential user base if it
negotiates the TLS session with a long list of CA distinguished names
(in the CertificateRequest message).
ah. In my work, I have discovered that it is far better to turn off all
decision making in the TLS/apache side, to simply set the cert request
to optional and pass the result in variables to the application.
SSLVerifyClient optional
SSLOptions +StdEnvVars +FakeBasicAuth +ExportCertData
SSLUserName SSL_CLIENT_S_DN_Email
Well, hum, I must confess something that might look like
"not-invented-here" syndrome, but I got rid of the apache server altogether.
The system model is TLS-protected-web-server in an HSM (derived from the
web-server-in-embedded-system and the more classical HSM).
Security assurance is obtained by having
*only*the*required*software*logic* in the system boundary (e.g. not
losing sleep with protocol downgrade attacks).
There are other rationales/excuses for getting rid of apache, but they
are out of scope in this list.
Then, in the application code, read all the cert variables and make an
application level decision.
My application model is a little different. Mine is not a CA context,
and "all the cert variables" reduces to *only* the client public key.
The management tools for the contemplated web server scheme would
include an issuer DN extraction utility from end-user or CA certificates
so that the list may be augmented based on casual observations. Also,
the SSL debugging tools will report the contents of CertificateRequest
messages from public servers supporting client certs.
Anyone went through such data collection before?
Well, to the extent above. My db has a table for all certs, and a table
for all users, with a join by cert identifiers between the two tables.
As you may infer from the above, my join (or equivalent in the ID
management database schema) is on the client public key.
Again, thanks for sharing this and best regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
