Re: Comments on Draft 11-May-2001

Hi Jim, thanks for the extensive comments! Assume fixed if not responded to.

At 04:04 6/5/2001, Jim Schaad wrote:

>6.  Section 2.2.1, Para [s1]:  Should text be inserted here (and in the
>discussion of type) that allows for an entire document to be identified as
>the type?  Under my understanding there may be issues here that need this
>documented.  One cannot insert a full document (with processing headers) in
>the middle of an existing document successfully without first applying some
>modifications to the document.  This appears to be a special case that needs
>to be identified.

I don't understand? The document has been changed, element content has been 
replaced as shown...?

>7.  Section 2.2.2:  I suggest that the KeyName (line [t05]) and
>corresponding KeyName (incorrectly used) in line [t09] both be removed.
>They confuse this example which purports to show the use of
>KeyRetrievalMethod.  If you want to keep it then the following changes
>should be made:
>- Change text to "[t05] ds:KeyName provides an alternative method of
>identifying the key needed to decrypt the CipherData.  Either or both the
>KeyName and KeyRetrivalMethod could be used to identify the key."
>- Line [t09] should read "<enc:EncryptedKey Id='EK' NameKey="John Doe"

Fixed.

>8.   same:  Suggested text for comment on [t09]. "The encryptedKey element
>is similar to the EncryptedData element.  The major differences being that
>the data encrypted is always a key value.  The NameKey attribute is used to
>give an internal name to the encrypted key value which may be referenced by
>the KeyName KeyInfo element."

Ok.

>9.  General:  I propose the following change to help clarify what NameKey
>and KeyName are used for:  NameKey should become "NameThisKey" and 
>"KeyName" should become "UseTheKeyNamed".  That makes it very explicit what 
>is what (although it would require either we create a new element or change 
>digsig
>since KeyName is currently defined there).

We didn't have any strong candidates, but we had to make a decision so on 
the last telecon folks agreed to move ahead with "CarriedKeyName".
        http://www.w3.org/Encryption/2001/Minutes/010514-tele.html

>11.  Section 3.2, Para 3:  I have not yet finished reading all of the mail
>history so I am going guess that somebody introduced the concept of reverse
>transforms with good intentions and good text, however I find the entire
>concept to be both fuzzy and confusing.  I suggest that all comments
>regarding reverse transforms be removed form the document leaving the
>concept of applying a set of transforms to obtain the cipher data but not to
>build the cipher data.  If one writes an XPATH transform along the lines of
>"Get the data of the element #x" or "Get the data of all elements with the
>tag 'HasData'", these are both valid transforms to use for obtaining the
>data, but the reverse of these transforms is a set (possibly infinite set)
>of transforms to be applied.  This entire section is simpler if we omit
>reverse transforms.

I think Takeshi has been most active on this text -- see previous emails -- 
so I'll defer response to him.

>12.  Section 3.2, Para 5:  If this is where the location of DigestValue is,
>then text needs to be included here about how to use this.  Unless the text
>created to be encrypted cannot be reasonably guessed at by an attacker, the
>inclusion of an unprotected digest value allows for guesses at the plain
>text to be confirmed (hash it and compare with the published value).  At a
>minimum, the text about this should be included  here.
>
>My personal opinion is that this should not be included in this structure.
>This allows for a simple attack on several fronts:  1) denial of service as
>the bits of this field could easily be tweaked, 2) comparison attacks: did
>the same data get encrypted in different messages to different people (must
>change the random value).  If there is a real need for this type of value
>then I believe it should be an encrypted value and if possible included
>within the cipher data itself (i.e. the plain text becomes the original text
>(possibly padded) with the digest value appended).

Amir's original proposal for <HashOfRandomized> [2], which we had a fair 
amount of discussion on the list over.

[2] http://lists.w3.org/Archives/Public/xml-encryption/2001May/0000.html
>To prevent guessing attacks, the plaintext MUST include
>sufficient enthropy, possibly by appending to the `real` plaintext a random
>string just to increase its enthropy.

Eventually, we decided to move forward with this but reusing the dsig syntax 
instead of "HashOfRandomized." So I'll let Amir or others more substantively 
respond to this.

>13.  Section 3.4, Para 1:  The last sentence should be removed from this
>paragraph.  In the case of item 3, 1 the information is NOT contained within
>a KeyInfo element.

/- In all cases, this information is contained within a KeyInfo element.-/

>14.  Section 3.4.1:  I will attempt to clarify a comment made in a previous
>message:
>
>EncryptedKey is built in schema by extending the base case EncryptedType.
>When this is done I don't under stand the proper placing of the
>ReferenceList element.  There are three distinct "correct" ways of doing an
>EncryptedKey element.
>
>It is my believe that either a or b is the correct answer (probably b) and
>thus all examples need to be updated accordingly.

Will look into this -- want to confirm with the schema validator, but 
something's buggy and holding me up.

>16.  Section 4.1:  I suggest that a new item "5. Place the new XML
>structure" be inserted between items 4 and 4.1.  4.1 and 4.2 deal with where
>to put the new XML structure and not how to built it.

But the how to build and where both align along whether it's XML savvy or 
octets. (Not sure if I completely understand.)

>17.  Section 4.3:  see comment 6 about possibly separating "document" from
>"content?".
>
>18.  Section 6.1, item 1:  I do not agree that this solves the first issue.
>One can still hash previously encrypted data and then do a super-encryption
>of that data and the signature and still have all of the problems in item 1.
>It does address Hal's concern however.
>
>19.  Section 6.2:  The only sensible text here is that of paragraph 2.
>Remove paragraph 1.  Even if we don't identify it that does not stop people
>from trying existing keys.
>
>20.  Section 8.2, item 4:  We can obviously move from KeyRetrieval to just
>Retrieval since it is defined that way.  The only reason that it was defined
>the way it is has to do with the fact that I thought it might be easier on
>code to know in advance that is what it was going to see (although with
>XPATH type queries it probably is about the same).  This needs to be
>answered by implementation experience.  Does it make the code easier?
>
>jim


--
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Wednesday, 6 June 2001 17:17:55 UTC