W3C home > Mailing lists > Public > xml-encryption@w3.org > February 2001

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

From: Paul Lambert <Paul.Lambert@cosinecom.com>
Date: Fri, 23 Feb 2001 19:11:09 -0800
Message-ID: <5E686636124A2042B4E5EE1F15191F27165A19@exchsrv3>
To: "'Joseph M. Reagle Jr.'" <reagle@w3.org>
Cc: XML Encryption WG <xml-encryption@w3.org>

> ... does this support the inter-EncryptedData chaining ... ?

The "inter-EncryptedData chaining" is a proposal for a mechanism and not a
requirement.  This mechanism is of no value unless there are requirements
for checking the integrity of encrypted data. 

 # 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.


Integrity is a critical service.  There are a variety of attacks possible if
the veracity of decrypted information is not validated.  This validity check
should be mandatory.

Digital signatures provide integrity and could be used within an
EncryptedData element. This is overkill.  All that is needed is a more
simple mechanism (checksum, MAC or know value) to reliably indicate that the
decryption process was successful.


  # On the Chaining of Encryption

The chaining mechanism in the current specification attempts to provide
"inter-EncryptedData integrity".  If this was a requirement it might be
stated as:

y. The specification may provide means to validate that a sequence of
EncryptedData blocks have not been modified.  Such changes might include
omitting EncryptedData blocks or changing the position of a EncryptedData
block in a sequence.


The chaining process implies that individual EncryptedData elements could
not be checked for validity until the complete sequence had been processed.
So, both integrity checks and padding would have to be added to every
chained EncryptedData.

"Chaining" ... is typically implemented as three different types of
operations: first_block, continue and final_block.  A parameter could be
used to indicate these states of the overall chained set of transformations.

Chaining adds complexity.  It saves the length of the IV for some
EncrypteData blocks and provides "inter-EncryptedData sequence integrity".
This is a quirky security service ... forcing the encrypted blocks to remain
in sequence, but allowing interspersed unencrypted XML to be modified. 

A more reasonable way to ensure the integrity of a sequence of encrypted
blocks would be to use a separate integrity or authentication syntax.  This
already seems to have been eliminated as a requirement by this work group.  



Summary:

 - Please add "x" above as a requirement for XML encryption.
 - "inter-EncryptedData chaining" is a dubious feature should be removed.
 - An integrity mechanism should be included in the definition 
   of any mandatory-to-implement encryption algorithms.





Integrity checking is one of those practical engineering issues that always
seem to get left out of the base descriptions of cryptographic transforms.  

-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Friday, February 23, 2001 3:06 PM
To: Paul Lambert
Cc: XML Encryption WG
Subject: RE: HW Support and XML Encryption Requirements



>At 12:50 2/22/2001 -0800, Paul Lambert wrote:
>One approach might be to better define the complete algorithm as the 
>complete suite of processing.  For example:
>
>   <xenc:EncryptionMethod 
> xenc:Algorithm="urn:nist-gov:tripledes-ede-cbc-IV-pad">

However, while I agree, does this support the inter-EncryptedData chaining 
described in section 4.5 of [prop3]? (I don't see 4.5 as that compelling a 
use case regardless so perhaps someone could speak to that?)


[prop3] 
http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEn
cryption_v01.html#_Toc501424257
5.4 Chaining between EncryptedData Elements
In this example, we show how chaining between two EncryptedData cipher 
texts. The EncryptedData "ED1" can be decrypted using the explicit IV and 
referenced symmetric key. EncryptedData "ED2" can be decrypted by using the 
output from decrypting ED1 as the input IV to "ED2".




__
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/
Received on Friday, 23 February 2001 22:11:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:18 GMT