RE: XML Encryption 1.1 comments

Frederick,
I have reviewed your comments and in general I think this looks good, but I have a few suggestions below. I cannot really comment on the EXI ones due to my limited EXI knowledge.

> (9) Section 5.4.1, ConcatKDF
> 
> Replace 'The concatenation shall be done using the original, unpadded bit string
> values."'
> 
> with
> 
> 'The concatenation MUST be done using the original, unpadded bit string
> values.'

Perhaps: "The concatenation SHALL ..."?

> (10) Section 5.4.1, ConcatKDF
> 
> In the example, what does it mean to have PartyVInfo=""? is this necessary, or a
> mistake?

I agree that it would be better to have a non-empty PartyVInfo; I can't think of situation where you provide PartyUInfo and not PartyVInfo.
Any value would do for our purposes (as long as it meets the padding rules we introduced).
 
> (11) 5.5.1 RSA Version 1.5
> 
> Replace
> "Support of this key transport algorithm for transporting 192 bit keys is
> MANDATORY to implement. "
> 
> with
> 
> "Implementations MUST implement this key transport algorithm with support
> for transporting 192 bit keys."

I suggest to instead change to: "Implementations MUST support this key transport algorithm for transport of 192-bit TRIPLEDES keys." (since the key transport algorithm is already required).

-- Magnus


> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org]
> On Behalf Of Frederick Hirsch
> Sent: Monday, April 26, 2010 6:06 PM
> To: XMLSec WG Public List
> Cc: Frederick Hirsch
> Subject: XML Encryption 1.1 comments
> 
> I have some  comments on latest editors draft of XML Encryption 1.1 at
> <http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm>
> 
> Editorial comments follow substantive comments.
> 
> Substantive:
> 
> (1) Section 2.1, Encryption Granularity
> 
> Add warning that examples do not consider plaintext guessing attack or other
> risks, and are only for illustrative purposes.
> 
> (2) Section 3.3.1, The CipherReference Element
> 
> In example, replace
> 
> xmlns:rep="http://www.example.org/repository"
> with
> xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
> 
> and replace "parent::rep:CipherValue" with "parent::enc:CipherValue"
> See 3.6 for example that already takes this suggested approach.
> (3) Section 3.5.1, The EncryptedKey Element
> 
> Replace
> 
> "The value of the key is to be the same in all EncryptedKey elements identified
> with the same CarriedKeyName label within a single XML document."
> 
> with
> 
> "The value of the key MUST be the same in all EncryptedKey elements identified
> with the same CarriedKeyName label within a single XML document."
> 
> (in CarriedKeyName paragraph)
> 
> (4) Section 3.5.2, The DerivedKey Element
> 
> Replace
> 
> "The value of the master key is to be the same in all DerivedKey elements
> identified with the same MasterKeyName label within a single XML document."
> 
> with
> 
> "The value of the master key MUST be the same in all DerivedKey elements
> identified with the same MasterKeyName label within a single XML document."
> 
> (in MasterKeyName paragraph)
>
> (5) 3.5.3 The ds:RetrievalMethod Element
> 
> (5a) After first sentence add:
> 
> "The ds:RetrievalMethod with a Type of
> 'http://www.w3.org/2001/04/xmlenc#DerivedKey'
>   provides a way to express a link to a DerivedKeyelement used to derive the key
> needed to decrypt the CipherData associated with an EncryptedData or
> EncryptedKey element."
> 
> (5b) In next sentence replace "with this type" with "with one of these types"
> 
> (5c) Remove " fixed='http://www.w3.org/2001/04/xmlenc#EncryptedKey'"
> from schema example comment.
> 
> (6) The ReferenceList Element
> 
> (6a) In first sentence, replace "EncryptedKey" with "EncryptedKey or DerivedKey"
> 
> (6b) In first sentence after example, replace "EncryptedKey" with "EncryptedKey
> or DerivedKey"
> 
> (6c) In second paragraph after example, beginning "KeyReference elements..."
> replace 2nd occurrence of EncryptedKey (not first) with "EncryptedKey or
> DerivedKey"
> 
> (7) Section 4.1, Intended Application Model
> 
> In the last paragraph, "If XML Encryption is used with an EXI stream [EXI], then
> Encryptors and Decryptors commonly perform type-specific processing." is not
> clear.
> 
> I think the intent is to say perform normal processing at XML Infoset model, but
> serialize using EXI.
> 
> Replace noted sentence with "If XML Encryption is used with an EXI stream [EXI],
> then Encryptors and Decryptors process content as for XML element or XML
> content processing, but taking into account EXI serialization."
> 
> (8) Section 4.3 Encryption
> 
> How does the following statement relate to EXI serialization, any concerns?
> 
> " If the cleartext is of type element or content, the data must be serialized in
> UTF-8 as specified in [XML10], using Normal Form C [NFC]."
> 
> (9) Section 5.4.1, ConcatKDF
> 
> Replace 'The concatenation shall be done using the original, unpadded bit string
> values."'
> 
> with
> 
> 'The concatenation MUST be done using the original, unpadded bit string
> values.'
> 
> (10) Section 5.4.1, ConcatKDF
> 
> In the example, what does it mean to have PartyVInfo=""? is this necessary, or a
> mistake?
> 
> (11) 5.5.1 RSA Version 1.5
> 
> Replace
> "Support of this key transport algorithm for transporting 192 bit keys is
> MANDATORY to implement. "
> 
> with
> 
> "Implementations MUST implement this key transport algorithm with support
> for transporting 192 bit keys."
> 
> =======
> 
> Editorial
> 
> (1) Abstract
> 
> s/structure data/structured data/
> 
> s/which/that/
> 
> (2) 1 Introduction
> 
> s/which/that/
> 
> (3) 2.1.2 Encrypting XML Content (Elements)
> 
> s/ is encrypted:/can be encrypted:/
> 
> (4) 2.1.3 Encrypting XML Content (Character Data)
> 
> s/Or,/Alternatively, /
> 
> (5) 2.1.5 Super-Encryption
> 
> New paragraph before "For example"
> 
> (6) Section 2.2.2 EncryptedKey and elsewhere
> 
> is using &xenc; to represent enc namespace really clear, or should we just spell
> out namespace URI where needed. General comment.
> 
> (7) 3, Encryption Syntax
> 
> s/to fit on the page/URI to fit on this page, but is not part of the URI/
> 
> Add newline to example near end, schemaLocation, and repeat note about
> newline.
> 
> (8) 3.1 The EncryptedType Element
> 
> s/Implementation MUST/Implementations MUST/
> 
> s/or EncryptedKey/or EncryptedKey elements/
> 
> (9) 3.2 The EncryptionMethod Element
> 
> s/which/that/ in 3rd paragraph
> 
> (10) 3.3 The CipherData element
> 
> in 1st paragraph
> 
> s/encoded text/encoded text  as element content/
> 
> (11) 3.4 The EncryptedData Element
> 
> s;replaces the encrypted element;replaces the encrypted element/ element
> content;
> 
> (12) 4.3 Encryption, 4.4 Decryption
> 
> new paragraph before and after every numbered list item as needed.
> 
> (13) 4.5 XML Encryption
> 
> Replace "transforms" with "operations" in first sentence to avoid confusion with
> XML Security specific transforms.
> 
> Replace last sentence
> 
> These sections are non-normative and optional to implementers of this
> specification, but they may be normatively referenced by and MANDATORY to
> other specifications that require a consistent processing for applications, such as
> [XMLENC-DECRYPT].
> 
> with
> 
> These sections are non-normative and optional to implementers of this
> specification, but they may be normatively referenced by and be required by
> other specifications that require a consistent processing for applications, such as
> [XMLENC-DECRYPT].
> 
> 
> (14) 4.5.4 Text Wrapping
> 
> new paragraph before and after every numbered list item as needed.
> 
> replace "element is fed is decrypted" with "element is decrypted"
> 
> (15) 5.2.4 AES-GCM
> 
> space between ']' and 'is'
> 
> (16) 5.4.1 ConcatKDF
> 
> 3rd paragraph after first example, s/for The/for the/
> 
> new paragraph before and after every numbered list item as needed.
> 
> (17) 5.4.2, PBKDF2
> 
> Add newline before "default" for last complexType definition, add note about
> newline
> 
> (18) 5.5.2 RSA-OAEP
> 
> Are spaces ok/misleading in OAEPparams value?
> 
> (19) 6.1 Relationship to XL Digital Signatures
> 
> new paragraph before and after every numbered list item as needed.
> 
> 
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
>

Received on Tuesday, 4 May 2010 03:39:56 UTC