Subject: [KEYPROV] PSKC - response from Authors on comments received from Tim Moses

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 24 Sep 2007 12:20:54 +0200

Please find comments to your questions from Ming Pei [MP] and myself
[PH].

Thanks for reviewing,

Philip

From: Tim Moses [mailto:[email-masked]] 
Sent: Thursday, September 13, 2007 10:57 AM
To: Philip Hoyer; Shuh; Salah; Pei, Mingliang
Subject: Comments on July '07 version of 'pesky' 

Colleagues - I just had a quick look at the July '07 version of the
'pesky' draft.  I haven't done a comprehensive review.  But, I do have a
couple of questions/comments.  Please don't feel you have to respond.
But, if you do want me to clarify something, don't hesitate to contact
me.  Thanks a lot.  All the best.  Tim.

1. Where does the need for multiple users per device come from?  It
doesn't seem to come from any of the requirements in Section 4 as far as
I can tell.  Is it to support multiple personas? 

MP: Yes, it is to support multiple personas - a user may use a token to
login Unix with userid u1 and windows with user id u2.

2. The schema in Section 7 is not consistent with the schema fragments
throughout the text.

MP: Will examine and fix them.

3. Where a default value is specified, the 'use="optional"' attribute is
not required.

MP: Will fix it.

4. <AccessRules> should not be described in Section 6.1.2.

MP: Good catch. Will fix it.

5. What is the reason for not using XML-ENC to encrypt the secret
values?

MP: One of the design goals of PSKC is to keep the XML size small.
XML-ENC is generic and powerful but it brings larger XML size for
encryption than we come up for the need of PSKC.

6. The EncryptionMethod type could be defined, more simply, as <element
name="EncryptionMethod" type="pskc:EncryptionMethodType"/>.  The same
comment applies elsewhere.

MP: Actually yes. Will fix it. Not sure what was there in the beginning
that is wrapped in an unnecessary "complexContent" and extension stuff.

7. Commonly, the version of a schema is captured in its uri, rather than
in an internal data element.  Is there a reason for using a data element
for this information?

MP: In practice, we felt that a version in data element allows less
revision on using different namespace URIs from version to version.
Maybe it isn't so "XML

8. The logic behind the definition of EncKeyLabel is not clear to me.
Are the two sequences that it contains mutually exclusive?  Perhaps it
would be clearer if the two sequences were named.  Why is a hash
algorithm required if the RSA algorithm is used for encryption?  One is
required by OAEP.  But, that should be identified in the OAEPParams
element.

MP: EncKeyLabel is used to indicate encryption key, which can be present
when neither RSA nor PBE is used. The two seq are mutually exclusive.

[PH] The hash algorithm might be legacy from before we added KeyInfo and
OAEPParams elements. I think we can remove this.

9. The ext-algorithm attribute ... it isn't described in the text.  Why
is it mandatory?

MP: It is required when algorithm is OTHER.

10. PKCS#5 is mentioned as a password-based encryption method.  But, it
isn't listed in Section 6.2.  Is PKCS#5 the only PBE scheme
contemplated?  If so, this should be stated.

MP: Need discussion. Prefer to add it.

11. Why are both a key label and ds:KeyInfo allowed together?  If a
label is supplied, there should be no need to transfer a key.  Right?

MP: Agree. See 8 above.

[PH] does this mean we need to change the schema to reflect this?

12. In Section 6.1.8, a digest is described for integrity verification
of encrypted secret keys.  This is required to ensure that the correct
key was used to decrypt the secret.  However, a keyed digest is also
allowed.  This leaves the question of verifying that the correct key was
used in the digest.  Wouldn't it make better sense to only allow unkeyed
digests for this purpose?

MP: Need discussion. Digest alone can serve the purpose. Keyed hash is
safer. Salah?

[PH] a digest is security dangerous since it will allow the checking of
the right key in a brute force attack. This combined with the fact that
probably some of the most common used digest algorithms like SHA-1 will
probably be broken soon makes the use of keyed hashes more appropriate

13. In Sections 6.3 and 6.4, the text does not match the schema
fragment.

MP: Will fix.

14. The specification defines the structure of data to be conveyed
between servers or between a server and a client that hosts a device.
Is it the hope that subsets of this data structure would be passed from
the client to the device?  Is the specification suitable for that usage?

MP: It is up to client to extract respective attributes, and set to a
device according to device software's usage.

[PH] It was also envisaged that PSKC could be sent directly to the
device eg application on a smart card chip

15. Is it the intention to define transport bindings for the data
structure?

MP: Transport is mentioned to indicate to a provisioning protocol
respective security implication. This spec itself doesn't need to
consider transport binding.

16. In Section 6.6, the specification should be clear about the
processing of challenges and responses to and from the encoded
representation.  For instance, does a decimal representation of a
challenge have to the converted to binary before being presented to the
device?

MP:Yes. Encoding should be applied to convert back to original source
data.

[PH] I think Tim is making a different point here, assume that you have
an application on a device that requires a binary challenge but the user
enters it numeric into a form. I believe that the valueformat specifies
the format of the value sent to the algorithm eg sent to the device it
does not drive forms or screens.

17. The oath_logotype is not mentioned in the text.

MP: Will add.

Tim Moses

+1 613 270 3183

________________________________

Philip Hoyer 

Senior Architect - Office of CTO

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL

Telephone: +44 (0) 20 7744 6248

Direct: +44 (0) 20 7744 6455

Fax: +44 (0) 20 7744 6249

Private and confidential: This message and any attachments may contain

privileged / confidential information. If you are not an intended
recipient,

you must not copy, distribute, discuss or take any action in reliance on
it.

If you have received this communication in error, please notify the
sender

and delete this message immediately.

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