[1]W3C [2]XML Encryption WG
[1] http://www.w3.org/
[2] http://www.w3.org/tmp/Overview.html
2001-September-10
Chair: Joseph Reagle
Note Taker: Joseph Reagle [[3]text]
[3] http://www.w3.org/010910-tele.html,text
Participants
* Joseph Reagle, W3C
* (regrets) Blair Dillaway, Microsoft
* Katherine Betz, IBM
* Donald Eastlake 3rd, Motorola
* Ed Simon, XMLsec
* Frederick Hirsch, Zolera
* Amir Herzberg, NewGenPay
* Merlin Hughes, Baltimore
News
Status of documents
* We'd like to go to last call, need to finish up a few of
these issues.
Reviewing [4]Previous Items
[4] http://www.w3.org/010820-tele.html
From [5]previous minutes minutes.
1. [DEL: Reagle[DEL: : make it a declaration within CipherData
using Eastlake's nonce proposal text where necessary. :DEL]
:DEL]
2. [DEL: Dillaway[DEL: : tweak section 4.0 to represnt his
understanding/proposal of recent discussions. :DEL] :DEL]
3. Schaad: on DigestMethod/DigestValue send proposal for
integrity to list within the week with the necessary
changes. Action Eastlake: given Schaad's absence, send an
email with this proposal.
4. Eastlake: add real life examples in section 5.5 to
illustrate.
[5] http://www.w3.org/010820-tele.html
Requirements
...
Draft
* [6]XML Encryption Processing Model: Are we satisfied with
the present text; does it have the right balance between
specific detail for encoding and implementation
abstraction? We're using an octet processing model, but
don't want to preclude the encryption application from
being able to return an infoset or node list when
processing data of type Element or ElementContent.
Reagle: (off-line Dillaway said he was ok with the present
text.)
Simon: Reasonably happy, I'd still like to see some
implementation feedback on processing Element/Content using
DOM approach.
Hughes: Yes, generally happy. Action Hughes: Will
investigate and send an email on Xerces implementation
using XNI, or DOM when processing Element or Element
Content.
http://lists.w3.org/Archives/Public/xml-encryption/2001Aug/0031.html
* [7]Plaintext Integrity (Redux)
Eastlake: Amir, why do you want the HashValue to not be
encrypted?
Herzberg: Ensure integrity of the encrypted information.
When you have a single signature over encrypted data, how
do you prove what you signed is the real decrypted version.
In particular, consider a one time pad being used to
encrypt a plaintext paragraph in a given key.. It's also
digested (and encrypted) using Schaad's proposal. I then
sign the whole document (including the encrypted form of
the paragraph). Later, I want to reveal and prove the
signature over that single plaintext paragraph. Given the
one time pad, someone can find a different paragraph with a
different key that will yield the same CipherValue. The
signature over it is useless. If the digest itself is part
of that which is signed, this is no longer the case.
(Eastlake: Schaad's proposal is more of a checksum for
accidental alterations, not strong authenticity.)
Reagle: But given what the XMLDSIG spec says with "see what
you sign" we shouldn't read a signature over encrypted text
as a commitment to the plaintext.
Herzberg: Yes, but sometimes this can be useful feature.
Reagle: Well then, why not sign, then encrypt the parts and
their signatures?
Herzberg: You might only want one signature.
Eastlake: Why do you want only one signature?
Herzberg: Efficiency.
Simon: You could do this in signature, you could digest the
entire plaintext version of the document, as well as the
particular parts (paragraphs), with References in
SignedInfo, that you want to encrypt so they can be
selectively processed.
Herzberg: Functionally, this is similar to what I've
proposed! The difference is that the DigestMethod/Value are
part of the SignedInfo. The problem is that XMLDSIG
requires all the References to validate, so if I'm only
trying to verify the authenticity of a single paragraph,
the signature breaks. I could move these into a manifest
but that's an optional part of XMLDSIG and gets more
complex.
Herzberg: The other nice feature is I can also create a
transform that removes the CipherValues but retains the
digests, so the encryptor could upgrade the key, and
strengthen the encryption, without invalidating the
Signature over the (transformed) document.
Additionally, Jim's proposal could mislead people as a way
to provide authenticity, given the one time pad example
(use a different key with a different plaintext). If the
hash is in the clear (you can use a nonce to address
concerns about that) then the question is do these digests
get included in the EncryptedData, or reside in a Signature
Manifest?
Merlin: given our two options are (1) a manifest with a
transform and signature; or (2) all these hashes and a
signature, the latter seems to have extra processing as
part of Encryption, I think it'd be easier to do within
Signature.
Action Reagle: I think I understand this issue much better
now, so will post a poll to the list.
http://lists.w3.org/Archives/Public/xml-encryption/2001Sep/0010.html
* [8]KeyAgreement (keyszie and (pseudo) random number
generation)
Action Eastlake: make the tweaks with respect to
KeyAgreement.
http://lists.w3.org/Archives/Public/xml-encryption/2001Aug/0062.html
* [9]Should we permit normal public key encryption and not
restrict them to key transport?
Action Eastlake: add a sentence saying the public key
algorithms can be used for more than just Key Transport
(encrypting actual data) though it is inefficient.
http://lists.w3.org/Archives/Public/xml-encryption/2001Sep/0000.html
* [10]Do we want a EncryptedProperties?
Eastlake: if it's an optional thing, doesn't seem terribly
complex.
Hirsch: I used an ds:Object in my proposal, don't mind
calling it EncryptionProperties.
Herzberg: Prefer to call it EncryptionProperties.
http://lists.w3.org/Archives/Public/xml-encryption/2001Aug/0032.html
* [11]Add text on the creation of nonce and integrity in the
processing rules.
Action Reagle: once we're stable on the nonce and
integrity, add the appropriate text.
[11] http://lists.w3.org/Archives/Public/xml-encryption/2001Sep/0002.html
Misc.
* Next call on September 17, 2001.