[keycloak-dev] Certificate subject DN is provider dependent

[Marek Posolda]

On 12/02/2019 22:26, Pedro Igor Silva wrote:
> On Tue, Feb 12, 2019 at 6:43 PM John Dennis <jdennis at redhat.com> wrote:
>
>> On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
>>> Pretty much, but not the same. The fix for this still does not seem to
>>> solve the problem being discussed in the other thread.
>>>
>>> The change provided by Sebastian does solve this problem while still
>>> backwards compatible with certificates with subject dn containing an
>>> emailAddress. My point though is whether or not we should be backward
>>> compatible given that emailAddress is a deprecated RDN in the subject DN.
>>>
>>> As you mentioned, RFC-2253 was superseded by RFC-4514 and there you
>>> can't have emailAddress in subject DN but prefer a SAN. So, my question
>>> is ... Is OK in 2019 to assume that certificates are using RFC-4514 ? So
>>> we could just use the canonical format in our side and avoid any
>>> additional configuration.
>>>
>>> You are right, java defaults to RFC-2253, I'm not sure if the
>>> "canonical" format is related with the support for 4514 (at least
>>> removing emailAddress from subject DN).
>> No, RFC's 2253 and 4514 *only* describe the process by which a binary DN
>> in ASN.1 format is converted to a string representation. These RFC's do
>> not define the permissible members of a DN in an X509 certificate. In
>> fact the subject member of an X509 certificate was originally *under*
>> specified leading to all sorts of compatibility problems. The usual
>> solution adopted only by convention and not by specification is to
>> extract the CommonName (i.e. CN) RDN value and use that as the subject
>> name (usually in the scope of the issuer). But as you can imagine that
>> also has it's own problems (e.g. name collisions that would otherwise be
>> uniquely determined by the other RDN values and/or scoping to the issuer).
>>
> Sure, but note that RFC-4514 relies on 4519 (which actually defines the
> supported attributed types).
>
>
>> I go back to my original assertion when I first replied weeks ago. If
>> you want to compare DN's for equality you're going to have to do so by
>> breaking the DN down into it's component parts and comparing them
>> individually or reformat the string representation of the DN into a
>> canonical form and perform a string comparison (note that forming a
>> canonical string representation also requires breaking the components
>> apart so there is little actual difference between doing an equality
>> test between DN objects and an equality comparison on the resulting
>> canonical strings, the later just adds the cycles needed to format the
>> individual components).
>>
> Yeah, I think so. I hope this can solve the "comparison issue". Need to get
> more familiar with what was discussed in the other thread.

Just to refresh, the problem discussed on the other thread was 
unfortunately not simply "comparison issue" (which I think is not hard 
to solve with the proposal you suggested above), but "lookup user 
issue", which makes things slightly more complicated.

AFAIR the use-case was, that you just received the certificate with some 
Subject DN and based on that, you needed to lookup Keycloak user with 
corresponding LDAP DN.

Marek

>
> So, based on your experience in Openstack. Is there people still using
> certificates with deprecated emailAddress as part of the subject DN ? If
> your answer is no, we probably want to avoid an additional configuration to
> enable/disable java canonical format. Otherwise, if your answer is
> yes/don't know, maybe we should keep the configuration option implemented
> in the PR.
>
> The main reason for pushing this question is that from a security
> perspective, using a deprecated attribute type in subject dn is not good.
> Privacy concerns may apply here too where you may not want people to put
> the email (sensitive) in something that is supposed to be public.
>
> Thanks.
>
>
>>
>> --
>> John Dennis
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev