On 09/10/2009 04:41 AM, Sam Laidler wrote:
Hi, hope all is well.
I'd like to make a variety of connections within the same application
-- one acting as server the other as client. I would like to be able
to use one list of trusted CA certificates for one connection, but a
different list for the other. Having read the documentation, I'm not
sure how (or if) I can do this.
This sounds less like different trust lists and more like different
trust purposes.
If you are handshaking as both the client and the server, then you are
trusting certificates for different purposes. Clients need to trust
certs for ssl server auth and servers need to trust certs for SSL client
auth. These are two separate trust bits in a single database.
My first plan was to create separate databases. However, the
initialisation command is not idempotent.
I then looked at the API. The closest command I could find to what I
need was SSL_AuthCertificate(), but it only accepts the certificate
database handle, it does not allow you to select a subset of CA
certificates you want to use in authentication.
Currently we have no public way to create a new trust domain other than
the default trust domain. This is a feature we wanted to add for a
number of years, but we have never really had the customer justification
for doing so (who would use it if we had it). It sounds like your case
is probably more easily solved using the proper trust bit settings
already included in NSS.
That being said, if someone provided a well written patch to build up
their own trust domains (the internal primitives are there in NSS), I
would probably look favorably toward such a patch.
My one worry it the potential for abuse. Application writers often try
to solve pki privilege problems by creating multiple cert hierarchic. In
practice what you really want is a single cert hierarchy with policy and
attributes on the certs themselves. Managing multiple trees becomes a
burden on users and administrators, so while it's probably the easiest
module to think about as an application writer, it's much harder on the
end product (especially if you have multiple applications and libraries,
each using this trick). So far all the uses I've heard propose for this
feature fall into this category.
I'm beginning to think my only options (without lower level hacking)
are to either split the application into separate executables, or live
with the fact that the same CA list will be used in authenticating ALL
connections.
In general, if you think about what SSL *means*, this is correct. SSL
authenticates that the user on the other end is who they say they
are.... not if they have the particular privilege to do a particular
operation (that is the machine I made and SSL connection is XYZ -- it's
up to me to know if XYZ is an appropriate http, mail or ldap server). It
does make sense to separate the privilege of authenticating servers and
users, which NSS does with the trust bits (NSS supports 4 types of
Authentication: Object Signing, Email, SSL Server, and SSL Client -- In
any NSS supplied default the latter is never sent).
Ideally your application will want to map the SSL client cert to some
access list to determine if that particular user has the appropriate
privilege. (It's probably not a good idea to just trust the fact the
client has a cert from a given CA for this).
I would be most grateful if someone could please confirm whether I'm
right in thinking that or (if not) some other means.
Thank you and best regards,
*Sam Laidler*
Software Engineer
direct +44 (0)1252 644 207
email samuel.laid...@the-logic-group.com
<mailto:samuel.laid...@the-logic-group.com>
<http://www.the-logic-group.com/>
The Logic Group Enterprises Limited, Logic House, Waterfront Business
Park, Fleet Road, Fleet,
Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered
No. 2609323
The information in this email and any attachments are confidential and
may be legally privileged and protected by law. It is for the intended
recipient only. If you are not the intended recipient you may not use,
disclose, copy, distribute, print or rely on the content of this email
or its attachments. If this email has been received by you in error
please advise the sender and delete the email from your system.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
