At 10:05 PM +1300 1/5/08, 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. 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.
Pragmatism is all too often cited as a justification for ill-advised behavior. All of your examples of what cab be stuffed into the CN attribute are good examples of what NOT to put there. The penultimate example specifically is disparaged by PKIX standards.
In the early days of TCP/IP, the folks responsible for the BSD implementation decided to NOT calculate the TCP checksum for each packet. Pragmatically, they found the Ethernet MAC layer CRC to suffice and having to calculate the TCP checksum slowed down their implementation. The fact that a standard defined what to put in the the TCP checksum field was irrelevant to them, based on a purely local, pragmatic view of the situation.
I see echos of that mentality here. Steve