Subject: [KEYPROV] Review comments - PSKC

From: "Doherty, Andrea" <[email-masked]>
Date: Thu, 16 Aug 2007 09:50:29 -0400

I reviewed draft-hoyer-keyprov-portable-symmetric-key-container-02.txt
and have the following comments:

General:
========
1. Align terminology with DSKPP, esp. use of "token", "credentials",
"seed records", "shared secret", "secret key", "attributes" throughout
the document.

2. Add section for IANA Considerations

3. Several typos found; recommend running document through spell
checker.

Abstract:
=========
Is last paragraph appropriate for IETF document?

Section 1 (Introduction):
=========================
1. It would be best if this document would be more generic to
application context.  Currently, it is still more "OTP" focused than
useful for all constituents interested in this specification.

2. First sentence should read "...systems based ^^upon^^ one time..."

3. Last sentence has spelling error "wherears"

Section 3.1.1 (Credential migration by end-user):
=================================================
Last paragraph - this is example where alignment with DSKPP Key
Initialization Profiles will be required (refer to Issue #9 in issue
tracker).

Section 3.2.1 (Online provisioning...):
=======================================
Perhaps clarify last sentence of first paragraph ("user can download
more than one...").  Doesn't this capability depend on whether an
application has concept of a session, and how the session is defined?
Note that this capability is more of a provisioning server feature, and
is not applicable to DSKPP.

Section 3.2.2 (Server to server...):
====================================
First sentente, "...information from ^^a^^ manufacturer".

Section 5.1.4 (KeyID):
=========================
Perhaps add explanation here that namespace is not encoded into the
KeyID, but maintained as a separate attribute, e.g., "Issuer".

Section 5.1.7 (AccessRules):
============================
Recommend that you allow for a more complex PIN policy, esp., (a) how
the PIN is to be used in the OTP calculation (e.g., concatenated vs.
XOR's with the token code) and (b) PIN length.

Section 5.1.8 (EncryptionMethod):
=================================
1. Align this section with DSKPP Key Initialization Methods (see Issue
Tracker #9).

2. Last paragraph - "KeyContainer" is referred to here, but not
previously defined.

Section 6 (diagram):
====================
1. Typo in diagram -- arrow between Key n and Key p should be shown to
the right.

2. Align model represented by the diagram with Object Model in DSKPP.

3. Provide note that while PSKC supports bulk provisioning of keys,
DSKPP does not.

Section 6.1.1 (KeyType):
========================
1. SECRET has typo "key key". 

2. Last paragraph on 'Value Digest' - Perhaps refer to Section 5.1.8 for
clarity.

Section 6.1.2 (UsageType):
==========================
<AlgorithmIdentifier> - replace reference to [OCRA] with URI.

Section 6.1.4 (DeviceIdType):
=============================
1. Would be better if description were more generic; add storage device
as an example.

2. I recommend base64Binary as data type for SerialNo.

Section 6.1.5 (UserType):
=========================
To be consistent with the DSKPP Object Model, "UserIdType" would be more
consistent that "UserType".  Alternatively, "ClientIDType" would be more
consistent than "UserType" since a user may be a software application.

Section 6.1.9 (AlgorithmIdentifierType):
========================================
1. Replace [OCRA] throughout this section with appropriate URI.

2. "The AlgorithmIdentifierType is define^^d^^ as follows"

Section 6.5 (KeyAlgorithmType):
===============================
This type overlaps with "KeyType" in DSKPP; align.

Section 8.1 (Payload Confidentiality):
======================================
I recommend that you identify and define each of the profiles that are
described at a high-level here.

Section 8.2 (Payload Integrity):
================================
"provides a mean^^s^^ to"

Section 11 (Normative References):
==================================
1. Many of the references in the list are not normative but
"informative" (e.g., all of the I-D's).  I think the section should
either be divided in two, or simply called "References".

2. Is [OATHRefArch] used in the document?

3. Update [DSKPP] reference to draft-ietf-keyprov-dskpp-00.txt.

-- Andrea

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

---

From: "CHANG Shuh" <[email-masked]>
Date: Wed, 29 Aug 2007 01:33:06 +0200

Hi Andrea,

Thanks for the great comments on the PSKC draft. The PSKC WG had an
extensive discussion today and is providing the responses shown below
under each issue.

Regards,
Shuh

> -----Original Message-----
> From: Doherty, Andrea [mailto:[email-masked]] 
> Sent: Thursday, August 16, 2007 8:50 AM
> To: Pei, Mingliang; [email-masked]; Philip Hoyer
> Subject: [KEYPROV] Review comments - PSKC
> 
> 1. Align terminology with DSKPP, esp. use of "token", 
> "credentials", "seed records", "shared secret", "secret key", 
> "attributes" throughout the document.

We acknowledge this issue, and will address it in the next revision.

> 2. Add section for IANA Considerations

We will add this IANA section in this revision. (Ming's work item)

> 
> 3. Several typos found; recommend running document through 
> spell checker.

Yes, we'll do that. (Ming's work item)

> Is last paragraph appropriate for IETF document?

We'll remove this paragraph and add it in the Acknowledgement section.
(Ming's work item)

This work is a joint effort by the members of OATH (Initiative for Open
AuTHentication) to specify a format that can be freely distributed to
the technical community.

> application context.  Currently, it is still more "OTP" 
> focused than useful for all constituents interested in this 
> specification.

Need further discussion, and we'll address this issue in the next
revision.

> 2. First sentence should read "...systems based ^^upon^^ one time..."

Yes, we'll correct that. (Ming will correct it today.)

> 3. Last sentence has spelling error "wherears"

Yes, we'll correct that. (Ming will correct it today.)

> Last paragraph - this is example where alignment with DSKPP 
> Key Initialization Profiles will be required (refer to Issue 
> #9 in issue tracker).

Need further discussion, and we'll address this issue in the next
revision.

> Perhaps clarify last sentence of first paragraph ("user can 
> download more than one...").  Doesn't this capability depend 
> on whether an application has concept of a session, and how 
> the session is defined?
> Note that this capability is more of a provisioning server 
> feature, and is not applicable to DSKPP.

We'll clarify and rephrase the sentence to "a payload can contain
multiple credentials". We'll address this issue in this revision.

> Section 3.2.2 (Server to server...):

Yes, we'll correct that. (Ming will correct it today.)

> Perhaps add explanation here that namespace is not encoded 
> into the KeyID, but maintained as a separate attribute, e.g., 
> "Issuer".

Agree and will do it in the next revision.. (Ming's action item)

> Recommend that you allow for a more complex PIN policy, esp., 
> (a) how the PIN is to be used in the OTP calculation (e.g., 
> concatenated vs.

Yes, agree. Ming will open an issue in issuer tracker. Add (c) how to
transfer initial PIN value. Shuh to chat with people for some best
practice.

The issue "When PIN is used, how do you actually transfer the initial
PIN using PSKC?" needs to be further discussed. Different vendors might
have different approaches. We'd also like to solicit from the KeyProv
list members for inputs on this issue.

> 1. Align this section with DSKPP Key Initialization Methods 
> (see Issue Tracker #9).

We'll defer this to next revision.

> 
> 2. Last paragraph - "KeyContainer" is referred to here, but 
> not previously defined.

We'll rephrase this sentence by changing word "KeyContainer" to
"payload".

> 
> Section 6 (diagram):
> ====================
> 1. Typo in diagram -- arrow between Key n and Key p should be 
> shown to the right.

Yes and will correct. (Shuh's action item)

> 2. Align model represented by the diagram with Object Model in DSKPP.

This issue has been discussed in a previous PSKC conf call. The diagram
is a more clear representation of the container. On the other hand, a
more detailed object model will be genereated after the final XML schema
is finalized. (Shuh's work item)

> 
> 3. Provide note that while PSKC supports bulk provisioning of 
> keys, DSKPP does not.

This is a provisioning protocol, not a format. Therefore, it's better to
specify it in DSKPP.

> Section 6.1.1 (KeyType):

Agree and will correct.  (Ming will correct it today.)

> 
> 2. Last paragraph on 'Value Digest' - Perhaps refer to 
> Section 5.1.8 for clarity.

Agree and will rephrase in this revision.

> Section 6.1.2 (UsageType):

We'll do that in the next revision. Deferred when URI is used.

> 1. Would be better if description were more generic; add 
> storage device as an example.

We'll rephrase it in the next revision.

> 2. I recommend base64Binary as data type for SerialNo.

Will track as an issue to discuss. (Ming)

> To be consistent with the DSKPP Object Model, "UserIdType" 
> would be more consistent that "UserType".  Alternatively, 
> "ClientIDType" would be more consistent than "UserType" since 
> a user may be a software application.

We'll refer this to further study.

> Section 6.1.9 (AlgorithmIdentifierType):

We'll do that in the next revision.

> 2. "The AlgorithmIdentifierType is define^^d^^ as follows"

Agree and will correct. (Ming)

> Section 6.5 (KeyAlgorithmType):

PSKC already has a KeyType. KeyAlgorithm is another attribute layer on
top of KeyType. The KeyAlgorithmType in PSKC is different from KeyType
in DSKPP. KeyAlgorithmType is the algorithm where the key will be
applied. Therefore, we'll need to do more study on this issue to better
clarify.

> I recommend that you identify and define each of the profiles 
> that are described at a high-level here.

We'll defer it to the next revision.

> Section 8.2 (Payload Integrity):

Agree and will correct. (Ming to change today)

> "informative" (e.g., all of the I-D's).  I think the section 
> should either be divided in two, or simply called "References".

We need to further discuss this issue.

> 2. Is [OATHRefArch] used in the document?

Will remove it.

> 3. Update [DSKPP] reference to draft-ietf-keyprov-dskpp-00.txt.

Agree. (Ming to change in this revision)