Comments on Draft 11-May-2001

1.  Hey the title is wrong -- it say 11-Mar-2001 -- oh well.

2.  Section 1, Para 3:  These MAYs should become "can" or "may".  First
there is no protocol statement here and secondly I doubt that you really
want this to be "optional" to implement.

3.  Section 2, Para 2:  Formatting issue. For some reason KeyInfo is
indented one level and it should not be.

4.  same:  It is my believe that the EncryptedKey and KeyRetrievalMethod
elements should have a trailing ? as they are optional elements.

5.  Section 2.1.2, Para 1:  Change "expiration date secret" to "expiration
date."

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.

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"

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."

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).

10.  Section 3.1, Para 1:  "usef ul" should become "useful".

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.

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).

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.

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.

a)  The new extended element properly belongs before the base elements.
  <EncryptedKey>
    <ReferenceList/>
    <EncryptionMethod/>
    <CipherData/>
  </EncryptedKey>

b)  The new extended element property belongs after the base elements.
  <EncryptedKey>
    <EncryptionMethod/>
    <CipherData/>
    <ReferenceList/>
  </EncryptedKey>

c) The new extended element can be placed anywhere in the sequence of base
elements (thus implying no conical ordering for schema sequences).
   <EncryptedKey>
     <EncryptionMethod/>
     <ReferenceList/>
     <CipherData/>
   </EncyptedKey>

It is my believe that either a or b is the correct answer (probably b) and
thus all examples need to be updated accordingly.

15.  Section 3.5, Para 1:  Suggest text "ReferenceList is an element that
contains pointers from a key value to items encrypted by that key value
(EncryptedData or EncryptedKey elements)."

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.

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

Received on Tuesday, 5 June 2001 04:04:36 UTC