|
Ming do you think we should add ‘class’
in DeviceInfo ? See comment from Robert below in the
email. Philip From: Pei, Mingliang
[mailto:mpei at verisign.com] Hi Robert, Great comments and suggestions. Thanks. Philip, I read through your comments and answers.
The proposed changes all look fine to me. Are you going to make the few
changes (ID naming, PIN properties, extension type, dateTime) today? Thanks, - Ming From: Philip
Hoyer [mailto:philip.hoyer at actividentity.com] Robert, First of all thank you for the review and
comments. Please see my comments inline [PH] Since we are rapidly approaching the
deadline I would really like if you could have a look at my comments and
respond where there are new questions to you or acknowledge. Also, please note my comments on the
additional <Data> attributes and I would really appreciate you send me a
list with semantics to include in this version of the spec (e.g): <DisplayInterval>
, of type integerData – “Number of seconds between the interval of
a display of a token) Thanks a lot again, Philip From:
robert.philpott at rsa.com [mailto:robert.philpott at rsa.com] I just finished
reviewing the recent spec/schema changes which IMO, represent a significant
improvement in usability. I do have some additional comments and change
requests that would pretty much bring it in line with our needs and with other
schema practice I’m familiar with: ****RE: 2. Review the spec (Salah, Hannes, Andrea) especially the wording
around the new changes (please see KeyData Element definition in the new spec) 1. As currently defined, I don’t see a reason to put
an xs:ID attribute on the PINPolicyType type. The <PINPolicy>
element can only exist as part of a <KeyProperties> element or a
<Key> element. The schema doesn’t have any elements with an
IDREF-based attribute that refers to the ID on a <PINPolicy> element.
IMO, it only make sense to put an ID on <PINPolicy> if the
<PINPolicy> can stand alone in the container instance (as is the case
with <KeyProperties>) and then referring to it from other elements. But I
don’t think this is necessary. If we keep the <PINPolicy> as
part of KeyPropertiesType, I would get rid of the PINPolicyId attribute. [PH] ok
fair enough I am happy to take it out 2. Now that a number of the elements have been given xs:ID
based attributes, I’d like to suggest that the name of the attribute for
these ID’s be simply “ID” rather than using element-specific
names (e.g. ContainerId, PINPolicyId, etc). While I can’t point to
a best practices document for this convention, this is the approach I’ve
seen in nearly all of the standards schemas I’ve seen. I’d point
out that the PSKC schema itself has an xs:ID attribute in DerivedKeyType called
“Id” instead of “DerivedKeyId”, so even the current
schema is inconsistent. Basically, my suggestion is that any element that
is defined with an attribute of type xs:ID should all simply be named “Id”. [PH]
agreed and probably more in line with other standards 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. 4. On a related note, when defining attributes of type
xs:IDREF, I would NOT use an attribute name that ends in “Id”.
Doing this leads to confusion with attributes that end in “Id” that
are of type xs:ID. This includes the attribute in KeyType called “KeyPropertiesId”
and assuming I am correct about #3a above, it also includes PINKeyId and
MasterKeyId. In many schemas I’m familiar with, the attribute name
of the IDREF would just drop the “Id”. In some cases, the
name is appended with “Ref”. So in the case of KeyPropertiesType,
the reference attribute name would be either “KeyProperties” or “KeyPropertiesRef”
(I prefer the former which I believe is more common). [PH]
agree with you here lets settle for KeyProperties 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. 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. 7. The <Usage> element is correctly identified as
optional in the schema types KeyPropertiesType and KeyType but is described in
the spec text as “MANDATORY”. [PH]
Thanks, will change this before submitting 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. 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). 9. To aid with interoperability, I strongly suggest
defining constraints on the use of values of the type xs:dateTime. For
example, in SAML, the spec includes a section that states: All SAML time
values have the type xs:dateTime, which
is built in to the W3C XML Schema Datatypes specification [Schema2], and MUST
be expressed in UTC form, with no time zone component. SAML system entities SHOULD NOT
rely on time resolution finer than milliseconds. Implementations MUST NOT
generate time instants that specify leap seconds. [PH] agreed on this one and I will add it
to the spec 10. A nit – Just curious why the <StartDate> element is
listed after the <ExpiryDate> element in the sequences where they are
defined (KeyPropertiesType, KeyType, and DeviceInfoType). I usually think
of expiring something after the date it was enabled J. [PH] makes sense I am happy to change it *** 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). 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) 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) 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. 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 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 Thus, we would like
to have an element in the <DeviceInfo> element that can be used to
restrict use of the key(s) to the specific or “class” of device.
The element should be of type xs:string. I’m open to suggestion for
an element name for this. I can suggest something like
<BindingInfo> or <DeviceRestriction> but acknowledge those aren’t
really clear. 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 *** RE: 4. Review extension points are correct 1. While what was defined should work, it inhibits schema
validation since anything not recognized as the standard child elements will be
assumed to be extensions. I would prefer to see another approach that I’ve
seen used with success which defines a separate type for extensions that
requires grouping the undefined elements together. This approach makes it
VERY clear what elements have been added as extensions. The way it works is to
define something like: <xs:complexType
name="ExtensionsType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
maxOccurs="unbounded"/>
</xs:sequence> </xs:complexType>
This type is then
used in other elements that wish to be extensible. For example, the current
DeviceType would look like: <xs:complexType
name="DeviceType">
<xs:sequence>
<xs:element name="DeviceInfo" type="pskc:DeviceInfoType"
minOccurs="0"/>
<xs:element name="Key" type="pskc:KeyType"
maxOccurs="unbounded"/>
<xs:element name="UserId" type="xs:string"
minOccurs="0"/>
<xs:element name="Extensions" type=”pskc:ExtensionsType”
minOccurs="0"/>
</xs:sequence> </xs:complexType> I could then create
the following: <Device>
<DeviceInfo …>
…
</DeviceInfo> <Key
…>
…
</Key>
<UserId>user1</UserId>
<Extensions>
<MyExtension1>blah</Myextension1>
<YourExtension99>blahblah</YourExtension99>
</Extensions> </Device> [PH] I like this idea and will modify the
spec to encompass this Well, that’s
it for now. I realize we’re pretty late in the cycle to deal with
more edits, but I think some of these are pretty important to making the spec
more usable (at least for us). Thanks, Rob Philpott RSA,
the Security Division of EMC From: Philip Hoyer
[mailto:philip.hoyer at actividentity.com] Please find attached the latest work in
progress draft and related schema, TODOs:
Changes
made from version 4 are:
Extension points: Added a ‘<xs:any
namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>’ to
Added a ‘<xs:anyAttribute
namespace="##other"/>’ to:
<xs:attribute name="OTP" type="xs:boolean"
default="false"/>
<xs:attribute name="CR" type="xs:boolean"
default="false"/>
<xs:attribute name="Integrity" type="xs:boolean"
default="false"/>
<xs:attribute name="Encrypt" type="xs:boolean"
default="false"/>
<xs:attribute name="Unlock" type="xs:boolean"
default="false"/>
So I thought it would be wise to be able to extend this Outstanding
issues that need to be discussed:
Philip From:
andrea.doherty at rsa.com [mailto:andrea.doherty at rsa.com] Here is Philip Hoyer's response
to Rob's comments (see below), which we initially handled offline, and
then we decided it would be better to further the discussion on the mailing
list. -- Andrea
[PH] good point I was
thinking that xs:Id for KeyPropertiesId could be a good choice The KeyId
on the other hand is not really used to be referred to. Do you think it would
be better to use xs:ID for this aswell? And in case we use it now is it
backwards compatible to what we have?
[PH] valid comment and I
will think we should add this [PH] agreed [PH] so basically you are saying that any
high level entity (Key, Device, KeyContainer etc) should have an ID that is
xs:ID? The thought of DeviceId was to aggregate under a specific type the
elements that comprise the compound key to look up the device
[PH] agreed I think we
should add an xs:any [PH] this has been
extensively discussed at IETF and there are pros and cons for all approaches.
The pro’s of the name value approach is that it will be re-usable for the
ASN.1 spec and that we will have a semantic registry defined by IANA.
[PH] this has been
extensively discussed. And we opted for the name value pair approach. This mean
that all elements in Data can be parsed in the same manner and individually be
encrypted or not. There will be a centralized semantic registry by IANA, etc
[PH] why do you say that,
the name could be also be a namespace for an wholly encrypted or base64 encoded
XML sub node. I see your point though in terms of parsing here. Could you give
me an example of what you had in mind since we have considered quite a few use
cases and not come across the requirement for grouped extensions.
[PH] using xs:string for
plainvalue was discussed during the last IETF meeting (I personally am in favor
of it) but Sean Turner and the rest of the people did not see much value in it.
If we use string we will need to deice for specific data elements what the
encoding rules are. For example do we say for 8 byte unsigned int to encode
just string e.g. ‘60’ or leading 0 examples ‘00000060’.
I would appreciate your thoughts on this. Also how would we encode binary data
in string form base64 encoded?
[PH] agreed and see
answer above
[PH] if you are referring
to the fact that ‘<xs:attribute name="PINKeyId"
type="xs:string" use="required"/>’ is set to
required I agree with you. We should set this to ‘optional’. I do
not agree with your 90% use case analysis since the main use cases I have come
across where to transmit the initial random pin for PINPads tokens within the
same PSKC document from manufacturing to the validation server.
[PH] I agree we need to
make PINPolicy extensible and not put stuff into the Data elements of the
PINKey. Are there any other elements that you know of we should include now and
not just as an xs:any extension?
<Key
KeyId="07552252661"
KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
<Usage>
<ResponseFormat Length="4" Format="DECIMAL"/>
</Usage>
<Data Name="SECRET">
<PlainValue>MTIzNA==</PlainValue> </Data> </Key> [PH] I see your point. If we make PINKeyId optional as in the
comment above you can have a common PINPolicy as part of the shared
KeyProperties. I believe that would serve your purpose.
[PH] agreed, will change
|
_______________________________________________ KEYPROV mailing list KEYPROV at ietf.org https://www.ietf.org/mailman/listinfo/keyprov