Subject: RE: LTANS: Examples of ERS data - cross checking of implementations
From: "A. Jerman Blazic" <[email-masked]>
To: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Date: Wed, 21 Dec 2005 17:19:13 +0100
List-Id: <ietf-ltans.imc.org>

Tobias

SETCCE has done the implementation of LTAP as well as (its own XML
interpretation of) ERS. Interoperability testing is however desirable, but I
wonder whether ERS will be limited to ASN.1 syntax only. The LTAP includes
both.

Best regards

Aleksej

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tobias Gondrom
> Sent: 16. december 2005 18:26
> To: [email-masked]
> Subject: LTANS: Examples of ERS data - cross checking of 
> implementations
> Importance: Low
> 
> Hello,
> 
>  
> 
> I learned that two companies (IXOS and Fraunhofer) currently 
> make cross tests of their implementations of the ERS Draft. 
> Attached you find an example of an ERS produced, along with 
> the file which it is protecting. If you are implementing ERS 
> at the moment, too, you are invited to contact them via this 
> mailing-list (or I will happily relay the contact for you), 
> maybe we find a third or forth one who implemented ERS and 
> wants to share and cross check her implementation.
> 
>  
> 
> Best regards,
> 
>  
> 
> Tobias
> 
>  
> 
>  
> 
>  
> 
> __________________________________________
> Tobias Gondrom
> Senior Security Architect
> Head of Open Text Security Team
> 
> Open Text Corporation
> Technopark 2
> Werner-von-Siemens-Ring 20
> D-85630 Grasbrunn
> Phone:  +49 (0) 89 4629-1816
> Telefax:        +49 (0) 89 4629-33-1816
> eMail:  mailto:[email-masked]
> Internet:      http://www.opentext.com/
> 
> This eMail may contain confidential and/or privileged 
> information. If you are not the intended recipient or have 
> received this eMail in error, please notify the sender 
> immediately and destroy this eMail. Any use, disclosure or 
> distribution of the material in this eMail is strictly forbidden.
> 
> Diese eMail enthält vertrauliche und/oder rechtlich 
> geschützte Informationen. Wenn Sie nicht der richtige 
> Adressat sind oder diese eMail irrtümlich erhalten haben, 
> informieren Sie bitte sofort den Absender und vernichten Sie 
> diese eMail. Jegliche Art der Verwendung, Vervielfältigung 
> oder Weitergabe ist nicht gestattet.
> 
>  
> 
> 

To: [email-masked]
From: [email-masked]
Date: Fri, 16 Dec 2005 15:50:01 -0500
Cc: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-notareqs-03.txt
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		: Requirements for Data Validation and Certification  Services
	Author(s)	: T. Gondrom, et al.
	Filename	: draft-ietf-ltans-notareqs-03.txt
	Pages		: 12
	Date		: 2005-12-16
	
This document establishes the goals and requirements for protocols
   and data structures for use with services that provide additional
   means for users to ensure and prove the validity of data, especially
   digitally signed data, in a common and reproducible way.  The data
   being validated may correspond to assertions about real-world facts
   or events.  This document establishes the need for components to be
   used in addition to or in conjunction with long-term archive
   services.  It provides some use cases and scenarios, and establishes
   technical requirements for protocols and data structures to support
   them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-03.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-notareqs-03.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-notareqs-03.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-notareqs-03.txt

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

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Date: Fri, 16 Dec 2005 14:18:37 -0800
From: "Carl Wallace" <[email-masked]>
To: "Young H. Etheridge" <[email-masked]>
Cc: "Tobias Gondrom" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> > Yes but the structures and/or processes defined here should 
> support such. 
> >
> >   
> On closer examination of all four (4) TimeStamp methods produced in 
> X9.95 it seems that most of the necessary TimeStamp artifacts are 
> encodable options, particularly, in the CMS ASN.1 encoding.   In 
> particular, the applicable cert validation paths and CRLs for 
> digitally 
> signed TimeStamps are optional encodings.  There are CMS software 
> development APIs, e.g., BouncyCastle's Java-based crypto API, 
> that allow 
> a developer to simply exercise these options.  This seems to provide 
> additional credence to my request to give X9.95 an equal footing with 
> RFC-3161 in the LTANS ERS I-D.

Of course, CMS supports cert bags and CRL bags.  These certainly could
be used.  Are they?  How are they incorporated into the generation and
validation operations?  For example, when the timestamp is refreshed the
validation material would already need to be incorporated into the
timestamp.  These details should be in the document.  Are there issues
related to supporting users in multiple PKI communities who may validate
the timestamp signature, and thus impact what should be included in the
timestamp's cert and CRL bags?  Where are the trust anchors obtained to
verify the old timestamps?  In Paris, much seemed to be made about
policies.  Do those need to be in this document?  These seem like issues
that should be addressed to me.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-notareqs-03.txt 
Date: Fri, 16 Dec 2005 15:50:01 -0500
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		: Requirements for Data Validation and Certification  Services
	Author(s)	: T. Gondrom, et al.
	Filename	: draft-ietf-ltans-notareqs-03.txt
	Pages		: 12
	Date		: 2005-12-16
	
This document establishes the goals and requirements for protocols
   and data structures for use with services that provide additional
   means for users to ensure and prove the validity of data, especially
   digitally signed data, in a common and reproducible way.  The data
   being validated may correspond to assertions about real-world facts
   or events.  This document establishes the need for components to be
   used in addition to or in conjunction with long-term archive
   services.  It provides some use cases and scenarios, and establishes
   technical requirements for protocols and data structures to support
   them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-03.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-notareqs-03.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-notareqs-03.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-notareqs-03.txt

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

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

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: LTANS: Examples of ERS data - cross checking of implementations
Date: Fri, 16 Dec 2005 18:25:57 +0100
Importance: low
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C60265.BFF33ACD
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C60265.BFF33ACD"

------_=_NextPart_002_01C60265.BFF33ACD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

=20

I learned that two companies (IXOS and Fraunhofer) currently make cross =
tests of their implementations of the ERS Draft. Attached you find an =
example of an ERS produced, along with the file which it is protecting. =
If you are implementing ERS at the moment, too, you are invited to =
contact them via this mailing-list (or I will happily relay the contact =
for you), maybe we find a third or forth one who implemented ERS and =
wants to share and cross check her implementation.

=20

Best regards,

=20

Tobias

=20

=20

=20

__________________________________________
Tobias Gondrom
Senior Security Architect
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:[email-masked]
Internet:      http://www.opentext.com/

This eMail may contain confidential and/or privileged information. If =
you are not the intended recipient or have received this eMail in error, =
please notify the sender immediately and destroy this eMail. Any use, =
disclosure or distribution of the material in this eMail is strictly =
forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte =
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den =
Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.

=20

------_=_NextPart_002_01C60265.BFF33ACD
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I learned that two companies (IXOS and Fraunhofer) =
currently
make cross tests of their implementations of the ERS Draft. Attached you =
find
an example of an ERS produced, along with the file which it is =
protecting. If
you are implementing ERS at the moment, too, you are invited to contact =
them
via this mailing-list (or I will happily relay the contact for you), =
maybe we
find a third or forth one who implemented ERS and wants to share and =
cross
check her implementation.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Tobias<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>__________________________________________</span></font=
></b><font
face=3DArial><span style=3D'font-family:Arial'><br>
</span></font><b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black;font-weight:bold'>Tobias =
Gondrom</span></font></b><br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Senior Security Architect<br>
Head of Open Text Security Team<br>
</span></font><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Open Text =
Corporation</span></font></b><br>
<font color=3Dblack><span style=3D'color:black'>Technopark 2<br>
Werner-von-Siemens-Ring 20<br>
D-85630 Grasbrunn</span></font><br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Phone:&nbsp; +49 (0) 89 4629-1816<br>
Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0) 89 =
4629-33-1816<br>
eMail:&nbsp;</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</a><br>
<font color=3Dblack><span =
style=3D'color:black'>Internet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span=
></font><a
href=3D"http://www.opentext.com/">http://www.opentext.com/</a></span></fo=
nt><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>This eMail may contain confidential =
and/or
privileged information. If you are not the intended recipient or have =
received
this eMail in error, please notify the sender immediately and destroy =
this
eMail. Any use, disclosure or distribution of the material in this eMail =
is
strictly forbidden.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span lang=3DDE =
style=3D'font-size:10.0pt;font-family:
Arial'>Diese eMail enth=E4lt vertrauliche und/oder rechtlich =
gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder
Weitergabe ist nicht gestattet.</span></font><span =
lang=3DDE><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DDE
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_002_01C60265.BFF33ACD--

------_=_NextPart_001_01C60265.BFF33ACD
Content-Type: image/jpeg;
	name="flight-doc.jpg"
Content-Transfer-Encoding: base64
Content-Description: flight-doc.jpg
Content-Disposition: attachment;
	filename="flight-doc.jpg"

------_=_NextPart_001_01C60265.BFF33ACD
Content-Type: application/octet-stream;
	name="flight-ats.der"
Content-Transfer-Encoding: base64
Content-Description: flight-ats.der
Content-Disposition: attachment;
	filename="flight-ats.der"

------_=_NextPart_001_01C60265.BFF33ACD--

Content-class: urn:content-classes:message
Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Date: Fri, 16 Dec 2005 18:18:52 +0100
From: "Tobias Gondrom" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, "Young H. Etheridge" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Three comments:

A) At first I think we will not be able to provide the _perfect_
solution capturing all problems with ERS - there might always be
problems with long-term validation. (and from my experience to go for
perfect lead to go for "no-go" ;-)  )

But Carl is right one has to think of the availability of the
verification data in the medium to far future: any technical authority
can only guarantee the availability of additional verification data for
a limited time (the TSA might be shut down, might face an accident, or
other). At the moment facing the problem of necessary verification data
I see two approaches (complementing each other):
1. it is possible to add all necessary verification data into the
timestamps we use in ERS. We already do this in both implementations I
know first hand. 
(At the time you receive the timestamp from a TSA, you also verify it
and for the verification get all necessary data (i.e. all certificates
up to the root, and optionally an OCSP or CRL. With certified TSAs you
most probably will not need a OCSP as the press would usually cover any
compromising of the private key of a TSA - but of course this may differ
from country to country.)
2. the availability of long term validation data can be provided along
with the ERS by the SCVP/ERS approach. 

#1 is solving most of the problems of long term verification and #2
could flexibly bridge gaps. 

B) more general: I believe the following paradigm to be a good approach:
All for the verification necessary information should be allocated as
close as possible to the objects to be verified (in case of RFC3161 TS
this is _within_ the TS structure, in case of CMS this is _within_ the
CMS structure). This is already possible with the currently available
specifications. 
If this is not possible due to time constraints, or limited availability
of verification data (maybe some of the verification data are only
getting available after several days after archiving, the approach via
SCVP should be used to handle this data, but it should not lead to
_additional_ general  fields ("buckets") in ERS to hold any possibly
necessary data. 

C) How do others think about the proposed text from Young for the ERS
draft? 

Best regards, 

Tobias

> -----Original Message-----
> From: Carl Wallace [mailto:[email-masked]]
> Sent: Thursday, December 15, 2005 10:25 PM
> To: 'Young H. Etheridge'
> Cc: Tobias Gondrom; [email-masked]
> Subject: RE: LTANS: ERS - question for consensus about the mentioning
of
> other TS Services (other than RFC3161) in the I-D
> 
> <snip>
> > To some extent isn't this being partially addressed
> > by providing for TimeStamp renewal?
> 
> I don't think so.  What's the value of renewed timestamps without the
> means
> to verify them?
> 
> > This seems to place the
> > burden on those who have a vested interest in the Evidence
> > Record as well as the viability of the Evidence Record to
> > perform good practices on Evidence Record Management.
> 
> Yes but the structures and/or processes defined here should support
such.

Date: Fri, 16 Dec 2005 10:10:00 -0500
From: "Young H. Etheridge" <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, [email-masked]
Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Sender: [email-masked]

Carl Wallace wrote:
> <snip>
>   
>> To some extent isn't this being partially addressed 
>> by providing for TimeStamp renewal?  
>>     
>
> I don't think so.  What's the value of renewed timestamps without the means
> to verify them?
>
>   
>> This seems to place the 
>> burden on those who have a vested interest in the Evidence 
>> Record as well as the viability of the Evidence Record to 
>> perform good practices on Evidence Record Management.
>>     
>
> Yes but the structures and/or processes defined here should support such. 
>
>   
On closer examination of all four (4) TimeStamp methods produced in 
X9.95 it seems that most of the necessary TimeStamp artifacts are 
encodable options, particularly, in the CMS ASN.1 encoding.   In 
particular, the applicable cert validation paths and CRLs for digitally 
signed TimeStamps are optional encodings.  There are CMS software 
development APIs, e.g., BouncyCastle's Java-based crypto API, that allow 
a developer to simply exercise these options.  This seems to provide 
additional credence to my request to give X9.95 an equal footing with 
RFC-3161 in the LTANS ERS I-D.

Date: Thu, 15 Dec 2005 13:39:59 -0800
From: Arshad Noor <[email-masked]>
Subject: Sorry for the earlier e-mail to the wrong alias
To: [email-masked]
Organization: StrongAuth, Inc.
Sender: [email-masked]

From: "Carl Wallace" <[email-masked]>
To: "'Young H. Etheridge'" <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Date: Thu, 15 Dec 2005 16:25:19 -0500
Sender: [email-masked]

<snip>
> To some extent isn't this being partially addressed 
> by providing for TimeStamp renewal?  

I don't think so.  What's the value of renewed timestamps without the means
to verify them?

> This seems to place the 
> burden on those who have a vested interest in the Evidence 
> Record as well as the viability of the Evidence Record to 
> perform good practices on Evidence Record Management.

Yes but the structures and/or processes defined here should support such. 

Date: Thu, 15 Dec 2005 16:06:02 -0500
From: "Young H. Etheridge" <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, [email-masked]
Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Sender: [email-masked]

Carl Wallace wrote:.
.
.
.
>> Are these not problems for CMS consumers now?  Or, am I 
>> missing some other point?
>>     
>
> These are problems for CMS consumers now but the problem is magnified by
> time in our case.  CMS consumers performing signature verification and path
> validation now can obtain information for directories, OCSP responders, etc.
> When performing these operations on historical artifacts, the information is
> not readily available.  There's been very little discussion regarding how
> the verification of EvidenceRecords will be carried out, including how the
> artifacts necessary to verify the interior timestamps will be obtained.
> These concerns could result in changes to the ERS syntax.  How do existing
> implementations of ERS handle this?  There seems to be a significant gap at
> the moment and last call seems premature without a plan in place to support
> validating the structures.  
>
> As noted earlier, separating the preservation of verification artifacts from
> the archived data seems to be the right way to proceed.  This seems worthy
> of standardization to me.  I've been planning to submit an I-D similar to
> the ERS/SCVP draft that describes alternative directory attributes to hold
> historical certificates (and possibly ERS-protected certificates) and CRL
> techniques to support long-term archive.  
>
>   
I agree that your concerns are well-taken.  But to this point when such 
concerns arise the predominant attitude that I've noticed is the typical 
Ostrich reaction to frightening info - head in the sand or run.  What 
are your potential Evidence Record consumers saying?  Mine are shrugging 
and saying "yeah, that's a problem alright, but I'll be retired before 
that problem arises! " Handling, e.g., maintaining readers/editors, for 
historical e-archives has similar issues aside from time-honored 
integrity.  Theoretically this is being somewhat pursued in the 
OpenDocument format to the point that there will be but two formats for 
the future, Microsoft's and all other's.

Perhaps your I-D is the best means of addressing the concern while 
assuming the problem is not strictly a syntax concern?   Evidence Record 
without Evidence Record artifacts and archived data seems to be 
vacuous.  Just as good backup procedures necessarily promote testing the 
efficacy of the backup media, it seems that Evidence Record management 
should promote assurances of the availability and subsequent viability 
of the Evidence Record.  To some extent isn't this being partially 
addressed by providing for TimeStamp renewal?  This seems to place the 
burden on those who have a vested interest in the Evidence Record as 
well as the viability of the Evidence Record to perform good practices 
on Evidence Record Management.

From: "Carl Wallace" <[email-masked]>
To: "'Young H. Etheridge'" <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Date: Thu, 15 Dec 2005 14:51:26 -0500
Sender: [email-masked]

> > No.  The material needed to perform the validation must 
> come from somewhere.
> > That somewhere has not been defined.
> >
> >   
> Are you suggesting that the EncapulatedContentInfo with 
> Optional Content needs a URL/URI to the 
> DigestedData/SignedData/MACData/... and/or possibly a URL/URI 
> to at least one potential Verification subscriber service?  

No.  A verification service is not required.  

> Are these not problems for CMS consumers now?  Or, am I 
> missing some other point?

These are problems for CMS consumers now but the problem is magnified by
time in our case.  CMS consumers performing signature verification and path
validation now can obtain information for directories, OCSP responders, etc.
When performing these operations on historical artifacts, the information is
not readily available.  There's been very little discussion regarding how
the verification of EvidenceRecords will be carried out, including how the
artifacts necessary to verify the interior timestamps will be obtained.
These concerns could result in changes to the ERS syntax.  How do existing
implementations of ERS handle this?  There seems to be a significant gap at
the moment and last call seems premature without a plan in place to support
validating the structures.  

As noted earlier, separating the preservation of verification artifacts from
the archived data seems to be the right way to proceed.  This seems worthy
of standardization to me.  I've been planning to submit an I-D similar to
the ERS/SCVP draft that describes alternative directory attributes to hold
historical certificates (and possibly ERS-protected certificates) and CRL
techniques to support long-term archive.  

Date: Thu, 15 Dec 2005 14:08:34 -0500
From: "Young H. Etheridge" <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, [email-masked]
Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Sender: [email-masked]

Carl Wallace wrote:
>    
>   
>> Do you have ASN.1 code envisioned for this mechanism?
>>     
>
> Not at the moment but I can provide some.
>  
>   
>> Does the X9.95 TimeStampToken Verification protocol for each 
>> of the TSTs not address your concerns?
>>     
>
> No.  The material needed to perform the validation must come from somewhere.
> That somewhere has not been defined.
>
>   
Are you suggesting that the EncapulatedContentInfo with Optional Content 
needs a URL/URI to the DigestedData/SignedData/MACData/... and/or 
possibly a URL/URI to at least one potential Verification subscriber 
service?  Are these not problems for CMS consumers now?  Or, am I 
missing some other point?

From: "Carl Wallace" <[email-masked]>
To: "'Young H. Etheridge'" <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Date: Thu, 15 Dec 2005 13:15:03 -0500
Sender: [email-masked]

> Do you have ASN.1 code envisioned for this mechanism?

Not at the moment but I can provide some.
 
> Does the X9.95 TimeStampToken Verification protocol for each 
> of the TSTs not address your concerns?

No.  The material needed to perform the validation must come from somewhere.
That somewhere has not been defined.

Date: Thu, 15 Dec 2005 12:40:27 -0500
From: "Young H. Etheridge" <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, [email-masked]
Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Sender: [email-masked]

Carl Wallace wrote:
.
.
.
>
> I think we need to define a mechanism so each application does not need to
> invent a mechanism.  There's a general purpose "bucket" out the outermost
> layer of the EvidenceRecord but this does not seem ideal for collecting
> materials used to validate interior timestamps.  For CMS-based timestamps,
> we could use the certs bag or unsigned attributes.  Once we identify where
> to store the material, we need to identify how to preserve that material
> (since in many/most cases these items will also be signed).  This is where
> the ERS/SCVP draft fits in.  Instead of preserving validation materials with
> each archived data object, the materials can be preserved one time separate
> from the object and retrieved at validation time.
>
>   
Do you have ASN.1 code envisioned for this mechanism?

Does the X9.95 TimeStampToken Verification protocol for each of the TSTs 
not address your concerns?

.
.
.

From: "Carl Wallace" <[email-masked]>
To: "'Young H. Etheridge'" <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Date: Thu, 15 Dec 2005 06:31:31 -0500
Sender: [email-masked]

> > This does re-raise the question of how/where to convey information 
> > necessary to verify interior timestamps in an EvidenceRecord.
> If I understand your question correctly then a digitally 
> signed TimeStamp does not necessarily resolve the need 
> either, does it?  

No, the same problem exists for signature-based timestamps but the addition
of timestamp format may place additional requirements for a generic
solution.

> It seems that ERS is presently application 
> specific or an API could offer a driver to try all available 
> TSA - not exactly efficient and rather prone to error.  What 
> do you suggest as a resolution?

I think we need to define a mechanism so each application does not need to
invent a mechanism.  There's a general purpose "bucket" out the outermost
layer of the EvidenceRecord but this does not seem ideal for collecting
materials used to validate interior timestamps.  For CMS-based timestamps,
we could use the certs bag or unsigned attributes.  Once we identify where
to store the material, we need to identify how to preserve that material
(since in many/most cases these items will also be signed).  This is where
the ERS/SCVP draft fits in.  Instead of preserving validation materials with
each archived data object, the materials can be preserved one time separate
from the object and retrieved at validation time.

> >   It also raises the
> > possibility of different timestamps over a single EvidenceRecord.
> >   
> Agreed.  An opportunity for EvidenceRecord resilience.
> >
> >   
> 

Date: Wed, 14 Dec 2005 16:42:24 -0500
From: "Young H. Etheridge" <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, [email-masked]
Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Sender: [email-masked]

Carl Wallace wrote:
>>> Young suggested to also mention and name also some other timestamp 
>>> techniques, especially ISO ([I180141], [I180142], [I180143], and 
>>> [ANSX995] - References see below).
>>>
>>>       
>> My goal was to place ANSI X9.95, ISO 18014-1, and ISO 18014-3 
>> on a similar cryptographic level with RFC-3161, not emphasize 
>> any one over the other. My game is cryptographic resilience. 
>> Offer cryptographic choices for ERS TimeStamps as a step 
>> toward future proofing TimeStamps.
>>     
>
> This does re-raise the question of how/where to convey information necessary
> to verify interior timestamps in an EvidenceRecord.
If I understand your question correctly then a digitally signed 
TimeStamp does not necessarily resolve the need either, does it?  It 
seems that ERS is presently application specific or an API could offer a 
driver to try all available TSA - not exactly efficient and rather prone 
to error.  What do you suggest as a resolution?
>   It also raises the
> possibility of different timestamps over a single EvidenceRecord.
>   
Agreed.  An opportunity for EvidenceRecord resilience.
>
>   

From: "Carl Wallace" <[email-masked]>
To: "'Young H. Etheridge'" <[email-masked]>, "'Tobias Gondrom'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Date: Wed, 14 Dec 2005 16:19:20 -0500
Sender: [email-masked]

> > Young suggested to also mention and name also some other timestamp 
> > techniques, especially ISO ([I180141], [I180142], [I180143], and 
> > [ANSX995] - References see below).
> >
> My goal was to place ANSI X9.95, ISO 18014-1, and ISO 18014-3 
> on a similar cryptographic level with RFC-3161, not emphasize 
> any one over the other. My game is cryptographic resilience. 
> Offer cryptographic choices for ERS TimeStamps as a step 
> toward future proofing TimeStamps.

This does re-raise the question of how/where to convey information necessary
to verify interior timestamps in an EvidenceRecord.  It also raises the
possibility of different timestamps over a single EvidenceRecord.

Date: Wed, 14 Dec 2005 16:04:14 -0500
From: "Young H. Etheridge" <[email-masked]>
To: Tobias Gondrom <[email-masked]>
Cc: [email-masked]
Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Sender: [email-masked]

Please see response interspersed below:

Tobias Gondrom wrote:
>
> Hello,
>
> at the moment the role of other TS mechanisms (besides RFC3161) is not 
> fully agreed.
>
> In all past versions we specified that for ERS a TimeStamp should be 
> used and mentioned RFC3161 as one example, not naming any other ones 
> specifically.
>
> Young suggested to also mention and name also some other timestamp 
> techniques, especially ISO ([I180141], [I180142], [I180143], and 
> [ANSX995] – References see below).
>
My goal was to place ANSI X9.95, ISO 18014-1, and ISO 18014-3 on a 
similar cryptographic level with RFC-3161, not emphasize any one over 
the other. My game is cryptographic resilience. Offer cryptographic 
choices for ERS TimeStamps as a step toward future proofing TimeStamps.
>
> Which I did in a first and soft step in ERS-04, besides I asked Carl 
> to raise this topic at the last IETF meeting.
>
> Young asked me to prepare a slightly stronger wording about the use of 
> the timestamps other than RFC3161.
>
> So I ask for mailing-list opinion to find out about consensus how to 
> change the draft.
>
> Currently I see three options (but am open for additional ones coming 
> from the community):
>
> a) we stay with the 04-draft 
> (http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-04.txt)
>
My reason for suggesting the ANSI and ISO standards is that they offer 
implementers a number of choices for verifiable TimeStamp from an 
appropriate TSA, not all of which require PKI solutions. The -04 draft 
does mention the added standards, but still seems to unnecessarily 
require a PKI digital signature even if one of the ANSI or ISO standards 
is implemented. The ISO standards provide cryptological efficacy for a 
number of TimeStamp choices, including that offered in RFC3161. The ANSI 
standard rather definitively suggests cryptographic resilience for 
TimeStamp.
>
> b) we change the draft as proposed by Young slightly, more emphasizing 
> the use of ISO timestamps and in my opinion de-emphasizing the use of 
> others not mentioned in the draft
>
As already stated I intended that my proposal offer TimeStamp choices of 
similar cryptographic stature as specified by standards bodies in good 
standing by most enterprises, especially the financial community. 
Certainly my intent is to not emphasize one TimeStamp over another. It 
seems to me that the implementer and subsequent buyer who desires to be 
standards compliant should be able to choose that which best fits their 
business requirements.
>
> c) go back to the wording in ERS-03 by removing the names and 
> references to the ISO timestamp concepts.
>
This choice seems to squarely place ERS as a PKI-only solution. Many 
businesses depend on the standards bodies to aid them in specifying 
correct cryptographic choices. I believe that it not desirable or 
necessary for all business digital information evidence records to 
require PKI-based TimeStamps.
>
> The specific parts in question are:
>
> In Section 1.3. Terminology -- change --
>
> "Time-Stamp: A signed confirmation generated by a Time Stamping
>
> Authority (TSA) that a data item existed at a certain time.
>
> [RFC3161] specifies a good structure for time-stamps and a
>
> protocol for communicating with a Time-stamp Authority (TSA).
>
> Further good structures and protocols for communicating with a
>
> Time-stamp Authority (TSA) may also, but not exclusively, be
>
> [I180141], [I180142], [I180143], and [ANSX995]."
>
> -- to --
>
> "Time-Stamp: A signed confirmation generated by a Time Stamping
>
> Authority (TSA) that a data item existed at a certain time.
>
> [RFC3161] specifies an acceptable structure for time-stamps and a
>
> protocol for communicating with a Time-stamp Authority (TSA).
>
> Further acceptable structures and protocols for communicating with a
>
> Time-stamp Authority (TSA) may be those specified in
>
> [I180141], [I180143], or [ANSX995]."
>
> In Section 3.1 Syntax -- change --
>
> "timeStamp should contain the time-stamp as defined in section 1.3
>
> "Terminology". (e.g. as defined with timeStampToken in [RFC 3161]).
>
> Other types of time-stamp might be used, if they contain time data,
>
> time-stamped data and a signature from the TSA of these data."
>
> -- to --
>
> "timeStamp should contain the time-stamp as defined in section 1.3
>
> "Terminology". (e.g. as defined with timeStampToken in [RFC 3161],
>
> [ANSX995], [I180141], or [I180143])."
>
> *Open for votes, opinion, discussion!*
>
> Best regards, Tobias
>
Thanks, yhe.
>
> References:
>
> [ANSX995] American National Standard for Financial Services,
>
> "Trusted Timestamp Management and Security", ANSX X9.95-
>
> 2005, June 2005.
>
> [I180141] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1:
>
> Framework", ISO ISO-18014-1, February 2002.
>
> [I180142] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2:
>
> Mechanisms producing independent tokens", ISO ISO-18014-2,
>
> December 2002.
>
> [I180143] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3:
>
> Mechanisms producing linked tokens", ISO ISO-18014-3,
>
> February 2004.
>
> *__________________________________________*
> *Tobias Gondrom*
> Senior Security Architect
> Head of Open Text Security Team
>
> *Open Text Corporation*
> Technopark 2
> Werner-von-Siemens-Ring 20
> D-85630 Grasbrunn
> Phone: +49 (0) 89 4629-1816
> Telefax: +49 (0) 89 4629-33-1816
> eMail: mailto:[email-masked]
> Internet: http://www.opentext.com/
>
> This eMail may contain confidential and/or privileged information. If 
> you are not the intended recipient or have received this eMail in 
> error, please notify the sender immediately and destroy this eMail. 
> Any use, disclosure or distribution of the material in this eMail is 
> strictly forbidden.
>
> Diese eMail enthält vertrauliche und/oder rechtlich geschützte 
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese 
> eMail irrtümlich erhalten haben, informieren Sie bitte sofort den 
> Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, 
> Vervielfältigung oder Weitergabe ist nicht gestattet.
>

Content-class: urn:content-classes:message
Subject: RE: Change Request: draft-ietf-ltans-ers-04.txt
Date: Wed, 14 Dec 2005 18:53:08 +0100
From: "Tobias Gondrom" <[email-masked]>
To: "Young H. Etheridge" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Young, 

thank you, for raising this issue. 
(I sent the same request out just before I received yours; but assume it
will hit the list a few minutes later)

Actually I have no strong opinion on the wording, than that I think ERS
should stay open to other time-stamping technologies (not only limiting
itself to any set) as had this been through all our drafts. 

I would prefer to stick with the current text as I think that this
already gives other standards especially the ones named by you the right
emphasize and space. 

I could also live with the texts you propose except for one small
change:

Use "e.g." instead of "i.e." in the second section:
> "timeStamp must contain the verifiable time-stamp as defined in
>    section "1.3. Terminology", i.e., as defined with TimeStampToken in
>    [RFC 3161], [ANSX995], [I180141], or [I180143]."
(e.g. = "as an example", i.e. = "That is" might falsely suggest that we
tend to limit the draft to those four references.)

At the moment I don't feel that I have sufficient knowledge of the ISO
standards you mentioned that I would feel perfectly fine with stating
that they "specify an acceptable time-stamp structure". I know this for
sure for RFC3161, but am not sure about the ISO standards.

Other opinions please?

Regards, Tobias

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Young H. Etheridge
> Sent: Wednesday, December 14, 2005 6:27 PM
> To: [email-masked]
> Subject: Change Request: draft-ietf-ltans-ers-04.txt
> 
> 
> Regarding the recent posting of "draft-ietf-ltans-ers-04", it seems
> reasonable to me that the ERS validation spec should refer to an
> abstract timestamp validation algorithm with details provided by the
> specification associated with the type of timestamp employed by an
> implementer.  To that end, I suggest the following simple changes to
the
> draft:
> 
> In section "1.3.  Terminology" -- change --
> 
> -- from --
> 
>     "Time-Stamp: A signed confirmation generated by a Time Stamping
>      Authority (TSA) that a data item existed at a certain time.
>      [RFC3161] specifies a good structure for time-stamps and a
>      protocol for communicating with a Time-stamp Authority (TSA).
>      Further good structures and protocols for communicating with a
>      Time-stamp Authority (TSA) may also, but not exclusively, be
>      [I180141], [I180142], [I180143], and [ANSX995]."
> 
> -- to --
> 
>      "Time-Stamp: A verifiable confirmation generated by a Time
Stamping
>      Authority (TSA) that a data item existed at a certain time.
> [RFC3161],
>      [ANSX995], [I180141], or [I180143] specify an acceptable
time-stamp
>      structure  along with a protocol for communicating with a TSA."
> 
> and
> 
> In Section "3.1. Syntax" -- change --
> 
> -- from --
> 
>    "timeStamp should contain the time-stamp as defined in section 1.3
>    "Terminology". (e.g. as defined with timeStampToken in [RFC 3161]).
>    Other types of time-stamp might be used, if they contain time data,
>    time-stamped data and a signature from the TSA of these data."
> 
> -- to --
> 
>    "timeStamp must contain the verifiable time-stamp as defined in
>    section "1.3. Terminology", i.e., as defined with TimeStampToken in
>    [RFC 3161], [ANSX995], [I180141], or [I180143]."

Content-class: urn:content-classes:message
Subject: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D
Date: Wed, 14 Dec 2005 18:41:17 +0100
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C600D5.920E583D
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

=20

at the moment the role of other TS mechanisms (besides RFC3161) is not =
fully agreed.=20

=20

In all past versions we specified that for ERS a TimeStamp should be =
used and mentioned RFC3161 as one example, not naming any other ones =
specifically.=20

=20

Young suggested to also mention and name also some other timestamp =
techniques, especially ISO ([I180141], [I180142], [I180143], and =
[ANSX995] - References see below).

=20

Which I did in a first and soft step in ERS-04, besides I asked Carl to =
raise this topic at the last IETF meeting.=20

=20

Young asked me to prepare a slightly stronger wording about the use of =
the timestamps other than RFC3161.

So I ask for mailing-list opinion to find out about consensus how to =
change the draft.

Currently I see three options (but am open for additional ones coming =
from the community):

a)       we stay with the 04-draft =
(http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-04.txt)

b)       we change the draft as proposed by Young slightly, more =
emphasizing the use of ISO timestamps and in my opinion de-emphasizing =
the use of others not mentioned in the draft

c)       go back to the wording in ERS-03 by removing the names and =
references to the ISO timestamp concepts.

=20

=20

=20

The specific parts in question are:

=20

In Section 1.3.  Terminology -- change --

=20

"Time-Stamp: A signed confirmation generated by a Time Stamping

      Authority (TSA) that a data item existed at a certain time.

      [RFC3161] specifies a good structure for time-stamps and a

      protocol for communicating with a Time-stamp Authority (TSA).

      Further good structures and protocols for communicating with a

      Time-stamp Authority (TSA) may also, but not exclusively, be

      [I180141], [I180142], [I180143], and [ANSX995]."

=20

-- to --

=20

"Time-Stamp: A signed confirmation generated by a Time Stamping

      Authority (TSA) that a data item existed at a certain time.

      [RFC3161] specifies an acceptable structure for time-stamps and a

      protocol for communicating with a Time-stamp Authority (TSA).

      Further acceptable structures and protocols for communicating with =
a

      Time-stamp Authority (TSA) may be those specified in

      [I180141], [I180143], or [ANSX995]."

=20

=20

In Section 3.1 Syntax -- change --

=20

"timeStamp should contain the time-stamp as defined in section 1.3

   "Terminology". (e.g. as defined with timeStampToken in [RFC 3161]).

   Other types of time-stamp might be used, if they contain time data,

   time-stamped data and a signature from the TSA of these data."

=20

-- to --

=20

"timeStamp should contain the time-stamp as defined in section 1.3

   "Terminology". (e.g. as defined with timeStampToken in [RFC 3161],

  [ANSX995], [I180141], or [I180143])."

=20

=20

Open for votes, opinion, discussion!

=20

Best regards, Tobias

=20

=20

=20

=20

References:=20

   [ANSX995]  American National Standard for Financial Services,

              "Trusted Timestamp Management and Security", ANSX X9.95-

              2005, June 2005.

=20

   [I180141]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1:

              Framework", ISO ISO-18014-1, February 2002.

=20

   [I180142]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2:

              Mechanisms producing independent tokens", ISO ISO-18014-2,

              December 2002.

=20

   [I180143]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3:

              Mechanisms producing linked tokens", ISO ISO-18014-3,

              February 2004.

=20

=20

=20

=20

__________________________________________
Tobias Gondrom
Senior Security Architect
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:[email-masked]
Internet:      http://www.opentext.com/

This eMail may contain confidential and/or privileged information. If =
you are not the intended recipient or have received this eMail in error, =
please notify the sender immediately and destroy this eMail. Any use, =
disclosure or distribution of the material in this eMail is strictly =
forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte =
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den =
Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.

=20

------_=_NextPart_001_01C600D5.920E583D
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:357396569;
	mso-list-type:hybrid;
	mso-list-template-ids:-1791184436 67698711 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-number-format:alpha-lower;
	mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>at the moment the role of other TS mechanisms =
(besides RFC3161)
is not fully agreed. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In all past versions we specified that for ERS a =
TimeStamp
should be used and mentioned RFC3161 as one example, not naming any =
other ones
specifically. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Young suggested to also mention and name also some =
other timestamp
techniques, especially ISO ([I180141], [I180142], [I180143], and =
[ANSX995] &#8211;
References see below).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Which I did in a first and soft step in ERS-04, =
besides I
asked Carl to raise this topic at the last IETF meeting. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Young asked me to prepare a slightly stronger wording =
about
the use of the timestamps other than =
RFC3161.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>So I ask for mailing-list opinion to find out about
consensus how to change the draft.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Currently I see three options (but am open for =
additional
ones coming from the community):<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>a)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>we stay with
the 04-draft =
(http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-04.txt)<o:p></o=
:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>b)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>we change
the draft as proposed by Young slightly, more emphasizing the use of ISO
timestamps and in my opinion de-emphasizing the use of others not =
mentioned in
the draft<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>c)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>go back to
the wording in ERS-03 by removing the names and references to the ISO =
timestamp
concepts.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The specific parts in question =
are:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>In Section 1.3.=A0 =
Terminology
-- change --<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&quot;Time-Stamp: A =
signed
confirmation generated by a Time Stamping<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
Authority (TSA) that a
data item existed at a certain time.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
[RFC3161] specifies a
good structure for time-stamps and a<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
protocol for
communicating with a Time-stamp Authority =
(TSA).<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
Further good
structures and protocols for communicating with =
a<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
Time-stamp Authority
(TSA) may also, but not exclusively, be<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
[I180141], [I180142],
[I180143], and [ANSX995].&quot;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>-- to =
--<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&quot;Time-Stamp: A =
signed
confirmation generated by a Time Stamping<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
Authority (TSA) that a
data item existed at a certain time.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
[RFC3161] specifies an
acceptable structure for time-stamps and a<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
protocol for
communicating with a Time-stamp Authority =
(TSA).<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
Further acceptable
structures and protocols for communicating with =
a<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
Time-stamp Authority
(TSA) may be those specified in<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0=A0=A0=A0 =
[I180141], [I180143],
or [ANSX995].&quot;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>In Section 3.1 =
Syntax --
change --<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&quot;timeStamp =
should
contain the time-stamp as defined in section =
1.3<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0 =
&quot;Terminology&quot;.
(e.g. as defined with timeStampToken in [RFC =
3161]).<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0 Other types =
of time-stamp
might be used, if they contain time data,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0 time-stamped =
data and a
signature from the TSA of these data.&quot;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>-- to =
--<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&quot;timeStamp =
should
contain the time-stamp as defined in section =
1.3<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0=A0 =
&quot;Terminology&quot;.
(e.g. as defined with timeStampToken in [RFC =
3161],<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>=A0 [ANSX995], =
[I180141], or
[I180143]).&quot;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Open for votes, opinion, =
discussion!<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Best regards, Tobias<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>References: <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0 [ANSX995]=A0 American National Standard for =
Financial
Services,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 &quot;Trusted =
Timestamp Management and
Security&quot;, ANSX X9.95-<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2005, June =
2005.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0 [I180141]=A0 ISO/IEC JTC 1/SC 27, &quot;Time =
stamping
services - Part 1:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Framework&quot;, ISO ISO-18014-1, February
2002.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0 [I180142]=A0 ISO/IEC JTC 1/SC 27, &quot;Time =
stamping
services - Part 2:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Mechanisms =
producing independent tokens&quot;,
ISO ISO-18014-2,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 December =
2002.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0 [I180143]=A0 ISO/IEC JTC 1/SC 27, &quot;Time =
stamping
services - Part 3:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Mechanisms =
producing linked tokens&quot;, ISO
ISO-18014-3,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 February =
2004.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>__________________________________________</span></font=
></b><font
face=3DArial><span style=3D'font-family:Arial'><br>
</span></font><b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black;font-weight:bold'>Tobias =
Gondrom</span></font></b><br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Senior Security Architect<br>
Head of Open Text Security Team<br>
</span></font><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Open Text =
Corporation</span></font></b><br>
<font color=3Dblack><span style=3D'color:black'>Technopark 2<br>
Werner-von-Siemens-Ring 20<br>
D-85630 Grasbrunn</span></font><br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Phone:&nbsp; +49 (0) 89 4629-1816<br>
Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0) 89 =
4629-33-1816<br>
eMail:&nbsp;</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</a><br>
<font color=3Dblack><span =
style=3D'color:black'>Internet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span=
></font><a
href=3D"http://www.opentext.com/">http://www.opentext.com/</a></span></fo=
nt><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>This eMail may contain confidential =
and/or
privileged information. If you are not the intended recipient or have =
received
this eMail in error, please notify the sender immediately and destroy =
this
eMail. Any use, disclosure or distribution of the material in this eMail =
is
strictly forbidden.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span lang=3DDE =
style=3D'font-size:10.0pt;font-family:
Arial'>Diese eMail enth=E4lt vertrauliche und/oder rechtlich =
gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder
Weitergabe ist nicht gestattet.</span></font><span =
lang=3DDE><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DDE
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C600D5.920E583D--

Date: Wed, 14 Dec 2005 12:26:37 -0500
From: "Young H. Etheridge" <[email-masked]>
To: [email-masked]
Subject: Change Request: draft-ietf-ltans-ers-04.txt
Sender: [email-masked]

Regarding the recent posting of "draft-ietf-ltans-ers-04", it seems 
reasonable to me that the ERS validation spec should refer to an 
abstract timestamp validation algorithm with details provided by the 
specification associated with the type of timestamp employed by an 
implementer.  To that end, I suggest the following simple changes to the 
draft:

In section "1.3.  Terminology" -- change --

-- from --

    "Time-Stamp: A signed confirmation generated by a Time Stamping
     Authority (TSA) that a data item existed at a certain time.
     [RFC3161] specifies a good structure for time-stamps and a
     protocol for communicating with a Time-stamp Authority (TSA).
     Further good structures and protocols for communicating with a
     Time-stamp Authority (TSA) may also, but not exclusively, be
     [I180141], [I180142], [I180143], and [ANSX995]."

-- to --

     "Time-Stamp: A verifiable confirmation generated by a Time Stamping
     Authority (TSA) that a data item existed at a certain time.  [RFC3161],
     [ANSX995], [I180141], or [I180143] specify an acceptable time-stamp
     structure  along with a protocol for communicating with a TSA."

and

In Section "3.1. Syntax" -- change --

-- from --

   "timeStamp should contain the time-stamp as defined in section 1.3
   "Terminology". (e.g. as defined with timeStampToken in [RFC 3161]).
   Other types of time-stamp might be used, if they contain time data,
   time-stamped data and a signature from the TSA of these data."

-- to --

   "timeStamp must contain the verifiable time-stamp as defined in
   section "1.3. Terminology", i.e., as defined with TimeStampToken in
   [RFC 3161], [ANSX995], [I180141], or [I180143]."

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Certificate Validity Problem
Date: Fri, 9 Dec 2005 12:53:24 -0500
Sender: [email-masked]

The work being done in the IETF LTANS will also help.

Also, there is an I-D that is relevant to this effort.  The following is the
I-D URL.

http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-00.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Friday, December 09, 2005 11:04 AM
To: Stephen Kent; Ersin Gulacti
Cc: [email-masked]
Subject: Re: Certificate Validity Problem

The protocol accommodates the query, but the server need to keep the 
historical data to respond property.  As I see it, this historical 
data retention is optional.

Russ

At 11:59 AM 12/8/2005, Stephen Kent wrote:

>>Hello,
>>
>>We are operating a Certificate Authority (which uses our own CA software)
>>and we have a process to set certificate status to on-hold. Owners of
>>certificates can put their certificates on-hold and they can return them
>>to the valid status.
>>
>>When somebody tries to verify the validity of signature he can only check
>>the most recent status of the certificate. He can use the most fresh CRL
>>or execute an OCSP query. Both of these techniques lack an important
>>functionality, you cannot query the status of a certificate at a certain
>>time in the past. Maybe at the time of signing the certificate used was
>>on-hold.
>>
>>Is there a method or another technique to solve this problem?
>>
>>Thanks.
>
>SCVP should be able to accommodate queries about the status of a 
>cert at a previous point in time.
>
>Steve
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-ers-04.txt 
Date: Thu, 08 Dec 2005 15:50:01 -0500
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		: Evidence Record Syntax (ERS)
	Author(s)	: R. Brandner, et al.
	Filename	: draft-ietf-ltans-ers-04.txt
	Pages		: 25
	Date		: 2005-12-8
	
In many scenarios, users need to be able to ensure and prove the
   existence and integrity of data, especially digitally signed data, in
   a common and reproducible way over a long and possibly undetermined
   period of time.  This document specifies the syntax and processing of
   an Evidence Record, designed for long-term non-repudiation of
   existence of data, which particularly can be used for conservation of
   evidence of digitally signed data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-04.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-ers-04.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-ers-04.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-ers-04.txt

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

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

--OtherAccess--

--NextPart--

From: "Carl Wallace" <[email-masked]>
To: "'Tobias Gondrom'" <[email-masked]>, "'Hannes Weber'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: ERS and certificates
Date: Tue, 6 Dec 2005 06:58:18 -0500
Sender: [email-masked]

<snip>
> And before answering: in nearly all commercial applications 
> it can be expected that they are able to (and DO) retrieve 
> the verification data (certificate path and OCSP/CRL) at the 
> time of entry into the system and can add this information as 
> recommended by ISIS-MTT to the signed documents. 

Similarly, this could be done before applying a refreshed timestamp.  What's
the process for discovering the validation information used to verify a
timestamp chain?

> In case this is not the case, one has to find a solution as 
> you thought of.
> And your idea of simply extending the model of the 
> EvidenceRecord by simply adding the additional verification 
> data as an additional file represented by a hash value in the 
> normal hashtrees is the right approach. 

1) Should we define a standard means of associating validation information
with an EvidenceRecord to cover these cases instead of leaving it up to
folks to roll their own?
2) Is there anything else that should be associated with an EvidenceRecord
besides validation information?  I thought the consensus during the Paris
meeting was the crypto policy needed to be covered.  Perhaps ERS needs some
extensible fields a la attributes or extensions.

<snip>

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Cc: "'Young H. Etheridge'" <[email-masked]>, "'Carl Wallace'" <[email-masked]>
Subject: RE: ltans: ers-04
Date: Tue, 6 Dec 2005 00:06:01 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C5F9F8.D8668450
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

  _____ =20

From: Tobias Gondrom [mailto:[email-masked]]=20
Sent: Monday, December 05, 2005 11:51 AM
To: [email-masked]
Cc: Jim Schaad; Young H. Etheridge; Carl Wallace
Subject: ltans: ers-04

Jim, Young, Carl,

=20

Thanks for your thorough review.=20

I adopted your remarks and made the corrections you recommended.

Document will soon also be sent via IETF to the mailing-list =96 until =
then so
far via attachment.=20

Before the long Q&A below: I really adopted nearly all comments and
corrections you proposed, these are mainly answers to questions from Jim =
and
a few requests for further clarification of some of comments from Jim.

@Young: I widened the scope of the potentially used timestamps as you
requested (though not using such a quite strong wording as you proposed =
in
your comments sent to me). Please provide me feedback whether this is
sufficient in your eyes.

=20

@all: take a final look! =96 we SHOULD go to WG last call next week.

=20

=20

Thanks for your help

=20

            Tobias

=20

=20

=20

=20

I only refer to questions where I did not change the text:

>From Jim:

Q: Section 2.1: digestAlgorithms - is this just the OIDs of the =
algorithm
identifiers or does this include all of the parameters as well?

A: We refer here to =93AlgorithmIdentifier FROM AI ;=94

=20

Q: Section 2.1: field encryption in EvidenceRecord is not described in =
order
and in the same format.

A: Yes, but I don=92t understand the problem. Encryption is optional and
covers the option to encrypt content before submitting it to an archive. =
We
define EncryptionMethod for this. =20

=20

<JLS>  I don't object to the fact that there is a fuller descripiton =
else
where, but feel the text should say something like:

=20

encryption contains the data necessary to allow for .... and is more
completely discussed in section 5.1

=20

Q: Section 2.1: field encrytion - is this suppose to contain infomration
about re-encryption or about decryption of the fields?  There is some
differences

between these.   Suggest a hint about where keys are found is included =
as

well in this location.

A: EncryptionMethod  is defined in Section 5.1

=20

<JLS> The discription of EncryptionMethod refered to having enough data =
to
re-encrypt the message if necessary.  Where is the informatino to =
decrypt
the message kept?  Is the document suppose to be a ContentInfo object?=20

=20

Q: Section 3.1:  Are you restricted to a single set of parameters?  If =
you
are doing multiple hash operations  might one which to allow for =
different
sets of parameters for each of the hash operations?

A: Within one hash-tree: Yes. As you can see within an =
ArchiveTimeStampChain
one can of course have multiple ArchiveTimeStapms with different hash =
algs
for the hash-trees.

Do you see need for more than one hash alg within one hash-tree?

=20

<JLS> The question deals not with multiple hash algorithms but a single =
hash
algorithm which has parameters.  I.e. a keyed hash fucntion.  In this =
case
there might be multiple sets of parameters that are used with the single
hash function.=20

=20

Q: Section 3.2: From my reading of the text, Figure 3 should be (h1), =
(h2a,
h2b, h2c), (h3) as this is the order items are in the tree above.=20

A: No. The hash-tree in figure 1 does not reflect with its order the =
binary
order of the elements on the same level of the tree. See also above =
Figure 2
=93Assuming that the sorted binary ordering of the hashes in Figure 1 =
is:
h2abc < h1 then the reduced hash-tree for data group 1 (d1) is:=93 =20

=20

<JLS> OK.=20

=20

Q: Section 3.2:  There not text or reference for how grouping is done. =
(step
4

- place in groups and sort)

A: sorting is in binary ascending order, the granularity of the tree is =
not
necessary to define. E.g. the number of leaves on every level is open =
for
the implementation =96 any number can be verified with the described
algorithms.=20

=20

<JLS> My issue is not with sorting, but with grouping.  The information
dealing with grouping is not kept in the tree, does it need to be?  When
does one know that grouping is necessary --- is this out of scope of the
document?=20

=20

Q: Section 3.3:  Why search in the first list rather than the entire =
list of
reducedHashtree?  It seems to me that it could be anyplace in the list =
and
still be valid.

A: as only corresponding neighboring leaves are in the reducedhashtree =
and
the lowest level is the first list, it must be in the first group of =
values.

See also section 3.2 below figure 1 listed items 1-3=20

=20

<JLS> The answer has to to do with how a new hash algorithm is applied.=20

=20

Q: Section 3.3: In step 3 it says that the value must be a member of the
next higher list --- WHAT LIST????? The reduction removes these from the
list of hash values.  It must be taken on faith that it is correct until =
you
reach the root.

A: Yes. Computing the complete hashtree will need to compute until the
highest node to verify that the hashtree is consistent. On the other =
hand we
expect less false trees and can save memory by not storing values that =
are
easily computable (redundantly). The fact that an item belongs to a =
reduced
hash-tree on the other hand can easily be verified as this hash value is =
in
the first list.=20

=20

<JLS> Then make the text simplier and just say that the hash tree is
re-computed to get the root value and don't talk about intermediate =
values.=20

=20

Q: Section 3.3: How does one re-construct the grouping that was created =
in
the production step?  Very non-obious

You don=92t need to do much reconstruction. Verify the lists you got is =
all
you need to do. For this the simple rules (order binary ascendant and
concatenate, compute hash of next level) are fully sufficient.

=20

<JLS> As with the above, if you just say use the existing reduced tree =
and
re-compute the root value of the tree then the question of how to =
re-group
because unimportant.=20

=20

Q: Section 4.1:  What does it mean for a ArchiveTimeStampSequence to be
ordered by time of timestamp?  If I run two parallel =
ArchiveTimeStampChains
with different hash functions and sign both at the approx the same time =
--
which comes first?  Ordered by the first entry or the last entry on the
chain?

There is no reason to assume that all of the entries in the second chain
occur after all of the entiries in the first chain.

A: Oh yes it is. Every ArchiveTimeStampChain is securing the existence =
of
the one before (it refers to the timestamp of the one before) as well as
every ArchiveTimeStampChain must be temporal after the first one (it =
also
refers to the one before =96 for that it could not be created without =
there
one before closed.

=20

<JLS> Which means that you need to include text someplace which says I
cannot run to conccurent ArrivheTimeStampChains at the same time with
different hash values.=20

=20

Q: Section 4.2:  It states that the hash algorithms must be the same -- =
how
about the hash algorithm parameters?

A: You are probably right and it should state a SHOULD (but a really =
strong
SHOULD ;-) ) =96 will discuss this with a person who implemented it =96 =
maybe
someone else can verify this too?

=20

Q: Section 4.2, 4.3: I have serveral issues with the algorithm that you =
are
using to replace a hash functions.  They are:

=20

Q: 1) I believe that atsc(i) should be a constant for all documents.  A
document should never be deleted and then re-added, nor is a document =
added
during the process of renewing a timestamp.  Thus either the document =
has
been deleted (in which case it is not re-hashed) or it is in every
ArchiveTimeStampSequence.  Ergo - atsc(i) is constant for all values of =
i.

A: no atsc(i) is not constant for all documents within a tree as the =
atsc(i)
consists on the lowest atomic level of reducedhashtrees which do NOT =
contain
all hashvalues of all documents but only the hash values of all =
neighbours
to the document in question. (comment: this has the advantage of =
limiting
the size of the EvidenceRecord to the amount of data really needed =96 =
not
unnecessarily inflating the data =96 think e.g. of 10^9 objects in a =
hashtree
and adding new hashtrees=85.)=20

=20

<JLS> I am definately going to implement this incorrectly.  What you are
discribing and what I read in the document have absolutely no relation =
with
each other.=20

=20

Q: 2) Verification requires that an implemenation of all previous hash
algorithms be kept is that what one wants to do?  (I.e. do you want to =
be
able to have a "fast" proof using just the current data).

A: you MUST keep the old hash values because they are the algs to prove =
the
consistent over the first periods of time =96 using only the new hash =
algs can
never provide proof over time where they have not been used.

=20

<JLS> I understand that I need to be able to do a full walk of the tree, =
the
question of being able to start with a fast walk and then go back and do =
the
complete proof is what I was asking.=20

=20

Q: 3) What happens if only one item is left in a document group (i.e the
rest have been deleted)?  Is it treated as a document group of one or as =
a
single document?

A: The hash values of these documents still remain in the group they can
never be removed as by this the integrity of the group could never be
proved. On the other hand thanks to the characteristics of hash algs =
there
is no way to get information about a deleted document from its former =
e.g.
160bit hash value (one way, etc.)

=20

<JLS>  How do I compute H((d(i)) in the event that the document has been
deleted, but d(i) is part of a group with d(j)

=20

Q: Section 5.1:  The proper term is detached content rather than =
external
content.  Suggest "encryptionCover is a CMS content type of =
EnvelopedData
where the encryptedContent field is absent"

A: could you please explain this a bit more? I don=92t understand your
suggestion completely.=20

=20

<JLS> I believe that this is a simpler way of saying the same thing that
your current text is attempting to say, but using CMS language.

=20

Q: Section 5.1: Putting the private key into a BIT STRING is =
problematic.  I
would suggest either an OCTET STRING or an ANY DEFINED BY with the OID =
as
well.

A: What problem do you see with BIT STRING ?=20

=20

<JLS> Well -- the first think you are wasting space for the unused bit =
field
-- going to an OCTET STRING would eliminate that problem.  Secondly I =
don't
know if there is a justification for adding the wrapping field at all.
Lastly having the OID present would make life easier in terms of trying =
to
figure out what the internal data structure really is.=20

=20

Q: Section 5.1:  I don't understand the set of parameters that you have
defined for re-encryption of the structure.  I would thing that the only
thing that you need is the ContentEncryptionKey in the clear - The rest =
of
the parameters are kept in the encryptionCover field.  You don't need to =
the
public key or the KeyEncryptionKey fields unless you are intending to
re-build the EncryptionCover field.

A: first you might want them for convenience and better organization of =
the
verification, second you need e.g. the ssed to be counter potential =
attacks
trying to bring in a second encrypted document with different content =
and
different seed but same hash value of the encrypted document. I know =
this is
potential paranoia, but discussions pointed our potential attack vectors
here.=20

=20

<JLS> If this is really what you are trying to protect against it would =
be
better to have a hash of the original document and rely on not being =
able to
(1) invert the hash and (2) not having the document to do a comparision =
for
equivalance of the document to see if it is the one that was archived.
Unless the encryptiojn parameters are included in the timestamp value =
(which
does not appear to be true from the text) then you are not protecting
againist having a different document show up that has the same hash =
value
but different content encryption key.=20

=20

Q: Section 5.1:  If you are using the EncryptedData field you need to =
make
some additional statements that are not required in CMS.

A. where in the document do you refer to the EncryptedData field?

=20

1) The ContentInfo field to be submitted MUST be DER encoded.

2) The encrypted content MUST be connonicalized PRIOR to being =
encrypted.

(i.e. ASN.1 is DER encoded, MIME uses S/MIME rules and so forth)

3) The EncryptedData RecipientInfos MUST ALL be kept intact unless the
EncryptedData field was not archived.=20

=20

<JLS> Sorry -- I meant EnvelopedData not EncryptedData.

=20

=20

Section 6:  Use the correct module for CMS --=20

   CryptographicMessageSyntax2004

     { iso(1) member-body(2) us(840) rsadsi(113549)

       pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

Q: thanks for the correction =96 done.

=20

=20

Q: Section 6:  Add a reference comment to each of the IMPORT-ed modules =
--
>From [RFCXXXX] so that they can be easily found

A: done.

=20

=20

Comment:  Useful to have the list name in the document so I know where =
to
send mail to.

A: you=92re right would be useful. On the other hand the WG is named and =
the
mailing-list can be derived from that easily via www.ietf.org
<http://www.ietf.org/>  and further it is not common, and therefore not
done.

=20

 <JLS> -- pity one of the problems with going to the XML document =
version.
I used to include the mailing list name in the status section of all of =
the
documents that I wrote.

=20

=20

=20

=20

=20

=20

=20

__________________________________________
Tobias Gondrom
Senior Security Architect
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:[email-masked]
Internet:      http://www.opentext.com/

This eMail may contain confidential and/or privileged information. If =
you
are not the intended recipient or have received this eMail in error, =
please
notify the sender immediately and destroy this eMail. Any use, =
disclosure or
distribution of the material in this eMail is strictly forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung
oder Weitergabe ist nicht gestattet.

=20

------=_NextPart_000_001F_01C5F9F8.D8668450
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR>
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Tobias Gondrom=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Monday, December 05, =
2005=20
  11:51 AM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> Jim Schaad; =
Young H.=20
  Etheridge; Carl Wallace<BR><B>Subject:</B> ltans: =
ers-04<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Jim, Young,=20
  Carl,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks for your thorough =
review.=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I adopted your remarks =
and made=20
  the corrections you recommended.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Document will soon also =
be sent=20
  via IETF to the mailing-list =96 until then so far via attachment.=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Before the long Q&amp;A =
below: I=20
  really adopted nearly all comments and corrections you proposed, these =
are=20
  mainly answers to questions from Jim and a few requests for further=20
  clarification of some of comments from =
Jim.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">@Young: I widened the =
scope of the=20
  potentially used timestamps as you requested (though not using such a =
quite=20
  strong wording as you proposed in your comments sent to me). Please =
provide me=20
  feedback whether this is sufficient in your =
eyes.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">@all: take a final look! =
=96 we=20
  SHOULD go to WG last call next week.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks for your=20
  help<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
  Tobias<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I only refer to =
questions where I=20
  did not change the text:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">From=20
  Jim:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section 2.1:=20
  digestAlgorithms - is this just the OIDs of the algorithm identifiers =
or does=20
  this include all of the parameters as =
well?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A: We refer here to=20
  =93</SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">AlgorithmIdentifier FROM=20
  AI ;=94</SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section 2.1: =
field=20
  encryption in EvidenceRecord is not described in order and in the same =

  format.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A: Yes, but I don=92t =
understand the=20
  problem. Encryption is optional and covers the option to encrypt =
content=20
  before submitting it to an archive. We define </SPAN></FONT><FONT=20
  face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">EncryptionMethod</SPAN></FONT><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> for this.&nbsp;<FONT=20
  color=3D#0000ff><SPAN =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><FONT=20
  color=3D#0000ff><SPAN =
class=3D151194007-06122005></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><FONT=20
  color=3D#0000ff><SPAN =
class=3D151194007-06122005>&lt;JLS&gt;&nbsp;&nbsp;I don't=20
  object to the fact that there is a fuller descripiton else where, but =
feel the=20
  text should say something like:</SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><FONT=20
  color=3D#0000ff><SPAN =
class=3D151194007-06122005></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>encryption contains =
the data=20
  necessary to allow for .... and is more completely discussed in =
section=20
  5.1</SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section 2.1: =
field=20
  encrytion - is this suppose to contain infomration about re-encryption =
or=20
  about decryption of the fields?&nbsp; There is some=20
  differences<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">between =
these.&nbsp;&nbsp;=20
  Suggest a hint about where keys are found is included=20
  as<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">well in this=20
  location.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A:=20
  EncryptionMethod</SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp; is defined in =
Section=20
  5.1<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p><SPAN=20
  class=3D151194007-06122005><FONT color=3D#0000ff>&lt;JLS&gt; The =
discription of=20
  EncryptionMethod refered to having enough data to re-encrypt the =
message if=20
  necessary.&nbsp; Where is the informatino to decrypt the message =
kept?&nbsp;=20
  Is the document suppose to be a ContentInfo=20
  object?</FONT></SPAN>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
3.1:&nbsp; Are=20
  you restricted to a single set of parameters?&nbsp; If you are doing =
multiple=20
  hash operations&nbsp; might one which to allow for different sets of=20
  parameters for each of the hash =
operations?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: Within one =
hash-tree:=20
  Yes. As you can see within an ArchiveTimeStampChain one can of course =
have=20
  multiple ArchiveTimeStapms with different hash algs for the=20
  hash-trees.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Do you see need =
for more=20
  than one hash alg within one hash-tree?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><o:p><SPAN=20
  class=3D151194007-06122005><FONT face=3DArial =
color=3D#0000ff>&lt;JLS&gt;=20
  The&nbsp;question deals not with multiple hash algorithms but a single =
hash=20
  algorithm which has parameters.&nbsp; I.e. a keyed hash =
fucntion.&nbsp; In=20
  this case there might be multiple sets of&nbsp;parameters that are =
used with=20
  the single hash function.</FONT></SPAN>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section 3.2: =
>From my=20
  reading of the text, Figure 3 should be (h1), (h2a, h2b, h2c), (h3) as =
this is=20
  the order items are in the tree above. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: No. The =
hash-tree in=20
  figure 1 does not reflect with its order the binary order of the =
elements on=20
  the same level of the tree. See also above Figure 2 =93Assuming that =
the sorted=20
  binary ordering of the hashes in Figure 1 is: h2abc &lt; h1 then the =
reduced=20
  hash-tree for data group 1 (d1) is:=93&nbsp;<FONT face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>&lt;JLS&gt;=20
  OK.&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
3.2:&nbsp;=20
  There not text or reference for how grouping is done. (step=20
  4<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">- place in =
groups and=20
  sort)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: sorting is in =
binary=20
  ascending order, the granularity of the tree is not necessary to =
define. E.g.=20
  the number of leaves on every level is open for the implementation =96 =
any=20
  number can be verified with the described algorithms.<FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>&lt;JLS&gt; My issue =
is not with=20
  sorting, but with grouping.&nbsp; The information dealing with =
grouping is not=20
  kept in the tree, does it need to be?&nbsp; When does one know that =
grouping=20
  is necessary&nbsp;--- is this out of scope of the=20
  document?&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
3.3:&nbsp; Why=20
  search in the first list rather than the entire list of =
reducedHashtree?&nbsp;=20
  It seems to me that it could be anyplace in the list and still be=20
  valid.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: as only =
corresponding=20
  neighboring leaves are in the reducedhashtree and the lowest level is =
the=20
  first list, it must be in the first group of=20
  values.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">See also section =
3.2 below=20
  figure 1 listed items 1-3<FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>&lt;JLS&gt;&nbsp;The =
answer has=20
  to&nbsp;to do with how a new hash&nbsp;algorithm is=20
  applied.&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section 3.3: =
In step 3=20
  it says that the value must be a member of the next higher list --- =
WHAT=20
  LIST????? The reduction removes these from the list of hash =
values.&nbsp; It=20
  must be taken on faith that it is correct until you reach the=20
  root.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: Yes. =
Computing the=20
  complete hashtree will need to compute until the highest node to =
verify that=20
  the hashtree is consistent. On the other hand we expect less false =
trees and=20
  can save memory by not storing values that are easily computable=20
  (redundantly). The fact that an item belongs to a reduced hash-tree on =
the=20
  other hand can easily be verified as this hash value is in the first=20
  list.<FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN =
class=3D151194007-06122005>&lt;JLS&gt;&nbsp;Then&nbsp;make=20
  the text simplier&nbsp;and just say that the hash tree is re-computed =
to get=20
  the root&nbsp;value and don't talk about intermediate=20
  values.&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section 3.3: =
How does=20
  one re-construct the grouping that was created in the production =
step?&nbsp;=20
  Very non-obious<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">You don=92t need =
to do much=20
  reconstruction. Verify the lists you got is all you need to do. For =
this the=20
  simple rules (order binary ascendant and concatenate, compute hash of =
next=20
  level) are fully sufficient.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><o:p><SPAN=20
  class=3D151194007-06122005><FONT face=3DArial =
color=3D#0000ff>&lt;JLS&gt; As with=20
  the above, if you just say use the existing reduced tree =
and&nbsp;re-compute=20
  the root value of the tree then&nbsp;the question of how to re-group=20
  because&nbsp;unimportant.</FONT></SPAN>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
4.1:&nbsp; What=20
  does it mean for a ArchiveTimeStampSequence to be ordered by time of=20
  timestamp?&nbsp; If I run two parallel ArchiveTimeStampChains with =
different=20
  hash functions and sign both at the approx the same time -- which =
comes=20
  first?&nbsp; Ordered by the first entry or the last entry on the=20
  chain?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">There is no =
reason to=20
  assume that all of the entries in the second chain occur after all of =
the=20
  entiries in the first chain.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: Oh yes it is. =
Every=20
  ArchiveTimeStampChain is securing the existence of the one before (it =
refers=20
  to the timestamp of the one before) as well as every =
ArchiveTimeStampChain=20
  must be temporal after the first one (it also refers to the one before =
=96 for=20
  that it could not be created without there one before=20
  closed.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><o:p><SPAN=20
  class=3D151194007-06122005><FONT face=3DArial =
color=3D#0000ff>&lt;JLS&gt; Which=20
  means that you need to include text someplace which says I cannot run =
to=20
  conccurent ArrivheTimeStampChains&nbsp;at the same time with different =
hash=20
  values.</FONT></SPAN>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
4.2:&nbsp; It=20
  states that the hash algorithms must be the same -- how about the hash =

  algorithm parameters?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: You are =
probably right=20
  and it should state a SHOULD (but a really strong SHOULD ;-) ) =96 =
will discuss=20
  this with a person who implemented it =96 maybe someone else can =
verify this=20
  too?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section 4.2, =
4.3: I=20
  have serveral issues with the algorithm that you are using to replace =
a hash=20
  functions.&nbsp; They are:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: 1) I believe =
that=20
  atsc(i) should be a constant for all documents.&nbsp; A document =
should never=20
  be deleted and then re-added, nor is a document added during the =
process of=20
  renewing a timestamp.&nbsp; Thus either the document has been deleted =
(in=20
  which case it is not re-hashed) or it is in every=20
  ArchiveTimeStampSequence.&nbsp; Ergo - atsc(i) is constant for all =
values of=20
  i.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: no atsc(i) is =
not=20
  constant for all documents within a tree as the atsc(i) consists on =
the lowest=20
  atomic level of reducedhashtrees which do NOT contain all hashvalues =
of all=20
  documents but only the hash values of all neighbours to the document =
in=20
  question. (comment: this has the advantage of limiting the size of the =

  EvidenceRecord to the amount of data really needed =96 not =
unnecessarily=20
  inflating the data =96 think e.g. of 10^9 objects in a hashtree and =
adding new=20
  hashtrees=85.)<FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>&lt;JLS&gt; I am =
definately going=20
  to implement this incorrectly.&nbsp; What you are discribing and what =
I read=20
  in the document have absolutely no relation with each=20
  other.&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: 2) =
Verification=20
  requires that an implemenation of all previous hash algorithms be kept =
is that=20
  what one wants to do?&nbsp; (I.e. do you want to be able to have a =
"fast"=20
  proof using just the current data).<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: you MUST keep =
the old=20
  hash values because they are the algs to prove the consistent over the =
first=20
  periods of time =96 using only the new hash algs can never provide =
proof over=20
  time where they have not been used.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><o:p><SPAN=20
  class=3D151194007-06122005><FONT face=3DArial =
color=3D#0000ff>&lt;JLS&gt; I=20
  understand that I need to be able to do a full walk of the tree, the=20
  question&nbsp;of being able to start with a fast walk and then go back =
and do=20
  the complete proof is what I was=20
  asking.</FONT></SPAN>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: 3) What =
happens if only=20
  one item is left in a document group (i.e the rest have been =
deleted)?&nbsp;=20
  Is it treated as a document group of one or as a single=20
  document?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: The hash =
values of=20
  these documents still remain in the group they can never be removed as =
by this=20
  the integrity of the group could never be proved. On the other hand =
thanks to=20
  the characteristics of hash algs there is no way to get information =
about a=20
  deleted document from its former e.g. 160bit hash value (one way,=20
  etc.)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><o:p><SPAN=20
  class=3D151194007-06122005>&lt;JLS&gt;&nbsp; How do I compute H((d(i)) =
in the=20
  event that the document has been deleted, but d(i) is part of a group =
with=20
  d(j)</SPAN></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><o:p><SPAN=20
  class=3D151194007-06122005></SPAN></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
5.1:&nbsp; The=20
  proper term is detached content rather than external content.&nbsp; =
Suggest=20
  "encryptionCover is a CMS content type of EnvelopedData where the=20
  encryptedContent field is absent"<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: could you =
please=20
  explain this a bit more? I don=92t understand your suggestion =
completely.<FONT=20
  face=3DArial><FONT color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>&lt;JLS&gt;&nbsp;I =
believe that=20
  this is a simpler way of saying the same thing that &nbsp;your current =
text is=20
  attempting to say, but using CMS=20
  language.</SPAN><o:p></o:p></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section 5.1: =
Putting=20
  the private key into a BIT STRING is problematic.&nbsp; I would =
suggest either=20
  an OCTET STRING or an ANY DEFINED BY with the OID as=20
  well.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: What problem =
do you see=20
  with BIT STRING ?<FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>&lt;JLS&gt;&nbsp;Well =
-- the=20
  first&nbsp;think&nbsp;you are wasting space for the unused bit field =
-- going=20
  to an OCTET STRING would eliminate that problem.&nbsp; Secondly I =
don't know=20
  if there is a justification for adding the wrapping field at =
all.&nbsp; Lastly=20
  having the OID present would make life easier in terms of trying to =
figure out=20
  what the&nbsp;internal data structure really=20
  is.&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
5.1:&nbsp; I=20
  don't understand the set of parameters that you have defined for =
re-encryption=20
  of the structure.&nbsp; I would thing that the only thing that you =
need is the=20
  ContentEncryptionKey in the clear - The rest of the parameters are =
kept in the=20
  encryptionCover field.&nbsp; You don't need to the public key or the=20
  KeyEncryptionKey fields unless you are intending to re-build the=20
  EncryptionCover field.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A: first you =
might want=20
  them for convenience and better organization of the verification, =
second you=20
  need e.g. the ssed to be counter potential attacks trying to bring in =
a second=20
  encrypted document with different content and different seed but same =
hash=20
  value of the encrypted document. I know this is potential paranoia, =
but=20
  discussions pointed our potential attack vectors here.<FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>&lt;JLS&gt; If =
this&nbsp;is=20
  really what you are trying to protect against it would be better to =
have a=20
  hash of the original document and rely on&nbsp;not being able to (1) =
invert=20
  the hash and (2)&nbsp;not having the document to do a comparision for=20
  equivalance of the document to see if it is the one that was =
archived.&nbsp;=20
  Unless the encryptiojn parameters are included in the timestamp=20
  value&nbsp;(which does not appear to be true from the text) then you =
are not=20
  protecting againist having a different document show up that has the =
same hash=20
  value but different&nbsp;content encryption=20
  key.&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
5.1:&nbsp; If=20
  you are using the EncryptedData field you need to make some additional =

  statements that are not required in CMS.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A. where in the =
document=20
  do you refer to the EncryptedData field?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">1) The =
ContentInfo field=20
  to be submitted MUST be DER encoded.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">2) The encrypted =
content=20
  MUST be connonicalized PRIOR to being =
encrypted.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">(i.e. ASN.1 is =
DER=20
  encoded, MIME uses S/MIME rules and so =
forth)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">3) The =
EncryptedData=20
  RecipientInfos MUST ALL be kept intact unless the EncryptedData field =
was not=20
  archived.<FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D151194007-06122005>&lt;JLS&gt; Sorry -- =
I=20
  meant&nbsp;EnvelopedData not=20
  EncryptedData.</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New"><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D151194007-06122005>&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN><=
/FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Section 6:&nbsp; =
Use the=20
  correct module for CMS -- <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;=20
  CryptographicMessageSyntax2004<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp; {=20
  iso(1) member-body(2) us(840) =
rsadsi(113549)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)=20
  }<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: thanks for =
the=20
  correction =96 done.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Q: Section =
6:&nbsp; Add a=20
  reference comment to each of the IMPORT-ed modules -- From [RFCXXXX] =
so that=20
  they can be easily found<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">A:=20
  done.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Comment:&nbsp; =
Useful to=20
  have the list name in the document so I know where to send mail=20
  to.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">A: you=92re right would =
be useful.=20
  On the other hand the WG is named and the mailing-list can be derived =
from=20
  that easily via <A href=3D"http://www.ietf.org/">www.ietf.org</A> and =
further it=20
  is not common, and therefore not done.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;<SPAN=20
  class=3D151194007-06122005><FONT color=3D#0000ff>&lt;JLS&gt; -- pity =
one of the=20
  problems with going to the XML document version.&nbsp; I used to =
include the=20
  mailing list name in the status section of all of the documents that I =

  wrote.</FONT></SPAN></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P><B><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">__________________________________________</SPAN></FONT></B><FONT =

  face=3DArial><SPAN style=3D"FONT-FAMILY: =
Arial"><BR></SPAN></FONT><B><FONT=20
  face=3DArial color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: Arial">Tobias=20
  Gondrom</SPAN></FONT></B><BR><FONT face=3DArial color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Senior =
Security=20
  Architect<BR>Head of Open Text Security =
Team<BR></SPAN></FONT><BR><B><FONT=20
  face=3DArial color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: Arial">Open=20
  Text Corporation</SPAN></FONT></B><BR><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black">Technopark 2<BR>Werner-von-Siemens-Ring =
20<BR>D-85630=20
  Grasbrunn</SPAN></FONT><BR><FONT face=3DArial color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Arial">Phone:&nbsp; +49 (0)=20
  89 4629-1816<BR>Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 =
(0) 89=20
  4629-33-1816<BR>eMail:&nbsp;</SPAN></FONT> <FONT face=3DArial =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A=20
  =
href=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</A><BR><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: =
black">Internet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT><A=20
  =
href=3D"http://www.opentext.com/">http://www.opentext.com/</A></SPAN></FO=
NT><o:p></o:p></P>
  <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">This eMail =
may=20
  contain confidential and/or privileged information. If you are not the =

  intended recipient or have received this eMail in error, please notify =
the=20
  sender immediately and destroy this eMail. Any use, disclosure or =
distribution=20
  of the material in this eMail is strictly=20
  forbidden.</SPAN></FONT><o:p></o:p></P>
  <P><FONT face=3DArial size=3D2><SPAN lang=3DDE=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Diese eMail enth=E4lt =
vertrauliche=20
  und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der =
richtige=20
  Adressat sind oder diese eMail irrt=FCmlich erhalten haben, =
informieren Sie=20
  bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art =
der=20
  Verwendung, Vervielf=E4ltigung oder Weitergabe ist nicht=20
  gestattet.</SPAN></FONT><SPAN lang=3DDE><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =
lang=3DDE=20
  style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------=_NextPart_000_001F_01C5F9F8.D8668450--

From: "Carl Wallace" <[email-masked]>
To: "'Tobias Gondrom'" <[email-masked]>, "'Hannes Weber'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: ERS and certificates
Date: Mon, 5 Dec 2005 16:28:03 -0500
Sender: [email-masked]

Have a look at the SCVP/ERS draft.  It uses ERS but separates the
preservation of the certification path entirely and thus avoids maintaining
an ERS for the certification path repeatedly. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tobias Gondrom
> Sent: Monday, December 05, 2005 3:28 PM
> To: Hannes Weber
> Cc: [email-masked]
> Subject: RE: ERS and certificates
> Importance: Low
> 
> 
> Hi Hannes, 
> 
> nice to read. I heard of about 3 diploma thesis about this 
> issue in the last 18 months. (one was from IBM, one from FHG, 
> the third I've forgotten, maybe Siemens) Your findings are 
> true. It is necessary to include any verification data 
> (especially the complete certificate path) before the time of 
> the first hashing and timestamping. If it would be added 
> lated it would of course change the hash value. 
> Concerning the certificate path for the timestamps in the 
> ArchiveTimeStamp itself, it should of course be trivial to 
> get them at the time of request.
> The others should be obtained when the data enters the system 
> and runs through a first verification before archiving (good 
> process design would recommend to verify data before archiving).
> 
> And before answering: in nearly all commercial applications 
> it can be expected that they are able to (and DO) retrieve 
> the verification data (certificate path and OCSP/CRL) at the 
> time of entry into the system and can add this information as 
> recommended by ISIS-MTT to the signed documents. 
> 
> In case this is not the case, one has to find a solution as 
> you thought of.
> And your idea of simply extending the model of the 
> EvidenceRecord by simply adding the additional verification 
> data as an additional file represented by a hash value in the 
> normal hashtrees is the right approach. 
> 
> But as you can in this case not know when the information 
> might become available to the system (it might even be AFTER 
> several timestamp and hashtree renewals) the logic connection 
> between the elements (original file, verification data) must 
> be kept by the leading application (in your case the DMS) and 
> not within the ERS! 
> 
> Of course all hash values of all elements can (and SHOULD) 
> end up in one
> hashtree: So if e.g. you add a document with signatures at 
> let's say Dec
> 1 2005 and build a first hashtree (with timestamp) without 
> the certificate path. You might add the file containing the 
> certificate path information one day later (Dec 2, 2005) (or 
> five years later) in a second hashtree. At the time of the 
> next occurring renewal (no matter how many occurred in 
> between and no matter be it a timestamp or hashtree
> renewal) you simply take care that both hashtrees have their 
> highest node be represented by a hash in the same new 
> hashtree. Of course you could also just add the hash value of 
> the verification data right besides the hash value of the 
> ArchiveTimeStamp(Chain) of the original document. 
> 
> In the end for verification you have a bit more work of 
> course than you would have had if you included the 
> verification data before archiving:
> You have to verify the integrity of both EvidenceRecords (the 
> one for the original file and the second for the file with 
> the additional verification data you e.g. received a day 
> later). Note: as both EvidenceRecords might have come 
> together at some point in time as leaves in a new hashtree 
> you probably can simplify verification procedure due to duplication.
> After this first step (or in parallel) you verify the 
> signatures in the document with the verification data and 
> only if ALL checks succeed you can assume that the document 
> and its signatures are correct. 
> 
> I strongly recommend to use the EvidenceRecord solely to 
> proof the non-repudiation of the single objects (ignoring any 
> potential further relationship between them) and leaving the 
> link between them to the leading application. (Small personal 
> comment: I discussed this also with my team and all other 
> things will most probably get you in trouble with your 
> implementation. ;-) )
> 
> Best regards, and if you like please feel free to call if you 
> have further questions - am always happy to help (and same 
> time zone could make things easier ;-) ).
> 
> Tobias
> 
> __________________________________________
> Tobias Gondrom
> Head of Open Text Security Team
> 
> Open Text Corporation
> Technopark 2
> Werner-von-Siemens-Ring 20
> D-85630 Grasbrunn
> Phone:  +49 (0) 89 4629-1816
> Telefax:        +49 (0) 89 4629-33-1816
> eMail:  mailto:[email-masked]
> Internet:      http://www.opentext.com/
> 
> 
> 
> 
> 
> > Hi,
> > i am a student at the university of Bremen (Germany) and recently
> wrote my
> > diploma thesis about
> > digital signatures in long-term archives. The aim of my work was to 
> > develop a library capable of performing the long-term 
> non-repudiation 
> > for digital signed documents
> in
> > the context of document management systems.
> > 
> > My solution relies on ERS, but in order to be able to 
> ensure long-term 
> > non-repudiation for any kind of signatures - that are conform to 
> > ISIS-MTT - I extended ERS. This
> was
> > necessary because ERS is
> > not capable of prooving the evidence for digital signatures that do
> not
> > include the complete
> > certificate path. 
> > At the time the evidence record is generated it is not possible to 
> > extend the renewed signature with the missing certificates of the 
> > certificate path (the certificates field of a CMS-object in 
> a signed 
> > field) which are necessary for the non-repudiation proof.
> > So I integrated the certificates of the certificate path 
> and the OCSP 
> > responses into the evidence record by exploiting the data 
> object group 
> > feature. The renewal of a signed documents must be extended as 
> > follows:
> > Timestamp Renewal/Inital Renewal: Before a digital signature
> (CMS-Object,
> > ERS-Object,...) is renewed
> > a proof of its validity is performed and the data (called 
> > RevocationInfoArchival [RIA] and consits of certificates and OCSP 
> > responses) is stored within the evidence
> record.
> > For each certificate and
> > each ocsp the hash value is computed. These hash values are sorted, 
> > concated and hashed again.
> > This hash value (the hash value for one RIA) is treated as 
> an ordinary 
> > signed document within a data object group.
> > Hashtree Renewal: First create the RIA for the latest 
> signature. Then 
> > compute the hashvalue for each RIA of the evidece record. Sort, 
> > concate and hash these hashvalues and integrate this 
> together with the 
> > hashvalue of the evidence record into the hashtree using the data 
> > object group procedure.
> > Validation: Within the validiation of an evidence record the stored
> RIAs
> > have to be used for all but
> > the latest signature. To ensure their validity it is checked whether
> the
> > hashvalue appears in the
> > first hashlist of the "next" archive time stamp (meeting 
> the usual ERS 
> > terms as timeliness, correct hash algortihm, and so on).
> > 
> > I would be glad to hear your opinion about this soultion.
> > 
> > Best Regards
> > Hannes Weber
> 
> 

Content-class: urn:content-classes:message
Subject: RE: ERS and certificates
Date: Mon, 5 Dec 2005 21:28:15 +0100
Importance: low
From: "Tobias Gondrom" <[email-masked]>
To: "Hannes Weber" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Hannes, 

nice to read. I heard of about 3 diploma thesis about this issue in the
last 18 months. (one was from IBM, one from FHG, the third I've
forgotten, maybe Siemens)
Your findings are true. It is necessary to include any verification data
(especially the complete certificate path) before the time of the first
hashing and timestamping. If it would be added lated it would of course
change the hash value. 
Concerning the certificate path for the timestamps in the
ArchiveTimeStamp itself, it should of course be trivial to get them at
the time of request.
The others should be obtained when the data enters the system and runs
through a first verification before archiving (good process design would
recommend to verify data before archiving).

And before answering: in nearly all commercial applications it can be
expected that they are able to (and DO) retrieve the verification data
(certificate path and OCSP/CRL) at the time of entry into the system and
can add this information as recommended by ISIS-MTT to the signed
documents. 

In case this is not the case, one has to find a solution as you thought
of.
And your idea of simply extending the model of the EvidenceRecord by
simply adding the additional verification data as an additional file
represented by a hash value in the normal hashtrees is the right
approach. 

But as you can in this case not know when the information might become
available to the system (it might even be AFTER several timestamp and
hashtree renewals) the logic connection between the elements (original
file, verification data) must be kept by the leading application (in
your case the DMS) and not within the ERS! 

Of course all hash values of all elements can (and SHOULD) end up in one
hashtree: So if e.g. you add a document with signatures at let's say Dec
1 2005 and build a first hashtree (with timestamp) without the
certificate path. You might add the file containing the certificate path
information one day later (Dec 2, 2005) (or five years later) in a
second hashtree. At the time of the next occurring renewal (no matter
how many occurred in between and no matter be it a timestamp or hashtree
renewal) you simply take care that both hashtrees have their highest
node be represented by a hash in the same new hashtree. Of course you
could also just add the hash value of the verification data right
besides the hash value of the ArchiveTimeStamp(Chain) of the original
document. 

In the end for verification you have a bit more work of course than you
would have had if you included the verification data before archiving:
You have to verify the integrity of both EvidenceRecords (the one for
the original file and the second for the file with the additional
verification data you e.g. received a day later). Note: as both
EvidenceRecords might have come together at some point in time as leaves
in a new hashtree you probably can simplify verification procedure due
to duplication.
After this first step (or in parallel) you verify the signatures in the
document with the verification data and only if ALL checks succeed you
can assume that the document and its signatures are correct. 

I strongly recommend to use the EvidenceRecord solely to proof the
non-repudiation of the single objects (ignoring any potential further
relationship between them) and leaving the link between them to the
leading application. (Small personal comment: I discussed this also with
my team and all other things will most probably get you in trouble with
your implementation. ;-) )

Best regards, and if you like please feel free to call if you have
further questions - am always happy to help (and same time zone could
make things easier ;-) ).

Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:[email-masked]
Internet:      http://www.opentext.com/

> Hi,
> i am a student at the university of Bremen (Germany) and recently
wrote my
> diploma thesis about
> digital signatures in long-term archives. The aim of my work was to
> develop
> a library capable of
> performing the long-term non-repudiation for digital signed documents
in
> the context of document management systems.
> 
> My solution relies on ERS, but in order to be able to ensure long-term
> non-repudiation for any kind
> of signatures - that are conform to ISIS-MTT - I extended ERS. This
was
> necessary because ERS is
> not capable of prooving the evidence for digital signatures that do
not
> include the complete
> certificate path. 
> At the time the evidence record is generated it is not
> possible to extend
> the renewed signature with the missing certificates of the certificate
> path
> (the certificates
> field of a CMS-object in a signed field) which are necessary for the
> non-repudiation proof.
> So I integrated the certificates of the certificate path and the OCSP
> responses into the evidence
> record by exploiting the data object group feature. The renewal of a
> signed
> documents must be
> extended as follows:
> Timestamp Renewal/Inital Renewal: Before a digital signature
(CMS-Object,
> ERS-Object,...) is renewed
> a proof of its validity is performed and the data (called
> RevocationInfoArchival [RIA] and consits
> of certificates and OCSP responses) is stored within the evidence
record.
> For each certificate and
> each ocsp the hash value is computed. These hash values are sorted,
> concated and hashed again.
> This hash value (the hash value for one RIA) is treated as an ordinary
> signed document within a
> data object group.
> Hashtree Renewal: First create the RIA for the latest signature. Then
> compute the hashvalue for each
> RIA of the evidece record. Sort, concate and hash these hashvalues and
> integrate this together with
> the hashvalue of the evidence record into the hashtree using the data
> object group procedure.
> Validation: Within the validiation of an evidence record the stored
RIAs
> have to be used for all but
> the latest signature. To ensure their validity it is checked whether
the
> hashvalue appears in the
> first hashlist of the "next" archive time stamp (meeting the usual ERS
> terms as timeliness, correct
> hash algortihm, and so on).
> 
> I would be glad to hear your opinion about this soultion.
> 
> Best Regards
> Hannes Weber

Date: Mon, 05 Dec 2005 15:32:57 +0100
To: [email-masked]
From: Hannes Weber <[email-masked]>
Subject: ERS and certificates
Cc: [email-masked]
Sender: [email-masked]

Hi,
i am a student at the university of Bremen (Germany) and recently wrote my 
diploma thesis about
digital signatures in long-term archives. The aim of my work was to develop 
a library capable of
performing the long-term non-repudiation for digital signed documents in 
the context of document
management systems.

My solution relies on ERS, but in order to be able to ensure long-term 
non-repudiation for any kind
of signatures - that are conform to ISIS-MTT - I extended ERS. This was 
necessary because ERS is
not capable of prooving the evidence for digital signatures that do not 
include the complete
certificate path. At the time the evidence record is generated it is not 
possible to extend
the renewed signature with the missing certificates of the certificate path 
(the certificates
field of a CMS-object in a signed field) which are necessary for the 
non-repudiation proof.
So I integrated the certificates of the certificate path and the OCSP 
responses into the evidence
record by exploiting the data object group feature. The renewal of a signed 
documents must be
extended as follows:
Timestamp Renewal/Inital Renewal: Before a digital signature (CMS-Object, 
ERS-Object,...) is renewed
a proof of its validity is performed and the data (called 
RevocationInfoArchival [RIA] and consits
of certificates and OCSP responses) is stored within the evidence record. 
For each certificate and
each ocsp the hash value is computed. These hash values are sorted, 
concated and hashed again.
This hash value (the hash value for one RIA) is treated as an ordinary 
signed document within a
data object group.
Hashtree Renewal: First create the RIA for the latest signature. Then 
compute the hashvalue for each
RIA of the evidece record. Sort, concate and hash these hashvalues and 
integrate this together with
the hashvalue of the evidence record into the hashtree using the data 
object group procedure.
Validation: Within the validiation of an evidence record the stored RIAs 
have to be used for all but
the latest signature. To ensure their validity it is checked whether the 
hashvalue appears in the
first hashlist of the "next" archive time stamp (meeting the usual ERS 
terms as timeliness, correct
hash algortihm, and so on).

I would be glad to hear your opinion about this soultion.

Best Regards
Hannes Weber 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Comments on the draft ltrans-ers-03
Date: Sun, 4 Dec 2005 17:12:46 -0800
Sender: [email-masked]

Gentlemen,

Here is a first level review.  I have not gone into the document in any
depth nor have I actually tried to compile the ASN.1 module.

I am not on this mailing list so if you have any questions for me then you
need to respond directly to me.

Jim Schaad
Soaring Hawk Consulting.

Section 1.1 "example are" --> "example is"

Section 1.3: "An evidence record include" --> "includes"

Section 3.2 - consistancy on "hash-tree" "hash tree" "hashtree"

Appendix A   - "In this case the hash value of the CMS Object as well as the
hash value of the     content have --> "has"

Section 2.1: digestAlgorithms - is this just the OIDs of the algorithm
identifiers or does this include all of the parameters as well?

Section 2.1: field encryption in EvidenceRecord is not described in order
and in the same format.

Section 2.1: field encrytion - is this suppose to contain infomration about
re-encryption or about decryption of the fields?  There is some differences
between these.   Suggest a hint about where keys are found is included as
well in this location.

Section 3.1:  Are you restricted to a single set of parameters?  If you are
doing multiple hash operations  might one which to allow for different sets
of parameters for each of the hash operations?

Section 3.2: From my reading of the text, Figure 3 should be (h1), (h2a,
h2b, h2c), (h3) as this is the order items are in the tree above.  

Section 3.2:  There not text or reference for how grouping is done. (step 4
- place in groups and sort)

Section 3.3:  Why search in the first list rather than the entire list of
reducedHashtree?  It seems to me that it could be anyplace in the list and
still be valid.

Section 3.3: In step 3 it says that the value must be a member of the next
higher list --- WHAT LIST????? The reduction removes these from the list of
hash values.  It must be taken on faith that it is correct until you reach
the root.

Section 3.3: How does one re-construct the grouping that was created in the
production step?  Very non-obious

Section 4.1:  What does it mean for a ArchiveTimeStampSequence to be ordered
by time of timestamp?  If I run two parallel ArchiveTimeStampChains with
different hash functions and sign both at the approx the same time -- which
comes first?  Ordered by the first entry or the last entry on the chain?
There is no reason to assume that all of the entries in the second chain
occur after all of the entiries in the first chain.

Section 4.2:  It states that the hash algorithms must be the same -- how
about the hash algorithm parameters?

Section 4.2, 4.3: I have serveral issues with the algorithm that you are
using to replace a hash functions.  They are:

1) I believe that atsc(i) should be a constant for all documents.  A
document should never be deleted and then re-added, nor is a document added
during the process of renewing a timestamp.  Thus either the document has
been deleted (in which case it is not re-hashed) or it is in every
ArchiveTimeStampSequence.  Ergo - atsc(i) is constant for all values of i.

2) Verification requires that an implemenation of all previous hash
algorithms be kept is that what one wants to do?  (I.e. do you want to be
able to have a "fast" proof using just the current data).

3) What happens if only one item is left in a document group (i.e the rest
have been deleted)?  Is it treated as a document group of one or as a single
document?

Section 5.1:  The proper term is detached content rather than external
content.  Suggest "encryptionCover is a CMS content type of EnvelopedData
where the encryptedContent field is absent"

Section 5.1: Putting the private key into a BIT STRING is problematic.  I
would suggest either an OCTET STRING or an ANY DEFINED BY with the OID as
well.

Section 5.1:  I don't understand the set of parameters that you have defined
for re-encryption of the structure.  I would thing that the only thing that
you need is the ContentEncryptionKey in the clear - The rest of the
parameters are kept in the encryptionCover field.  You don't need to the
public key or the KeyEncryptionKey fields unless you are intending to
re-build the EncryptionCover field.

Section 5.1:  If you are using the EncryptedData field you need to make some
additional statements that are not required in CMS.

1) The ContentInfo field to be submitted MUST be DER encoded.
2) The encrypted content MUST be connonicalized PRIOR to being encrypted.
(i.e. ASN.1 is DER encoded, MIME uses S/MIME rules and so forth)
3) The EncryptedData RecipientInfos MUST ALL be kept intact unless the
EncryptedData field was not archived.

Section 6:  Use the correct module for CMS -- 
   CryptographicMessageSyntax2004
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

Section 6:  Add a reference comment to each of the IMPORT-ed modules -- From
[RFCXXXX] so that they can be easily found

Section 6:  ASN Errors
   id-EncryptionCMS_encryptedmessage ::= {id-ATS-1}

-- id-ATS-1 not defined

   EncryptionKeyRandom::= SEQUENCE {
      encryptionKey   OCTET STRING,
      randomValue     BIT STRING}}

-- illegal token }

Comment:  Useful to have the list name in the document so I know where to
send mail to.

---- need guidence on what happens if a key is revoked -- need to have a
second signature added before hand?