Re: comments on "Note on XML Encryption"

Blair,

I discussed your comments with Hiroshi Maruyama and we just thought of some
comments.

>1. This approach tries to reuse the same mechanisms for both data
>encryption and key transport
>...
>We fail to see the benefit of this deeply
>nested structure and reuse of tags with different meanings.  A simpler
>structure, that makes it clear this is key transport information, seems
>like a better choice.  Such a structure, as an immediate child of the
><EncryptionInfo>, might look like
>       <EncryptionKey>
>          <KeyInfo>
>             <!-- asymmetric public key -->
>          </KeyInfo>
>          <EncryptionMethod> ...
>          <EncryptedData> ...
>       ...

With your structure, a few scenarios cannot be dealt with:

1. When an application specifies a URI that identifies information or a
service to decrypt an encrypted key.

2. When re-using the same keying information, it is wasteful to include it
repeatedly.  For example, suppose that some <EncryptedData> elements also
contain session keys encrypted with a public key and an <EncryptionInfo>
element containing the public key is stored at a remote location.

3. When some keys are encrypted sequentially, where the result will be a
chain of <EncryptionInfo> elements.  For example, suppose that a session
key is encrypted with another session key, the latter session key is
encrypted with another session key, ...


>6. It's not clear how one would use the proposed design to handle
encryption
>to multiple recipients.  We will need to decide how to indicate the
>appropriate EncryptionInfo for each recipient, shared use of a single
>EncryptionInfo, and so forth.

When using key transport, does your structure allow that the
<EncryptionKey> element occurs two or more times?  Though we are still
unsure whether encryption information for all recipients should be
collected into one <EncryptionInfo> element, our structure allows that.
However, when an <EncryptionInfo> element contains some <EncryptedData>
elements (in our structure) and each of them references another
<EncryptionInfo> element, a recipient has to find his <EncryptedData>
element in them.  If the number of them is large, that will be pains.  Do
you have any thoughts on this?

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
E-mail: imamu@jp.ibm.com



From: Takeshi Imamura/Japan/IBM@IBMJP@w3.org on 2000/10/27 07:26 PM

Please respond to Takeshi Imamura/Japan/IBM@IBMJP

Sent by:  xml-encryption-request@w3.org


To:   Blair Dillaway <blaird@microsoft.com>
cc:   xml-encryption@w3.org, Hiroshi Maruyama/Japan/IBM@IBMJP, Satoshi
      Hada/Japan/IBM@IBMJP
Subject:  Re: comments on "Note on XML Encryption"





Hi Blair,

Thank you for commenting on our note.

>1. This approach tries to reuse the same mechanisms for both data
encryption
>and key transport
>...
>We fail to see the benefit of this deeply
>nested structure and reuse of tags with different meanings.  A simpler
>structure, that makes it clear this is key transport information, seems
like
>a better choice.

Your structure seems to be almost the same as CMS uses.  We also used a
CMS-like structure before, but we changed it into the one in the note
because we thought that it is natural that the <EncryptionInfo> element is
used for both of encrypted data and encrypted keys uniformly.  If the
element is designed in such a way, the same processor can be used.
However, we also understand that ours is a little complicated.


>2. The design separates out encryption KeyInfo, KeyAgreement, and
KeySharing
>as distinct mechanisms for transmitting information about a symmetric
>encryption key.  These are simply options as to how keying information may
>be communicated.  To align more cleanly with DSig, these should be unified
>into a single mechanism.  In addition, use of this mechanism should be
>optional, i.e., the symmetric key may be implied.

We have no problem here.


>Key sharing using a name key might look like:
>   <EncryptionInfo>
>    <EncryptionKey>
>         <KeyName>foo</KeyName>
>    </EncryptionKey>
>   ...

Sorry, my description on key sharing was very poor.  I expected that the
<KeySharing> element was used for managing a key by secret sharing (or
threshold schemes), and what you illustrated in the above example will be
done by using the <KeyName> element as follows (in our style):

  <EncryptionInfo>
    <KeyInfo>
      <KeyName>foo</KeyName>
    </KeyInfo>
    ...
  </EncryptionInfo>


>3. We disagree that encryption meta-data should be an integral part of the
>EncryptionInfo.

We think the <EncryptionInfo> element should contain a general-purpose
element to contain meta-data because meta-data such as decryption policies
should be contained in the element (of course, another processor will be
needed to enforce the policies).


>4. We believe that there's a need to support References from the
>EncryptionInfo to the EncryptedData  elements as well as from the
>EncryptedData to the EncryptionInfo as indicated in the Note.
>...
>We believe they should be.

We believe so, too.


>5. We disagree with the proposed algorithms.

We just quoted these algorithms from CMS, and so we don't insist on them.


>6. It's not clear how one would use the proposed design to handle
encryption
>to multiple recipients.  We will need to decide how to indicate the
>appropriate EncryptionInfo for each recipient, shared use of a single
>EncryptionInfo, and so forth.

Do you have any concrete ideas?


>7. We'd like to see explicit linkage between use of asymmetric keys in
>support of encryption and the XML DSig work.  Specifically, we should
re-use
>the DSig <KeyInfo> definition, rather than creating a new one, when we
need
>to express asymmetric key information.

We agree with you.  In fact, we designed the <KeyInfo> element so that we
could immigrate into the one in DSig easily.  If the one in DSig is reused,
our style will be as follows:

  <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc">
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <!-- key identifier for already shared key -->
      <KeyName>...</KeyName>
      <!-- the same key encrypted with someone's public key -->
      <EncryptedData xmlns
="http://www.w3.org/2000/10/xmlenc">...</EncryptedData>
    </KeyInfo>
    ...
  </EncryptionInfo>

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
E-mail: imamu@jp.ibm.com



From: Blair Dillaway <blaird@microsoft.com>@w3.org on 2000/10/27 08:10 AM

Please respond to Blair Dillaway <blaird@microsoft.com>

Sent by:  xml-encryption-request@w3.org


To:   "'xml-encryption@w3.org'" <xml-encryption@w3.org>
cc:   Brian LaMacchia <bal@microsoft.com>, Barb Fox
      <bfox@exchange.microsoft.com>
Subject:  comments on "Note on XML Encryption"



(the following represents the combined comments of Blair Dillaway, Barb
Fox,
and Brian LaMacchia)

Below are several comments in response to the earlier posting of "Note on
XML Encryption" from Takeshi Imamura and Hiroshi Maruyama.  That document
is
a reasonable starting point, but we'd like to raise some issues that should
be addressed by the working group.  Looking forward to the meeting next
week.

1. This approach tries to reuse the same mechanisms for both data
encryption
and key transport Specifically, the encoding of an
        <EncryptedData>
          <EncryptionInfo>
               <KeyInfo>
                <EncryptionMethod>
          .....
element structure inside of an <EncryptionInfo><KeyInfo> to handle
symmetric
key wrapping using a public key.  We fail to see the benefit of this deeply
nested structure and reuse of tags with different meanings.  A simpler
structure, that makes it clear this is key transport information, seems
like
a better choice.  Such a structure, as an immediate child of the
<EncryptionInfo>, might look like
       <EncryptionKey>
          <KeyInfo>
               <!-- asymmetric public key >>
          </KeyInfo>
          <EncryptionMethod> ...
          <EncryptedData> ...
       ...


2. The design separates out encryption KeyInfo, KeyAgreement, and
KeySharing
as distinct mechanisms for transmitting information about a symmetric
encryption key.  These are simply options as to how keying information may
be communicated.  To align more cleanly with DSig, these should be unified
into a single mechanism.  In addition, use of this mechanism should be
optional, i.e., the symmetric key may be implied.  Key sharing using a name
key might look like:
   <EncryptionInfo>
     <EncryptionKey>
          <KeyName>foo</KeyName>
     </EncryptionKey>
   ...
Key transport as above, etc.  (Note: The <KeySharing> tag defined in the
Note has no examples of its use )

3. We disagree that encryption meta-data should be an integral part of the
EncryptionInfo.  As the document states, this information varies by
context/application so we can't define any standard structure for this
information.  Some applications may also want to encrypt this meta-data.
We
feel this will be easier if it is a separate XML 'blob' left to the
discretion of the using application.

4. We believe that there's a need to support References from the
EncryptionInfo to the EncryptedData  elements as well as from the
EncryptedData to the EncryptionInfo as indicated in the Note.  What isn't
clear is whether the authors believe both types of references are optional.
We believe they should be.

5. We disagree with the proposed algorithms.  The mandatory algorithm set
should avoid any potential IP encumberences and hence, we suggest that
Diffie-Hellman be dropped.  We would like to see triple-DES and RSA as
recommended and AES mandatory.

6. It's not clear how one would use the proposed design to handle
encryption
to multiple recipients.  We will need to decide how to indicate the
appropriate EncryptionInfo for each recipient, shared use of a single
EncryptionInfo, and so forth.

7. We'd like to see explicit linkage between use of asymmetric keys in
support of encryption and the XML DSig work.  Specifically, we should
re-use
the DSig <KeyInfo> definition, rather than creating a new one, when we need
to express asymmetric key information.

Regards,
Blair

Received on Friday, 27 October 2000 13:22:32 UTC