----- Original Message ----- From: "Aljosa Jerman Blazic" <aljosa@xxxxxxxxx>
To: <ietf-ltans@xxxxxxx> Sent: Friday, October 19, 2007 9:14 AM Subject: RE: Encryption and ERS
HelloHi, as it is said in the paragraph before: "Only encryption methods should be used that make it possible to prove that archive-timestamped encrypted data objects unambiguously represent unencrypted data objects. All data necessary to prove unambiguous representation should be included in the archived data objects."Indeed, but the next paragraph states: "...additional data necessary to re-encrypt data objects should be inserted into the evidence record by the client..." meaning that data is inserted in an evidence record by a client after it is created. Or am I missing something...?
The problem is in editing the data object to create a derivative of the original IP and representing that this is the original IP. Its not... its IP that was reencapsulated or chaned cryptographically inside of an LTANS carrier. What needs to happen is restamped images need to be 'and'ed into the envelope as an additional instance of the document. That is to say there are both legal and business reasons for maintaining the document's signature status, and to do that a chain of custody as to the changes that it underwent also have to be included with the newly updated evedntiary content envelope IMHO.
Note, that this implies a 1:n - Function (1 unencrypted message may represented by n encrypted messages) not a 1:1 - Function. In practice some encryption functions - e.g. used in CMS - use additional start parameters (random numbers) - in order to avoid some kind of attacks knowing plaintexts.I am aware of the additional parameters, however 1 encrypted message may result in n unencrypted messages when different cryptographic material is used. And this is where I see the problem as there is no hard proof that 1:1 transformation is provided for ERS checking. If a client is in control of such information (crypto material) then there is hard to set a proper level of trust as the (encrypted) data submitted for ERS generation may actually originate from n different data sets... In theory at least.Therfore these additional Parameters may be necessary to reconstruct the (archive-)timestamped encrypted message, if it was deleted. Nethertheless, there is no security problem, if these parameters are not time-stamped - because of the requirement, that the encrypted message should unambiguous represent the clear-text message.Hmmm, I understood that by inserting some of the information into the ERS this "unambiguousity" is achieved...AJBUlrich Pordesch -----Ursprüngliche Nachricht----- Von: owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx] Im Auftrag von Aljosa Jerman Blazic Gesendet: Freitag, 19. Oktober 2007 16:01 An: ietf-ltans@xxxxxxx Betreff: Encryption and ERS Hi I am working on the next version of XMLERS and by studying the last ERS spec (RFC actually), I stumbled over encryption part: "When a relying party uses an evidence record to prove the existence of encrypted data objects, it may be desirable for clients to only store the unencrypted data objects and to delete the encrypted copy. In order to use the evidence record, it must then be possible to unambiguously re-encrypt the unencrypted data to get exactly the data that was originally archived. Therefore, additional data necessary to re-encrypt data objects should be inserted into the evidence record by the client, i.e., the LTA never sees these values." This approach foresees the inclusion of, correct me if I am wrong, data necessary to re-encrypt data by a client to validate ERS generated. Now the question here is, how can such information be trusted from a client? It somehow breaks the point of ERS. It is true that LTA never sees such data but this, IMO, does not affect the confidentiality issues and it even does not make sense, as the crypto material used for encryption is usually public... Or? Also, there is a typo on page 19: instead of "ha(1), ha(2), ha(3) are as defined in step 4 above" it should be "ha(1), ha(2), ha(3) are as defined in step 3 above" A. ------------------- SETCCE Jamova 39 SI-1000 Ljubljana Europe tel: +386 1 4773505 fax: +386 1 4773911 www.setcce.si -------------------