RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates

[Stephen Kent <kent@xxxxxxx>]

Title: RE: [secdir] Please review draft-ietf-capwap-protocol-spe

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