CableLabs and WiMAX specifications include the MAC address in the CN.
Russ
At 06:19 PM 12/26/2007, Joseph Salowey (jsalowey) wrote:
>I don't believe that 802.1AR uses the MAC address in the CN field. I
>believe it makes use of the SerialNumber field and does not mandate that
>the identity must be a MAC address (it doesn't prevent it either). The
>current text from draft 1.2 on SubjectName is
>
>"The DevID subject field shall uniquely identify the particular DevID
>credential within the issuer's domain of significance. The formatting of
>this field shall contain a unique X.500 distinguished name (DN). This
>may include the manufacturer's serial number, manufacturer's factory
>programmed MAC address, issuer's or user's node name or any other
>suitable unique string that the issuer prefers.
>
>It is recommended that the subject field's DN encoding include the
>'serialNumber' attribute with the device's unique serial number. "
>
>The current editor of the document, Max Pritikin, is copied on this
>message.
>
>Joe
>
> > -----Original Message-----
> > From: secdir-bounces@xxxxxxx [mailto:secdir-bounces@xxxxxxx]
> > On Behalf Of Bernard Aboba
> > Sent: Friday, December 21, 2007 8:00 PM
> > To: Scott G. Kelly; Stephen Kent; Sam Hartman
> > Cc: capwap-chairs@xxxxxxxxxxxxxx; ietf-pkix@xxxxxxx; secdir@xxxxxxx
> > Subject: Re: [secdir] Please review
> > draft-ietf-capwap-protocol-specification's use of certificates
> >
> >
> > Although I agree with Steve that a MAC address would best be
> > placed within the SerialNumber attribute, the cat is long out
> > of the bag. WiMAX Forum, IEEE 802.1ar and DOCSIS have all
> > specified inclusion of a MAC address within a CN. So the
> > issue is no longer whether this is done, but rather, whether
> > it is done in a uniform way.
> >
> >
> >
> > ----------------------------------------
> > > Date: Fri, 21 Dec 2007 16:54:45 -0500
> > > From: s.kelly@xxxxxxxxxxxxx
> > > To: kent@xxxxxxx; hartmans-ietf@xxxxxxx
> > > CC: capwap-chairs@xxxxxxxxxxxxxx; ietf-pkix@xxxxxxx; secdir@xxxxxxx
> > > Subject: Re: [secdir] Please review
> > > draft-ietf-capwap-protocol-specification's use of certificates
> > >
> > > Hi Steve,
> > >
> > > Thanks for taking a look at this. Regarding placement of
> > the MAC in the CN, I would offer two observations:
> > >
> > > 1) this is what is specified in the DOCSIS and PacketCable cert
> > > profiles, and it was on this basis that device certs for LWAPP were
> > > originally designed in this way. You can see the DOCSIS profile at
> > > www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> > >
> > > 2) I don't see anything in the X.520 language that
> > explicitly precludes this usage, so assuming that the
> > docsis/packetcable designers reviewed that spec, I can see
> > how they could reasonably conclude that this is acceptable.
> > Arguably, the string representation of the MAC address is "a
> > string chosen [by the] organization responsible for the
> > object it describes for devices and application entities".
> > >
> > > Please don't misunderstand: I'm not trying to be difficult,
> > and I have a very healthy respect for the depth of your
> > knowledge in this area. However, there are a *lot* of devices
> > deployed that already use this convention. It might be more
> > pragmatic to interpret X.520 a little less restrictively.
> > >
> > > Scott
> > >
> > > -----Original Message-----
> > >>From: Stephen Kent
> > >>Sent: Dec 21, 2007 3:00 PM
> > >>To: Sam Hartman
> > >>Cc: capwap-chairs@xxxxxxxxxxxxxx, ietf-pkix@xxxxxxx, secdir@xxxxxxx
> > >>Subject: Re: [secdir] Please review
> > >>draft-ietf-capwap-protocol-specification's use of certificates
> > >>
> > >>At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> > >>>Hi, folks. The capwap working group is preparing to last
> > call their
> > >>>protocol specification draft.
> > >>>
> > >>>I'd appreciate review from the pkix community of section
> > 2.4.4.3 and
> > >>>12.6 of this draft. These sections specify certificate validation
> > >>>and certificate usage for the protocol. Scott Kelly and Charles
> > >>>Clancy are security advisors for the working group and have been
> > >>>heavily involved.
> > >>>
> > >>>The capwap certificate profile assumes that the CN in the
> > certificate
> > >>>has structure and contains an ethernet MAC address. The capwap
> > >>>certificate profile also assumes that parts of the subject
> > name such
> > >>>as the organization and organizational unit will be important to
> > >>>certificate matching.
> > >>>
> > >>>I'd appreciate review and comments.
> > >>>
> > >>>--Sam
> > >>
> > >>It would be preferable to get an allocated name space for MAC
> > >>addresses, under the OtherName or, better yet, under registeredID.
> > >>
> > >>I'd argue that it is inappropriate to put a MAC address into a CN.
> > >>The text from X.520 makes this clear:
> > >>
> > >>The Common Name attribute type specifies an identifier of
> > an object.
> > >>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.
> > >>
> > >>An attribute value for common name is a string chosen either by the
> > >>person or organization it describes or the organization responsible
> > >>for the object it describes for devices and application
> > entities. For
> > >>example, a typical name of a person in an English-speaking country
> > >>comprises a personal title (e.g., Mr., Ms., Rd, Professor,
> > Sir, Lord),
> > >>a first name, middle name(s), last name, generation
> > qualifier (if any,
> > >>e.g., Jr.) and decorations and awards (if any e.g., QC).
> > >>
> > >>Examples
> > >>CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> > >>CN = "Divisional Coordination Committee"
> > >>CN = "High Speed Modem".
> > >>
> > >>If there is a very strong desire to make use of an existing
> > attribute
> > >>in the X.502 space, the SerialNumber attribute makes more sense. So
> > >>long as we are talking about long, term, stable MAC
> > addresses assigned
> > >>to devices by manufacturers, this is consistent with the
> > semantics of
> > >>that attribute. Moreover, we have advised folks to use
> > SerialNumber
> > >>to represent data such as employee/student IDs in the past, so one
> > >>might expect to see support for this attribute in many CAs and
> > >>clients.
> > >>
> > >>Steve
> > >
> > > _______________________________________________
> > > secdir mailing list
> > > secdir@xxxxxxx
> > > https://mailman.mit.edu/mailman/listinfo/secdir
> >
> > _______________________________________________
> > secdir mailing list
> > secdir@xxxxxxx
> > https://mailman.mit.edu/mailman/listinfo/secdir
> >