[rabbitmq-discuss] rabbitmq_auth_mechanism_ssl limitations

[Massimo Paladin]

Will this take part of the next release?

Regards,
---
Massimo Paladin

email: massimo.paladin at gmail.com
website: http://www.mpaladin.com
flickr's page: http://flickr.com/photos/massimop



On Thu, Jul 7, 2011 at 7:26 PM, Matthias Radestock
<matthias at rabbitmq.com> wrote:
> Massimo,
>
> On 07/07/11 17:17, Massimo Paladin wrote:
>>
>> Matthias, would you say there is no way to get this right?
>
> I don't know. It's a tricky problem.
>
>> In any case I think this implementation is not very useful since it
>> takes one CN (which one if multiple?) as username and limit to only
>> one CA signed certificates.
>
> The current implementation does not permit multi-valued CNs. I don't
> remember whether the x509 RFCs permit them.
>
> We could just forget about ASN.1/x509's obscure notions of equivalence and
> convert the DNs to strings according to RFC 4514. That will be ok as long as
> users always present exactly the same certificate and whoever provisions the
> rabbit auth db can get hold of the certificates or the RFC 4514
> presentations of their subject DNs.
>
> In practice that would probably also work in many cases where users present
> multiple certs containing the same logical subject DN. But there is no
> guarantee of that since it is possible for, say, two CAs to issue certs for
> the same subject DN but construct the underlying ASN.1 differently such that
> an RFC4514 conversion to string produces different results. Or even for the
> same CA to do that when a cert is renewed.
>
>
> Regards,
>
> Matthias.
>