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

[Steven Legg <steven.legg@xxxxxxxxxxx>]

Peter,

Peter Gutmann wrote:
> Stephen Kent <kent@xxxxxxx> writes:
>
> > 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.
>
> Only in the eyes of X.500 theologists.  As a pragmatic decision it's perfectly
> appropriate.  If you're identifying a CC holder, the CN is your credit card
> number.

One of the modes for accessing a directory is browsing up and down the
directory tree. As a human user browsing the directory tree, seeing a
list of entries with common names that are just numbers isn't very
helpful to me. A common name like "Peter Gutmann's Visa Card" is much
more informative than the common name "1234 5678 9012 3456". If I'm
interested in the entry for a particular card number then I would
just search directly on the attribute holding the card number, rather
that browsing the tree. The same considerations apply to the other
examples you've given.

The commonName attribute is not a particularly appropriate choice for
searching and sorting purposes either because it uses caseIgnoreMatch
as the equality matching rule. The values "1234 5678 9012 3456" and
"1234567890123456" are different common name values, but would be
the same value for an attribute with the NumericString syntax and
numericStringMatch equality matching rule. Unfortunately, LDAP and
X.500 don't define a general-purpose number attribute with this syntax
(serialNumber uses PrintableString and caseIgnoreMatch). Perhaps they
(or PKIX) should, to avoid further abuses of the commonName attribute ?

> If you're identifying a taxpayer, the CN is the taxpayer ID.  If
> you're identifying a web server, the CN is the server's URL/FQDN.  If you're
> identifying a piece of hardware addressed by MAC address, the CN is the MAC
> address.
>
> > If one looks at ALL of the text associated with the definition of CN, it is
> > clear what sorts of names are envisioned
>
> Yup, something that works with the global X.500 directory.  Just as soon as
> that appears we can start requiring people to choose names compliant with it.

The presence or absence of a global X.500 directory is not relevant.
Good naming practice applies just as much to stand-alone enterprise
directory deployments.

Regards,
Steven

> Peter.