RE: comments on "Note on XML Encryption"

Takeshi, 

As stated in the original posting our intent was to identify some
significant issues to be discussed.  The simple examples were intended to
illustrate the issue, not present a complete XML schema proposal.  We can
proceed to that once the group agrees upon the scope of problems we are
intending to solve.

a few other comments in-line...


Blair

> -----Original Message-----
> From: Takeshi Imamura [mailto:IMAMU@jp.ibm.com]
> Sent: Friday, October 27, 2000 10:19 AM
> To: Blair Dillaway
> Cc: xml-encryption@w3.org; Hiroshi Maruyama; Satoshi Hada
> Subject: 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.

I presume we would handle this through inclusion of something along the
lines of the XML DSig <RetrievalMethod> tag. 

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

We agree information shouldn't be repeated if not required.  Hence our
insistence that all of the fields be optional.  I would disgree we want to
encourage applications to place encrypted symmetric keys in arbitrary
EncryptedData blobs if we provide a structure in EncryptionInfo to hold this
data.  While you couldn't prevent an application from doing this, it would
make development of standard tools and interop difficult.

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

We do need to deal with the case of a symmetric key encrypted with another
symmetric key.  But I believe this can be dealt with by an appropriate key
reference inside the <EncryptionKey> element.

> 
> 
> >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?

This is a potentially complicated issue.  I'd prefer we agree upon what
multi-recipient scenarios the group will address and then move forward with
a design proposal.

> 
> 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:59:57 UTC