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

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 3 Jul 2008 14:03:03 +0200

Please find attached the latest work in progress draft and related
schema,

TODOs:

1.	Hannes to change the IANA section relating XML tag registry
since not needed anymore
2.	Review the spec (Salah, Hannes, Andrea) especially the wording
around the new changes (please see KeyData Element definition in the new
spec)
3.	Add additional elements under KeyData based on input from Rob
Philpot
4.	Review extension points are correct

Changes made from version 4 are:

1.	Added optional Id element to the container in case another
document includes more than one container and wants to reference it
uniquely, this is of type xs:Id
2.	Made PINKeyId of PINPolicy optional (in version 4 it wrongly
became mandatory) 
3.	Changed KeyPropertiesType:KeyPropertiesId from type xs:String to
xs:ID
4.	Changed KeyType:KeyPropertiesId from type xs:string to be of
type xs:IDREF as it refers to the ID of the element of (3) see directly
above
5.	Added optional PINPolicyId attribute of type xs:ID to
PINPolicyType
6.	Added the KeyContainer:KeyProperties element that was missing
from version -04 (oversight).This is where the common properties for a
key are actually held within a container
7.	Changed PINPolicyType: WrongPINtry into WrongPINTry so that it
is proper camel-case but the discussed naming and changed to
'MaxFailedAttempts'
8.	Changed PINUsageMode 'InAlgo' to 'Algorithmic'
9.	Added description for added extension points (see below)
10.	Changed DeviceIdType to DeviceInfoType (please see other email
for rational to keep separate type and not move elements directly under
Device)
11.	Moved Keyporperties in front of device under KeyContainer for
more readability
12.	Changed Namespace as per Hannes proposal from
"urn:ietf:params:xml:ns:keyprov:container:1.0" to
"urn:ietf:params:xml:ns:keyprov:pskc:1.0"
13.	Cleaned up the way that attributes (no angled brackets) and
elements (angled brackets <elementName>) are described in the spec
14.	Corrected some spelling and grammar
15.	Changed schema and spec to new proposal that removes name value
pairs
16.	Added OCRA URI to the spec and added an example 
17.	Added TOTP URI to the spec and added an example 
18.	Added an example of KeyProperties 
19.	Added 'Append' to PIN for completeness. 

Extension points:

Added a '<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>' to 

1.	KeyContainerType
2.	KeyPropertiesType
3.	KeyType
4.	PINPolicy
5.	DeviceIDType
6.	DeviceType
7.	UsageType

Added a '<xs:anyAttribute namespace="##other"/>' to:

1.	UsageType (since it contains the attributes of '

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

1.	Most of the examples have been hand-composed in XML  so not
verified
2.	Some examples use explicit 'pskc:' namespace not sure we need to
do this but maybe we should be consistent 

Philip

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 30, 2008 4:36 PM
To: [email-masked]
Cc: Philip Hoyer
Subject: FW: [KEYPROV] [pskc] Latest draft of PSKC

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

 1.       Use of xs:ID attributes:

a.       The xs:ID datatype is only used in the DerivedKeyType
complexType.  xs:ID is the preferred mechanism for referring to other
XML elements in an instance document.  So why are custom attributes
defined to be able to referto elements of the types KeyPropertiesType
(the "KeyPropertiesId" attribute) and KeyType ("KeyId")? Why don't these
use xs:ID attributes?

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

b.      Why doesn't a KeyContainer have an (optional) ID that could be
used to reference it in an instance document?

[PH] valid comment and I will think we should add this 

c.       Same question for PINPolicy?

[PH] agreed

d.      The use of the DeviceIdType is inconsistent with other "ID"'s
(that are used for referential information).  The elements in the
DeviceIDType seem more appropriate for the DeviceType or KeyType
elements.  At a minimum, I would not call this a "DeviceIdType" (perhaps
"DeviceInfoType"?) but really, I would just put its elements directly in
the DeviceType complexType).  I would also give <Device> elements an
optional referential ID via xs:ID.

[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

e.      Section 5.2.1 says that the DeviceIdType is an extensible type,
but there are no extension points in it.

[PH] agreed I think we should add an xs:any

2.       We are really unhappy with the proposed extensibility
mechanism. This goes against general XML schema best practice. Defining
extension points via xs:any/xs:anyAttribute is vastly superior (IMO):

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

a.       The use of "Reserved data attribute names" as described in
section 7 is really difficult to work with. First, <Data> elements
should ONLY be used for "real" extensions... i.e. things that aren't
already known at the time the spec is written.  If we already know that
the items defined in section 7 are needed, they should just be defined
in the schema with their own element/attribute definitions. They should
not be "reserved" uses of the <DATA> element.  We just don't understand
the desire to do it this way. Having explicitly defined elements also
allows for more flexible datayping.

[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

b.      This mechanism only lets us create very simple name-value pair
extensions.  If we have some small groups of related extensions, we'd
really like to be able to define them externally in a private schema via
their own complexType definitions.  With the current method, it's going
to be very messy to add groups of extensions or extensions that have
more complex data values.

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

c.       It is also a pain for implementers to deal with the limitation
of the data typing available for unencrypted <Data> elements.  For
example, for a SecurID token with a display interval of 60 seconds, I
cannot simply use an xml schema-defined datatype of xs:integer with a
value of "60".  I have to Base64-encode the big-endian 2-byte binary
value for 60 seconds (and then decode it on the receiving end). Why is
this necessary?  I could define such an item with a single XML element,
but here I need 3 or 4.

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

d.      This approach does not produce "readable" XML since the data
values are always Base64-encoded.  That is just crazy when the data is
not sensitive in nature.  Please do not underestimate the value of being
able to look at data in an instance document and know what it is without
having to run it through a Base64 decoder! This is a major drawback.

[PH] agreed and see answer above

3.       RE: PINPolicy:

a.       If I specify a PINPolicy, I am forced to specify a PINKeyID,
which forces me to create another Key element (even if I don't have any
additional PIN policy info that I need to pass along in that Key
element). For 90% of the use cases, this referential style of
description is overkill and makes the instance document much more
complex than it needs to be. 

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

b.      The PINPolicy element only contains "policy" attributes for
"WrongPINtry" and "PINUsageMode" and the element is not directly
extensible.  Any extensions we need have to go in Data elements inside a
separate Key element that the PINPolicy then references.  IMO, PIN
policy info should be in the PINPolicy element, not in a separate "Key"
element! The only thing that should go in the Key element is a PIN value
that is being expressly communicated with the instance document.  That
is, a PIN value IS a key; PIN policy information IS NOT a key.

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

c.       It seems to us that there are additional universally-known PIN
policy attributes that should be included in the schema.  Things such as
the PIN's maximum and minimum length and it's data type (integer,
alphanumeric).  Unless these are part of the spec, we currently are
forced to create custom Data elements for them (and put them in a
referenced Key element). BTW - Just to be clear, I am talking about the
POLICY information associated with whatever PIN a user uses with their
token.  I'm not talking about the attributes of a specific PIN value
that can be expressed in a Key element.  As an example, to express a min
and max PIN length policy, we have to create custom Data elements in a
separate Key element (and also Base64 encode the values).  I'm sorry,
but this is getting ridiculous. 

           <Key KeyId="07552252661"

             KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">

              <Data Name="PIN_MIN_LENGTH">

                  <PlainValue>NA==</PlainValue>

              </Data>

              <Data Name="PIN_MAX_LENGTH">

                  <PlainValue>OA==</PlainValue>

              </Data>

           </Key>

[PH] no the format and length would be in the UsageElement of the
PINKey. I had hoped Example (Section 12.2 of the spec) would make that
clear here is the XML fragment:

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

Notes:

a.       If I had an xs:any extension point, I could express this in 2
lines of XML in the PinPolicy element.

b.      This example doesn't include the PIN format, which would require
me to either:

                                                                     i.
Use another custom Data element 

                                                                   ii.
Include a ResponseFormat element that then requires inclusion of a
"Length" attribute. But what would the Length attribute really mean in
this case?

d.      Why isn't a PINPolicy reusable across multiple tokens (it has no
ID that can be used in a reference from a token definition).  If I want
to define a PINPolicy that applies to multiple tokens, the PINPolicy
element needs its own ID.

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

e.      The "WrongPINtry" element name (in PINPolicyType) is not
consistent with the other camel-case names ("try" should be "Try").

[PH] agreed, will change

f.        In general, it is undesirable to create abbreviations such as
"InAlgo" (in PINUsageMode) to be used as XML keywords. To stay
consistent with "Local" and "Prepend", I would strongly suggest
something like "Embed" or "Algorithmic".
[PH[ we had Embed before and people got confused by the meaning. So
maybe Algorithmic is a better choice, that is why I tried to express the
use of the PIN in the algorithm as InAlgo. I do not feel very strong
about it. Maybe we can have a vote

4.       The use of "ResponseFormat" for describing a PIN is very
confusing.  The spec defines ResponseFormat as follows "The
ResponseFormat element defines the characteristics of the result of a
computation.  This defines the format of the OTP or of the response to a
challenge." A PIN is not the result of a "computation", nor is it a
response to a challenge.  It seems quite odd to use this Key construct
for a PIN. I think that either another usage type should be defined or
the ResponseFormat definition should be changed to also reflect its use
for describing a PIN.
[PH] Yes I think we need to change the description. I am getting a lot
of push back to include PIN requirements in the spec so I tried to
convince people that tit was a good idea without having to introduce to
many new schema types. Here you say it is odd to use the Key element for
the PIN value but above you agree that a PIN IS a Key. So I would keep
it in the Key element buy change description.

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

---

From: [email-masked]
Date: Tue, 8 Jul 2008 02:52:30 -0400

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. 

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

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.

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

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. 

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.

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

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.

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.

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.

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

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.

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. 

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

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>

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

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
Senior Technologist | e-Mail: [email-masked] | Office: (781)
515-7115 | Mobile: (617) 510-0893

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

TODOs:

 

Extension points:

1.	KeyContainerType
2.	KeyPropertiesType
3.	KeyType
4.	PINPolicy
5.	DeviceIDType
6.	DeviceType
7.	UsageType

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 8 Jul 2008 12:59:36 +0200

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: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 7:53 AM
To: Philip Hoyer; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value
pairs

[PH] ok fair enough I am happy to take it out 

[PH] agreed and probably more in line with other standards

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

[PH] agree with you here lets settle for KeyProperties

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

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

[PH] Thanks, will change this before submitting 

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

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

[PH] makes sense I am happy to change it

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

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

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

[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

</xs:complexType>

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

  <xs:sequence>

  </xs:sequence>

</xs:complexType> 

  <xs:sequence>

  </xs:sequence>

</xs:complexType>

<Device>

   <DeviceInfo ...>

      ...

   </DeviceInfo>

   <Key ...>

      ...

   </Key>

   <UserId>user1</UserId>

   <Extensions>

   </Extensions>

</Device>

[PH] I like this idea and will modify the spec to encompass this

Thanks,

Rob Philpott 

 

TODOs:

 

Extension points:

1.	KeyContainerType
2.	KeyPropertiesType
3.	KeyType
4.	PINPolicy
5.	DeviceIDType
6.	DeviceType
7.	UsageType

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 8 Jul 2008 04:09:58 -0700

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:[email-masked]] 
Sent: Tuesday, July 08, 2008 4:00 AM
To: [email-masked]; Pei, Mingliang; [email-masked];
[email-masked]; Hallam-Baker, Phillip; [email-masked]
Cc: [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value
pairs

Robert,

 

Thanks a lot again,

Philip

</xs:complexType>

 

  <xs:sequence>

  </xs:sequence>

</xs:complexType> 

  <xs:sequence>

  </xs:sequence>

</xs:complexType>

<Device>

   <DeviceInfo ...>

      ...

   </DeviceInfo>

   <Key ...>

      ...

   </Key>

   <UserId>user1</UserId>

   <Extensions>

   </Extensions>

</Device>

Thanks,

Rob Philpott 

 

TODOs:

 

Extension points:

1.	KeyContainerType 
2.	KeyPropertiesType 
3.	KeyType 
4.	PINPolicy 
5.	DeviceIDType 
6.	DeviceType 
7.	UsageType 

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 8 Jul 2008 13:56:01 +0200

Yes working on it right now, I will try my best , in case I will send
you over a draft with changes made so far.

From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 12:10 PM
To: Philip Hoyer; [email-masked]; [email-masked];
[email-masked]; Hallam-Baker, Phillip; [email-masked]
Cc: [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value
pairs

Hi Robert,

Philip,

Thanks,

- Ming

Robert,

 

Thanks a lot again,

Philip

</xs:complexType>

 

  <xs:sequence>

  </xs:sequence>

</xs:complexType> 

  <xs:sequence>

  </xs:sequence>

</xs:complexType>

<Device>

   <DeviceInfo ...>

      ...

   </DeviceInfo>

   <Key ...>

      ...

   </Key>

   <UserId>user1</UserId>

   <Extensions>

   </Extensions>

</Device>

Thanks,

Rob Philpott 

 

TODOs:

 

Extension points:

1.	KeyContainerType 
2.	KeyPropertiesType 
3.	KeyType 
4.	PINPolicy 
5.	DeviceIDType 
6.	DeviceType 
7.	UsageType 

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 8 Jul 2008 14:15:51 +0200

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

See comment from Robert below in the email.

Philip

Hi Robert,

Philip,

Thanks,

- Ming

Robert,

 

Thanks a lot again,

Philip

</xs:complexType>

 

  <xs:sequence>

  </xs:sequence>

</xs:complexType> 

  <xs:sequence>

  </xs:sequence>

</xs:complexType>

<Device>

   <DeviceInfo ...>

      ...

   </DeviceInfo>

   <Key ...>

      ...

   </Key>

   <UserId>user1</UserId>

   <Extensions>

   </Extensions>

</Device>

Thanks,

Rob Philpott 

 

TODOs:

 

Extension points:

1.	KeyContainerType 
2.	KeyPropertiesType 
3.	KeyType 
4.	PINPolicy 
5.	DeviceIDType 
6.	DeviceType 
7.	UsageType 

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 8 Jul 2008 15:19:33 +0200

Please find attached the latest work in progress draft and related
schema after the additions that address Robert Philpott's latest
comments (if they resulted in  changes to existing changes from draft
-04 they have been prefixed [UPDATE]),

TODOs:

1.	[UPDATE] Added optional Id element to the container in case
another document includes more than one container and wants to reference
it uniquely, this is of type xs:Id named 'ID'
2.	Made PINKeyId of PINPolicy optional (in version 4 it wrongly
became mandatory) 
3.	Changed KeyPropertiesType:KeyPropertiesId from type xs:String to
xs:ID
4.	[UPDATE] Changed KeyType:KeyPropertiesId from type xs:string to
be of type xs:IDREF as it refers to the ID of the element of (3) see
directly above, also renamed to simply KeyProperties
5.	[UPDATE] Removed PINPolicyId as not needed, Added optional
PINPolicyId attribute of type xs:ID to PINPolicyType - 
6.	Added the KeyContainer:KeyProperties element that was missing
from version -04 (oversight).This is where the common properties for a
key are actually held within a container
7.	Changed PINPolicyType: WrongPINtry into WrongPINTry so that it
is proper camel-case but the discussed naming and changed to
'MaxFailedAttempts'
8.	Changed PINUsageMode 'InAlgo' to 'Algorithmic'
9.	Added description for added extension points (see below)
10.	Changed DeviceIdType to DeviceInfoType (please see other email
for rational to keep separate type and not move elements directly under
Device)
11.	Moved Keyporperties in front of device under KeyContainer for
more readability
12.	Changed Namespace as per Hannes proposal from
"urn:ietf:params:xml:ns:keyprov:container:1.0" to
"urn:ietf:params:xml:ns:keyprov:pskc:1.0"
13.	Cleaned up the way that attributes (no angled brackets) and
elements (angled brackets <elementName>) are described in the spec
14.	Corrected some spelling and grammar
15.	Changed schema and spec to new proposal that removes name value
pairs
16.	Added OCRA URI to the spec and added an example 
17.	Added TOTP URI to the spec and added an example 
18.	Added an example of KeyProperties 
19.	Added 'Append' to PIN for completeness. 
20.	Corrected the wrong 'MANDATORY' in the usage description of
KeyType and KeyPropertiesType 
21.	Added the following comment the elements of type xs:dateTime:
"MUST be expressed in UTC form, with no time zone component.
Implementations SHOULD NOT rely on time resolution finer than
milliseconds and MUST NOT generate time instants that specify leap
seconds."
22.	Moved StartDates before ExpiryDates for easier readability
23.	Added the following sub-elements to PINPolicyType

	a.	<MinLength (OPTIONAL)>, the minimum lenght of a PIN that
can be set to protect this key. It MUST not be possible to set a PIN
shorter than this value. If the Format element is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
digits/characters. If the Format attribute is 'BASE64' or 'BINARY', this
value indicates the number of bytes of the unencoded value.
	b.	<MaxLength (OPTIONAL)>, the maximum lenght of a PIN that
can be set to protect this key. It MUST not be possible to set a PIN
longer than this value. If the Format element is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
digits/characters. If the Format attribute is 'BASE64' or 'BINARY', this
value indicates the number of bytes of the unencoded value.
	c.	<Format (OPTIONAL)>, defines the format of the PIN and
MUST be one of the values defined in Section 5.4.3

24.	 

[Update] Extension points:

Changed to model proposed by Rob Philpott declaring a new type:

              <xs:sequence>

                        <xs:any namespace="##other"
processContents="lax" maxOccurs="unbounded"/>

              </xs:sequence>

              <xs:attribute name="definition" type="xs:anyURI"
use="optional"/>

            </xs:complexType>

Which has been added as "<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/>"

To:

1.	KeyContainerType 
2.	KeyPropertiesType
3.	KeyType
4.	PINPolicy
5.	DeviceInfoType
6.	DeviceType
7.	UsageType

Please NOTE that KeyData still has the existing "<xs:any
namespace="##other" minOccurs="0" maxOccurs="unbounded"/>"

Because of the special nature of the KeyData element and subelements

PINUsageMode too maintains the existing   "<xs:any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/>"

Being an extensible enumeration

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Wed, 9 Jul 2008 16:39:21 +0200

Another day another edition.

I realized that the IntegerDataType was actually creating BigIntegers in
java since it was of type xs:integer and hence have changed it to xs:int
to more reflect what we need. And I have also renamed it to intDataType
to be in line with the longDataType used for counters.

The OCRA example was also corrected and some nits from Sean Turner abut
different spelling of crypto modules in the use cases.

Philip

TODOs:

24.	 

              <xs:sequence>

              </xs:sequence>

            </xs:complexType>

To:

1.	KeyContainerType 
2.	KeyPropertiesType
3.	KeyType
4.	PINPolicy
5.	DeviceInfoType
6.	DeviceType
7.	UsageType

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Pei, Mingliang" <[email-masked]>
Date: Wed, 9 Jul 2008 22:47:21 -0700

Hi Philip,
 
Here are some of my comments on the draft and a few minor fixes made.
See the attached version including my few changes.

Comments:
 
- Three issues with regard to defining algorithm URI: 
 
1. Shouldn't we use a permanent URI should be used instead of file
location? For example
 
TOTP and OCRA algorithm URI is defined by their current v00 RFC draft
URL. When the draft changes, we have to change the URI again.
 
URI:  
http://www.ietf.org/internet-drafts/draft-mraihi-totp-timebased-00.txt
<http://www.ietf.org/internet-drafts/draft-mraihi-totp-timebased-00.txt>

OCRA: 
http://www.ietf.org/internet-drafts/draft-mraihi-mutual-oath-hotp-varian
ts-07.txt#OCRA-1:HOTP-SHA512-8:C-QN08
<http://www.ietf.org/internet-drafts/draft-mraihi-mutual-oath-hotp-varia
nts-07.txt#OCRA-1:HOTP-SHA512-8:C-QN08> 
 
2. Consistency
 
HOTP: URI: http://www.ietf.org/keyprov/pskc#hotp
<http://www.ietf.org/keyprov/pskc#hotp> 
TOTP: URI: <RFC doc URL>
 
Let us use either the RFC URL (when final) or the style of HOTP as
above. Considering that hmac-sha1 URI isn't necessarily defined by its
RFC URL
 
http://www.ietf.org/rfc/rfc2104.txt
 
but
 
http://www.w3.org/2000/09/xmldsig#hmac-sha1
 
we don't have to use RFC draft URL for URI. We may continue to use the
pattern for HOTP to define TOTP and OCRA as follows for a consistent
approach.
 
HOTP  URI: http://www.ietf.org/keyprov/pskc#totp
<http://www.ietf.org/keyprov/pskc#totp> 
OCRA URI: http://www.ietf.org/keyprov/pskc#OCRA-1:HOTP-SHA512-8:C-QN08
<http://www.ietf.org/keyprov/pskc#OCRA-1:HOTP-SHA512-8:C-QN08> 
 
The pros of this pattern is the URI doesn't attach to a moving URL from
draft to draft. The cons is that the URI is somehow associated with
pskc.
 
Suggest to track this an issue to discuss during IETF-72.
 
3. OCRA URI definition with regard to the parameters
 
OCRA-1:HOTP-SHA512-8:C-QN08
 
Shall we just use "-" for all?
Shall we list all options for registration here or we want the IANA to
look at the OCRA document to find all options?
 
- Should we also use ExtensionsType in KeyDataType in place of the
following?
 
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
 
- Should we recommend <ValueMAC> in all key data where value is
encrypted? In particular, 
should we add a ValueMAC for secxzgzbret data in PBE based example 11.4?
We had it in v1.3.
I prefer to add it.
 
- Element name for type xs:ID
 
KeyPropertiesId in <KeyPropertiesType>
Id in <DerivedKeyType>
 
Shall we also change them to "ID" for consistency?
 
- Section 5.2 The following sentence doesn't sound smooth:
 
      "KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm
      to use with the secret key, for profiles are described in
      Section 6.3"
 
Should it be
 
      "KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm
      to use with a secret key for the profiles described in
      Section 6.3"
 
- Changes made:
 
1. Section 11.4 and 11.5 Example change:
 
<PlainValue>0</PlainValue>
 
to
 
<pskc:PlainValue>0</pskc:PlainValue>
 
2. Change all occurence of pskc:ExtensionType to pskc:ExtensionsType
 
- Ming

From: Philip Hoyer [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 7:39 AM
To: Pei, Mingliang; [email-masked]; Hannes Tschofenig;
Hallam-Baker, Phillip; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value
pairs

Philip

TODOs:

24.	  

              <xs:sequence>

              </xs:sequence>

            </xs:complexType>

To:

1.	KeyContainerType 
2.	KeyPropertiesType 
3.	KeyType 
4.	PINPolicy 
5.	DeviceInfoType 
6.	DeviceType 
7.	UsageType 

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 10 Jul 2008 10:55:27 +0200

Ming,

Thanks for the time to help out first.

On the matter of URIs I actually agree with you and we should change the
current spec to become:

OCRA: URI:
http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters)

TOTP: URI: http://www.ietf.org/keyprov/pskc#totp

Since PSKC is mainly to transmit keys regarding a specific use I do not
think we need to have the OCRA '-' means all approach. One will always
have specific OCRA suite parameters.

 

No I strongly believe we should NOT do this here because of the
consistency of the subelement structure. 

Everything underneath KeyData follows:

<elementName>

            <PlainValue>

            <ENcryptedValue>

</elementName>

If we would add an Extensions tag this consistent structure would be
broken.

No we really discussed this with Magnus, ValueMAC should only be there
for algorithms where integrity checks are not built in. Actually our
examples using AES CBC from my understanding have integrity checks built
into the algorithm so we would not need this either.

Maybe it would be better to have a recommendation for which algorithms
it should be there. Do you have an idea of which supported algorithms do
have built in integrity checks?

Yes you are right KeypropertisId should be just 'ID' I will change this.

Should it be

Agree will change it

Philip

From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Thursday, July 10, 2008 6:47 AM
To: Philip Hoyer; [email-masked]; Hannes Tschofenig;
Hallam-Baker, Phillip; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value
pairs

Hi Philip,

Comments:

URI:

OCRA:

2. Consistency

but

Should it be

- Changes made:

to

- Ming

Philip

TODOs:

24.	 

              <xs:sequence>

              </xs:sequence>

            </xs:complexType>

To:

1.	KeyContainerType 
2.	KeyPropertiesType 
3.	KeyType 
4.	PINPolicy 
5.	DeviceInfoType 
6.	DeviceType 
7.	UsageType 

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 10 Jul 2008 12:09:03 +0200

Please find attached the latest work in progress draft and related
schema after Ming Pei's and Sean Turner's latest comments.

TODOs:

24.	Corrected consistency of term cryptomodules in use case
description
25.	Ming corrected use of pskc:ExtensionType to pskc:ExtensionsType
26.	IntegerDataType was actually creating BigIntegers in java since
it was of type xs:integer and hence have changed it to xs:int to more
reflect what we need. And I have also renamed it to intDataType to be in
line with the longDataType used for counters.
27.	Changed KeyPropertiesId to 'ID' to be in line with best
practices and comment received from Robert Phillpot
28.	Changed OCRA and TOTP URI from pointing at IETF draft to be
inline with HOTP URI

	a.	HOTP: URI: http://www.ietf.org/keyprov/pskc#hotp
<http://www.ietf.org/keyprov/pskc#hotp> 
	b.	OCRA: URI: 
http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters)
	c.	TOTP: URI: http://www.ietf.org/keyprov/pskc#totp

29.	Corrected the ambiguous description of KeypProperties in section
5.1 (one or more) . Thanks Sean Turner
30.	Added a minOccurs="1" to the Device in the KeyContainer making
it more obvious that it is MANDATORY. Thanks Sean Turner
31.	Corrected the erroneous MANDATORY in section error 5.4.2 to
(OPTIONAL). Thanks Sean Turner
32.	Corrected the erroneous MANDATORY in section error 5.4.2.1.1 to
(OPTIONAL). Thanks Sean Turner
33.	Added Sean Turner and Robert Philpott to the acknowledgement
section.

 

              <xs:sequence>

              </xs:sequence>

            </xs:complexType>

To:

1.	KeyContainerType 
2.	KeyPropertiesType
3.	KeyType
4.	PINPolicy
5.	DeviceInfoType
6.	DeviceType
7.	UsageType

 

 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: [email-masked]
Date: Thu, 10 Jul 2008 16:33:21 -0400

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 

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

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

Philip

[RSP] <snip>

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

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

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

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

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:

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.

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

[RSP] <snip>

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:

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

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

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

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

</xs:complexType>

[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

---

From: [email-masked]
Date: Sat, 12 Jul 2008 23:52:31 -0400

Philip,
 
Great job on the spec!  The new organization and wording look good.  An editorial review would be help correct minor typos.  Otherwise, just two comments on the content:
 
1. Section 5.4.1 KeyData - states that "all elements within Data hence obey a simple structure in that they MUST have".  "MUST" does not match the element structure in that the text implies both PlainValue AND EncryptedValue are required, when the definition shows that a choice between PlainValue and EncryptedValue is allowed.  Further, the "MUST" implies that ValueMac is required when it is defined as optional (see definition that follows in XML).
 
2. Section 8.4.4 - Please add a sub-section for SecurID-AES-Counter, where Class = OTP, URI, Algorithm Definition, and Identifier Definition = http://www.rsa.com/names/2008/04/algorithms/SecurID#SecurID-AES128-Counter <https://email.emc.com/exchweb/bin/redir.asp?URL=https://email.emc.com/exchweb/bin/redir.asp?URL=http://www.rsa.com/names/2008/04/algorithms/SecurID%2523SecurID-AES128-Counter> .
 
Andrea

From: Philip Hoyer [mailto:[email-masked]]
Sent: Thu 7/10/2008 6:09 AM
To: Philip Hoyer; Pei, Mingliang; [email-masked]; Hannes Tschofenig; Hallam-Baker, Phillip; Philpott, Robert; Doherty, Andrea
Cc: [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs

Please find attached the latest work in progress draft and related schema after Ming Pei's and Sean Turner's latest comments.

TODOs:

1.	Hannes to change the IANA section relating XML tag registry since not needed anymore 
2.	Review the spec (Salah, Hannes, Andrea) especially the wording around the new changes (please see KeyData Element definition in the new spec) 
3.	Add additional elements under KeyData based on input from Rob Philpot 
4.	Review extension points are correct 

1.	[UPDATE] Added optional Id element to the container in case another document includes more than one container and wants to reference it uniquely, this is of type xs:Id named 'ID' 
2.	Made PINKeyId of PINPolicy optional (in version 4 it wrongly became mandatory) 
3.	Changed KeyPropertiesType:KeyPropertiesId from type xs:String to xs:ID 
4.	[UPDATE] Changed KeyType:KeyPropertiesId from type xs:string to be of type xs:IDREF as it refers to the ID of the element of (3) see directly above, also renamed to simply KeyProperties 
5.	[UPDATE] Removed PINPolicyId as not needed, Added optional PINPolicyId attribute of type xs:ID to PINPolicyType - 
6.	Added the KeyContainer:KeyProperties element that was missing from version -04 (oversight).This is where the common properties for a key are actually held within a container 
7.	Changed PINPolicyType: WrongPINtry into WrongPINTry so that it is proper camel-case but the discussed naming and changed to 'MaxFailedAttempts' 
8.	Changed PINUsageMode 'InAlgo' to 'Algorithmic' 
9.	Added description for added extension points (see below) 
10.	Changed DeviceIdType to DeviceInfoType (please see other email for rational to keep separate type and not move elements directly under Device) 
11.	Moved Keyporperties in front of device under KeyContainer for more readability 
12.	Changed Namespace as per Hannes proposal from "urn:ietf:params:xml:ns:keyprov:container:1.0" to "urn:ietf:params:xml:ns:keyprov:pskc:1.0" 
13.	Cleaned up the way that attributes (no angled brackets) and elements (angled brackets <elementName>) are described in the spec 
14.	Corrected some spelling and grammar 
15.	Changed schema and spec to new proposal that removes name value pairs 
16.	Added OCRA URI to the spec and added an example 
17.	Added TOTP URI to the spec and added an example 
18.	Added an example of KeyProperties 
19.	Added 'Append' to PIN for completeness. 
20.	Corrected the wrong 'MANDATORY' in the usage description of KeyType and KeyPropertiesType 
21.	Added the following comment the elements of type xs:dateTime: "MUST be expressed in UTC form, with no time zone component. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds." 
22.	Moved StartDates before ExpiryDates for easier readability 
23.	Added the following sub-elements to PINPolicyType 

	a.	<MinLength (OPTIONAL)>, the minimum lenght of a PIN that can be set to protect this key. It MUST not be possible to set a PIN shorter than this value. If the Format element is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of digits/characters. If the Format attribute is 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value. 
	b.	<MaxLength (OPTIONAL)>, the maximum lenght of a PIN that can be set to protect this key. It MUST not be possible to set a PIN longer than this value. If the Format element is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of digits/characters. If the Format attribute is 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value. 
	c.	<Format (OPTIONAL)>, defines the format of the PIN and MUST be one of the values defined in Section 5.4.3 

24.	Corrected consistency of term cryptomodules in use case description 
25.	Ming corrected use of pskc:ExtensionType to pskc:ExtensionsType 
26.	IntegerDataType was actually creating BigIntegers in java since it was of type xs:integer and hence have changed it to xs:int to more reflect what we need. And I have also renamed it to intDataType to be in line with the longDataType used for counters. 
27.	Changed KeyPropertiesId to 'ID' to be in line with best practices and comment received from Robert Phillpot 
28.	Changed OCRA and TOTP URI from pointing at IETF draft to be inline with HOTP URI 

	a.	HOTP: URI: http://www.ietf.org/keyprov/pskc#hotp <http://www.ietf.org/keyprov/pskc#hotp>  
	b.	OCRA: URI: http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters) 
	c.	TOTP: URI: http://www.ietf.org/keyprov/pskc#totp 

29.	Corrected the ambiguous description of KeypProperties in section 5.1 (one or more) . Thanks Sean Turner 
30.	Added a minOccurs="1" to the Device in the KeyContainer making it more obvious that it is MANDATORY. Thanks Sean Turner 
31.	Corrected the erroneous MANDATORY in section error 5.4.2 to (OPTIONAL). Thanks Sean Turner 
32.	Corrected the erroneous MANDATORY in section error 5.4.2.1.1 to (OPTIONAL). Thanks Sean Turner 
33.	Added Sean Turner and Robert Philpott to the acknowledgement section. 

 

              <xs:sequence>

                        <xs:any namespace="##other" processContents="lax" maxOccurs="unbounded"/>

              </xs:sequence>

              <xs:attribute name="definition" type="xs:anyURI" use="optional"/>

            </xs:complexType>

Which has been added as "<xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/>"

To:

1.	KeyContainerType 
2.	KeyPropertiesType 
3.	KeyType 
4.	PINPolicy 
5.	DeviceInfoType 
6.	DeviceType 
7.	UsageType 

Please NOTE that KeyData still has the existing "<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>"

PINUsageMode too maintains the existing   "<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>"

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

 

1.	Most of the examples have been hand-composed in XML  so not verified 
2.	Some examples use explicit 'pskc:' namespace not sure we need to do this but maybe we should be consistent 

Philip

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

a.       The xs:ID datatype is only used in the DerivedKeyType complexType.  xs:ID is the preferred mechanism for referring to other XML elements in an instance document.  So why are custom attributes defined to be able to referto elements of the types KeyPropertiesType (the "KeyPropertiesId" attribute) and KeyType ("KeyId")? Why don't these use xs:ID attributes?

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

b.      Why doesn't a KeyContainer have an (optional) ID that could be used to reference it in an instance document?

[PH] agreed

d.      The use of the DeviceIdType is inconsistent with other "ID"'s (that are used for referential information).  The elements in the DeviceIDType seem more appropriate for the DeviceType or KeyType elements.  At a minimum, I would not call this a "DeviceIdType" (perhaps "DeviceInfoType"?) but really, I would just put its elements directly in the DeviceType complexType).  I would also give <Device> elements an optional referential ID via xs:ID.

[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

e.      Section 5.2.1 says that the DeviceIdType is an extensible type, but there are no extension points in it.

2.       We are really unhappy with the proposed extensibility mechanism. This goes against general XML schema best practice. Defining extension points via xs:any/xs:anyAttribute is vastly superior (IMO):

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

a.       The use of "Reserved data attribute names" as described in section 7 is really difficult to work with. First, <Data> elements should ONLY be used for "real" extensions... i.e. things that aren't already known at the time the spec is written.  If we already know that the items defined in section 7 are needed, they should just be defined in the schema with their own element/attribute definitions. They should not be "reserved" uses of the <DATA> element.  We just don't understand the desire to do it this way. Having explicitly defined elements also allows for more flexible datayping.

[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

b.      This mechanism only lets us create very simple name-value pair extensions.  If we have some small groups of related extensions, we'd really like to be able to define them externally in a private schema via their own complexType definitions.  With the current method, it's going to be very messy to add groups of extensions or extensions that have more complex data values.

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

c.       It is also a pain for implementers to deal with the limitation of the data typing available for unencrypted <Data> elements.  For example, for a SecurID token with a display interval of 60 seconds, I cannot simply use an xml schema-defined datatype of xs:integer with a value of "60".  I have to Base64-encode the big-endian 2-byte binary value for 60 seconds (and then decode it on the receiving end). Why is this necessary?  I could define such an item with a single XML element, but here I need 3 or 4.

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

d.      This approach does not produce "readable" XML since the data values are always Base64-encoded.  That is just crazy when the data is not sensitive in nature.  Please do not underestimate the value of being able to look at data in an instance document and know what it is without having to run it through a Base64 decoder! This is a major drawback.

3.       RE: PINPolicy:

a.       If I specify a PINPolicy, I am forced to specify a PINKeyID, which forces me to create another Key element (even if I don't have any additional PIN policy info that I need to pass along in that Key element). For 90% of the use cases, this referential style of description is overkill and makes the instance document much more complex than it needs to be. 

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

b.      The PINPolicy element only contains "policy" attributes for "WrongPINtry" and "PINUsageMode" and the element is not directly extensible.  Any extensions we need have to go in Data elements inside a separate Key element that the PINPolicy then references.  IMO, PIN policy info should be in the PINPolicy element, not in a separate "Key" element! The only thing that should go in the Key element is a PIN value that is being expressly communicated with the instance document.  That is, a PIN value IS a key; PIN policy information IS NOT a key.

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

c.       It seems to us that there are additional universally-known PIN policy attributes that should be included in the schema.  Things such as the PIN's maximum and minimum length and it's data type (integer, alphanumeric).  Unless these are part of the spec, we currently are forced to create custom Data elements for them (and put them in a referenced Key element). BTW - Just to be clear, I am talking about the POLICY information associated with whatever PIN a user uses with their token.  I'm not talking about the attributes of a specific PIN value that can be expressed in a Key element.  As an example, to express a min and max PIN length policy, we have to create custom Data elements in a separate Key element (and also Base64 encode the values).  I'm sorry, but this is getting ridiculous. 

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

[PH] no the format and length would be in the UsageElement of the PINKey. I had hoped Example (Section 12.2 of the spec) would make that clear here is the XML fragment:

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

a.       If I had an xs:any extension point, I could express this in 2 lines of XML in the PinPolicy element.

b.      This example doesn't include the PIN format, which would require me to either:

                                                                     i.            Use another custom Data element 

                                                                   ii.            Include a ResponseFormat element that then requires inclusion of a "Length" attribute. But what would the Length attribute really mean in this case?

d.      Why isn't a PINPolicy reusable across multiple tokens (it has no ID that can be used in a reference from a token definition).  If I want to define a PINPolicy that applies to multiple tokens, the PINPolicy element needs its own ID.

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

e.      The "WrongPINtry" element name (in PINPolicyType) is not consistent with the other camel-case names ("try" should be "Try").

[PH] agreed, will change

f.        In general, it is undesirable to create abbreviations such as "InAlgo" (in PINUsageMode) to be used as XML keywords. To stay consistent with "Local" and "Prepend", I would strongly suggest something like "Embed" or "Algorithmic".
[PH[ we had Embed before and people got confused by the meaning. So maybe Algorithmic is a better choice, that is why I tried to express the use of the PIN in the algorithm as InAlgo. I do not feel very strong about it. Maybe we can have a vote

4.       The use of "ResponseFormat" for describing a PIN is very confusing.  The spec defines ResponseFormat as follows "The ResponseFormat element defines the characteristics of the result of a computation.  This defines the format of the OTP or of the response to a challenge." A PIN is not the result of a "computation", nor is it a response to a challenge.  It seems quite odd to use this Key construct for a PIN. I think that either another usage type should be defined or the ResponseFormat definition should be changed to also reflect its use for describing a PIN.
[PH] Yes I think we need to change the description. I am getting a lot of push back to include PIN requirements in the spec so I tried to convince people that tit was a good idea without having to introduce to many new schema types. Here you say it is odd to use the Key element for the PIN value but above you agree that a PIN IS a Key. So I would keep it in the Key element buy change description.

---

From: [email-masked]
Date: Sun, 13 Jul 2008 00:05:32 -0400

It appears the URI in #2 of my last email got corrupted.  Here is the email again without the error:
===================================
Philip,

2. Section 8.4.4 - Please add a sub-section for SecurID-AES-Counter, where Class = OTP, URI, Algorithm Definition, and Identifier Definition = http://www.rsa.com/names/2008/04/algorithms/SecurID#SecurID-AES128-Counter.
 
Andrea

From: [email-masked] on behalf of [email-masked]
Sent: Sat 7/12/2008 11:52 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Philpott, Robert
Cc: [email-masked]
Subject: Re: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs

Philip,

Andrea

TODOs:

              <xs:sequence>

              </xs:sequence>

            </xs:complexType>

To:

1.      KeyContainerType
2.      KeyPropertiesType
3.      KeyType
4.      PINPolicy
5.      DeviceInfoType
6.      DeviceType
7.      UsageType

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661"

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 14 Jul 2008 13:56:00 +0200

Rob,

Please see comments inline [PH2]

Thanks again for all your help,

Philip

Sent: Thursday, July 10, 2008 9:33 PM

Hi folks,

Cheers,

Rob Philpott 

device or class of device (sorry for the long sentence :-)).  

Philip

[PH2] understood and added to submitted spec

[RSP] <snip>

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

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

[RSP] <snip>

In <DeviceType>, change:

To

In <KeyType>, add:

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.

 

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

 

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

</xs:complexType>

[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

[PH2] changed wording 

[PH2] Changed this, thanks for the catch!

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)

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

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 14 Jul 2008 14:02:27 +0200

Thanks for comments Andrea, 
See my answers [PH[ inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, July 13, 2008 5:06 AM
To: [email-masked]; 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

It appears the URI in #2 of my last email got corrupted.  Here is the
email again without the error:
===================================
Philip,

Great job on the spec!  The new organization and wording look good.  An
editorial review would be help correct minor typos.  Otherwise, just two
comments on the content:

1. Section 5.4.1 KeyData - states that "all elements within Data hence
obey a simple structure in that they MUST have".  "MUST" does not match
the element structure in that the text implies both PlainValue AND
EncryptedValue are required, when the definition shows that a choice
between PlainValue and EncryptedValue is allowed.  Further, the "MUST"
implies that ValueMac is required when it is defined as optional (see
definition that follows in XML).

[PH] changed this with clarifications for spec

2. Section 8.4.4 - Please add a sub-section for SecurID-AES-Counter,
where Class = OTP, URI, Algorithm Definition, and Identifier Definition
=
http://www.rsa.com/names/2008/04/algorithms/SecurID#SecurID-AES128-Count
er.
 
[PH] added to spec

Andrea

From: [email-masked] on behalf of [email-masked]
Sent: Sat 7/12/2008 11:52 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
Philpott, Robert
Cc: [email-masked]
Subject: Re: [KEYPROV] [pskc] Latest draft of PSKC - no more name value
pairs

Philip,

Great job on the spec!  The new organization and wording look good.  An
editorial review would be help correct minor typos.  Otherwise, just two
comments on the content:

1. Section 5.4.1 KeyData - states that "all elements within Data hence
obey a simple structure in that they MUST have".  "MUST" does not match
the element structure in that the text implies both PlainValue AND
EncryptedValue are required, when the definition shows that a choice
between PlainValue and EncryptedValue is allowed.  Further, the "MUST"
implies that ValueMac is required when it is defined as optional (see
definition that follows in XML).

2. Section 8.4.4 - Please add a sub-section for SecurID-AES-Counter,
where Class = OTP, URI, Algorithm Definition, and Identifier Definition
=
http://www.rsa.com/names/2008/04/algorithms/SecurID#SecurID-AES128-Count
er
<https://email.emc.com/exchweb/bin/redir.asp?URL=https://email.emc.com/e
xchweb/bin/redir.asp?URL=http://www.rsa.com/names/2008/04/algorithms/Sec
urID%2523SecurID-AES128-Counter> .

Andrea

From: Philip Hoyer [mailto:[email-masked]]
Sent: Thu 7/10/2008 6:09 AM
To: Philip Hoyer; Pei, Mingliang; [email-masked]; Hannes
Tschofenig; Hallam-Baker, Phillip; Philpott, Robert; Doherty, Andrea
Cc: [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value
pairs

TODOs:

              <xs:sequence>

              </xs:sequence>

            </xs:complexType>

To:

1.      KeyContainerType
2.      KeyPropertiesType
3.      KeyType
4.      PINPolicy
5.      DeviceInfoType
6.      DeviceType
7.      UsageType

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661"

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 14 Jul 2008 14:08:48 +0200

Please find attached the draft of the PSKC submitted to IETF today.

It contains some additional update based on late comments from Rob
Philpott and Andrea Doherty.

29.	Corrected the ambiguous description of KeypProperties in section
5.1 (one or more) . Thanks Sean Turner
30.	Added a minOccurs="1" to the Device in the KeyContainer making
it more obvious that it is MANDATORY. Thanks Sean Turner
31.	Corrected the erroneous MANDATORY in section error 5.4.2 to
(OPTIONAL). Thanks Sean Turner
32.	Corrected the erroneous MANDATORY in section error 5.4.2.1.1 to
(OPTIONAL). Thanks Sean Turner
33.	Added Sean Turner and Robert Philpott to the acknowledgement
section.
34.	Added a <DeviceBinding> optional element based on feedback from
Rob Phillpot.
35.	Removed IANA section for XML tag registry
36.	Added clarification to KeyId and MasterKeyId that they are
external to the document and not XML Ids
37.	Added an optional UserId to the Key "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 <xref
target="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."
38.	Renamed the User binding in deviceType from 'UserId' to 'User'
and changed description 
39.	Cleaned up definition of MANDTORY/OPTIONAL element description
(outside of angled brackets now)
40.	Cleaned up definition of ChallengeFormat and ResponseFormat
(stykle was different from rest of spec)
41.	Changed description of KeyData element structure - thanks Andrea
for comment
42.	Added RSA SecurID-AES-Counter algorithm defintion

 

              <xs:sequence>

              </xs:sequence>

            </xs:complexType>

To:

1.	KeyContainerType 
2.	KeyPropertiesType
3.	KeyType
4.	PINPolicy
5.	DeviceInfoType
6.	DeviceType
7.	UsageType

 

1.	Do we need some for of IANA registry to register the extensions
to the format
2.	Issue about KeyId:

"

" Rob Philpot

3.	Issue about Time KeyData 
	"

" - Rob Philpot

4.	 

Philip

-- Andrea

[PH] agreed

3.       RE: PINPolicy:

           <Key KeyId="07552252661"

              </Data>

              </Data>

           </Key>

       <Key KeyId="07552252661" 

            <Usage>

            </Usage>

            <Data Name="SECRET">

            </Data>

        </Key>

Notes:

                                                                     i.

                                                                   ii.

[PH] agreed, will change

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2008 15:31:02 +0300

Hi Philip, Salah, Ming,

thanks a lot for the draft update and for addressing so many of the 
discussed issues.
We are getting very close to Working Group Last Call.

Ciao
Hannes

Philip Hoyer wrote:
> *Changes made from version 4 are:*
>
>       another document includes more than one container and wants to
>       reference it uniquely, this is of type xs:Id named ‘ID’
>       be of type xs:IDREF as it refers to the ID of the element of (3)
>       see directly above, also renamed to simply KeyProperties
>       from version -04 (oversight).This is where the common properties
>       for a key are actually held within a container
>    7. Changed PINPolicyType: WrongPINtry into WrongPIN*T*ry so that it
>       ‘MaxFailedAttempts’
>    8. Changed PINUsageMode ‘InAlgo’ to ‘Algorithmic’
>       for rational to keep separate type and not move elements
>       directly under Device)
>       “urn:ietf:params:xml:ns:keyprov:pskc:1.0"
>   19. Added ‘Append’ to PIN for completeness.
>   20. Corrected the wrong ‘MANDATORY’ in the usage description of
>       “MUST be expressed in UTC form, with no time zone component.
>       milliseconds and MUST NOT generate time instants that specify
>       leap seconds.”
>          1. <MinLength (OPTIONAL)>, the minimum lenght of a PIN that
>             can be set to protect this key. It MUST not be possible to
>             set a PIN shorter than this value. If the Format element
>             is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value
>             indicates the number of digits/characters. If the Format
>             attribute is 'BASE64' or 'BINARY', this value indicates
>             the number of bytes of the unencoded value.
>          2. <MaxLength (OPTIONAL)>, the maximum lenght of a PIN that
>             can be set to protect this key. It MUST not be possible to
>             set a PIN longer than this value. If the Format element is
>             'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value
>             indicates the number of digits/characters. If the Format
>             attribute is 'BASE64' or 'BINARY', this value indicates
>             the number of bytes of the unencoded value.
>          3. <Format (OPTIONAL)>, defines the format of the PIN and
>       it was of type xs:integer and hence have changed it to xs:int to
>       more reflect what we need. And I have also renamed it to
>       intDataType to be in line with the longDataType used for counters.
>   27. Changed KeyPropertiesId to ‘ID’ to be in line with best
>          1. HOTP: URI: http://www.ietf.org/keyprov/pskc#hotp
>          2. OCRA: URI: http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra
>             <http://www.ietf.org/keyprov/pskc#OCRA-1:%28ocra>_suite_parameters)
>          3. TOTP: URI: http://www.ietf.org/keyprov/pskc#totp
>   30. Added a minOccurs=”1” to the Device in the KeyContainer making
>   37. Added an optional UserId to the Key “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 <xref target="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.”
>   38. Renamed the User binding in deviceType from ‘UserId’ to ‘User’
>       and changed description
>   41. Changed description of KeyData element structure – thanks Andrea
>       for comment
> Which has been added as “<xs:element name="Extensions" 
> type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/>”
>
> To:
>
>    1. KeyContainerType
>    2. KeyPropertiesType
>    3. KeyType
>    4. PINPolicy
>    5. DeviceInfoType
>    6. DeviceType
>    7. UsageType
>
> Please NOTE that KeyData still has the existing “<xs:any 
> namespace="##other" minOccurs="0" maxOccurs="unbounded"/>”
>
> PINUsageMode too maintains the existing “<xs:any namespace="##other" 
> minOccurs="0" maxOccurs="unbounded"/>”
>
> Added a ‘<xs:anyAttribute namespace="##other"/>’ to:
>
>    1. UsageType (since it contains the attributes of ‘
>
> *Outstanding issues that need to be discussed:*
>
> “
> 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.
>
> “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 
> */[RSP] I suspected that might be the case. However, based on my 
> 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" 
> */ /*
> */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 
> characters./*
> “ Rob Philpot
>       “
> */BTW, we’d also like to raise a concern about defining <Time> 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./*
>
> “ – Rob Philpot
>
>   4.
>
> Philip
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Friday, May 30, 2008 4:36 PM
> *To:* [email-masked]
> *Cc:* Philip Hoyer
> *Subject:* FW: [KEYPROV] [pskc] Latest draft of PSKC
>
> 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
>
>
> a. The xs:ID datatype is only used in the DerivedKeyType complexType. 
> xs:ID is the preferred mechanism for referring to other XML elements 
> in an instance document. So why are custom attributes defined to be 
> able to referto elements of the types KeyPropertiesType (the 
> “KeyPropertiesId” attribute) and KeyType (“KeyId”)? Why don’t these 
> use xs:ID attributes?
>
> [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 
> aswell? And in case we use it now is it backwards compatible to what 
> we have?
>
>
> b. Why doesn’t a KeyContainer have an (optional) ID that could be used 
> to reference it in an instance document?
>
> d. The use of the DeviceIdType is inconsistent with other “ID”’s (that 
> are used for referential information). The elements in the 
> elements. At a minimum, I would not call this a “DeviceIdType” 
> (perhaps “DeviceInfoType”?) but really, I would just put its elements 
> directly in the DeviceType complexType). I would also give <Device> 
> elements an optional referential ID via xs:ID.
>
> 2. We are really unhappy with the proposed extensibility mechanism. 
> This goes against general XML schema best practice. Defining extension 
> points via xs:any/xs:anyAttribute is vastly superior (IMO):
>
> [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.
>
>
>
> a. The use of “Reserved data attribute names” as described in section 
> 7 is really difficult to work with. First, <Data> elements should ONLY 
> be used for “real” extensions… i.e. things that aren’t already known 
> at the time the spec is written. If we already know that the items 
> defined in section 7 are needed, they should just be defined in the 
> schema with their own element/attribute definitions. They should not 
> be “reserved” uses of the <DATA> element. We just don’t understand the 
> desire to do it this way. Having explicitly defined elements also 
> in the same manner and individually be encrypted or not. There will be 
> a centralized semantic registry by IANA, etc
>
>
> extensions. If we have some small groups of related extensions, we’d 
> really like to be able to define them externally in a private schema 
> via their own complexType definitions. With the current method, it’s 
> going to be very messy to add groups of extensions or extensions that 
> have more complex data values.
>
> 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.
>
>
> c. It is also a pain for implementers to deal with the limitation of 
> the data typing available for unencrypted <Data> elements. For 
> value of “60”. I have to Base64-encode the big-endian 2-byte binary 
> 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?
>
>
>
> d. This approach does not produce “readable” XML since the data values 
> are always Base64-encoded. That is just crazy when the data is not 
> sensitive in nature. Please do not underestimate the value of being 
> able to look at data in an instance document and know what it is 
> without having to run it through a Base64 decoder! This is a major 
> drawback.
>
> a. If I specify a PINPolicy, I am forced to specify a PINKeyID, which 
> forces me to create another Key element (even if I don’t have any 
> [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.
>
>
>
> b. The PINPolicy element only contains “policy” attributes for 
> “WrongPINtry” and “PINUsageMode” and the element is not directly 
> extensible. Any extensions we need have to go in Data elements inside 
> a separate Key element that the PINPolicy then references. IMO, PIN 
> policy info should be in the PINPolicy element, not in a separate 
> “Key” element! The only thing that should go in the Key element is a 
> PIN value that is being expressly communicated with the instance 
> document. That is, a PIN value IS a key; PIN policy information IS NOT 
> a key.
>
> [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?
>
>
> policy attributes that should be included in the schema. Things such 
> as the PIN’s maximum and minimum length and it’s data type (integer, 
> referenced Key element). BTW – Just to be clear, I am talking about 
> the POLICY information associated with whatever PIN a user uses with 
> their token. I’m not talking about the attributes of a specific PIN 
> value that can be expressed in a Key element. As an example, to 
> express a min and max PIN length policy, we have to create custom Data 
> elements in a separate Key element (and also Base64 encode the 
> values). I’m sorry, but this is getting ridiculous.
>
> <Key KeyId="07552252661"
>
> b. This example doesn’t include the PIN format, which would require me 
> to either:
>
> ii. Include a ResponseFormat element that then requires inclusion of a 
> “Length” attribute. But what would the Length attribute really mean in 
> this case?
>
> d. Why isn’t a PINPolicy reusable across multiple tokens (it has no ID 
> that can be used in a reference from a token definition). If I want to 
> define a PINPolicy that applies to multiple tokens, the PINPolicy 
> e. The “WrongPINtry” element name (in PINPolicyType) is not consistent 
> with the other camel-case names (“try” should be “Try”).
>
> [PH] agreed, will change
>
>
> “InAlgo” (in PINUsageMode) to be used as XML keywords. To stay 
> consistent with “Local” and “Prepend”, I would strongly suggest 
> something like “Embed” or “Algorithmic”.
> maybe Algorithmic is a better choice, that is why I tried to express 
> the use of the PIN in the algorithm as InAlgo. I do not feel very 
> strong about it. Maybe we can have a vote
>
>
> 4. The use of “ResponseFormat” for describing a PIN is very confusing. 
> The spec defines ResponseFormat as follows “The ResponseFormat element 
> defines the characteristics of the result of a computation. This 
> defines the format of the OTP or of the response to a challenge.” A 
> PIN is not the result of a “computation”, nor is it a response to a 
> challenge. It seems quite odd to use this Key construct for a PIN. I 
> think that either another usage type should be defined or the 
> ResponseFormat definition should be changed to also reflect its use 
> for describing a PIN.
> convince people that tit was a good idea without having to introduce 
> to many new schema types. Here you say it is odd to use the Key 
> element for the PIN value but above you agree that a PIN IS a Key. So 
> I would keep it in the Key element buy change description.
>