In-line -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 10:42 AM To: Ryan Hurst; Ray Bell; Bernard Aboba; [email protected] Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> -----Original Message----- > From: Ryan Hurst [mailto:[EMAIL PROTECTED] > Sent: Friday, February 16, 2007 10:23 AM > To: Ray Bell; Joseph Salowey (jsalowey); Bernard Aboba; [email protected] > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > Ray - I am familiar with the cable labs stuff, they put the > MAC in the CN although if I recall they don't specify how the > value should be represented which really limits its value IMHO. > > I have looked at 802.1ar and from what I can tell they have > not decided where the value should go in their certificate > profile, from the various revisions it looks like they have > considered many locations from the CN, certificate Serial > Number, subject serial number to a SAN othernames. > [Joe] The identifier in AR is not necessarily a MAC address. The identifier format is determined by the manufacturuer. [rmh] Your right, in the early versions of the document it read as if it were a MAC, later revisions generalized it to a permanent identifier; yet it still uses the MAC as a example but doesn't provide guidance on format or limit its usage to a generalized identifier where format wouldn't be relevant. > I have spoken to Bernard off-line and he has convinced me > that it would be useful for there to be a appendix discussing > how one would include this value in a certificate if it's to > be used within EAP-TLS. > [Joe] What value? [rmh] MAC. > 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. > 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'; > [email protected] > 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; [email protected] > 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; [email protected] > 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: [email protected] > > 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 > > [email protected] > > https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > Emu mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Emu mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
