[keycloak-dev] Certificate subject DN is provider dependent

[Pedro Igor Silva]

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.

Thanks.


>
>
> --
> John Dennis
>