Subject: [KEYPROV] Review comments for -03 PSKC draft

From: [email-masked]
Date: Sun, 6 Apr 2008 11:21:51 -0400

Philip, etal,
Good work on the latest (-03) draft.  I gave it a review, and detailed comments follow.
Andrea
 
General
-------
1. The entire document is in need of grammar and spelling checks.
2. A Terminology Section is needed; esp. one aligned with DSKPP
3. Abstract, Use Cases, and Requirements sections describe a specific application, OTP authentication.  Based on comments received on early drafts of DAKPP, it would be more acceptable to a broader constituency if these sections were more broadly application.  This is particularly true as other groups are interested in PSKC, e.g., IEEE P1619.3, and still others participate in KEYPROV who are not part of the OTP constituency and will have difficulty understanding the meaning/significance of the content. Here are some sample suggestions whose aims are consistency with other KEYPROV work, esp. DSKPP:
a. The term "crypto module" would be preferable to "authentication token"
b. The term "key transport" is more generic than "key migration"
c. Online use cases are more important to KEYPROV work than offline cases, and so should be listed first to avoid confusion.
4. Otherwise, in the Use Cases section, there are times wherein requirements are mentioned, e.g., last paragraph of 3.1.1, which are already listed in the Requirements Section.  No need to have requirements in both places.
5. IANA Considerations is missing, as was already noted by Hannes.
 
Section 5.1
-----------
1. <EncryptionKey>: "for profile and usage" - what profile ("Key Protection profile) and usage of what?  
2. <Device>: MANDATORY?
3. <Device>: "allowing for bulk provisioning of keys" - yes, but this can be achieved by defining multiple keys per device.
 
Section 5.2
-----------
1. First paragraph - "recommended" or "required" (i.e., is this a MAY or a MUST)?  The sentence is stated as a requirement not a recommendation.  
2. Section 5.2.1 -  "For keys hold on banking cards" -- please fix phrasing.
3. Section 5.2.1 - "big number" would sound better as "long number" - big implies a high value whereas "long" implies a large number of digits.
4. Section 5.2.1 <SerialNo>, <IssueNo>, <ExpiryDate>, etc. - do you view these are generic enough, or can you provide additional examples of devices beyond smart cards?
 
Section 5.3
-----------
1. Alignment is needed between PSKC and DSKPP for the terms "Key" and "KeyType".
2. <CardAppPersoProfileId> is too specific, in my opinion.
3. In general, the complexType KeyType could use cleanup, particularly for the bulk provisioning use cases.  As I read further in the document, I think it would be much simpler if there were a KeyHeader defined (perhaps KeyHeaderType) at the Device level (e.g., as part of the DeviceType), which contains elements common to one or many keys.  After all, looking at KeyType, the following elements are common to multiple keys:
  <Issuer>
  <Usage>
  <CardAppPersoProfileId>
  <PINPolicy>
  <ExpiryDate>
  <StartDate>
  <KeyAlgorithm>
If KeyHeaderType (or whatever it is called) is extensible, then it can be more easily adopted by future applications of PSKC.
(As an alternative, perhaps a KeyHeaderType could be defined as OPTIONAL in both DeviceType and KeyType so that its implementation is left to the application developer.  For example, one app developer may desire a repeat of key header info on a per key basis for certain business reasons, while another may want to avoid potential maintenance/troubleshooting headaches, and specify this information at the Device Level).
4. Sorry to "beat a dead horse", but why are "KeyID" and "KeyAlgorithm" defined as attributes in KeyType?
5. <Data> - does this "data" refer to a key value?  The sentence reads "Data carries data related to the key" - what key data?  
6. Section 5.3.1 - Why wasn't KeyID defined in DataType?
7. Section 5.3.1 <ValueMAC> - where are the key protection algorithms defined.  This appears to be the first reference to these, but without context.
8. Section 5.3.2 - really refers specifically to OTPUsageType.  Aren't other UsageTypes supported.  Perhaps an abstract UsageType is needed.
9. Section 5.3.2, UsageType - I think it would make the schema more readable if ChallengeFormat were listed before ResponseFormat.
10. Section 5.3.2, UsageType - Does CardAppProfileId> belong here instead of in <KeyType>, esp. as "UsageType" really refers to "OTPUsageType".
11. Section 5.3.2, UsageType, Issue open still re attribute name-value pairs.
12. section 5.3.2.1 - we agreed during the Interim meeting to remove this section. Also note that the schema (contained later in the doc) doesn't match the inclusion of this text here.
13. Section 5.3.2.1.1 and 5.3.2.2.2 - although these should be removed per the Interim meeting, the checksum algorithm in DSKPP is CRC32 not Luhn.
14. Section 5.3.4, Pin Policy - Suggested changes to first paragraph:
a. "defines a mean to define" -> "provides a means to define".  
b. "The PIN itself can be transmitted using the container as another key" -> "The PIN itself can be transmitted as a key using the container.
c. An example for (b) would be helpful.
d. In other parts of document (e.g., 5.1), MANDATORY and OPTIONAL are appended to element names.  Looks like this practice was abandoned?
15. Section 5.3.4, PIN Policy - how does one specify whether or not a PIN is required by policy?
16. Section 5.3.4.1 - How might one specify System-generated vs. user-generated PINs for New PIN Mode (or is this relevant here)?
 
Section 6.1.1
-------------
According to interim meeting, we agreed to reference Eastlake doc here (e.g., see paragraph that begins "The following is the lsit of symmetric key encryption algorithms"...)
 
Section 6.1.2
-------------
For alignment purposes, please refer to DSKPP for iterationCount value specified for the PKCS5 PBE alg
 
Section 6.1.3
-------------
During the interim meeting we agreed to remove this section (incl 6.3.1.1 and 6.3.1.2) and reference the Eastlake doc instead.
 
Section 9.1
-----------
1. Second paragraph - according to Section 6.1.1, 3DES and AES are MANDATORY, not "recommended".
2. Second paragraph - what length for the AES (see sentence ending with "advised to use AES")?
 
Section 12 
----------
a. Not all of these are normative.  For example, I-Ds cannot be listed as normative.  This applies to:
  [DSKPP]
  [OCRA]
b. Would you call [Schneier] normative, or informational?
c. Once the OTP algorithms are removed, the OATH references ([OATH] and [OATHRefArch]) would belong in the Eastlake doc?  Where are these applicable?  How are they normative to this document?  Adding them here implies implementers must be able to access the OATH web site, retrieve the documents, and apply them.  But not everyone has access to the OATH web site for doc downloads, nor will everyone wish to use PSKC to implement OTP nor OTP-OATH based applications.
c. Same comment applies, more or less, to [CAP] and [HOTP].
d. The Eastlake I-D should be referenced.
e. In other words, two sub-sections are needed in the References section - Normative and Informational.
f. I suggest you refer to the DSKPP References section, which already reflects comments from the mailing list.
 
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 7 Apr 2008 00:19:23 -0700

Hi Andrea,

Thank you very much for the detail comments. We will look into these and
incorporate them properly. A quick reply about the section 12: agree
with your comments there. We have actually made some changes according
in the current work-in-progress draft for -04; we have both Normative
and Informational sections as you suggested. We will provide additional
replies for each of your other comments after we go through them in
detail.

- Ming

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Sunday, April 06, 2008 8:22 AM
To: [email-masked]
Subject: [KEYPROV] Review comments for -03 PSKC draft

Philip, etal,
Good work on the latest (-03) draft.  I gave it a review, and detailed
comments follow.
Andrea
 
General
-------
1. The entire document is in need of grammar and spelling checks.
2. A Terminology Section is needed; esp. one aligned with DSKPP 3.
Abstract, Use Cases, and Requirements sections describe a specific
application, OTP authentication.  Based on comments received on early
drafts of DAKPP, it would be more acceptable to a broader constituency
if these sections were more broadly application.  This is particularly
true as other groups are interested in PSKC, e.g., IEEE P1619.3, and
still others participate in KEYPROV who are not part of the OTP
constituency and will have difficulty understanding the
meaning/significance of the content. Here are some sample suggestions
whose aims are consistency with other KEYPROV work, esp. DSKPP:
a. The term "crypto module" would be preferable to "authentication
token"
b. The term "key transport" is more generic than "key migration"
c. Online use cases are more important to KEYPROV work than offline
cases, and so should be listed first to avoid confusion.
4. Otherwise, in the Use Cases section, there are times wherein
requirements are mentioned, e.g., last paragraph of 3.1.1, which are
already listed in the Requirements Section.  No need to have
requirements in both places.
5. IANA Considerations is missing, as was already noted by Hannes.
 
Section 5.1
-----------
1. <EncryptionKey>: "for profile and usage" - what profile ("Key
Protection profile) and usage of what?  
2. <Device>: MANDATORY?
3. <Device>: "allowing for bulk provisioning of keys" - yes, but this
can be achieved by defining multiple keys per device.
 
Section 5.2
-----------
1. First paragraph - "recommended" or "required" (i.e., is this a MAY or
a MUST)?  The sentence is stated as a requirement not a recommendation.

2. Section 5.2.1 -  "For keys hold on banking cards" -- please fix
phrasing.
3. Section 5.2.1 - "big number" would sound better as "long number" -
big implies a high value whereas "long" implies a large number of
digits.
4. Section 5.2.1 <SerialNo>, <IssueNo>, <ExpiryDate>, etc. - do you view
these are generic enough, or can you provide additional examples of
devices beyond smart cards?
 
Section 5.3
-----------
1. Alignment is needed between PSKC and DSKPP for the terms "Key" and
"KeyType".
2. <CardAppPersoProfileId> is too specific, in my opinion.
3. In general, the complexType KeyType could use cleanup, particularly
for the bulk provisioning use cases.  As I read further in the document,
I think it would be much simpler if there were a KeyHeader defined
(perhaps KeyHeaderType) at the Device level (e.g., as part of the
DeviceType), which contains elements common to one or many keys.  After
all, looking at KeyType, the following elements are common to multiple
keys:
  <Issuer>
  <Usage>
  <CardAppPersoProfileId>
  <PINPolicy>
  <ExpiryDate>
  <StartDate>
  <KeyAlgorithm>
If KeyHeaderType (or whatever it is called) is extensible, then it can
be more easily adopted by future applications of PSKC.
(As an alternative, perhaps a KeyHeaderType could be defined as OPTIONAL
in both DeviceType and KeyType so that its implementation is left to the
application developer.  For example, one app developer may desire a
repeat of key header info on a per key basis for certain business
reasons, while another may want to avoid potential
maintenance/troubleshooting headaches, and specify this information at
the Device Level).
4. Sorry to "beat a dead horse", but why are "KeyID" and "KeyAlgorithm"
defined as attributes in KeyType?
5. <Data> - does this "data" refer to a key value?  The sentence reads
"Data carries data related to the key" - what key data?  
6. Section 5.3.1 - Why wasn't KeyID defined in DataType?
7. Section 5.3.1 <ValueMAC> - where are the key protection algorithms
defined.  This appears to be the first reference to these, but without
context.
8. Section 5.3.2 - really refers specifically to OTPUsageType.  Aren't
other UsageTypes supported.  Perhaps an abstract UsageType is needed.
9. Section 5.3.2, UsageType - I think it would make the schema more
readable if ChallengeFormat were listed before ResponseFormat.
10. Section 5.3.2, UsageType - Does CardAppProfileId> belong here
instead of in <KeyType>, esp. as "UsageType" really refers to
"OTPUsageType".
11. Section 5.3.2, UsageType, Issue open still re attribute name-value
pairs.
12. section 5.3.2.1 - we agreed during the Interim meeting to remove
this section. Also note that the schema (contained later in the doc)
doesn't match the inclusion of this text here.
13. Section 5.3.2.1.1 and 5.3.2.2.2 - although these should be removed
per the Interim meeting, the checksum algorithm in DSKPP is CRC32 not
Luhn.
14. Section 5.3.4, Pin Policy - Suggested changes to first paragraph:
a. "defines a mean to define" -> "provides a means to define".  
b. "The PIN itself can be transmitted using the container as another
key" -> "The PIN itself can be transmitted as a key using the container.
c. An example for (b) would be helpful.
d. In other parts of document (e.g., 5.1), MANDATORY and OPTIONAL are
appended to element names.  Looks like this practice was abandoned?
15. Section 5.3.4, PIN Policy - how does one specify whether or not a
PIN is required by policy?
16. Section 5.3.4.1 - How might one specify System-generated vs.
user-generated PINs for New PIN Mode (or is this relevant here)?
 
Section 6.1.1
-------------
According to interim meeting, we agreed to reference Eastlake doc here
(e.g., see paragraph that begins "The following is the lsit of symmetric
key encryption algorithms"...)
 
Section 6.1.2
-------------
For alignment purposes, please refer to DSKPP for iterationCount value
specified for the PKCS5 PBE alg
 
Section 6.1.3
-------------
During the interim meeting we agreed to remove this section (incl
6.3.1.1 and 6.3.1.2) and reference the Eastlake doc instead.
 
Section 9.1
-----------
1. Second paragraph - according to Section 6.1.1, 3DES and AES are
MANDATORY, not "recommended".
2. Second paragraph - what length for the AES (see sentence ending with
"advised to use AES")?
 
Section 12
----------
a. Not all of these are normative.  For example, I-Ds cannot be listed
as normative.  This applies to:
  [DSKPP]
  [OCRA]
b. Would you call [Schneier] normative, or informational?
c. Once the OTP algorithms are removed, the OATH references ([OATH] and
[OATHRefArch]) would belong in the Eastlake doc?  Where are these
applicable?  How are they normative to this document?  Adding them here
implies implementers must be able to access the OATH web site, retrieve
the documents, and apply them.  But not everyone has access to the OATH
web site for doc downloads, nor will everyone wish to use PSKC to
implement OTP nor OTP-OATH based applications.
c. Same comment applies, more or less, to [CAP] and [HOTP].
d. The Eastlake I-D should be referenced.
e. In other words, two sub-sections are needed in the References section
- Normative and Informational.
f. I suggest you refer to the DSKPP References section, which already
reflects comments from the mailing list.

---

From: "Philip Hoyer" <[email-masked]>
Date: Fri, 11 Apr 2008 19:57:45 +0200

Andrea,
Andrea,
First thank you so much for the review and for catching some really good
inconsistencies.

I went through these one by one so please see my comments below prefixed
[PH]

Most of them I have addressed in the work in progress for next revision.

There are a few where I need more clarification on your part to
understand what you mean and how to change for the better,

Thanks again,

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Sunday, April 06, 2008 4:22 PM
To: [email-masked]
Subject: [KEYPROV] Review comments for -03 PSKC draft

Philip, etal,
 
General
-------
[PH] agreed

2. A Terminology Section is needed; esp. one aligned with DSKPP
[PH] Ming has taken thye action to add this section for the next version
of the draft

3. Abstract, Use Cases, and Requirements sections describe a specific
[PH] Salah will review the use cases based on these comments and the
document received by Sean Turner. We will address this in the next
revision

5. IANA Considerations is missing, as was already noted by Hannes.
[PH] I am waiting for the exact wording to include here from Phillip
Hallam-Baker. I hope we can get this in time for the next revision
 
Section 5.1
-----------
1. <EncryptionKey>: "for profile and usage" - what profile ("Key
Protection profile) and usage of what?  
[PH] Reworded to
"Identifies the encryption key, algorithm and possible parameters used
to protect the Secret Key data in the container. Please see Section 6.1
for detailed description of how to protect key data in transit and the
usage of this element.
"

2. <Device>: MANDATORY?
[PH] Currently Keys have to be in devices hence MANDATORY

3. <Device>: "allowing for bulk provisioning of keys" - yes, but this
can be achieved by defining multiple keys per device.
[PH] not if you want to transmit multiple devices and multiple keys for
each device. So reworded to:
".... allowing for bulk provisioning of multiple devices each containing
multiple keys."
 
Section 5.2
-----------

[PH] Reworded to:
"A key SHOULD be bound to only one Device."

2. Section 5.2.1 -  "For keys hold on banking cards" -- please fix
phrasing.
[PH] reworded to 
" Symmetric Keys used in the payment industry are usually stored on
Integrated Circuit Smart Cards. These cards are uniquely identified via
the Primary Account Number (PAN, the long number printed on the front of
the card) and an expiry date of the card.
"

[PH] see above

4. Section 5.2.1 <SerialNo>, <IssueNo>, <ExpiryDate>, etc. - do you view
these are generic enough, or can you provide additional examples of
devices beyond smart cards?
[PH] so far I believe these to be generic enough.

Section 5.3
-----------
1. Alignment is needed between PSKC and DSKPP for the terms "Key" and
"KeyType".
[PH] Are you referring to the fact that 'KeyType' in PSKC is the XML
schema type to represent a Key whereas in DSKPP Key Type is defined as:
"   Key Type:  The type of symmetric key cryptographic methods for which
       the key will be used (e.g., OATH HOTP or RSA SecurID
       authentication, AES encryption, etc.)" ?
Could you suggest an alignment here please?

2. <CardAppPersoProfileId> is too specific, in my opinion.
[PH] Any suggestions for alternatives? I was thinking that at the end
this is a MasterKey derivation scheme and maybe we should just call it
<MasterKeyId> and in case of EMV cards this will also uniquely identity
the other parameters related to the derivation. What do you think?

[PH] yes agreed and we are creating a proposal for this. Personally I
see this more sitting at the container level since in bulk device and
key provisioning most use cases will transfer the same type of devices
harbouring exactly the same type e of keys.
Please refer to my other email for this.

4. Sorry to "beat a dead horse", but why are "KeyID" and "KeyAlgorithm"
defined as attributes in KeyType?
[PH] Sorry I do not recall other suggestions. KeyType is the XML schema
type for the Key hence KeyId and KeyAlgorithm need to be associated with
the Key.
Did you prefer elements instead of attributes?

5. <Data> - does this "data" refer to a key value?  The sentence reads
"Data carries data related to the key" - what key data?  
[PH] 
The sentence refers to the section immediately below that reads:
"
   Defines the data attributes of the symmetric key.  Each is a name
   value pair which has either a plain value (in case of no encryption)
   or a encrypted value as defined in EncryptedDatatype in XML
   Encryption.

   This is also where the key value is transported, Section 7 defines a
   list of reserved attribute names.
"
Do you think we need to be more explicit?

6. Section 5.3.1 - Why wasn't KeyID defined in DataType?
[PH] because it is related to the Key and not to the Data of the Key.

7. Section 5.3.1 <ValueMAC> - where are the key protection algorithms
defined.  This appears to be the first reference to these, but without
context.
[PH] reworded to:
" element in the DataType conveys a keyed MAC value of the unencrypted
data for the cases where the algorithm to protect key data in transit,
as described in section Section 6.1.1 ,does not support integrity
checks.
"

8. Section 5.3.2 - really refers specifically to OTPUsageType.  Aren't
other UsageTypes supported.  Perhaps an abstract UsageType is needed.
[PH] actually the UsageType currently has:

   o  OTP, the key will be used for OTP generation

   o  CR, the key will be used for Challenge/Response purposes

   o  Encrypt, the key will be used for data encryption purposes

   o  Integrity, the key will be used to generate a keyed message digest
      for data integrity or authentication purposes.

   o  Unlock, the key will be used for an inverse challenge response in
      the case a user has locked the device by entering a wrong PIN too
      many times (for devices with PIN-input capability)
So why do you say they are OTP specific?
Maybe we need to have an extension point here?

9. Section 5.3.2, UsageType - I think it would make the schema more
readable if ChallengeFormat were listed before ResponseFormat.
[PH] Agreed and changed for next revision

10. Section 5.3.2, UsageType - Does CardAppProfileId> belong here
instead of in <KeyType>, esp. as "UsageType" really refers to
"OTPUsageType".
[PH] see my comment on it really referring to the MasterKey label used
for key derivation hence not really about Usage more related to the key.

11. Section 5.3.2, UsageType, Issue open still re attribute name-value
pairs.
[PH] which issue are you referring to?

12. section 5.3.2.1 - we agreed during the Interim meeting to remove
this section. Also note that the schema (contained later in the doc)
doesn't match the inclusion of this text here.
[PH] we agreed to remove the description of the attributes, not the
ability to carry them. Maybe the word attribute is not the right one.
This refers to the fact that if in the usage element the XML attribute
OTP=true then the element Responseformat must be present.
Hence I reworded the section as follows:
"
When the intended usage of a key usage is OTP and/or CR, the following
additional elements MUST be provided within the Usage element to support
the OTP and/or the response computation as required by the underlying
algorithm. These elements also allow to customize or configure the
result of the computation (e.g. format, length).
"

13. Section 5.3.2.1.1 and 5.3.2.2.2 - although these should be removed
per the Interim meeting, the checksum algorithm in DSKPP is CRC32 not
Luhn.
[PH] see comment above. 
I agree that maybe we need to support more then one CheckDigit
algorithm.
Do you think an additional attribute in ResponseFormat and
ChallengeFormat like the following would be OK?
<xs:attribute name="CheckDigitAlgorithm"
type="xs:string" />
Which contains the URL for the check digit algorithm if not Luhn?

14. Section 5.3.4, Pin Policy - Suggested changes to first paragraph:
a. "defines a mean to define" -> "provides a means to define".  
[PH] Agreed and changed for next revision 

b. "The PIN itself can be transmitted using the container as another
key" -> "The PIN itself can be transmitted as a key using the container.
[PH] Agreed and changed for next revision

c. An example for (b) would be helpful.
[PH] Example of this is in  section 11.2 Do you think we should
reference it? 

[PH] Agreed and added

15. Section 5.3.4, PIN Policy - how does one specify whether or not a
PIN is required by policy?
[PH] If a policy is present then the PIN is required.
Added the following to the beginning of the section:
" If the PINPolicy element is present in the Key element then the key is
protected with a PIN as defined within the PINPolicy element.
"

16. Section 5.3.4.1 - How might one specify System-generated vs.
user-generated PINs for New PIN Mode (or is this relevant here)?
[PH] I do not think it is relevant, do you think that we should add it
to PINPolicy as an optional element called NewPINMode (SYSTEM,USER)?
 
Section 6.1.1
-------------
According to interim meeting, we agreed to reference Eastlake doc here
(e.g., see paragraph that begins "The following is the lsit of symmetric
key encryption algorithms"...)
[PH] this section will change based on the IANA considerations,
apparently we will not reference Eastlake but awaiting input fromPhillip
Hallam Baker on this.
 
Section 6.1.2
-------------
For alignment purposes, please refer to DSKPP for iterationCount value
specified for the PKCS5 PBE alg
[PH] Sorry could you be more explicit, what alignment you mean.

Section 6.1.3
-------------
[PH] see above
 
Section 9.1
-----------
1. Second paragraph - according to Section 6.1.1, 3DES and AES are
MANDATORY, not "recommended".
[PH] good catch, changed to mandatory

2. Second paragraph - what length for the AES (see sentence ending with
"advised to use AES")?
[PH] changed to 'use AES-256-CBC'
 
Section 12 
----------

[PH] Ming has been tasked to review this section for the next revision
of the spec