[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs
Thanks for comments Andrea,
See my answers [PH[ inline.
-----Original Message-----
From: andrea.doherty at rsa.com [mailto:andrea.doherty at rsa.com]
Sent: Sunday, July 13, 2008 5:06 AM
To: andrea.doherty at rsa.com; Philip Hoyer; mpei at verisign.com;
SMachani at diversinet.com; Hannes.Tschofenig at gmx.net; pbaker at verisign.com;
robert.philpott at rsa.com
Cc: keyprov at ietf.org
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: keyprov-bounces at ietf.org on behalf of andrea.doherty at rsa.com
Sent: Sat 7/12/2008 11:52 PM
To: philip.hoyer at actividentity.com; mpei at verisign.com;
SMachani at diversinet.com; Hannes.Tschofenig at gmx.net; pbaker at verisign.com;
Philpott, Robert
Cc: keyprov at ietf.org
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:philip.hoyer at actividentity.com]
Sent: Thu 7/10/2008 6:09 AM
To: Philip Hoyer; Pei, Mingliang; SMachani at diversinet.com; Hannes
Tschofenig; Hallam-Baker, Phillip; Philpott, Robert; Doherty, Andrea
Cc: keyprov at ietf.org
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
Changes made from version 4 are:
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.
[Update] Extension points:
Changed to model proposed by Rob Philpott declaring a new type:
<xs:complexType name="ExtensionsType">
<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
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: andrea.doherty at rsa.com [mailto:andrea.doherty at rsa.com]
Sent: Friday, May 30, 2008 4:36 PM
To: keyprov at ietf.org
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
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov
_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov