>One ought not expect the writers of X.520 to anticipate every
>questionable use of an attribute and say "no, don't do this" so I
>don't think your observation above is a valid argument in favor of
>using CN here. Also, the text for common name starts by saying "A
>Common Name is not a directory name; it is a (possibly ambiguous)
>name by which the object is commonly known in some limited scope
>(such as an organization) and conforms to the naming conventions of
>the country or culture with which it is associated." This text, which
>precedes the text you cite, makes it clear that a MAC address should
>not be represented as a common name. A vendor assigning a MAC
>generally does so in a globally unique fashion, which contradicts the
>"limited scope" concept cited in the standard. A MAC address is not
>at all congruent with the allusions to "naming conventions of the
>country or culture with which it is associated" part of the
>description of the common name attribute.
I would argue the reverse.
First it is far more important to be consistent with established practice than what the descriptive text in the X.520 spec might say. The Common Name is just a sequence of bits making up a tag-value pair. It is what it is, meaning is the result of usage.
More importantly I would argue that the word 'limited' should be considered in the context 'in at least a limited context'. In general we like names to be as unique as is possible. Common names are not unique in general (although my common name is in fact unique at this point in time). We should not hold the fact that EUI-48 addresses do in general have this desirable property against them. The spec says POSSIBLY ambiguous. EUI-48 names appear to comply in my view.