[keycloak-dev] Certificate subject DN is provider dependent

[Pedro Igor Silva]

On Tue, Feb 12, 2019 at 7:26 PM Pedro Igor Silva <psilva at redhat.com> 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.
>
> 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.
>

I mean, encourage people to use that way ....


>
> Thanks.
>
>
>>
>>
>> --
>> John Dennis
>>
>