XML Encryption WG
XML Encryption WGFrom previous minutes minutes.
...
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.
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.
Action Eastlake: make the tweaks with respect to KeyAgreement.
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.
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.
Action Reagle: once we're stable on the nonce and integrity, add the appropriate text.