RE: Integrity Checking Requirement was -> RE: HW Support and XML Enc ryption Requirements

>Could you speak to the points they raised? 
>...
>Philip Hallam-Baker [2] and Jim Schaad [3] opposed this requirement:

	"Given the history I think that authentication and encryption 
	in one operation needs to be considered as a separate algorithm 
	rather than supporting mix 'n match schemes. Most authentication 
	with encryption schemes will fail with RC4 and similarly constructed

	ciphers." {List: Hallam-Baker} 


< Jim Schaad:
>An additional reason that this should be part of the algorithm is that the
>hecksum should not appear in the clear.  

I don't see strong opposition ... but there is confusion in the discussion
on the differences between integrity checking, authentication and MACs.  

Integrity check mechanisms are required to validate the success of the
decryption process.  Without an integrity check, the random data (from
decryption with the wrong key) would processed and would occasionally be
parsed as "correct" data.

The integrity check must be contained within the encryption transform.  The
required strength of the integrity check depends on the encryption
algorithm.  SHA-1, HMACs and MACs are likely overkill for this mechanism
since we should be using "strong" encryption algorithms.   With a algorithm
like AES-cbc, all that should be required is a simple checksum or perhaps
even a known data field of sufficient length.  Even a known XML
encapsulation might suffice ... 

A message authentication code (MAC) is a keyed hash typically implemented
with an encryption algorithm.  The MAC is usually used when the data can not
be encrypted, but strong integrity checks are required.  MAC based
authentication is based on knowledge of the originators key that has been
used to create the MAC.  If the MAC is correct, only a peer with access to
the MACs key could have send the information.

The requirement for a MAC transform is a completely different debate from
the need to support integrity checking of the decryption process.  I see no
benefits of this mechanism that could not be provided by a digital
signature.

Paul

PS - I was on vacation this week so this note may be a little out of phase
fro the discussion.


-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Monday, February 26, 2001 7:12 AM
To: Mike Wray; Paul Lambert
Cc: xml-encryption@w3.org; jimsch5@home.com; pbaker@verisign.com
Subject: Re: Integrity Checking Requirement was -> RE: HW Support and
XML Enc ryption Requirements


At 09:31 2/26/2001 -0500, Mike Wray wrote:
> > # On Integrity Checking
> >
> >I propose that "integrity" requirements be added:
> >
> >x. The specification must provide mechanisms to check the integrity of
> >decrypted data.  Mandatory to implement algorithms should include
integrity
> >check mechanisms.

Well, we its now clear we need a requirement one way or the other as this 
has come up in the past, most recently on January 8th [1]. Philip 
Hallam-Baker [2] and Jim Schaad [3] opposed this requirement for the reasons

in the referenced thread. Could you speak to the points they raised? This 
issue is not captured in the requirements document [4].


[1] http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0011.html
[2] http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0014.html
[3] http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0059.html
[4] http://www.w3.org/Encryption/2001/01/23-xml-encryption-req#req-integrity


__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/