> > I want to ping a few people for their opinions on location, > my initial > > take is that specifying a consistent format to represent > the value as > > and putting it in the CN or the subjectAltName:OtherName:PI are > > probably the best bests but I need to think about it more. > > > [Joe] I'm not quite sure what value you are talking about, > but if it is a device identity then why not the SN RDN. > [rmh] The problem with just saying SN RDN is that you can > have many RDNs in a given DN, plus by putting in the DN you > potentially require directory schemas to change to > accommodate; the PI RFC > (http://www.ietf.org/rfc/rfc4043.txt) documents how one > handles the multiple RDN situation and specifies a othername > name-form for subjectAltName which allows you to specify the > value without the directory hit. > [rmh] Problem with PI is its intended for people not devices, > however from my read it has all the right properties to deal > with a device id such as a MAC address. > [Joe] OK, got it. A consistent place to find a MAC address in a cert. If this is the case I don't think CN is appropriate since it is used for all sorts of random stuff. I agree that subjectAltName:OtherName:PI looks promising. I support we could also define a MAC address OID.
> > Ryan > > > > -----Original Message----- > > From: Ray Bell [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 13, 2007 2:32 PM > > To: Ryan Hurst; 'Joseph Salowey (jsalowey)'; 'Bernard Aboba'; > > emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > > The CableLabs Device PKI process should be considered... > > > > http://www.cablelabs.com/certqual/security/ > > > > Ray > > > > > > -----Original Message----- > > From: Ryan Hurst [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 13, 2007 1:38 PM > > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > > I am not sure the MAC address is directly relevant to this > effort, as > > long as we allow for alternate bindings to be used (I think > the text I > > proposed does this) then these problems can be dealt with in other > > documents. > > > > As for the MAC address as a identifier, I actually am not a > fan; from > > what I can tell it has been added to facilitate better certificate > > selection but there are much better ways to achieve that; I > have been > > tempted to write a informational on how proper certificate > selection > > is done but have not had the time. > > > > The problem with a MAC address is that certificates > normally contain > > bindings of entitlements or constraints, these are all > assertions that > > the CA can stand behind (I have verified that the holder of > this key > > has the rights to this fqdn, I have verified he is entitled to > > represent that FQDN for server TLS transactions, etc.). > > > > You just can't do that with a MAC address, not in any > reasonable way; > > now device identity is a SUPER important thing without it we will > > continue to take dependencies on weak identifiers like MAC > addresses > > to perform exceptions and entitlements (which essentially throw out > > any security value modern isolation solutions provide) so the work > > being done by AR is important. > > > > As for where AR puts the identity, generally speaking you should be > > able to tell what is in a RDN given a certificate usage; so > if AR has > > a EKU for Device Authentication I suppose its fine for it > to say when > > this EKU is present the RDN CN has special meaning, otherwise it > > should go elsewhere. > > > > Actually now that I think about it I would suggest that they go in > > subjectAltName; again the general thinking about Subject > DNs is they > > map to a directory entity; this isn't always the case and > its likely > > not the case with a device certificate (many assumptions in this > > statement so be kind), in such cases its probably more > appropriate to > > have a empty Subject DN and use a existing name form (urn, etc.) in > > subjectAltName or define a new name form for the subjectAltName > > extension. > > > > Ryan > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 13, 2007 12:18 PM > > To: Bernard Aboba; emu@ietf.org > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > > 802.1AR is not specifying that a device identity within a > certificate > > has to be a MAC address. It can be any identifier that is unique > > within a manufacturer's domain. > > The current thinking is that the identity would go in the > common name > > of the subject name. > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, February 13, 2007 10:59 AM > > > To: emu@ietf.org > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > > > > Question: > > > > > > What about a device that has a MAC address as a name? Use > > of EAP-TLS > > > with MAC certificates is being discussed in WiMAX Forum and IEEE > > > 802.1AR. Where should the MAC address be placed (subject vs. > > > subjectAltName) and what field type should it have? Is there a > > > reference that defines the formatting of field types? Is there > > > guidance on how to format the MAC address consistently? (e.g. > > > 00037B5FCE73 in WiMAX vs. > > > 00:03:7B:5F:CE:73 in IEEE 802.1AR). > > > > > > > > > > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
