- From: Joseph Reagle <reagle@w3.org>
- Date: Tue, 4 Sep 2001 09:24:01 -0400
- To: Amir Herzberg <AMIR@newgenpay.com>, "Xml Encrypt (E-mail)" <xml-encryption@w3.org>
On Monday 03 September 2001 02:33, Amir Herzberg wrote: > Suggested new text: > > The optional set of ds:DigestMethod and ds:DigestValue elements are > provided for ensuring the integrity of the encrypted data, by providing a > digest (hash) computed over the data to be encrypted (plaintext). See > section 5.7 of the algorithm specification for more information. Ok, in new revision: 1.43; I should of done this from these minutes (also note we didn't quite understand that PlainData proposal. [ http://www.w3.org/Encryption/2001/Minutes/010625-tele.html PlainData Eastlake: I think he's trying to make it easier to denote what should be encrypted -- and make it clear that the DigestMethod and DigestValue apply to the plaintext not the ciphertext. Reagle: I hope it's clear in the spec that DigestValue is over the plaintext. Otherwise this seems like an application issue to me (how it internally designates which sections to process)? I asked him to explain it a bit more on the list, so we'll roll this forward. ] > I think it'll also be good to add description of the relevant processing to > section 4, I can suggest some text. Once Don sends text for reverting back to not using DigestMethod/DigestValue in the clear (I hope you saw Schaad's arguments [1]), I agree we should add some text about nonce, and digest processing. [1] http://www.w3.org/Encryption/2001/Minutes/0720-Redwood/minutes.html Proposal: DigestMethod/DigestValue Removal, Jim Schaad Schaad: believes Herzberg wanted integrity, and something about the plaintext as it was before encryption. For the same reasons that Finney raised earlier about signature over plaintext, Schaad doesn't like plaintext being in the clear, should be encrypted as part of the CipherData; otherwise it allows for guessing of the original text if insufficient randomness exists. Group: discussion of earlier approach of having integrity be part of the algorithm URI, people felt this led to too many algorithms identifiers. Present approach not liked for reasons stated. Reagle: a poll was taken for Jim?s proposal: 5 supported Jim?s proposal and 2 supported the current status. Eastlake suggested the proposal to be further discussion in the list. Schaad: Proposed this as an optional element: If one wants integrity checks, then provide a new URI. Action Schaad: send proposal for integrity to list within the week with the necessary changes. Otherwise, need a use case (Herzberg engage Schaad in discussion) of the initial problem was, so we can understand the application where it applies (understanding now that it was wanted to have the digest value outside)
Received on Tuesday, 4 September 2001 09:24:04 UTC