James Carlson wrote: > Darren Reed writes: > >> James Carlson wrote: >> >>> Darren Reed writes: >>> >>> >>>> I agrree, Jim, and I'd like to reiterate that we have an obligation to >>>> follow >>>> what the IEEE specification says is allowed here. Anything else introduces >>>> arbitrary restrictions that may introduce interoperability problems. >>>> >>>> >>> What IEEE specification says something about security object names? I >>> thought these names (unlike the keys stored inside) were an internal >>> Solaris implementation detail, not something that conformed to any >>> standard. >>> >>> >> I should have quoted the entirity of your email where you were >> talking about how we're using the ESSID/BSSID for the secobj >> name. If we're not going to use those, then we don't need to be >> concerned with what IEEE says. But if we are, then we do. >> > > I still don't think we care. > > The IEEE governs how the ESSID and BSSID themselves work. They don't > govern how we name our internal objects or the character set we use > for those names. > > In this case, we happen to use a *modified* form of ESSID (we > irreversibly translate ':' to '.', because dladm '-k' uses colon to > delimit slot numbers from a secobj), and a particular string > representation of BSSID (I don't think IEEE has a position on upper or > lower case hex or on zero pad, but we do when we're creating this > string), separated by '-', and we truncate the string because secobj > names are length-limited. > > We'd probably be better off just to hash ESSID and BSSID together and > use some printable form of the hash as the secobj name. >
I like that last idea better than any of the above as it reduces the chance of a natural collision. Darren _______________________________________________ networking-discuss mailing list [email protected]
