Subject: Re: [KEYPROV] DeviceBinding ?

From: [email-masked]
Date: Mon, 5 Jan 2009 12:08:39 -0500

Sorry for the delay in responding to this.  There was a discussion on
the list back in July describing the need for this element and why
existing functionality is inadequate.

Rob Philpott 
RSA, the Security Division of EMC
Senior Technologist | e-Mail: [email-masked] | Office: (781)
515-7115 | Mobile: (617) 510-0893

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Friday, December 19, 2008 6:34 AM
> To: [email-masked]
> Subject: [KEYPROV] DeviceBinding ?
> 
> I have a question regarding the following element:
> 
> "
> <DeviceBinding>
> 
> This element carries the identifier that can be used to bind keys to
the
> device or class of device. When loading keys into a device, this
> identifier can be checked against information obtained from the device
> to ensure that the correct device or class of device is being used.
> "
> 
> I am not sure about the purpose of the element and what is actually in
> there that makes it different from the already provided PSKC
> functionality.
> 
> Ciao
> Hannes
> 
> _______________________________________________
> KEYPROV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyprov

Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 14 Jul 2008 06:56:00 -0500

Rob,

Please see comments inline [PH2]

Thanks again for all your help,

Philip

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 10, 2008 9:33 PM
To: Philip Hoyer; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs

Hi folks,

Sorry I didn't get this out last night. I've continued the dialog below (some content was snipped to shorten the message)...  Sorry for the length - I'm trying to provide sufficient context around our use cases to justify the suggestions.

Cheers,

Rob Philpott 

RSA, the Security Division of EMC
Senior Technologist | e-Mail: [email-masked] | Office: (781) 515-7115 | Mobile: (617) 510-0893

From: Philip Hoyer [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 8:16 AM
To: Pei, Mingliang; Philpott, Robert; [email-masked]; [email-masked]; Hallam-Baker, Phillip; Doherty, Andrea
Cc: [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs

Ming do you think we should add 'class' in DeviceInfo ?

[RSP] I really would prefer not using the name "class" for the element as that only solves half of our use case.  The purpose of the element we need is to have a single item in the device description of the PSKC instance document that can be used to match against a characteristic of the device to ensure that the keys are being loaded on the correct device or class of device (sorry for the long sentence :-)).  

You suggested below that the combination of <Manufacturer> and <SerialNo> should identify a specific device and that adding a class element could then identify a class of device.  

First, <Manufacture>+<SerialNo> are inadequate for our "specific device" use case.  There are numerous devices (e.g. many phones) where we just cannot programmatically retrieve the device serial number.  For example, I have a Verizon WinMobile phone that has a unique serial number printed on it.  However, I cannot obtain that value from a WinMobile app.  

The use case I need to satisfy is when an admin provisions a key to me but our policy mandates that the key can only be loaded on my specific phone.  I thus need my application to verify that when I try to load the key into the device, that it truly is the right device.  Now if I gave the admin the serial number from the phone, the app can't verify it.  But I might be able to obtain the phone's IMEI  number or have the app show me some other unique value.  I could then provide this value when requesting my key and the admin would put it in the <Device> instance document and my app could verify it when loading the key.

While it would be feasible to put this identifier in the SerialNo element (even though it's not the serial number), I still have the "class" use case to deal with.  If you provide a separate <Class> element, we then will need yet another attribute or element to indicate which of the 2 options should be enforced when loading a key since both <Class> and the <Manufacture>+<SerialNo> combination could appear in the document. For us, it can only be one of the choices but we can't make that an arbitrary choice; it has to be based on an enterprise policy.  

This is a critical capability to us. Thus, we are requesting a single element to identify the restriction information. Since we are "binding" a key to either a device or to a device class with this information, I previously suggested calling it either <BindingInfo> or <DeviceRestriction>. Perhaps a better name would be simply <DeviceBinding>. This would go into the <DeviceInfoType> definition. The description for the spec would be as follows:

*      <DeviceBinding> (OPTIONAL), the identifier that can be used to bind keys to the device or class of device. When loading keys into a device, this identifier can be checked against information obtained from the device to ensure that the correct device or class of device is being used.

See comment from Robert below in the email.

Philip

[PH2] understood and added to submitted spec

[RSP] <snip>

________________________________

3.       Shouldn't the "KeyId" attribute in the KeyType type also be of type xs:ID? It is currently defined as xs:string?  If this was intentional, I am quite confused as to the reason for using xs:string.

a.       Assuming KeyId should be of type xs:ID (and renamed to simply "Id"), then the PINKeyId attribute in the PINPolicyType type (pending #1 above) and the MasterKeyId attribute in KeyPropertiesType and KeyType types would need to be of type xs:IDREF.  These attributes are described to be unique references to keys.

[PH] No it can't be of type xs:ID becaue KeyId is actually what you refer further down as the unique serial number of the keys.

[RSP] I suspected that might be the case.  However, based on my experience with a number of other XML-based protocols, I strongly recommend separating the mechanism of identifying a blob of XML in an instance document (for which xs:ID and xs:IDREF are very useful) from the serial numbers that tie the blob to information managed by external systems.  That is, it is generally not a good idea to overload an attribute to serve double-duty. IMO that's just a cleaner content model. The ID/IDREF  attributes provide formal semantics for defining/referring to the XML blobs. A "serial number" string does not. Also, it seems to me that the serial number of a key is no different from a serial number of a device in that it's info about the key itself, not the XML blob representing the key. Yet you didn't use the ID attribute of the device as the serial number of the device. Thus the current approach is internally inconsistent.  So, I still recommend:

*      In <KeyType>, change <xs:attribute name="KeyId" type="xs:string" use="required"/> to <xs:attribute name="ID" type="xs:ID" use="required"/>

*      Since <PINKeyId> refers to a specific <Key> in the instance document, in <PINPolicyType>, change <xs:attribute name="PINKeyId" type="xs:string" use="optional"/> to <xs:attribute name="PINKey" type="xs:IDREF" use="optional"/>

For <MasterKeyId>, I am assuming that the master key will also always be present in the instance document (it's not clear in the spec).  If it is always present, then in <KeyPropertiesType> and <KeyType>, change <xs:element name="MasterKeyId" type="xs:string" minOccurs="0"/> to <xs:element name="MasterKeyId" type="xs:IDREF" minOccurs="0"/>. If, however, the key being referred to is possibly external to the instance document, then this element should be left alone, but the description should state that the value refers to an externally-defined key with a <SerialNo> that matches the value.

Finally, in <KeyType> add <xs:element name="SerialNo" type="xs:string minOccurs="0">

I think it should be an optional element (since we would now have the xs:ID that can be used to refer to it), although I could be convinced it should be mandatory. The description would be:

*      <SerialNo>  (OPTIONAL), a unique and global identifier of the symmetric key.  The identifier is defined as a string of alphanumeric      characters.

[PH2] I understand that there is obviously a confusion here about semantics and especially with the referral of PIN Key there is a double use of an external unique identifier (BTW some people do not agree with the term KeySerialNumber because it somehow makes people think of a series or continuous number whereas unique keyId could be random. I left this for now since there is alignment with DSKPP and alos too kuch work but this is an issue that should be discussed at IETF before we finalise the spec. The MasterKeyId is external to the document hence left alone. I added some more I added some text that hoipefully should make it clear that these are external identifiers.

[RSP] <snip>

5.       I personally think the ability to override settings in the <KeyProperties> element with specific values defined in the <Key> element might be overkill and could create more opportunities for implementation bugs.  My first preference would be to just define standalone <KeyProperties> elements and ONLY allow references from the <Key> elements via the IDREF mechanism.  My second preference is to simply have the <Key> element directly embed a <KeyProperties> element that is of type KeyPropertiesType and eliminate the use of the IDREF.  I can live with it as is, but do think it over-complicates processing. 

[PH] the main use for Keyproperties is for bulk provisioning where many keys share same properties. Hence the model of being able to not have to repeat the common properties in the same instance. The override is something that I believe makes sense in this scenario. Assume you are carrying thousands of keys that share the same properties but a few have different values so you allow an instance to set a specific value for something that is already contained in the shared properties. I share your concern for the support of keyproperties all together. I believe that many implementations will not implement support for keyproperties at all. I am less concerned about the override.

[RSP] You convinced me; As I said, I can live with the override mechanism and also realized we have a use case that it can solve.

6.       In the DeviceInfoType, I believe that the <SerialNo> element should be optional.  I know of devices where you cannot discover the actual serial number of the specific device (e.g. it is embedded in a larger platform). But I still might desire to include some of the other device info in the declaration.  To do this, I'd have to include a dummy value for <SerialNo>, which IMO is a bad idea.

[PH] after long discussions we narrowed down a universal (multiple manufacturers) way to uniquely identify the device to the combination of Manufacturer + SerialNo. This is the same as in the certificate world the use of IssuerDN and serial number uniquely identifies a certificate. To enforce this combined key Manufacturer and SerialNo are Mandatory.  If you do not have a 'device' per se now that I clarified the KeyId is the SerialNo of the key you can use the same value for the SerialNo of a virtual device. 

[RSP] I'm not sure I understand. In our use case, we have a real, physical device (not a virtual one), but my physical device cannot provide me (programmatically) with the device serial number.  And my physical device can hold multiple keys.  So I can't use the KeyId of one of the keys as the serial number of the device... unless you are suggesting that I create a virtual device for every key that I want to load into my physical device.  This just doesn't make sense to me.

In order to put the <SerialNo> info into the instance document, the value has to get entered into the provisioning system that creates the document. As I said, we have run into quite a few devices where we can't obtain the device serial number at all or can only obtain it programmatically with elevated user privs.  Examples include my WinMobile phone, the TPM device on my laptop, and many secure USB flash drives.  If I can't find/display the serial number, it can't be transferred into the provisioning system to be associated with the <Device> element that holds my keys. Thus, I still believe <SerialNo> should be an optional element.

If you adopt our request to include an element in <DeviceInfo> called <DeviceBinding> (as described above), then I can live with having a required serial number element here.  In cases where we don't know the serial number, we'll just throw in a dummy value.

[RSP] <snip>

8.       I'm not sure I understand why the <UserId> element is part of the DeviceType type definition. In our environment, a key is typically aligned with a single user ID.  Consider a scenario where a <KeyContainer> holds the keys I will use across multiple applications  where I have been assigned different user ID's.  If I use a single device to hold all of my keys, I can't do this.  I thus would prefer to see the <UserId> element become part of the KeyPropertiesType type.  I don't think I understand the use case for having it be part of the device definition.

[PH] The userId represents the information of the binding of a physical device to a user. The userId here is more to do with the concept of a global UserId rather than the username for a specific application. I understand your use case but was wondering if this is not slightly out of scope of PSKC. The concept of UserId to application Username mapping is covered more in something like SPML. I think the concept of which key/device can be used for which application is something that we should leave for this version of the spec.

[RSP] Hmmm... I don't think this is quite right. We don't typically think of binding a device to a single "UserId"; We bind a device to a "user" (it's owner) or even multiple users (e.g. a multi-user workstation on a shop floor).  A "UserId" typically binds a "user" to a specific account in an authentication system/application.  Consider a user that has multiple accounts on multiple systems in an enterprise and they want to use the same device to hold all of the keys for those accounts.  They may of course have different UserId's for each of those accounts/keys. The enterprise provisioning system could certainly use SPML to provision the user's accounts (i.e. UserId's) and keys into the multiple systems/applications.  SPML is intended for provisioning this info into those systems.  But to provision the user's keys into the device, they will use PSKC.  Under the current PSKC, the provisioning system won't know which UserId to use when creating the PSKC instance document for the <Device>.  

Next, when the user wants to access one of the enterprise systems, they will access their device and need to choose one of the keys.  In our experience, this is best facilitated by associating a "friendly name" with each key so they can readily pick the one they need. Once they choose a key, the <UserId> associated with the key can then be provided to the system as part of the authentication. So, I'm not talking about bringing application-style provisioning into PSKC.  I'm simply associating the user id to which the key pertains with the <Key> element.  A single <Key> with a <UserId> and credential might be used across many applications.  But if I have different sets of keys, I want to know what the user id is that it relates to.

So, my suggestion is to allow BOTH associating an optional user name (e.g. <User>, not <UserId>) to a device AND associating an optional <UserId> for each key:

In <DeviceType>, change:

<xs:element name="UserId" type="xs:string" minOccurs="0"/>

To

              <xs:element name="User" type="xs:string" minOccurs="0"/>

The description should be shortened to:

*      <User> (OPTIONAL), identifies the owner or the user of the device.

I see no reason to place format constraints on this value as is currently described using RFC4514.

In <KeyType>, add:

<xs:element name="UserId" type="xs:string" minOccurs="0"/>

with a description of:

*      <UserId> (OPTIONAL), identifies the user account (e.g. username or user id) to which the key is assigned.  The value MAY be a string representation of a Distinguished Name as defined in [RFC4514]. For example "UID=jsmith,DC=example,DC=net".  In systems where unique user Ids are used the string representation 'UID=[uniqueId]' SHOULD be used.

Note that IMO, the use of "UID=[uniqueId]" should not be mandated (i.e. MUST).  It's use might help interoperability, but if the (potentially constrained) client devices just need the user id value, we'd be forcing them to parse the value to pull out the ID and I just don't think that should be mandated.

Also please consider the concept where keys can be tied to more than one user (role certs or attribute certs are examples) one could eve envisage having the same OTP key for multiple users in an environment where the OTP key protects access to a shared collaboration space (although if provisioning of an individual key is relatively cheap the it makes no sense to share an single access key). 

Absolutely. But the alternative I suggest supports this as well in addition to supporting the use case I described.

[PH2] agree with proposed changes but I am maintaining the format recommendation for User for interoperability (I changed the MUST to SHOULD though)

[RSP] <snip>

*** RE: 3. Add additional elements under KeyData based on input from Rob Philpot

The additions below are not just in KeyData:

1.       I mentioned this in my previous comments, but I still don't understand why the spec-defined elements currently listed under the <Data> element need to be nested under <Data>.  They are well-known properties of the <Key> so why not just list them as <Key> child elements?  For example, I don't consider <TimeInterval> to be any different than <ExpiryDate> or <FriendlyName> w.r.t. the keys properties, so why is one nested under <Data> and the others are not.  IMO, <Data>, if it is needed at all, should just be for extensions.  Note that my preference would be to not use "Data" at all and just use the <Extensions> mechanism I describe below.

[PH] I tried to explain that everything under Data has a common structure (e.g, PLainValue and EncryptedValue) and that only those under <Data> can be encrypted. This makes parsing in constraint environment easier, for example ona smarft card applet where full XML parsers are not available) (e.g. string search until one finds <Data> and then proceed). 

[RSP] I understand that point, but I strongly believe that this approach makes processing more difficult, especially for constrained environments. IMO there is an alternative that is better for both constrained and unconstrained environments. 

For example, in our environment, we would never encrypt a <TimeInterval>, so our <TimeInterval> would just be a value in a <PlainValue> element.  But in the current scheme, you say we would search for <Data> and proceed from there.  That means then searching  for <TimeInterval>, then parsing for <PlainValue>, then getting the xs:int value. Yes, I could perhaps skip the search for <Data> and look directly for <TimeInterval>, but the other parsing is still required. 

I contend that if <TimeInterval> was defined outside of <Data> with a type="xs:int", then I could simply search for <TimeInterval> and then grab the xs:int value.  This is much simpler in a constrained environment. And in environments where I do have an XML parser, this structure is even easier to deal with.

Also, at least in our use cases, we would never need to encrypt <Time>, <Counter> or <TimeDrift>, so the same argument applies to these as well.

The alternative mechanism we've used in other standards for dealing with the encrypted/plainvalue question is, for each item that might need to get encrypted, we define the plain value element and encrypted value element using different element names and types. For Secret, we would thus define:  

<xs:element name="Secret" type="xs:base64Binary" minOccurs="0"/>

<xs:element name="EncryptedSecret" type="xenc:EncryptedDataType" minOccurs="0"/>

If for some reason, you wanted Counter to have an encrypted alternative, we would have:

<xs:element name="Counter " type="xs:int " minOccurs="0"/>

<xs:element name="EncryptedCounter" type="xenc:EncryptedDataType" minOccurs="0"/>

Whether you want to encrypt these items or not, we get to avoid the extra parsing overhead.  I don't have to look for the <Data> element and then I don't have to see if the child element is a PlainValue or an EncryptedValue.  For those things I'd never encrypt, I just search for the tag and get the value.  The ONLY thing that is lost in this approach is enforcement of the "xs:choice" in the schema. But since no one will be doing schema validation/enforcement for this stuff anyway (especially in constrained environments), that's of no value and is far outweighed by the simpler processing.

I also point out that now that we've adopted the <ExtensionsType> mechanism, it becomes VERY easy to use that to define custom items without the special PSKC-defined data types. The items just get added into the <Extensions> element of the <Key> element. 

[PH2] we debated tis and we came up with the current proposal, I have to say I can see pros and cons for both approaches. I did not change this for current submittal as it is a major change. If you think we should discuss this at IETF let me know I out it on the agenda.

BTW, we'd also like to raise a concern about defining <Time> as an xs:int (via intDataType).  IMO, <Time> should be defined as an xs:dateTime, which we've recently agreed would uniformly express time as UTC in Z form.  Using an int for time is very problematic for computational reasons.  The spec leaves the interpretation of this value undefined. It just seems dangerous to leave this so ambiguously defined.  If expressed as a UTC time value using xs:dateTime, then it's pretty easy to do the right thing and timezones, etc don't get in the way.  Protocols really shouldn't leave such things to chance since it definitely inhibits interoperability.

<Time> also seems to have an overloaded use if the <TimeInterval> value is also provided.  In this case the <Time> value is not a time value, but is instead an interval count.  IMO, this is confusing and the overloading should be avoided by adding an optional <IntervalCount> element. If <TimeInterval> is not specified, is <Time> a local time?  What is the epoch? Etc. etc... It seems pretty ambiguous.  Now, we don't need it for our use cases, although we might in the future.  I do think it would be helpful to clean this up.

I also prefer having a description in the spec (semantic) of what the attribute is hence I would really like from you a list of additional elements under <Data> that you know about that make sense. For example:

<DisplayInterval> , of type integerData - "Number of seconds between the interval of a display of a token)

[RSP] We don't need <DisplayInterval> since <TimeInterval> is already defined in the spec.  In our case, the display interval is the time interval of the algorithm. I am assuming the same is true for other time-based algorithms.

I've provided descriptions elsewhere in this message for all elements we've asked to be added. We don't currently have any additional ones.

2.       In our environment, we assign unique serial numbers to our keys.  We would like to see an optional element added to the KeyType type named <SerialNo> of type xs:string. Note that these serial numbers are completely separate from serial numbers of "devices" that hold keys. And due to typing of the xs:ID attribute, the ID can't be used for this.  Serial numbers used by corporations may not follow conventions that would be required by xs:ID.

[PH] This is what KeyId actually is and why KeyId is NOT xs:Id (please see explanation above)

[RSP] As I mentioned earlier, I do not think the references to XML blobs (ID's) should serve double-duty as the serial number of the key.

3.       We have a use case where we must identify that a key should only be associated with a specific device or perhaps with a general "class" of device.  If I am able to find the serial number of a specific device, I can accomplish this for the specific device case by using the <SerialNo> element of the <DeviceInfo> element that is part of the <Device> that contains the Key element.  However, there are 2 cases where this doesn't work:

a.       On a device where you cannot discover the actual serial number of the specific device. As long as the system can create/display a unique value (e.g. a GUID) that will only be associated with that specific device, then I could use that identifier to associate the key with the device. Yes, this value could be inserted into the <SerialNo> element, but then it is misnamed. 

[PH] as explained above the compound key Manufacturer+SerialNo MUST uniquely identify the device hence a GUID in the SerialNo is acceptable here.

[RSP] See my earlier explanation of <DeviceBinding> and the <SerialNo> element in <Device>.

b.       I want to indicate that the key should only be used on a specific class of device.  For example, I may only want the key to be loaded into an HSM on a server or into a TPM on a laptop because these provide strong key protection.  Here, I don't care which HSM or which TPM it is nor do I care who the manufacturer is or what model it is. I just want it to be bound to the generic class of device.  The device class could be represented by a GUID or some other string (e.g. "TPM").

[PH] This is an interesting point, we have the optional element <Model> under <DeviceInfo> . This is described as: "<Model (OPTIONAL)>, the model of the device (e.g. one-button-HOTP-token-V1)" Do you think we can use this as what you describe as the class 

[RSP] Using <Model> won't work for us... See my earlier explanation of <DeviceBinding> and the <SerialNo> element in <Device>.

or would you prefer me to add another element in DeviceInfo called 'class' which is an enumerated extensible value. If you want me to add this could you provide a list of 'class' values that we can add to the spec

[RSP] See my earlier explanation of <DeviceBinding> and the <SerialNo> element in <Device>.

4.       In our environment, we need to define PIN policies that define the min and max length for PINs and the data type for the PIN (numeric or alphanumeric).  This is part of the policy, NOT part of a specific PIN key.  Thus, it shouldn't be part of a <ResponseFormat> element.  We'd like to see additional attributes on the policy to set these values. I could see these attributes getting added to either the <PINPolicy> element or to the <PINUsageMode> element.  It can be debated whether these should be attributes or child elements. I suggest defining a child element of PINUsageMode following the current xs:choice element such as

<xs:element name=PINProperties type="PINPropertiesType" minOccurs="0">

<xs:complexType name="PINPropertiesType">

                <xs:attribute name="MinLength" type="xs:integer">

                <xs:attribute name="MaxLength" type="xs:integer">

                <xs:attribute name="Format" type="pskc:ValueFormat">

</xs:complexType>

[PH] I agree with your suggestions but prefer to add them directly in the PINPolicy Type

[RSP] That's fine. Thanks!

Here's some additional nits:

*      When elements are listed as (MANDATORY) or (OPTIONAL), the parenthetical is listed inside the element names angle brackets.  For example, "<Signature (OPTIONAL)>, the...".  This looks odd.  Wouldn't "<Signature> (OPTIONAL), the..." make more sense?

[PH2] agreed and changed

*      There are quite a few element and attribute descriptions in the various sections that are not marked as (OPTIONAL) or (MANDATORY).

[PH2} I tried to add most of the missing

*      Section 5.2 states: "Since KeyProperties are a method to commonalise the elements in Key please refer to Section 5.4 for detailed description of all elements.".  I don't believe "Commonalise" is a word (I can't find it in a dictionary and Word complains about it).  Might I suggest: "The elements of KeyPropertiesType can be overridden with elements by elements of the same name defined in KeyType. Refer to section 5.4 for descriptions of the KeyPropertiesType elements."

[PH2] changed wording 

*      Section 5.3: "A Device MAY be bound to a user and MAY contain more than one keys." "more than one keys" should be "more than one key".  Also, the elements and attributes described in this section are not identified as mandatory or optional.

[PH2] Changed this, thanks for the catch!

*      The style/formatting/phrasing of the element and attribute descriptions in various sections is inconsistent.  The descriptions usually (but not always) show the element/attribute name followed by (OPTIONAL) or (MANDATORY) followed by a comma and then the description.  However, sometimes the description is written as a standalone phrase and other times it is written in sentence form.  Examples that all read differently include:

o    Version (MANDATORY), the version number for the portable key container format (the XML schema defined in this document).

o    <PINPolicy (OPTIONAL)>, the policy of the PIN relating to the usage of this key as defined in Section 5.4.4

o    The <Secret (OPTIONAL)> conveys the value of the key iself in binary. [Note there is also a type in this one "iself"].

o    The <TimeInterval (OPTIONAL)> the time interval value for time based OTP algorithms.

*   In other places, the element or attribute is listed on a bulleted line by itself and the description is indented below it without a bullet.  For example:

o        Format (MANDATORY)

Defines the format of the challenge accepted by the device and

MUST be one of the values defined in Section 5.4.3

[PH2] I changed most of this thanks for the detailed analysis and example.

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 5 Jan 2009 22:07:19 +0200

Hi Rob, 

Thanks for your response and for finding that mail. 

I read through the mail and also looked again at the -06 draft version.
It says: 

   o  <DeviceBinding> (OPTIONAL), the identifier that can be used to
      bind keys to the device or class of device.  When loading keys
      into a device, this identifier can be checked against information
      obtained from the device to ensure that the correct device or
      class of device is being used. 

Just to make sure that I correctly understand the idea: 

The <DeviceInfo> element contains a number of child elements that allow
to uniquely identify an entity for which the key carried in
<Key><Data><Secret> is going to be used. 

There are many different devices and many different usages of PSKC.
Different devices have different ways to identify them. Ideally, we want
to use information elements that allow the key (and additional data) to
be associated with the device >>without human interaction<<. (If we
assume human interaction, which we don't say in the document, then
things are much easier.) Currently, we have a number of elements that
can be used: <Manufacturer>, <SerialNo>, <Model>, <IssueNo>,
<StartDate>, <ExpiryDate>

We don't discuss specific devices in the PSKC document and therefore we
don't say that certain elements have to be used with a specific device.
Different elements may also need to be populated in a specific way (call
it encoding).

<DeviceBinding> is another element that contains an opaque identifier
that fulfills a similar role as, for example, <Manufacturer> and
<SerialNo>. 

In trying to understand it better may I try to compare it with operating
system concepts where software components are registered using a unique
identifier, such as a UUID (a 128-bit number). When establishing
communication to a specific software compontent the UUID is presented. 

Is this roughly the idea you had in mind? 

Do you think that all child elements of <DeviceInfo> should be optional,
i.e., one cannot assume one of them to be always present for the sum of
the devices we are looking at? (Still, something has to be present to
know to what the key is associated with.)

>From the current wording you don't assume a specific encoding for the
content of the <DeviceBinding> element. Right?

I am trying to figure out whether we can add additional text that allows
the reader to understand in what circumstances this element is used and,
for the implementer, with what the value in this element should be
compared with. Maybe we have a concrete example we could add. 

Does my question make any sense? 

Ciao
Hannes

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 05 January, 2009 19:09
>To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
>Subject: RE: [KEYPROV] DeviceBinding ?
>
>Sorry for the delay in responding to this.  There was a 
>discussion on the list back in July describing the need for 
>this element and why existing functionality is inadequate.
>
>Rob Philpott