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

["Erik Andersen" <era@xxxxxxxxxx>]

Hi Folks,

I do not want to be directly involved in this discussion.

As the project editor of X.500, including X.520, I may probably be titled as
an X.500 theologist, although I am not very religious.

I always get a little scare when people talks about pragmatic solutions, and
I normally translate that into "cutting corners" or "quick and dirty
solutions". Sticking to standards is not just a theological question, but a
very practical to allow systems from different vendors developed at
different times to interwork.

As to the matter at hand. It is not just theology to stick to the defined
semantics of different attribute types. It has a practical aspect as I have
been taught by implementers (never, never change the semantic). If there are
different semantics attached to the same attribute type, in adversely
affects (or confuses) client software.

This probably doesn't help.

Erik Andersen
Andersen's L-Service
Mobile: +45 20 97 14 90
e-mail: era@xxxxxxxxxx
http://www.x500standard.com/
http://home20.inet.tele.dk/era/me
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Peter Gutmann
> Sent: 5. januar 2008 10:06
> To: kent@xxxxxxx; pbaker@xxxxxxxxxxxx
> Cc: capwap-chairs@xxxxxxxxxxxxxx; hartmans-ietf@xxxxxxx; ietf-
> pkix@xxxxxxx; scott@xxxxxxxxxxxxxxxx; secdir@xxxxxxx
> Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-
> specification's use of certificates
> 
> 
> 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.
> 
> >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.
> 
> Peter.