You write the spec, you hope that people will take notice.
If people do not take notice that is at least in part the fault of the spec writer for failing to make their intentions more clearly understood.
What the CableLabs sec should have said seems like a pointless argument to me at this point but for the record we have a professional disagreement as to the most reasonable interpretation of this passage. EUI-48 identifiers do not exactly map onto any meaningful concept within X.520 space, this is due to the same lack of imagination on its designers part that makes X.500 the real world success it is today. The choice is between using the CN field and creating a new one. The CN field approach meets the expectations of existing applications much better than a new creation would.
From: owner-ietf-pkix@xxxxxxxxxxxx on behalf of Stephen Kent
Sent: Wed 02/01/2008 1:32 PM
To: Hallam-Baker, Phillip
Cc: Scott G. Kelly; Sam Hartman; capwap-chairs@xxxxxxxxxxxxxx; ietf-pkix@xxxxxxx; secdir@xxxxxxx
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
At 9:53 AM -0800 1/2/08, Hallam-Baker, Phillip wrote:
>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.
Why am I not surprised?
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.
If the DOCSIS and PacketCable specs preceded the X.520 publication, this would have been a good argument. But these specs came along much later. The folks at Cable Labs who decided to put the MAC address in the CN made a poor choice.
If your comments apply to the capwap I-D, I have already stated that, given the need to be compatible with the extant, deployed base, there isn't much of a choice here. However, the capwap I-D needs to cite these specs as the justification for this odd decision, so that readers don't draw the wrong conclusion.
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.
If one looks at ALL of the text associated with the definition of CN, it is clear what sorts of names are envisioned, and a MAC address is not a reasonable candidate. One might work hard to try to find a way to justify the use, but hopefully a smart guy like you is doing so tongue-in-cheek.
Steve