Subject: Re: Encryption and ERS
From: "TS Glassey" <[email-masked]>
To: "Aljosa Jerman Blazic" <[email-masked]>, <[email-masked]>
Date: Fri, 19 Oct 2007 12:41:28 -0700
List-Id: <ietf-ltans.imc.org>

Which is why its so important to keep a full chain of custody on all changes 
to the content. The amount of data being stored is irrelevant to the issue 
of this technology. A key Goal of LTANS should not be constrained by the 
size or amount of data stored but the integrity of the control process 
around the data.

That's one of the things I think is not addressed sufficiently to date.

Todd Glassey (as an Auditor).

----- Original Message ----- 
From: "Aljosa Jerman Blazic" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 19, 2007 7:01 AM
Subject: 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
> -------------------
> 

From: "TS Glassey" <[email-masked]>
To: "Aljosa Jerman Blazic" <[email-masked]>, <[email-masked]>
Subject: Re: Encryption and ERS
Date: Fri, 19 Oct 2007 09:59:50 -0700
Sender: [email-masked]

----- Original Message ----- 
From: "Aljosa Jerman Blazic" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 19, 2007 9:14 AM
Subject: RE: Encryption and ERS

>
> Hello
>
>> Hi,
>>
>> 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...
>
> AJB
>
>> Ulrich Pordesch
>>
>> -----Ursprüngliche Nachricht-----
>> Von: [email-masked]
>> [mailto:[email-masked]] Im Auftrag von Aljosa
>> Jerman Blazic
>> Gesendet: Freitag, 19. Oktober 2007 16:01
>> An: [email-masked]
>> 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
>> -------------------
>>
>>
>>
>>
> 

Content-class: urn:content-classes:message
Subject: RE: Encryption and ERS
Date: Fri, 19 Oct 2007 18:14:49 +0200
From: "Aljosa Jerman Blazic" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hello

> Hi,
> 
> 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...?

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

AJB

> Ulrich Pordesch
> 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Aljosa 
> Jerman Blazic
> Gesendet: Freitag, 19. Oktober 2007 16:01
> An: [email-masked]
> 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
> -------------------
> 
> 
> 
> 

From: "Ulrich Pordesch" <[email-masked]>
To: <[email-masked]>
Subject: AW: Encryption and ERS
Date: Fri, 19 Oct 2007 16:38:25 +0200
Sender: [email-masked]

Hi,

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

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

Ulrich Pordesch

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Aljosa Jerman Blazic
Gesendet: Freitag, 19. Oktober 2007 16:01
An: [email-masked]
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
-------------------

Content-class: urn:content-classes:message
Subject: Encryption and ERS
Date: Fri, 19 Oct 2007 16:01:24 +0200
From: "Aljosa Jerman Blazic" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ltans-dssc-01.txt 
Date: Tue, 16 Oct 2007 03:30:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF.

	Title           : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC)
	Author(s)       : T. Kunz, et al.
	Filename        : draft-ietf-ltans-dssc-01.txt
	Pages           : 34
	Date            : 2007-10-16

In many application areas it must be possible to prove the existence
and integrity of digital signed data.  This proof depends on the
security suitability of the used cryptographic algorithms.  Because
algorithms can become weak over the years, it is necessary to
periodically evaluate these security suitabilities.  When signing or
verifying data, these evaluations must be considered.  This document
specifies a data structure for security suitabilities of
cryptographic algorithms which may be automatically
interpreted.Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-ltans-dssc-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-dssc-01.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ltans-dssc-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ltans-dssc-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-10-16032024.I-D\@ietf.org>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
From: IETF I-D Submission Tool <[email-masked]>
Subject: New Version Notification for draft-ietf-ltans-dssc-01 
Date: Tue, 16 Oct 2007 03:20:27 -0400
Sender: [email-masked]

A new version of I-D, draft-ietf-ltans-dssc-01.txt has been successfuly submitted by Thomas Kunz and posted to the IETF repository.

Filename:	 draft-ietf-ltans-dssc
Revision:	 01
Title:		 Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC)
Creation_date:	 2007-10-15
WG ID:		 ltans
Number_of_pages: 34

Abstract:
In many application areas it must be possible to prove the existence
and integrity of digital signed data.  This proof depends on the
security suitability of the used cryptographic algorithms.  Because
algorithms can become weak over the years, it is necessary to
periodically evaluate these security suitabilities.  When signing or
verifying data, these evaluations must be considered.  This document
specifies a data structure for security suitabilities of
cryptographic algorithms which may be automatically interpreted.Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

The IETF Secretariat.