> -----Original Message----- > From: Joseph Salowey (jsalowey) > Sent: Friday, February 16, 2007 11:25 AM > To: Ryan Hurst; Ray Bell; Bernard Aboba; [email protected] > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > > > > 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.
[Joe] Should be "I suppose" instead of "I support" > > > > 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 > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
