[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
I would agree with Scott. I have personally created over 20M (that's
million) certificates over 4 complete IEEE OUIs with the MAC address in
the CN of the certificate subject DN. Besides the US version of DOCSIS,
we use the same setup for the European equivalent. We actually have 5
different setups, US DOCSIS, EU DOCSIS, US Packet Cable, EU Packet
Cable, and Cable Home operated under Cable Labs and tComLabs.
We are also starting to expand the use to other set top boxes and other
consumer type products that have MAC addresses. I would suggest that
the CAPWAP program remove the ":" from the MAC address. I would also
suggest that this profile be moved under PKIX because as you can see
there are several systems using it. We already have cable modems and
set top boxes used as wireless access points, it would be a shame to
have yet another certificate for the exact same device.
Thanks
Ron Ogle
Product Security
Thomson Inc.
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Scott G. Kelly
> Sent: Friday, December 21, 2007 4:55 PM
> To: 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
>
>
> 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 <kent@xxxxxxx>
> >Sent: Dec 21, 2007 3:00 PM
> >To: Sam Hartman <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
> >
> >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
>
>