RE: Microsoft and multi-valued RDNs (was: draft minutes)

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

"Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxx> writes:

>The scope for applications not doing the right thing in the presence of a
>multi-valued RDN is pretty big. Fore example, there is a large body of
>applications who extract subsets of data from the DN such as only using the
>common name in UI which will ignore subsequent values of the RDN. 

Yup, that's what I've found too, which is why I sent my earlier "Don't do
that, then" response to Michael Stroeder.  I haven't exhaustively enumerated
all the different behaviours, which app does what, and which version of which
app does what, but it ranges from ignoring everything but a small fixed set of
DN components (C, O, OU, locality, state, and obviously DN) to accepting most
components but not allowing duplicates (e.g. 2 x OU) to accepting dups but not
multi-valued AVAs.  Then the definition of "accept" varies from reading and
discarding (writing it out again removes the value), reading but ignoring
(writing retains the value), displaying or not displaying, etc etc etc.  This
is why, in writeups I've done like "PKI: Not dead just resting" I recommend
that for maximum usability people treat DNs as random blobs and don't try and
do anything fancy with them.  The further you depart from that, the more pain
you're in for.

>Therefore Microsoft's lack of support for multi-valued RDN with AD is the tip
>of the iceberg and anyone insisting on using them will have a lot of
>regression testing to perform. 

Exactly.  The range of options runs from the simplest possible DNs (C, O, OU,
etc) treated as blobs through to complex DNs, multi-AVA RDNs, etc etc, and
then relying on each component to work properly, with a corresponding increase
in pain level from 0 to infinity along the same scale.

Peter.