[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt
Andrea,
Thanks so much for the review.
Please see my comments and what I have changed for final submission:
Philip
-----Original Message-----
From: keyprov-bounces at ietf.org [mailto:keyprov-bounces at ietf.org] On
Behalf Of andrea.doherty at rsa.com
Sent: Monday, June 15, 2009 6:23 AM
To: Hannes.Tschofenig at gmx.net; keyprov at ietf.org
Subject: Re: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt
Philip, etal:
Great work on the document!
Please find my comments below.
Items representing things that I think are "issues" are prepended with
three asterisks ('***'). Note, however, that I think these are minor in
nature.
Andrea
==============================================
Key:
S - Section
P - Paragraph
F - Figure
Abstract: Insert a comma after "For example"
[PH] changed
Introduction, P1: ", for example^^,^^ vendors"
[PH] changed
S3, #6: "wether" is misspelled
[PH] could not find this, must have been corrected earlier
S4, P2: when describing the example, would help to mention the use of
PIN algorithm since PIN's might not automatically be thought of as
symmetric keys.
[PH] Changed the example to use HOTP algorithm
*** S4, 'Id': The reference to multiple containers threw me. According
to our terminology discussion, and the discussion on Bulk Provisioning
in Section 8, PSKC only defines one Key Container. Under what
circumstances would "multiple key containers" be embedded in larger xml
documents?
[PH] this was deemed good practice for XML so maybe if it is not DSKPP
but other larger xml documents the potentially could contain multiple
PSKC containers and hence having an Id would be very helpful to refer to
them
*** S4.1, 'Algorithm': [PSKC-ALGORITHM-PROFILES] is going to expire on
June 27, 2009.
[PH] I need to update the spec and update, I know.... not enough time,
too much to do.....
S4.1, last paragraph re <ValueMac>: This paragraph is difficult to
understand. Rather than "MUST be possible to carry" you are not
inferring that <ValueMac> is mandatory, but the wording implies this.
<ValueMac> is optional. Because <ValueMac> is defined in the schema, it
must be possible to carry the value --- this doesn't need explicit
mention here. Would be clearer to just have <ValueMac> as another item
in the list (after 'Encrypted:") and discuss it from there.
[PH]: changed
*** S4.2, sample schema, <UserID>: The <UserID> value is missing UID.
Under what situations would the Device have a different UserID than the
Key that the device holds? Does Device really refer to Issuer?
[PH] can't follow UID. It seems to be ok in my version. The UID for a
key could be a group of people (sort of a role certificate).
*** S4.2.1, <DeviceBinding>: Rob Philpott suggested the following
re-wording (I mentioned this re-wording in my comments on the previous
version of the doc):
"This element allows a provisioning server to ensure that the key is
going to be loaded into the device for which the key provisioning
request was approved. The device is bound to the request using a
device
identifier, e.g., an IMEI for the phone, or an identifier for a
class of
identifiers, e.g., those for which the keys are protected by a TPM."
[PH] changed
S4.2.3, P3: "indicates XXthatXX the entity"
[PH] changed
*** S4.2.3, P3: By "entity" what is being referenced? Issuer? The
distinction between UserID associated with key and UserID associated
with Device is unclear.
[PH] I changed this to 'it indicates the user the device is associated
with.'
S4.3, P1: "sending and receiving partiesXX,XX might"
[PH] changed
S4.3, P2: check wording for editorial problems
[PH] slightly changed wording
S4.3, P2: Would provide better context if you stated that this example
is based on MasterCard CAP, e.g., "For example, ^^in the case of
MasterCard CAP,^^
[PH] changed
S4.3, last paragraph: The text after F4 mentioned an external key called
"MasterKeyLabel", but this doesn't match the example, which instead uses
<KeyProfileId> called "keyProfile1".
[PH] good spot, changed the example and description
S5, <NumberOfTransactions>: "key carried within the PSKC document can be
used" - clarify what "used" means. I think it means the number of times
the key may be used by an application (after the key was imported by the
receiving party). But, "used" could also mean the number of times the
key can be imported.
[PH] changed
S5, <Verify>: "(000 is the vice versa of Integrity)"
[PH] changed
S5, <Prepend>: This description refers to "validation server". Would be
more consistent with the rest of the document to refer to this as the
"receiving party".
[PH] changed but not used receiving party since in this case it is the
party that validates the algorithm response
S5, <Append>: Same comment as above.
[PH] changed
S5, <MaxLength>: "lenght" --- misspelled
[PH] changed
*** S6.2: Alignment issue with DSKPP.
Note that according to DSKPP (-07, section 5.2.2), for
Passphrase-Based Key Wrap,
"the <ds:KeyName> option MUST be used and the key name MUST identify
the
passphrase that will be used by the server to generate the key
wrapping key.
The identifier and passphrase components of <ds:KeyName> MUST be set
to the
Client ID and authentication code components of AD (same AD as
contained in this
message)."
However, in S6.2 of this version of PSKC, <ds:KeyName> is not
mentioned.
[PH] not sure what I should add here could Ming help?
S6.3, last sentence: confusing sentence
[PH] changed
S6.4: The wording is difficult to understand, as there are lots of
misspellings, etc.
[PH] completely changed
S10.1, Profiling: "meta-data" --- everywhere else in the doc "meta data"
is used.
[PH] changed
S11: Is the annotation regarding line break within SchemaLocation
necessary? The DSKPP schema has lots of line breaks, but no annotations
included.
[PH] removed
S12.5 and S12.6, "depreciate": The word "deprecate" is typically used
instead of "depreciate".
[PH] changed
S13.2: "provides a mean^^s^^"
[PH] already changed
S15: "Veath"->"Vaeth"
[PH] D'oh, changed
S16.2: The [DSKPP] is out-of-date. The latest version was released in
Feb 2009 and was version -07.
A.1.3: "floppy" - I don't think floppy disks are used any more.
[PH] sadly yes
A.1.4: "Over-The-Aire" -> "Over-The-Air" (Aire is a river in N England)
[PH] changed
________________________________
From: keyprov-bounces at ietf.org on behalf of Hannes Tschofenig
Sent: Tue 6/9/2009 2:59 PM
To: KEYPROV
Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt
Hi all,
This is the 2nd Working Group Last Call for comments on "Portable
Symmetric
Key Container (PSKC)":
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-03.txt
Please have comments to the list by Sunday, 27 June.
As always, please remember to send a note in if you've read the document
and
have no other comments other than "its ready to go" - we need those as
much
as we need "I found a problem".
Ciao
Hannes & Phillip
_______________________________________________
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