[rabbitmq-discuss] rabbitmq_auth_mechanism_ssl limitations

[James Casey]

On 12 July 2011 17:42, Simon MacMullen <simon at rabbitmq.com> wrote:
> On 12/07/11 16:33, Massimo Paladin wrote:
>>
>> Will this take part of the next release?
>
> I doubt it, nothing has been done.
>
> This is something Matthias and I have been arguing about for ages. I suspect
> that even though just RFC 4514-serialising the DN and doing string matching
> is completely wrong in theory, in practice it would be what a decent number
> of users would want. Matthias thinks that it will lead into a tarpit of bugs
> around DN equivalence. And I have to admit that he has much more real world
> experience dealing with stupid SSL / x509 behaviour than I do!
>
> But neither of us really know. Hearing from people like you who want this
> would be helpful:
>
> * If you have many CAs, is that just a bunch of internal sysadmins running
> Openssl or real-world CAs?
>

I think one of the big use-cases which needs multiple CA support (and
the one that Massimo at CERN in fact has) are the various academic
Grid infrastructures which inherited X509 from Globus.  Here there are
multiple CAs (one per country usually) which all control different
parts of the DN namespace. The CAs collaborate via ta global body, the
IGTF (http://www.igtf.net/) on common policies.  For instance for any
CA there is a signing policy distributed which defines the allowed
subtrees of certificates signed by that CA - therefore if you're only
using certificates from IGTF CAs you should never run into any DN
collisions.

> * If you had to update usernames when a user had a new certificate and the
> DN format changed for some daft reason, how big a deal would that be?

Again, in the case CERN has there is a layer of membership services on
top of the CAs so you can map multiple DNs over time to some sort of
unique principal.   Also you can query the membership services for a
list of valid DNs and groups that they belong to - in the ActiveMQ
case this is then used to seed the JAAS authentication provider.

So in this case a lot of the issues have been sort of solved  - it's
often not pretty but it has been working in production for many years
now.  this is clearly a much more constrained problem that the general
case of X509 support in Rabbit.

cheers,

James.
--
>
> etc etc...
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, VMware
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>