|
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 From: Philip Hoyer
[mailto:philip.hoyer at actividentity.com] 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 [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. [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. [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. 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? ·
There are quite a few element and
attribute descriptions in the various sections that are not marked as (OPTIONAL)
or (MANDATORY). ·
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.” ·
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. ·
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 |
_______________________________________________ KEYPROV mailing list KEYPROV at ietf.org https://www.ietf.org/mailman/listinfo/keyprov