W3C home > Mailing lists > Public > xml-encryption@w3.org > October 2000

RE: comments on "Note on XML Encryption"

From: Blair Dillaway <blaird@microsoft.com>
Date: Fri, 27 Oct 2000 10:56:56 -0700
Message-ID: <AA19CFCE90F52E4B942B27D42349637921F7E7@red-msg-01.redmond.corp.microsoft.com>
To: "'Takeshi Imamura'" <IMAMU@jp.ibm.com>
Cc: xml-encryption@w3.org, Hiroshi Maruyama <MARUYAMA@jp.ibm.com>, Satoshi Hada <SATOSHIH@jp.ibm.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:17 GMT