W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2001

Protecting the integrity of retrieved ciphertext

From: <edsimon@xmlsec.com>
Date: Fri, 30 Nov 2001 15:58:57 -0500
Message-ID: <3C053CF100001028@mail.san.yahoo.com>
To: xml-encryption@w3.org, rivest@mit.edu
I should add that URIs are used for retrieving data in the <CipherReference>,
<DataReference>, and <KeyReference> elements.  Upon initial consideration,
the same views expressed below for <CipherReference> should hold for <DataReference>
and <KeyReference> as well.

Ed

-- Original Message --

>On Fri, Oct 26 2001, Ron Rivest wrote:
>
>(2) You have provisions for referring to some elements indirectly (e.g.
>through a URI), but you may need some way to ensure that what you retrieve
>is what was intended (e.g. through a hash of the element to be retrieved).
>Perhaps this is implicitly handled already...
>
>I respond:
>
>I think a key phrase in the comment is "ensure that what your retrieve
is
>what was intended".  Of course, the definition of "what was intended" will
>change from application to application.
>
>A common scenario would be data that was originally part of the document
>in question, that was encrypted, and stored outside the document.  If the
>application intends that no alteration happen to that data while it is
"away",
>then it should create a signature of the encrypted data beforehand and
verify
>that signature before decrypting.  Even if the data is not being stored
>outside of the document but whose encrypted form is being stored inline,
>it may be reasonable to use an XML Signature to protect its integrity.
>
>Another scenario is where a document has no or incomplete prior knowledge
>of the plaintext content of an <EncryptedData> element.  For example, suppose
>information about Imelda's stock portfolio is encrypted (directly or indirectly)
>with Imelda's encryption public key and held on a server at XYZ Corp. 
However,
>Imelda has a financial management program on her PC that integrates data
>from various sources, including her stock portfolio managed by XYZ Corp.
>
>
>Imelda's financial info document stored on her PC might look like this:
>
><MyFinancialInfo>
>
><MyBankAccounts>...</MyBankAccounts>
>
>...
>
><MyStockPortfolio>
><EncryptedData xmlns="...">
>...
><CipherData>
>  <CipherReference
>    URI="http://www.example.com/xyzcorp/OurClientsStockPortfolios/Imelda.xml">
>    <Transforms>
>      <ds:Transform
>       Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
>          <ds:XPath>
>            self::text()[parent::CipherValue[@id="StockPortfolio"]]
>          </ds:XPath>
>      <ds:Transform>
>      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
>    </Transforms>
>  </CipherReference>
></CipherData>
>
></EncryptedData>
></MyStockPortfolio>
></MyFinancialInfo>
>
>In the above example, the ciphertext octets that result from processing
>CipherData might best be signed by XYZ Corp. since it would be XYZ Corp.
>that would have last touched Imelda?s stock portfolio data.
>
>Regards, Ed
>
>
>-- Original Message --
>
>>
>>http://www.w3.org/Encryption/2001/Minutes/011119-tele.html
>>                             W3C XML Encryption WG
>>
>>  2001-November-19
>>  Chair: Joseph Reagle
>>  Note Taker: Joseph Reagle [ascii]
>>
>>Participants
>>
>>     * Joseph Reagle, W3C
>>     * Blair Dillaway, Microsoft
>>     * Ed Simon, XMLsec
>>     * Christian Geuer-Pollmann, University of Siegen
>>     * Eric Cohen, PwC
>>
>>News
>>
>>Status of documents
>>
>>     * Last Call ended November 9th. I've sent a nagmail to SOAP, SAML,
>>       and Schema WGs since I got them to agree to consider the Last
>>       Call, but they never responded with a date of response -- nor
>>       comments obviously.
>>
>>Reviewing Previous Items
>>
>>    1. Eastlake: add real life examples in section 5.5 to illustrate.
>>       Pending. Open for re-assignment.
>>    2. Action Hughes: ( XML Encryption Processing Model) Will investigate
>>       and send an email on Xerces implementation using XNI, or DOM when
>>       processing Element or Element Content.
>>       Pending.
>>
>>Requirements
>>
>>   ...
>>
>>Draft
>>
>>  Pending
>>
>>     * Ed Simon
>>         1. Should the CarriedKeyName attribute really be a child
>>            element?
>>            ACTION Reagle: change to a child element, cc: Merlin/Takeshi
>>            to see if they oppose.
>>         2. Section 3.5: The ReferenceList Element In the schema
>>            definition, why not use <choice> rather than <sequence>?
>>            ACTION Reagle: change to choice.
>>     * Christian Geuer-Pollmann
>>         1. (Many editorial comments)
>>         2. Should we add a warning into section "3.1 EncryptedType" that
>>            it is not allowed (or could cause problems) if an
>>            EncryptedData element becomes the DocumentElement of a new
>>            Document with @Type="ElementContent" ?
>>            ACTION Reagle: add warning text on this point if it doesn't
>>            already exist, "decrypted content may not be well-formed
>>            XML."
>>     * Herzberg's comments on Decryption Transform
>>         1. Requests a decrypt:Remove which indicates the identified
>>            element should not be part of the Signature.
>>            Reagle: I believe this functionality is addressed directly
>by
>>            XML Signature.
>>            Telecon participants agree.
>>     * Takeshi Imamu
>>         1. Should a nonce be associated with an EncryptedKey? A nonce
>>            cannot be used for encrypting a key, right? So I just thought
>>            that, if a user was trying to use a nonce for encrypting a
>>            key, it would be helpful to warn the user of the illegal use
>>            of nonce. Our implementation just ignores such a nonce,
>>            though.
>>            Reagle: I expect I'm not understanding the issue well, while
>>            I appreciate the algorithm itself might provide for a nonce,
>>            how would this redundancy hurt anything?
>>            Dillaway: agrees with Takeshi, EncryptedKey shouldn't have
>a
>>            nonce because it can complicate the algorithms. For example,
>>            some algorithms expect particular key sizes that this would
>>            confuse.
>>            ACTION Reagle: remove Nonce attribute from Encrypted Key.
>>
>>   (Section 5)
>>     * Ronald Rivest
>>         1. Does this support "new combined "encryption+integrity" modes
>>            of operation
>>            Yes, one can specify the approriate algorithm and
>>            identifier."
>>         2. "You have provisions for referring to some elements
>>            indirectly (e.g. through a URI), but you may need some way
>to
>>            ensure that what you retrieve is what was intended (e.g.
>>            through a hash of the element to be retrieved). Perhaps this
>>            is implicitly handled already..."
>>            Dillaway: this might be accomplished via a Transform that
>>            contains a digest within a CipherReference.
>>            ACTION Simon: send email to a list exploring this scenario.
>>         3. "There are of modes of encryption that won't fit your model,
>>            but which are very useful. For example, "secret-sharing"
>>            allows encryption of a document into several pieces, or
>>            shares, in such a way that a requisite number of them are
>>            required to decrypt/reconstruct the document. Just be sure
>>            you don't preclude somehow expansion to handle this sort of
>>            thing later on."
>>            Dillaway: way back when, we decided not to address threshold
>>            schemes. When Barb Fox asked the question, there was a
>>            resounding "no." However, I don't have a prolbem with someone
>>            layering it on top of what we specified.
>>            Reagle: do we then have some obligation to show how it can
>be
>>            done? Is anyone interested in this enough to take that on?
>>            Dillaway: Might have time in three weeks time.
>>            Simon: Perhaps we could ask Rivest to point out if it can't
>>            be done.
>>         4. "I'm very uncomfortable with allowing the encryption
>>            algorithm to be "understood" between the sender and the
>>            recipient; you should force the sender to be explicit.
>>            Non-explicitness is the cause of very many protocol
>>            failures."
>>            Reagle: we made SignatureMethod optional in xmldsig...
>>            Dillaway: Agrees it can be dangerous, but its difficult to
>>            keep people from doing it in their protocol if they always
>>            use a particular algorithm, just seems redundant to them
>>            then.
>>            Reagle: Do people on this call support any scenarios
>>            presently where this information isn't sent?
>>            Dillaway: Not yet, but I can think of a couple of protocol
>>            scenarios where this is unnecessary overhead.
>>            ACTION Reagle: add warning text if there's a place where it
>>            seem approriate, assume they both know and they are wrong.
>>            Reagle: is there a security problem when it relates to
>>            signing, where someone signs the ciphertext, but subsitutes
>a
>>            different message with different algorith?... Suppose not,
>as
>>            we already say if people want to secure plain text, that's
>>            what they need to sign.
>>            Simon: someone encrypted a flower, but gets white noise, the
>>            plaintext should've been signed.
>>     * Blake Dournaee
>>         1. Is Canonical XML really a recommended serialization
>>            algorithm; when exactly must one use it?
>>            ACTION Eastlake: tweak the c14n in section 5, include
>>            exclusive canonicalization as an algorithm.
>>     * Yongge Wang
>>         1. "Is it possible to change the order of the input to KM so
>>            that it will look like:"
>>            ACTION Eastlake: Edit section 5.5 .
>>     * Jiandong Guo
>>         1. Nonce and Key Wrap Algorithm: "It seems to me that with the
>>            key wrap algorithm specified in section 5.6.2, there is no
>>            way a nonce can be used, although you may still set up one
>in
>>            the corresponding CipherData element by the document."
>>            Defer until Eastlake can respond.
>>     * Christian Geuer-Pollmann
>>         1. I want it fixed that 168 bit keys are transported in 192 bit
>>            form, that's all.
>>            Defer to Eastlake.
>>     * Blake Dournaee
>>         1. <AgreementMethod> question. "it doesn't look like XML
>>            Encryption actually specifies the logistics to perform the
>>            key agreement without also specifying actual encrypted data,
>>            which is impossible because the shared key hasn't been
>>            generated "
>>            Defer to Eastlake.
>>
>>  Resolved
>>
>>     * Blake Dournaee:
>>         1. Is the Nonce attribute of type intenger?
>>            Reagle: Yes.
>>     * Christian Geuer-Pollmann:
>>         1. Encrypting IV in ECB
>>            Eatlake/Dillaway: Use a nonce.
>>
>>Misc.
>>
>>     * Reagle: just to repeat, if you know folks from related communities
>>       that should review our specification, please do a little arm
>>       twisting.
>>     * Simon: The MS Web Services Security Language (WS-Security) Draft
>>       combines xmldsig, xenc, and web protocols/services and is perhaps
>>       a good source of issues for how these things will work together.
>>
>>
>>
>>
>
>-----------------------------------------------------------------------------------------------
>Ed Simon
>XMLsec Inc.
>
>Interested in XML Security Training and Consulting services?  Visit "www.xmlsec.com".
>
>
>

-----------------------------------------------------------------------------------------------
Ed Simon
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit "www.xmlsec.com".
Received on Friday, 30 November 2001 15:59:14 GMT

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