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

From: "Philip Hoyer" <[email-masked]>
Date: Wed, 18 Jun 2008 18:50:55 +0200

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

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 

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.	Should we make KeyType:KeyId of type xs:ID instead of xs:string
2.	Should we make KeyType:KeyProfileId and
KeyProperties:KeyProfileId of type xs:ID instead of xs:string
3.	For all the uses of xs:ID should we add facets of minlength,
maxlength and whitespace? Or do we just have standard
4.	Should we go for xs:string for unencrypted data elements - Rob
Philpott and others seem strongly for it but Sean Turner was against it
at the last IETF in Philadelphia
5.	Where else do we need '<anyAttribute namespace="##other"
processContents="lax"/>' as extension points
6.	For the added '<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>' do we need a description within
the spec or do we just leave them in the parts of the schema fragments
throughout the spec as obvious extension points?
7.	Address other issues raised by Rob Philpott: Here below with my
comments and numbered Rob Philpott Comment plus number (RPC1, RPC2, ...
etc)

RPC1.      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. Also since there are
already implementations out there changing this would make it
incompatible.

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

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

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

RPC5        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

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: "Pei, Mingliang" <[email-masked]>
Date: Sun, 22 Jun 2008 16:11:10 -0700

Hi Philip,
 
Thank you for the updates. I went through the revised documents, and
verified the examples against the schema with my schema tool. The
changes mostly look good to me. Here are a few more minor changes
needed.
 
- There is one inconsistency in defining PINUsageModeType "InAlgo". The
schema section and schema file used "Embed" but the section 5.4.4.1 used
"InAlgo".
- For your change 3, I think that it would be better to place
KeyProperties element in KeyContainer in front of Device instead of
being after. Logically we should define common key headers
(KeyProperties) before a key is defined in a Device element and refer to
the key properties.
- The element name "WrongPINTry" doesn't sound natural as an element
name. Maybe it is due to some inconsistence with our other naming
conventions - we try to use an noun for an name elsewhere. How about an
alternative name such as "MaxBadAttempts" or "BadTryThreshold" etc.?
 
Please see my other comments inline for the discussion points.
 
One more discussion issue is about Hannes's suggestion:
"For the PSKC document I also suggest to use
"urn:ietf:params:xml:ns:keyprov:pskc:1.0" instead of
"urn:ietf:params:xml:ns:keyprov:container:1.0"

I am fine with the namespace change.

- Ming

From: Philip Hoyer [mailto:[email-masked]] 
Sent: Wednesday, June 18, 2008 9:51 AM
To: Pei, Mingliang; [email-masked]; Hannes Tschofenig;
Hallam-Baker, Phillip
Cc: [email-masked]; [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC

Extension points:

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

 

 
MP    : Prefer to keep it as xs:string. DSKPP will have the same
concept. Using it as both an element ID reference and actual key
identifier would be more confusing just for the case where PINKeyID
refers to KeyID from another element.

1.	Should we make KeyType:KeyProfileId and
KeyProperties:KeyProfileId of type xs:ID instead of xs:string  

MP: I don't think so. According to its current usage, it is almost a
proprietory value between a sending and a receiving party to consume.
Unless I miss something, xs:ID is mainly used for reference purpose
within an instance document of schema. But the KeyProfileId may have
actual meaning given by the key issuer.

1.	For all the uses of xs:ID should we add facets of minlength,
maxlength and whitespace? Or do we just have standard  

MP: Not sure we always need to define minlength and maxlength for all
IDs.

1.	Should we go for xs:string for unencrypted data elements - Rob
Philpott and others seem strongly for it but Sean Turner was against it
at the last IETF in Philadelphia  

MP: My preference was "string" type with an encoding attribute. The
meeting minutes of IETF indicates that a change isn't a must as people
won't care its type and it doesn't really matter in the final spec. In
other words, it seemed to be considered a low priority to change rather
than being against it or not.

1.	Where else do we need '<anyAttribute namespace="##other"
processContents="lax"/>' as extension points  

MP: Your addition seems to be complete. I cannot think of others for
now.

1.	For the added '<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>' do we need a description within
the spec or do we just leave them in the parts of the schema fragments
throughout the spec as obvious extension points?  

MP: I think that we should add a description for each "any" we added
even if they are obvious.

1.	Address other issues raised by Rob Philpott: Here below with my
comments and numbered Rob Philpott Comment plus number (RPC1, RPC2, ...
etc) 

MP: Note that DSKPP uses "DeviceIdentifierDataType" for the device
identity information. How about "DeviceIdDataType" instead of
"DeviceIdType" here?

MP: Agree to not reopen this discussion. The added "any" in KeyType
allows other extensions.

MP: "Algorithmic" is fine.

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, 23 Jun 2008 15:39:16 +0200

Ming,

I will do some of the changes below but I really start to think we
should consider this issue about typing and resistance to name value
pairs.

Can we have a call this week?

How about Tuesday morning PST would that work?

Philip

From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Monday, June 23, 2008 12:11 AM
To: Philip Hoyer; [email-masked]; Hannes Tschofenig;
Hallam-Baker, Phillip
Cc: [email-masked]; [email-masked]
Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC

Hi Philip,

- Ming

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: Mon, 23 Jun 2008 10:04:34 -0700

This Tuesday morning 8 or 9 PDT is good. - Ming

	Sent: Monday, June 23, 2008 6:39 AM

	Ming,

	I will do some of the changes below but I really start to think
we should consider this issue about typing and resistance to name value
pairs.

	Philip

	Hi Philip,

	Thank you for the updates. I went through the revised documents,
and verified the examples against the schema with my schema tool. The
changes mostly look good to me. Here are a few more minor changes
needed.

	- There is one inconsistency in defining PINUsageModeType
"InAlgo". The schema section and schema file used "Embed" but the
section 5.4.4.1 used "InAlgo".

	- The element name "WrongPINTry" doesn't sound natural as an
element name. Maybe it is due to some inconsistence with our other
naming conventions - we try to use an noun for an name elsewhere. How
about an alternative name such as "MaxBadAttempts" or "BadTryThreshold"
etc.?

	- Ming

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

	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 

	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 

	                        <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

	1.	Should we make KeyType:KeyId of type xs:ID instead of
xs:string   

	MP: I don't think so. According to its current usage, it is
almost a proprietory value between a sending and a receiving party to
consume. Unless I miss something, xs:ID is mainly used for reference
purpose within an instance document of schema. But the KeyProfileId may
have actual meaning given by the key issuer.

	1.	For all the uses of xs:ID should we add facets of
minlength, maxlength and whitespace? Or do we just have standard   

	MP: Not sure we always need to define minlength and maxlength
for all IDs.

	1.	Should we go for xs:string for unencrypted data elements
- Rob Philpott and others seem strongly for it but Sean Turner was
against it at the last IETF in Philadelphia   

	MP: My preference was "string" type with an encoding attribute.
The meeting minutes of IETF indicates that a change isn't a must as
people won't care its type and it doesn't really matter in the final
spec. In other words, it seemed to be considered a low priority to
change rather than being against it or not.

	MP: Your addition seems to be complete. I cannot think of others
for now.

	1.	For the added '<xs:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>' do we need
a description within the spec or do we just leave them in the parts of
the schema fragments throughout the spec as obvious extension points?   

	MP: I think that we should add a description for each "any" we
added even if they are obvious.

	1.	Address other issues raised by Rob Philpott: Here below
with my comments and numbered Rob Philpott Comment plus number (RPC1,
RPC2, ... etc) 

	RPC1.      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. Also since there
are already implementations out there changing this would make it
incompatible. 

	MP: Note that DSKPP uses "DeviceIdentifierDataType" for the
device identity information. How about "DeviceIdDataType" instead of
"DeviceIdType" here?

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

	MP: Agree to not reopen this discussion. The added "any" in
KeyType allows other extensions.

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

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

	RPC5        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

	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

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

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

	
	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.

	[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: "Philip Hoyer" <[email-masked]>
Date: Tue, 24 Jun 2008 19:27:03 +0200

Attendees: Ming Pei, Salah Macchani, Philip Hoyer

Apologies from Phillip Hallam-Baker and Hannes Tschofenig

Discussed:

*	PINUsageModeType "InAlgo" - Agreed to change to 'Algorithmic'
*	For the PINPolicy.WrongPINtry  agreed to change name to
MaxFailedAttempts
*	Decided not to adopt xs:ID for KeyId.since xs:ID is more used
for referencing elements within XML documents whereas KeyID is a unique
identifier beyond the boundaries of the provisioning transport.
*	Philip to go through description of entity in spec and add the
extension description to entities where <any added>
*	The comment on inconsistency of DeviceIDType. Since this type is
referred to directly in DSKPP it was seen that moving the elements into
Device would not be advisable since Device currently mandates the
presence of 1 key. So it was preferred to change the name of DeviceId to
DeviceInfo.
*	Comments on plainvalue being string and adversion to name-value
types

	*	Philip to create email based on proposal from Hannes but
inside the <Data> tag and discuss with Hannes
	*	Ming and Salah to think about additional possible
solutions - to reconvene at next sync up call on Wednesday 2nd of July

Philip will make agreed changes to current spec and then discuss with
Hannes if to submit before tackling name-value-pair issue.

Philip

Hi Philip,

- Ming

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: Fri, 27 Jun 2008 17:14:25 +0200

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

Extension points:

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

 

1.	Should we go for xs:string for unencrypted data elements - Rob
Philpott and others seem strongly for it but Sean Turner was against it
at the last IETF in Philadelphia (please see other email about proposal)
2.	Address other issues raised by Rob Philpott: Here below with my
comments and numbered Rob Philpott Comment plus number (RPC1, RPC2, ...
etc)
3.	For PINPolicy we have 'Prepend' should we add 'Append' for
completeness?

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