- From: <edsimon@xmlsec.com>
- Date: Fri, 30 Nov 2001 15:49:02 -0500
- To: xml-encryption@w3.org
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".
Received on Friday, 30 November 2001 15:49:04 UTC