Re: [KEYPROV] [pskc] Latest draft of PSKC

Rob,

Please see comments inline [PH2]

Thanks again for all your help,

Philip

From: robert.philpott at rsa.com [mailto:robert.philpott at rsa.com]
Sent: Thursday, July 10, 2008 9:33 PM
To: Philip Hoyer; mpei at verisign.com; SMachani at diversinet.com; Hannes.Tschofenig at gmx.net; pbaker at verisign.com; andrea.doherty at rsa.com
Cc: keyprov at ietf.org
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: robert.philpott at rsa.com | Office: (781) 515-7115 | Mobile: (617) 510-0893

Philip

Hi folks,

Cheers,

Rob Philpott

RSA, the Security Division of EMC
Senior Technologist | e-Mail: robert.philpott at rsa.com | Office: (781) 515-7115 | Mobile: (617) 510-0893

From: Philip Hoyer [mailto:philip.hoyer at actividentity.com]
Sent: Tuesday, July 08, 2008 8:16 AM
To: Pei, Mingliang; Philpott, Robert; SMachani at diversinet.com; Hannes.Tschofenig at gmx.net; Hallam-Baker, Phillip; Doherty, Andrea
Cc: keyprov at ietf.org
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 J).

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.

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 J).

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 l>

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 ideof 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

·      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><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.

[RSP] <snip>Calibri>

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.

[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.

[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>

[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,raph style='margin-left:0pt'>

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 th 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.

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"/>

<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 =nt size=2 color="#1f497d" face=Calibri>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 individ 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 preferenual 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 wouce 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).

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.

[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 sily:Calibri; color:#1F497D;font-weight:bold;font-style:italic'>

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 chema 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 thivalidation/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 ts 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.

Re: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs