Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UEamam012910; Thu, 30 Mar 2006 07:36:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2UEamK5012909; Thu, 30 Mar 2006 07:36:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from ns1.cpanel.btnaccess.com (ns1.cpanel.btnaccess.com [205.177.121.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UEalr1012903 for <ietf-ltans@imc.org>; Thu, 30 Mar 2006 07:36:47 -0700 (MST) (envelope-from robholliday@isocore.com)
Message-Id: <200603301436.k2UEalr1012903@balder-227.proper.com>
Received: from [65.213.193.6] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FOyGT-00065Y-Ty for ietf-ltans@imc.org; Thu, 30 Mar 2006 09:36:45 -0500
From: "Robert Holliday" <robholliday@isocore.com>
To: <ietf-ltans@imc.org>
Subject: ICNS 2006: Early Registration Ends April 1
Date: Thu, 30 Mar 2006 09:36:41 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C653DD.73C13EC0"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcZUB1xDp+6pv9IxSJCBvmmbjf1Bkw==
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - isocore.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C653DD.73C13EC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

International Conference on Network Security 2006, April 17-19, Reston,
Virginia

 

Only a few days remain to take advantage of Early Bird Specials when
registering for ICNS2006.  All those registering before April 1 receive will
receive a $200 dollar discount.  Don't miss out on the chance to interact
with industry leaders in a personal setting and unique format.

 

Technical Program: http://www.isocore.com/networksecurity2006/program.htm 

 

Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm

 


------=_NextPart_000_0015_01C653DD.73C13EC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<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;}
span.EmailStyle17
	{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>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span class=3Dtexte><b><font size=3D2 color=3Dblue =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial;color:blue;font-weight:
bold'>International Conference on Network Security 2006, April 17-19, =
Reston, Virginia</span></font></b></span></p>

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

<p class=3DMsoNormal><span class=3Dtexte><font size=3D2 =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial'>Only a few days remain to =
take
advantage of Early Bird Specials when registering for ICNS2006.&nbsp; =
All those
registering before April 1 receive will receive a $200 dollar =
discount.&nbsp;
Don&#8217;t miss out on the chance to interact with industry leaders in =
a
personal setting and unique format.</span></font></span></p>

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

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Technical =
Program:</span></font></b><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <a
href=3D"http://www.isocore.com/networksecurity2006/program.htm">http://ww=
w.isocore.com/networksecurity2006/program.htm</a>
</span></font></p>

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

<p class=3DMsoNormal><span class=3Dtexte><b><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold'>Registratio=
n:</span></font></b></span><span
class=3Dtexte><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:Arial'> <a
href=3D"http://www.isocore.com/networksecurity2006/onlineregis.htm">http:=
//www.isocore.com/networksecurity2006/onlineregis.htm</a></span></font></=
span></p>

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

</div>

</body>

</html>

------=_NextPart_000_0015_01C653DD.73C13EC0--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S7eujd048284; Tue, 28 Mar 2006 00:40:56 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S7euN6048283; Tue, 28 Mar 2006 00:40:56 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S7eskP048277 for <ietf-ltans@imc.org>; Tue, 28 Mar 2006 00:40:55 -0700 (MST) (envelope-from reiglmai@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2S7eoLt020393; Tue, 28 Mar 2006 09:40:51 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6523A.EF13257E"
Subject: RE: ERS tagging
Date: Tue, 28 Mar 2006 09:40:49 +0200
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680D8CB5@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS tagging
Thread-Index: AcZQFgrSl9kavaonQYSGQjNRbfXG3wCI9t2g
From: "Robert Eiglmaier" <reiglmai@opentext.com>
To: "Peter Sylvester" <Peter.Sylvester@edelweb.fr>, "Carl Wallace" <cwallace@orionsec.com>
Cc: <ietf-ltans@imc.org>
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

Thank you guys for the detailed responses, I appreciate them a lot!
=20
Robert
=20

	-----Original Message-----
	From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr]=20
	Sent: Samstag, 25. M=E4rz 2006 15:09
	To: Robert Eiglmaier
	Cc: Carl Wallace; ietf-ltans@imc.org; Tobias Gondrom; Susanne Okunick; =
Thomas Kunz
	Subject: Re: ERS tagging
	=20
	...
	=20
	 Yes. Whereever IMPLICIT would be possible syntactically, it is assumed =
asa soon
	as you mention it in the module IMPLICIT TAG
	=20
	...
=09

=20

=09
	-----Original Message-----
	From: Carl Wallace [mailto:cwallace@orionsec.com]=20
	Sent: Freitag, 24. M=E4rz 2006 17:12
	To: Robert Eiglmaier
	Cc: ietf-ltans@imc.org; Tobias Gondrom; Susanne Okunick; Thomas Kunz
	Subject: RE: ERS tagging
	=20
	...
=09

	As I read these, IMPLICIT is correct in this case.  Of course, we could
	simply put an EXPLICIT on the definition as below and eliminate
	potential confusion.  (I'd still prefer to see the nested sequences
	factored out into types.)
=09
	 ...
	=20


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><SPAN class=3D695253307-28032006><FONT face=3DArial color=3D#800080 =
size=3D2>Thank=20
you guys for the detailed responses, I appreciate them a=20
lot!</FONT></SPAN></DIV>
<DIV><SPAN class=3D695253307-28032006><FONT face=3DArial color=3D#800080 =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D695253307-28032006><FONT face=3DArial color=3D#800080 =

size=3D2>Robert</FONT></SPAN></DIV>
<DIV><SPAN class=3D695253307-28032006><FONT face=3DArial color=3D#800080 =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Peter Sylvester=20
  [mailto:Peter.Sylvester@edelweb.fr] <BR><B>Sent:</B> Samstag, 25. =
M=E4rz 2006=20
  15:09<BR><B>To:</B> Robert Eiglmaier<BR><B>Cc:</B> Carl Wallace;=20
  ietf-ltans@imc.org; Tobias Gondrom; Susanne Okunick; Thomas=20
  Kunz<BR><B>Subject:</B> Re: ERS tagging<BR><SPAN=20
  class=3D695253307-28032006><FONT face=3DArial=20
  color=3D#800080>&nbsp;</FONT></SPAN></FONT></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2><SPAN class=3D695253307-28032006><FONT =
face=3DArial=20
  color=3D#800080>...</FONT></SPAN></DIV></FONT>
  <DIV><SPAN class=3D695253307-28032006><FONT face=3DArial =
color=3D#800080=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D695253307-28032006>&nbsp;</SPAN>Yes. Whereever =
IMPLICIT would=20
  be possible syntactically, it is assumed asa soon<BR>as you mention it =
in the=20
  module IMPLICIT TAG<BR><SPAN class=3D695253307-28032006><FONT =
face=3DArial=20
  color=3D#800080 size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D695253307-28032006>...</SPAN></FONT></DIV><FONT face=3DArial=20
color=3D#800080></BLOCKQUOTE>
<DIV dir=3Dltr>
<DIV><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV><FONT color=3D#000000 size=3D2></FONT></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma color=3D#000000 size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
  Carl Wallace [mailto:cwallace@orionsec.com] <BR><B>Sent:</B> Freitag, =
24. M=E4rz=20
  2006 17:12<BR><B>To:</B> Robert Eiglmaier<BR><B>Cc:</B> =
ietf-ltans@imc.org;=20
  Tobias Gondrom; Susanne Okunick; Thomas Kunz<BR><B>Subject:</B> RE: =
ERS=20
  tagging<BR><SPAN class=3D695253307-28032006><FONT face=3DArial=20
  color=3D#800080>&nbsp;</FONT></SPAN></FONT></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma color=3D#000000 size=3D2><SPAN =
class=3D695253307-28032006><FONT=20
  face=3DArial color=3D#800080>...</FONT></SPAN></FONT></DIV><FONT =
color=3D#800080=20
  size=3D2><SPAN class=3D695253307-28032006></SPAN></FONT><FONT =
color=3D#000000>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><BR><FONT=20
  size=3D2>As I read these, IMPLICIT is correct in this case.&nbsp; Of =
course, we=20
  could<BR>simply put an EXPLICIT on the definition as below and=20
  eliminate<BR>potential confusion.&nbsp; (I'd still prefer to see the =
nested=20
  sequences<BR>factored out into types.)<BR><BR><SPAN=20
  class=3D695253307-28032006><FONT=20
  color=3D#800080>&nbsp;...</FONT></SPAN></FONT></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  size=3D2><SPAN=20
class=3D695253307-28032006>&nbsp;</SPAN></FONT></DIV></FONT></BLOCKQUOTE>=
</FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C6523A.EF13257E--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RI5D9I025817; Mon, 27 Mar 2006 11:05:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RI5DOx025814; Mon, 27 Mar 2006 11:05:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RI5B1f025786; Mon, 27 Mar 2006 11:05:12 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr)
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k2RI5Ai00993; Mon, 27 Mar 2006 20:05:10 +0200 (MEST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Mon, 27 Mar 2006 20:05:10 +0200 (MET DST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA17280; Mon, 27 Mar 2006 20:05:09 +0200 (MET DST)
Message-ID: <442828F9.7010205@edelweb.fr>
Date: Mon, 27 Mar 2006 20:03:37 +0200
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: ietf-ltans@imc.org, ietf-pkix@imc.org
Subject: EdelWeb Timestamping updated
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606030202010403010602"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

--------------ms090606030202010403010602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

First, please excuse the misuse of this list.

After more than 5 years, we updated our time stamping service.
and we are looking for some external testers. I
If you have a time stamping client, feel free to look at 

    http://timestamping.edelweb.fr

Peter Sylvester

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------ms090606030202010403010602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMzI3MTgwMzM3WjAjBgkqhkiG9w0B
CQQxFgQU8ejZRgp6yDvRRT8UYR8AjmicTacwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAd8nrodzfm+utaVfN
np6W7KsyyO1UfjDtzvF9SxRdcac3pzmYdABt/zzWsseJocsPwlCJcAL5eJyS+a13H/7jVVNR
aBCnMuRWwitJQsA5FV6ZeByx77QGX4EqizmZdAzhLBqeIiD5FmjAr5BlN+RmVkO+pSNcAsMj
zCedE4uHsDMAAAAAAAA=
--------------ms090606030202010403010602--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2PEBQLW034273; Sat, 25 Mar 2006 07:11:26 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2PEBQHI034272; Sat, 25 Mar 2006 07:11:26 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2PEBO8h034258 for <ietf-ltans@imc.org>; Sat, 25 Mar 2006 07:11:25 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr)
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k2PEAdi19019; Sat, 25 Mar 2006 15:10:39 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Sat, 25 Mar 2006 15:10:39 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA15435; Sat, 25 Mar 2006 15:10:38 +0100 (MET)
Message-ID: <44254F02.10001@edelweb.fr>
Date: Sat, 25 Mar 2006 15:09:06 +0100
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: Robert Eiglmaier <reiglmai@opentext.com>
CC: Carl Wallace <cwallace@orionsec.com>, ietf-ltans@imc.org, Tobias Gondrom <tgondrom@opentext.com>, Susanne Okunick <susanne.okunick@sit.fraunhofer.de>, Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
Subject: Re: ERS tagging
References: <2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net>
In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030708060001010602020102"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

--------------ms030708060001010602020102
Content-Type: multipart/alternative;
 boundary="------------050400010605060107040004"

This is a multi-part message in MIME format.
--------------050400010605060107040004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


>> reducedHashtree   [0] ReducedHashtree OPTIONAL
>>     
> is an example of an optional structure. [0] helps the parser detect whether or
> not a reducedHashtree is present.
>   
Just giving one line is not correct. The elements that follow the reason 
why you
might need a context tag.

Context [ ] tags are used in order to disambiguate situations as

     ambiguouscomplex ::= SEQUENCE {  re REAL OPTIONAL, im REAL OPTIONAL}

     complex ::= SEQUENCE {  re REAL OPTIONAL, im [0] REAL OPTIONAL}

having said this, this does not give enough information abut the actual 
encoding of the
imaginary part, since one also has to take into account the value for 
the TAGS setting
of the module which in the case of ERS is IMPLICIT.

I recommend that we add at the beginning of the document, at the end of 
the introduction,
so one does not have to read the asn.1 module first before being able to 
understand the
syntaxes in chapter 2, 3 ...

something like:

This document defines an ASN.1 module containing syntaxes for (list X Y 
Z). All syntaxes
are assumed to be qualified with a default tagging of IMPLICIT as 
indicated with the module
specification

   ERS
   {iso(1) identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) id-mod(0) id-mod-ers(4711) }

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN 


The mulues exports

   -- EXPORTS ALL --


sdo we really want to export everything

and imports the following structures.

   IMPORTS
     TimeStampToken
   FROM PKIXTSP -- [RFC3161]
           {iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13) }

   ContentInfo
   FROM CryptographicMessageSyntax2004 -- FROM [RFC3852]
        { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

   AlgorithmIdentifier FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                      module(1) authenticationFramework(7) 3 }
 ;



>   
   ArchiveTimeStamp ::= SEQUENCE {
      digestAlgorithm    AlgorithmIdentifier,
      reducedHashtree   [0] SEQUENCE OF {SEQUENCE OF OCTET STRING }
                                                           OPTIONAL,
      timeStamp         ContentInfo}


on needs indeed a tag to disambiguate the syntax in the sense of ASN.1 
where you
are not allowed to do any lookahead. See also below, since this syntax is
not the current one in draft 5
>> HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING
>> ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup
>>     
> both contain no OPTIONAL data, at least 1 element must be contained.
>
> Does the fact that reducedHashtree appears somewhere in this IMPLICIT TAGS block:
>
> DEFINITIONS IMPLICIT TAGS ::=
> BEGIN
>    ...
>    ArchiveTimeStamp ::= SEQUENCE {
>      digestAlgorithm    AlgorithmIdentifier,
>      reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
>    ...
> END
>
> ... mean that everything has to be tagged IMPLICIT?
>   
Yes. Whereever IMPLICIT would be possible syntactically, it is assumed 
asa soon
as you mention it in the module IMPLICIT TAG
> Then why don't we also make the HashGroup implicitely tagged?
>   

Do you mean to change the syntax to:

reducedHashtree   [0] SEQUENCE OF [0] SEQUENCE OF OCTET STRING


Why would you want to do that? You may, for fun ...
> 003D A0   FC:           [0] { --       [0] SEQUENCE OF 
> 0040 30   42:             [0] { --       [0] SEQUENCE OF OCTET STRING
>   
but then the encoding 30 42    does not match with [0] SEQUENCE ..  if 
would be another A0 42
and all other sequences similar. But here there is no need to 
disambiguate anything.                                                 
> 0042 04   14:               OCTET STRING
>             :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA 44 8E B0
>             :                 22 1D 39 D9
> 0058 04   14:               OCTET STRING
>             :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61 FC D9 E6
>             :                 22 65 1A D2
> 006E 04   14:               OCTET STRING
>             :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7 74 34 16
>             :                 A3 40 F7 EE
>             :               }
>
> Conclusion: I still don't know which way is the correct one.
>   
A correct one is anything you specify in the syntax that give a 
non-ambiguous syntax.
> Any hints would be gladly appreciated, especially those containing references
> to official specifications!
>   
Wouldn't ASN.1 be sufficient?

> Kind regards
>
> Robert
>
>
>
>
> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
> Sent: Freitag, 24. März 2006 14:07
> To: Tobias Gondrom; Susanne Okunick; Thomas Kunz
> Cc: ietf-ltans@imc.org
> Subject: RE: ERS tagging
>
>
>
> Tobias,
>
> I think the field in question should be encoded as below.  The initial
> SEQUENCE OF tag should be masked by the IMPLICIT [0] tag. 
>   
Looks like.
> 003D A0   FC:           [0] {	--				[0] SEQUENCE OF 
> 0040 30   42:             SEQUENCE {	-- 		SEQUENCE OF OCTET STRING
> 0042 04   14:               OCTET STRING
>             :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA 44 8E B0
>             :                 22 1D 39 D9
> 0058 04   14:               OCTET STRING
>             :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61 FC D9 E6
>             :                 22 65 1A D2
> 006E 04   14:               OCTET STRING
>             :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7 74 34 16
>             :                 A3 40 F7 EE
>             :               }
> 0084 30   2C:             SEQUENCE {
> 0086 04   14:               OCTET STRING
>             :                 B8 37 FB D6 1B 1C 82 64 4F D1 96 89 2C F9 FB 1E
>             :                 E1 6A 24 73
> 009C 04   14:               OCTET STRING
>             :                 46 D8 FC 30 3B ED 6C FA 43 3E 8F 09 14 6A CC 2F
>             :                 2C 32 A5 1C
>             :               }
>                           <snip>
>             :             }
>             :           } 
>
> For clarity, the structure might be re-written as follows:
>
> 	HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING
> 	ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup
>
> 	ArchiveTimeStamp ::= SEQUENCE {
> 	 digestAlgorithm    AlgorithmIdentifier OPTIONAL,
> 	 reducedHashtree   [0] ReducedHashtree OPTIONAL,
> 	 timeStamp         ContentInfo}
>   
Oh, the recent change to make the digest algorttm optional makes the
this syntax is ambiguous, since both Contentinfo and AlgorithmIdenifier
are starting with the same tag.

ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm    AlgorithmIdentifier OPTIONAL,
     reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
                                                         OPTIONAL,
     timeStamp         [1] ContentInfo}

or 

ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm   [0] AlgorithmIdentifier OPTIONAL,
     reducedHashtree   [1] SEQUENCE OF SEQUENCE OF OCTET STRING
                                                         OPTIONAL,
     timeStamp         ContentInfo}


or

ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm   [4711] AlgorithmIdentifier OPTIONAL,
     reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
                                                         OPTIONAL,
     timeStamp         ContentInfo}


>
>   
Please also correct the following, i.e. import it from the

IMPORT

 AlgorithmIdentifier FROM AI ;

i.e. import it from the

CMSEncryptionParams

FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                      module(1) authenticationFramework(7) 3 }


Please also define the object identifier for id-ERS-1, i.e. choose
a better name for it and define it locally.

Have fun.
Peter.


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 


--------------050400010605060107040004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">reducedHashtree   [0] ReducedHashtree OPTIONAL
    </pre>
  </blockquote>
  <pre wrap=""><!---->is an example of an optional structure. [0] helps the parser detect whether or
not a reducedHashtree is present.
  </pre>
</blockquote>
Just giving one line is not correct. The elements that follow the
reason why you<br>
might need a context tag. <br>
<br>
Context [ ] tags are used in order to disambiguate situations as<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; ambiguouscomplex ::= SEQUENCE {&nbsp; re REAL OPTIONAL, im REAL
OPTIONAL}<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; complex ::= SEQUENCE {&nbsp; re REAL OPTIONAL, im [0] REAL OPTIONAL}<br>
<br>
having said this, this does not give enough information abut the actual
encoding of the <br>
imaginary part, since one also has to take into account the value for
the TAGS setting <br>
of the module which in the case of ERS is IMPLICIT.<br>
<br>
I recommend that we add at the beginning of the document, at the end of
the introduction,<br>
so one does not have to read the asn.1 module first before being able
to understand the<br>
syntaxes in chapter 2, 3 ...<br>
<br>
something like: <br>
<br>
This document defines an ASN.1 module containing syntaxes for (list X Y
Z). All syntaxes<br>
are assumed to be qualified with a default tagging of IMPLICIT as
indicated with the module<br>
specification<br>
<br>
<pre>   ERS
   {iso(1) identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) id-mod(0) id-mod-ers(4711) }

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN 
</pre>
<br>
The mulues exports<br>
<pre>   -- EXPORTS ALL --</pre>
<br>
sdo we really want to export everything<br>
<br>
and imports the following structures.<br>
<pre>
   IMPORTS
     TimeStampToken
   FROM PKIXTSP -- [RFC3161]
           {iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13) }

   ContentInfo
   FROM CryptographicMessageSyntax2004 -- FROM [RFC3852]
        { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

   AlgorithmIdentifier FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                      module(1) authenticationFramework(7) 3 }
 ;


</pre>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap="">
  </pre>
</blockquote>
<pre>   ArchiveTimeStamp ::= SEQUENCE {
      digestAlgorithm    AlgorithmIdentifier,
      reducedHashtree   [0] SEQUENCE OF {SEQUENCE OF OCTET STRING }
                                                           OPTIONAL,
      timeStamp         ContentInfo}

</pre>
on needs indeed a tag to disambiguate the syntax in the sense of ASN.1
where you<br>
are not allowed to do any lookahead. See also below, since this syntax
is<br>
not the current one in draft 5<br>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING
ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup
    </pre>
  </blockquote>
  <pre wrap=""><!---->both contain no OPTIONAL data, at least 1 element must be contained.

Does the fact that reducedHashtree appears somewhere in this IMPLICIT TAGS block:

DEFINITIONS IMPLICIT TAGS ::=
BEGIN
   ...
   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm    AlgorithmIdentifier,
     reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
   ...
END

... mean that everything has to be tagged IMPLICIT?
  </pre>
</blockquote>
Yes. Whereever IMPLICIT would be possible syntactically, it is assumed
asa soon<br>
as you mention it in the module IMPLICIT TAG<br>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap="">Then why don't we also make the HashGroup implicitely tagged?
  </pre>
</blockquote>
<br>
Do you mean to change the syntax to: <br>
<pre wrap="">reducedHashtree   [0] SEQUENCE OF [0] SEQUENCE OF OCTET STRING

</pre>
Why would you want to do that? You may, for fun ...<br>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap="">003D A0   FC:           [0] { --       [0] SEQUENCE OF 
0040 30   42:             [0] { --       [0] SEQUENCE OF OCTET STRING
  </pre>
</blockquote>
but then the encoding 30 42 &nbsp;&nbsp; does not match with [0] SEQUENCE ..&nbsp; if
would be another A0 42 <br>
and all other sequences similar. But here there is no need to
disambiguate anything.&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap="">0042 04   14:               OCTET STRING
            :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA 44 8E B0
            :                 22 1D 39 D9
0058 04   14:               OCTET STRING
            :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61 FC D9 E6
            :                 22 65 1A D2
006E 04   14:               OCTET STRING
            :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7 74 34 16
            :                 A3 40 F7 EE
            :               }

Conclusion: I still don't know which way is the correct one.
  </pre>
</blockquote>
A correct one is anything you specify in the syntax that give a
non-ambiguous syntax.<br>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap="">
Any hints would be gladly appreciated, especially those containing references
to official specifications!
  </pre>
</blockquote>
Wouldn't ASN.1 be sufficient? <br>
<br>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap="">
Kind regards

Robert




-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-ietf-ltans@mail.imc.org">owner-ietf-ltans@mail.imc.org</a> [<a class="moz-txt-link-freetext" href="mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mail.imc.org</a>] On Behalf Of Carl Wallace
Sent: Freitag, 24. M&auml;rz 2006 14:07
To: Tobias Gondrom; Susanne Okunick; Thomas Kunz
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ietf-ltans@imc.org">ietf-ltans@imc.org</a>
Subject: RE: ERS tagging



Tobias,

I think the field in question should be encoded as below.  The initial
SEQUENCE OF tag should be masked by the IMPLICIT [0] tag. 
  </pre>
</blockquote>
Looks like.<br>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap="">
003D A0   FC:           [0] {	--				[0] SEQUENCE OF 
0040 30   42:             SEQUENCE {	-- 		SEQUENCE OF OCTET STRING
0042 04   14:               OCTET STRING
            :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA 44 8E B0
            :                 22 1D 39 D9
0058 04   14:               OCTET STRING
            :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61 FC D9 E6
            :                 22 65 1A D2
006E 04   14:               OCTET STRING
            :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7 74 34 16
            :                 A3 40 F7 EE
            :               }
0084 30   2C:             SEQUENCE {
0086 04   14:               OCTET STRING
            :                 B8 37 FB D6 1B 1C 82 64 4F D1 96 89 2C F9 FB 1E
            :                 E1 6A 24 73
009C 04   14:               OCTET STRING
            :                 46 D8 FC 30 3B ED 6C FA 43 3E 8F 09 14 6A CC 2F
            :                 2C 32 A5 1C
            :               }
                          &lt;snip&gt;
            :             }
            :           } 

For clarity, the structure might be re-written as follows:

	HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING
	ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup

	ArchiveTimeStamp ::= SEQUENCE {
	 digestAlgorithm    AlgorithmIdentifier OPTIONAL,
	 reducedHashtree   [0] ReducedHashtree OPTIONAL,
	 timeStamp         ContentInfo}
  </pre>
</blockquote>
Oh, the recent change to make the digest algorttm optional makes the<br>
this syntax is ambiguous, since both Contentinfo and AlgorithmIdenifier<br>
are starting with the same tag. <br>
<pre>ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm    AlgorithmIdentifier OPTIONAL,
     reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
                                                         OPTIONAL,
     timeStamp         [1] ContentInfo}

or 
</pre>
<pre>ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm   [0] AlgorithmIdentifier OPTIONAL,
     reducedHashtree   [1] SEQUENCE OF SEQUENCE OF OCTET STRING
                                                         OPTIONAL,
     timeStamp         ContentInfo}

</pre>
or <br>
<pre>ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm   [4711] AlgorithmIdentifier OPTIONAL,
     reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
                                                         OPTIONAL,
     timeStamp         ContentInfo}

</pre>
<blockquote
 cite="mid2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net"
 type="cite">
  <pre wrap="">

  </pre>
</blockquote>
Please also correct the following, i.e. import it from the <br>
<br>
<pre>IMPORT</pre>
<pre> AlgorithmIdentifier FROM AI ;</pre>
i.e. import it from the <br>
<pre>CMSEncryptionParams</pre>
<pre>FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                      module(1) authenticationFramework(7) 3 }</pre>
<br>
Please also define the object identifier for id-ERS-1, i.e. choose<br>
a better name for it and define it locally. <br>
<br>
Have fun.<br>
Peter.<br>
<br>
<br>
<pre class="moz-signature" cols="100000">-- 
To verify the signature, see <a class="moz-txt-link-freetext" href="http://edelpki.edelweb.fr/">http://edelpki.edelweb.fr/</a> 
Cela vous permet de charger le certificat de l'autorit&eacute;; 
die Liste mit zur&uuml;ckgerufenen Zertifikaten finden Sie da auch. 
</pre>
</body>
</html>

--------------050400010605060107040004--

--------------ms030708060001010602020102
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMzI1MTQwOTA2WjAjBgkqhkiG9w0B
CQQxFgQU0AjS2di/VgfGiT+PBhcS0HrtLa4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAl5DYe3XVbOA2hCzH
pN7nsXtvnYgl9IyZy31ySj1/kndGfdQVocyq82Tm0i2IqzvSJ51Iwwc+STJvOXIYX1xMrKZV
jN8DiOKHfqe8JyOP9q8NQWCOTX0/40+dSBeRmRm9WyyP43VLYVvM1bVrywYyC5EB8MBwbeLW
9/XoJno2/RMAAAAAAAA=
--------------ms030708060001010602020102--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OGCMv4063287; Fri, 24 Mar 2006 09:12:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OGCMjC063286; Fri, 24 Mar 2006 09:12:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OGCMSQ063278 for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 09:12:22 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: ERS tagging
Date: Fri, 24 Mar 2006 08:12:10 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901DEA560@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS tagging
thread-index: AcZMI3A3NxoNF7pDSmy+vsm/pS6tOgDAUOngAAeNIPAAA/EvkAACCFaw
From: "Carl Wallace" <cwallace@orionsec.com>
To: "Robert Eiglmaier" <reiglmai@opentext.com>
Cc: <ietf-ltans@imc.org>, "Tobias Gondrom" <tgondrom@opentext.com>, "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>, "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2OGCMSQ063281
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

<snip>
> 
> Does the fact that reducedHashtree appears somewhere in this 
> IMPLICIT TAGS block:
> 
> DEFINITIONS IMPLICIT TAGS ::=
> BEGIN
>    ...
>    ArchiveTimeStamp ::= SEQUENCE {
>      digestAlgorithm    AlgorithmIdentifier,
>      reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
>    ...
> END
> 
> ... mean that everything has to be tagged IMPLICIT?

When the module defaults to IMPLICIT, everything with a context specific
tag is tagged implicitly with a few exceptions.  If the definition
includes an EXPLICIT indication, then the tag is explicitly encoded.  If
the type tagged with the context tag is a CHOICE then it is encoded
explicitly.  The question here is whether or not there is another rule
that forces the tag to be explcit.  We polled the room during the WG
session on Monday and there was agreement that it should be implicitly
encoded.

> Then why don't we also make the HashGroup implicitely tagged?

Because it does not feature a context specific tag.

<snip>
> Conclusion: I still don't know which way is the correct one.
> 
> Any hints would be gladly appreciated, especially those 
> containing references to official specifications!

I searched through X.690 and found the following snips:

"30.6 The tagging construction specifies explicit tagging if any of the
following holds:
a) the "Tag EXPLICIT Type" alternative is used;
b) the "Tag Type" alternative is used and the value of "TagDefault" for
the module is either EXPLICIT TAGS
or is empty;
c) the "Tag Type" alternative is used and the value of "TagDefault" for
the module is IMPLICIT TAGS or
AUTOMATIC TAGS, but the type defined by "Type" is an untagged choice
type, an untagged open type, or
an untagged "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4,
8.3).

The tagging construction specifies implicit tagging otherwise."

"The only notation in this Recommendation | International Standard which
is an open type notation is the
"ObjectClassFieldType" specified in ITU-T Rec. X.681 | ISO/IEC 8824-2,
clause 14, where the "FieldName" denotes either a type field or a
variable-type value field."

As I read these, IMPLICIT is correct in this case.  Of course, we could
simply put an EXPLICIT on the definition as below and eliminate
potential confusion.  (I'd still prefer to see the nested sequences
factored out into types.)

> 	HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING
> 	ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup
> 
> 	ArchiveTimeStamp ::= SEQUENCE {
> 	 digestAlgorithm    AlgorithmIdentifier OPTIONAL,
> 	 reducedHashtree   [0] EXPLICIT ReducedHashtree OPTIONAL,
> 	 timeStamp         ContentInfo}

or

>    ...
>    ArchiveTimeStamp ::= SEQUENCE {
>      digestAlgorithm    AlgorithmIdentifier,
>      reducedHashtree   [0] EXPLICIT SEQUENCE OF SEQUENCE OF OCTET
STRING
>    ...




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OFMEBG061023; Fri, 24 Mar 2006 08:22:14 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OFMELN061022; Fri, 24 Mar 2006 08:22:14 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OFMChg061015 for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 08:22:13 -0700 (MST) (envelope-from reiglmai@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2OFMAS3003541; Fri, 24 Mar 2006 16:22:10 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: ERS tagging
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 24 Mar 2006 16:22:09 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680D8CAB@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS tagging
Thread-Index: AcZMI3A3NxoNF7pDSmy+vsm/pS6tOgDAUOngAAeNIPAAA/EvkA==
From: "Robert Eiglmaier" <reiglmai@opentext.com>
To: "Carl Wallace" <cwallace@orionsec.com>
Cc: <ietf-ltans@imc.org>, "Tobias Gondrom" <tgondrom@opentext.com>, "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>, "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2OFMDhg061017
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hi Carl,

thank you very much for the details.
I'm the poor soul responsible for the code that produces these EvidenceRecord
Documents (although I didn't initially develop it).

I searched through some specifications and didn't find anything that says
which one is right and which one is wrong. (What a surprise!)

But I only found the usage of the [classnumber] IMPLICIT tag for OPTIONAL data.
"Implicit tagging is used for optional SEQUENCE components with underlying type
 other than ANY throughout PKCS"
(which doesn't exclude it from being used elsewhere...?)

> reducedHashtree   [0] ReducedHashtree OPTIONAL
is an example of an optional structure. [0] helps the parser detect whether or
not a reducedHashtree is present.

> HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING
> ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup
both contain no OPTIONAL data, at least 1 element must be contained.

Does the fact that reducedHashtree appears somewhere in this IMPLICIT TAGS block:

DEFINITIONS IMPLICIT TAGS ::=
BEGIN
   ...
   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm    AlgorithmIdentifier,
     reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
   ...
END

... mean that everything has to be tagged IMPLICIT?
Then why don't we also make the HashGroup implicitely tagged?


003D A0   FC:           [0] { --       [0] SEQUENCE OF 
0040 30   42:             [0] { --       [0] SEQUENCE OF OCTET STRING
0042 04   14:               OCTET STRING
            :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA 44 8E B0
            :                 22 1D 39 D9
0058 04   14:               OCTET STRING
            :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61 FC D9 E6
            :                 22 65 1A D2
006E 04   14:               OCTET STRING
            :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7 74 34 16
            :                 A3 40 F7 EE
            :               }

Conclusion: I still don't know which way is the correct one.

Any hints would be gladly appreciated, especially those containing references
to official specifications!

Kind regards

Robert




-----Original Message-----
From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
Sent: Freitag, 24. März 2006 14:07
To: Tobias Gondrom; Susanne Okunick; Thomas Kunz
Cc: ietf-ltans@imc.org
Subject: RE: ERS tagging



Tobias,

I think the field in question should be encoded as below.  The initial
SEQUENCE OF tag should be masked by the IMPLICIT [0] tag. 

003D A0   FC:           [0] {	--				[0] SEQUENCE OF 
0040 30   42:             SEQUENCE {	-- 		SEQUENCE OF OCTET STRING
0042 04   14:               OCTET STRING
            :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA 44 8E B0
            :                 22 1D 39 D9
0058 04   14:               OCTET STRING
            :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61 FC D9 E6
            :                 22 65 1A D2
006E 04   14:               OCTET STRING
            :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7 74 34 16
            :                 A3 40 F7 EE
            :               }
0084 30   2C:             SEQUENCE {
0086 04   14:               OCTET STRING
            :                 B8 37 FB D6 1B 1C 82 64 4F D1 96 89 2C F9 FB 1E
            :                 E1 6A 24 73
009C 04   14:               OCTET STRING
            :                 46 D8 FC 30 3B ED 6C FA 43 3E 8F 09 14 6A CC 2F
            :                 2C 32 A5 1C
            :               }
                          <snip>
            :             }
            :           } 

For clarity, the structure might be re-written as follows:

	HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING
	ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup

	ArchiveTimeStamp ::= SEQUENCE {
	 digestAlgorithm    AlgorithmIdentifier OPTIONAL,
	 reducedHashtree   [0] ReducedHashtree OPTIONAL,
	 timeStamp         ContentInfo}




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OD7C3v054164; Fri, 24 Mar 2006 06:07:12 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OD7CFx054163; Fri, 24 Mar 2006 06:07:12 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OD79vg054154 for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 06:07:12 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: ERS tagging
Date: Fri, 24 Mar 2006 05:07:00 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901DEA2B3@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS tagging
thread-index: AcZMI3A3NxoNF7pDSmy+vsm/pS6tOgDAUOngAAeNIPA=
From: "Carl Wallace" <cwallace@orionsec.com>
To: "Tobias Gondrom" <tgondrom@opentext.com>, "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>, "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2OD7Cvg054158
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Tobias,

I think the field in question should be encoded as below.  The initial
SEQUENCE OF tag should be masked by the IMPLICIT [0] tag. 

003D A0   FC:           [0] {	--				[0]
SEQUENCE OF 
0040 30   42:             SEQUENCE {	-- 		SEQUENCE OF
OCTET STRING
0042 04   14:               OCTET STRING
            :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA 44
8E B0
            :                 22 1D 39 D9
0058 04   14:               OCTET STRING
            :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61 FC
D9 E6
            :                 22 65 1A D2
006E 04   14:               OCTET STRING
            :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7 74
34 16
            :                 A3 40 F7 EE
            :               }
0084 30   2C:             SEQUENCE {
0086 04   14:               OCTET STRING
            :                 B8 37 FB D6 1B 1C 82 64 4F D1 96 89 2C F9
FB 1E
            :                 E1 6A 24 73
009C 04   14:               OCTET STRING
            :                 46 D8 FC 30 3B ED 6C FA 43 3E 8F 09 14 6A
CC 2F
            :                 2C 32 A5 1C
            :               }
                          <snip>
            :             }
            :           } 

For clarity, the structure might be re-written as follows:

	HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING
	ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup

	ArchiveTimeStamp ::= SEQUENCE {
	 digestAlgorithm    AlgorithmIdentifier OPTIONAL,
	 reducedHashtree   [0] ReducedHashtree OPTIONAL,
	 timeStamp         ContentInfo}

> -----Original Message-----
> From: Tobias Gondrom [mailto:tgondrom@opentext.com] 
> Sent: Friday, March 24, 2006 4:33 AM
> To: Carl Wallace; Susanne Okunick; Thomas Kunz
> Cc: ietf-ltans@imc.org
> Subject: RE: ERS tagging
> Importance: High
> 
> Hello Carl,
> 
> I talked with my colleague and am not sure I understand the problem.
> He also mentioned that he recalls that the documents we 
> received from the other vendor (FHG) also implemented this 
> kind of encoding independently from us (@FHG: but of course I 
> may be wrong here).
> 
> I assume you see the problem in 003A and 0040?
> 
> The module from the spec defines reducedHashtree as: 
> reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
>                                                          OPTIONAL,
> 
> 
> So it looks correct for me, but probably my encoding skills 
> got meanwhile quite rusty. :-(
> 
> @Carl: could you maybe explain this a bit more and/or present 
> an example how you think it should have been encoded.
> 
> @Susanne and Thomas: Do you also have encoded the asn.1 the 
> same way or did I misunderstood this?
> 
> Tobias
> 
> 
> 
> 
> > -----Original Message-----
> > From: Carl Wallace [mailto:cwallace@orionsec.com]
> > Sent: Monday, March 20, 2006 2:38 PM
> > To: ietf-ltans@imc.org
> > Cc: Tobias Gondrom
> > Subject: ERS tagging
> > 
> > In the ERS example that Tobias posted a few months back 
> > (flight-ats.der), the tagging on the reducedHashtree field does not 
> > appear to be IMPLICIT.  The module has IMPLICIT tags by 
> default.  Is 
> > there an encoding rule that forces this tag to be EXPLICIT or should
> it
> > be encoded as IMPLICIT?  Here's a partially annotated excerpt from
> that
> > evidence record:
> > 
> > 0000 30 1BEE: SEQUENCE {		-- EvidenceRecord
> > 0004 02    1:   INTEGER 1		--	version
> > 0007 30   1A:   SEQUENCE {		--	digestAlgs
> > 0009 30    D:     SEQUENCE {		--		
> digestAlg
> > 000B 06    9:       OBJECT IDENTIFIER '2 16 840 1 101 3 4 2 3'
> > 0016 05    0:       NULL
> >             :       }
> > 0018 30    9:     SEQUENCE {		--		
> digestAlg
> > 001A 06    5:       OBJECT IDENTIFIER ripemd160 (1 3 36 3 2 1)
> > 0021 05    0:       NULL
> >             :       }
> >             :     }
> > 0023 30 1BCB:   SEQUENCE {		-- 	ArchiveTimestampSequence
> > 0027 30 109E:     SEQUENCE {		--
> > ArchiveTimestampChain
> > 002B 30  8CC:       SEQUENCE {	--
> ArchiveTimestamp
> > 002F 30    9:         SEQUENCE {	--
> > digestAlg
> > 0031 06    5:           OBJECT IDENTIFIER ripemd160 (1 3 36 3 2 1)
> > 0038 05    0:           NULL
> >             :           }
> > 003A A0   FF:         [0] {		--
> > reducedHashtree (first SEQ OF should be masked by [0])
> > 003D 30   FC:           SEQUENCE {	--
> > SEQ OF OCTET STRING
> > 0040 30   42:             SEQUENCE {	--
> > ???
> > 0042 04   14:               OCTET STRING
> >             :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA
> 44
> > 8E B0
> >             :                 22 1D 39 D9
> > 0058 04   14:               OCTET STRING
> >             :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61
> FC
> > D9 E6
> >             :                 22 65 1A D2
> > 006E 04   14:               OCTET STRING
> >             :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7
> 74
> > 34 16
> >             :                 A3 40 F7 EE
> >             :               }
> > 0084 30   2C:             SEQUENCE {
> > 0086 04   14:               OCTET STRING
> >             :                 B8 37 FB D6 1B 1C 82 64 4F D1 96 89 2C
> F9
> > FB 1E
> >             :                 E1 6A 24 73
> > 009C 04   14:               OCTET STRING
> >             :                 46 D8 FC 30 3B ED 6C FA 43 3E 8F 09 14
> 6A
> > CC 2F
> >             :                 2C 32 A5 1C
> >             :               }
> > 00B2 30   2C:             SEQUENCE {
> > 00B4 04   14:               OCTET STRING
> >             :                 CF 18 DD A2 1B 8D 71 D7 C4 3E 11 B6 03
> B3
> > C0 C3
> >             :                 09 98 6B D8
> > 00CA 04   14:               OCTET STRING
> >             :                 6B A0 A0 BB 6C F4 3C B7 66 5B 18 76 AB
> A9
> > DB 4F
> >             :                 90 32 56 B1
> >             :               }
> > 00E0 30   2C:             SEQUENCE {
> > 00E2 04   14:               OCTET STRING
> >             :                 C4 14 A0 0A 8E 57 9E 49 CE C5 BA AB 06
> AB
> > B5 77
> >             :                 A6 EF FE A3
> > 00F8 04   14:               OCTET STRING
> >             :                 34 13 E3 37 A9 DB FD 82 0A 32 15 50 EF
> 0B
> > F8 22
> >             :                 70 B5 E8 45
> >             :               }
> > 010E 30   2C:             SEQUENCE {
> > 0110 04   14:               OCTET STRING
> >             :                 F7 9A 6C A8 7A 7C 74 1C F4 0A EB AA A8
> 91
> > 80 55
> >             :                 F8 58 10 EA
> > 0126 04   14:               OCTET STRING '..........'
> >             :               }
> >             :             }
> >             :           }
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OA13gx045408; Fri, 24 Mar 2006 03:01:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OA138g045407; Fri, 24 Mar 2006 03:01:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mallaury.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OA11b3045292 for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 03:01:02 -0700 (MST) (envelope-from julien.stern@cryptolog.com)
Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 5EAA84F3DD for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 11:00:52 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id A3EB7440F3 for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 11:02:20 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17431-09 for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 11:02:15 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 9B1C044006 for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 11:02:14 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Fri, 24 Mar 2006 11:00:51 +0100
From: "Julien Stern" <julien.stern@cryptolog.com>
Date: Fri, 24 Mar 2006 11:00:51 +0100
To: ietf-ltans@imc.org
Subject: Re: ERS tagging
Message-ID: <20060324100046.GA6552@cryptolog.com>
Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, ietf-ltans@imc.org
References: <2666EB2A846BAC4BB2D7F593301A7868176684@MUCXGC2.opentext.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868176684@MUCXGC2.opentext.net>
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Tobias,

just wanted to let you know that we stumbled upon the same issue as Carl
Wallace (our test implementation choked on the example because of this
tag). The tag in the ASN.1 example is definitely EXPLICIT while it is
defined as IMPLICIT in the draft.

As far as I know, the only cases where one must replace an IMPLICIT
tag by an EXPLICIT tag automatically are when this tag is in front
of a CHOICE or a ANY.

Unless, there is some exotic encoding rule for SEQUENCE of SEQUENCE
which I'm not aware of, I also believe there is a minor bug in the
implementations that have produced the example.

Regards,

--
Julien


On Fri, Mar 24, 2006 at 10:32:49AM +0100, Tobias Gondrom wrote:
> 
> Hello Carl,
> 
> I talked with my colleague and am not sure I understand the problem.
> He also mentioned that he recalls that the documents we received from
> the other vendor (FHG) also implemented this kind of encoding
> independently from us (@FHG: but of course I may be wrong here).
> 
> I assume you see the problem in 003A and 0040?
> 
> The module from the spec defines reducedHashtree as: 
> reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
>                                                          OPTIONAL,
> 
> 
> So it looks correct for me, but probably my encoding skills got
> meanwhile quite rusty. :-(
> 
> @Carl: could you maybe explain this a bit more and/or present an example
> how you think it should have been encoded.
> 
> @Susanne and Thomas: Do you also have encoded the asn.1 the same way or
> did I misunderstood this?
> 
> Tobias
> 
> 
> 
> 
> > -----Original Message-----
> > From: Carl Wallace [mailto:cwallace@orionsec.com]
> > Sent: Monday, March 20, 2006 2:38 PM
> > To: ietf-ltans@imc.org
> > Cc: Tobias Gondrom
> > Subject: ERS tagging
> > 
> > In the ERS example that Tobias posted a few months back
> > (flight-ats.der), the tagging on the reducedHashtree field does not
> > appear to be IMPLICIT.  The module has IMPLICIT tags by default.  Is
> > there an encoding rule that forces this tag to be EXPLICIT or should
> it
> > be encoded as IMPLICIT?  Here's a partially annotated excerpt from
> that
> > evidence record:
> > 
> > 0000 30 1BEE: SEQUENCE {		-- EvidenceRecord
> > 0004 02    1:   INTEGER 1		--	version
> > 0007 30   1A:   SEQUENCE {		--	digestAlgs
> > 0009 30    D:     SEQUENCE {		--		digestAlg
> > 000B 06    9:       OBJECT IDENTIFIER '2 16 840 1 101 3 4 2 3'
> > 0016 05    0:       NULL
> >             :       }
> > 0018 30    9:     SEQUENCE {		--		digestAlg
> > 001A 06    5:       OBJECT IDENTIFIER ripemd160 (1 3 36 3 2 1)
> > 0021 05    0:       NULL
> >             :       }
> >             :     }
> > 0023 30 1BCB:   SEQUENCE {		-- 	ArchiveTimestampSequence
> > 0027 30 109E:     SEQUENCE {		--
> > ArchiveTimestampChain
> > 002B 30  8CC:       SEQUENCE {	--
> ArchiveTimestamp
> > 002F 30    9:         SEQUENCE {	--
> > digestAlg
> > 0031 06    5:           OBJECT IDENTIFIER ripemd160 (1 3 36 3 2 1)
> > 0038 05    0:           NULL
> >             :           }
> > 003A A0   FF:         [0] {		--
> > reducedHashtree (first SEQ OF should be masked by [0])
> > 003D 30   FC:           SEQUENCE {	--
> > SEQ OF OCTET STRING
> > 0040 30   42:             SEQUENCE {	--
> > ???
> > 0042 04   14:               OCTET STRING
> >             :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA
> 44
> > 8E B0
> >             :                 22 1D 39 D9
> > 0058 04   14:               OCTET STRING
> >             :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61
> FC
> > D9 E6
> >             :                 22 65 1A D2
> > 006E 04   14:               OCTET STRING
> >             :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7
> 74
> > 34 16
> >             :                 A3 40 F7 EE
> >             :               }
> > 0084 30   2C:             SEQUENCE {
> > 0086 04   14:               OCTET STRING
> >             :                 B8 37 FB D6 1B 1C 82 64 4F D1 96 89 2C
> F9
> > FB 1E
> >             :                 E1 6A 24 73
> > 009C 04   14:               OCTET STRING
> >             :                 46 D8 FC 30 3B ED 6C FA 43 3E 8F 09 14
> 6A
> > CC 2F
> >             :                 2C 32 A5 1C
> >             :               }
> > 00B2 30   2C:             SEQUENCE {
> > 00B4 04   14:               OCTET STRING
> >             :                 CF 18 DD A2 1B 8D 71 D7 C4 3E 11 B6 03
> B3
> > C0 C3
> >             :                 09 98 6B D8
> > 00CA 04   14:               OCTET STRING
> >             :                 6B A0 A0 BB 6C F4 3C B7 66 5B 18 76 AB
> A9
> > DB 4F
> >             :                 90 32 56 B1
> >             :               }
> > 00E0 30   2C:             SEQUENCE {
> > 00E2 04   14:               OCTET STRING
> >             :                 C4 14 A0 0A 8E 57 9E 49 CE C5 BA AB 06
> AB
> > B5 77
> >             :                 A6 EF FE A3
> > 00F8 04   14:               OCTET STRING
> >             :                 34 13 E3 37 A9 DB FD 82 0A 32 15 50 EF
> 0B
> > F8 22
> >             :                 70 B5 E8 45
> >             :               }
> > 010E 30   2C:             SEQUENCE {
> > 0110 04   14:               OCTET STRING
> >             :                 F7 9A 6C A8 7A 7C 74 1C F4 0A EB AA A8
> 91
> > 80 55
> >             :                 F8 58 10 EA
> > 0126 04   14:               OCTET STRING '..........'
> >             :               }
> >             :             }
> >             :           }
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O9WtaY043809; Fri, 24 Mar 2006 02:32:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2O9Wto7043808; Fri, 24 Mar 2006 02:32:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2O9WrOB043794 for <ietf-ltans@imc.org>; Fri, 24 Mar 2006 02:32:53 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2O9WoeF022989; Fri, 24 Mar 2006 10:32:51 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: ERS tagging
Date: Fri, 24 Mar 2006 10:32:49 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A7868176684@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS tagging
Thread-Index: AcZMI3A3NxoNF7pDSmy+vsm/pS6tOgDAUOng
X-Priority: 1
Importance: high
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Carl Wallace" <cwallace@orionsec.com>, "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>, "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2O9WsOB043795
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello Carl,

I talked with my colleague and am not sure I understand the problem.
He also mentioned that he recalls that the documents we received from
the other vendor (FHG) also implemented this kind of encoding
independently from us (@FHG: but of course I may be wrong here).

I assume you see the problem in 003A and 0040?

The module from the spec defines reducedHashtree as: 
reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING
                                                         OPTIONAL,


So it looks correct for me, but probably my encoding skills got
meanwhile quite rusty. :-(

@Carl: could you maybe explain this a bit more and/or present an example
how you think it should have been encoded.

@Susanne and Thomas: Do you also have encoded the asn.1 the same way or
did I misunderstood this?

Tobias




> -----Original Message-----
> From: Carl Wallace [mailto:cwallace@orionsec.com]
> Sent: Monday, March 20, 2006 2:38 PM
> To: ietf-ltans@imc.org
> Cc: Tobias Gondrom
> Subject: ERS tagging
> 
> In the ERS example that Tobias posted a few months back
> (flight-ats.der), the tagging on the reducedHashtree field does not
> appear to be IMPLICIT.  The module has IMPLICIT tags by default.  Is
> there an encoding rule that forces this tag to be EXPLICIT or should
it
> be encoded as IMPLICIT?  Here's a partially annotated excerpt from
that
> evidence record:
> 
> 0000 30 1BEE: SEQUENCE {		-- EvidenceRecord
> 0004 02    1:   INTEGER 1		--	version
> 0007 30   1A:   SEQUENCE {		--	digestAlgs
> 0009 30    D:     SEQUENCE {		--		digestAlg
> 000B 06    9:       OBJECT IDENTIFIER '2 16 840 1 101 3 4 2 3'
> 0016 05    0:       NULL
>             :       }
> 0018 30    9:     SEQUENCE {		--		digestAlg
> 001A 06    5:       OBJECT IDENTIFIER ripemd160 (1 3 36 3 2 1)
> 0021 05    0:       NULL
>             :       }
>             :     }
> 0023 30 1BCB:   SEQUENCE {		-- 	ArchiveTimestampSequence
> 0027 30 109E:     SEQUENCE {		--
> ArchiveTimestampChain
> 002B 30  8CC:       SEQUENCE {	--
ArchiveTimestamp
> 002F 30    9:         SEQUENCE {	--
> digestAlg
> 0031 06    5:           OBJECT IDENTIFIER ripemd160 (1 3 36 3 2 1)
> 0038 05    0:           NULL
>             :           }
> 003A A0   FF:         [0] {		--
> reducedHashtree (first SEQ OF should be masked by [0])
> 003D 30   FC:           SEQUENCE {	--
> SEQ OF OCTET STRING
> 0040 30   42:             SEQUENCE {	--
> ???
> 0042 04   14:               OCTET STRING
>             :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA
44
> 8E B0
>             :                 22 1D 39 D9
> 0058 04   14:               OCTET STRING
>             :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61
FC
> D9 E6
>             :                 22 65 1A D2
> 006E 04   14:               OCTET STRING
>             :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7
74
> 34 16
>             :                 A3 40 F7 EE
>             :               }
> 0084 30   2C:             SEQUENCE {
> 0086 04   14:               OCTET STRING
>             :                 B8 37 FB D6 1B 1C 82 64 4F D1 96 89 2C
F9
> FB 1E
>             :                 E1 6A 24 73
> 009C 04   14:               OCTET STRING
>             :                 46 D8 FC 30 3B ED 6C FA 43 3E 8F 09 14
6A
> CC 2F
>             :                 2C 32 A5 1C
>             :               }
> 00B2 30   2C:             SEQUENCE {
> 00B4 04   14:               OCTET STRING
>             :                 CF 18 DD A2 1B 8D 71 D7 C4 3E 11 B6 03
B3
> C0 C3
>             :                 09 98 6B D8
> 00CA 04   14:               OCTET STRING
>             :                 6B A0 A0 BB 6C F4 3C B7 66 5B 18 76 AB
A9
> DB 4F
>             :                 90 32 56 B1
>             :               }
> 00E0 30   2C:             SEQUENCE {
> 00E2 04   14:               OCTET STRING
>             :                 C4 14 A0 0A 8E 57 9E 49 CE C5 BA AB 06
AB
> B5 77
>             :                 A6 EF FE A3
> 00F8 04   14:               OCTET STRING
>             :                 34 13 E3 37 A9 DB FD 82 0A 32 15 50 EF
0B
> F8 22
>             :                 70 B5 E8 45
>             :               }
> 010E 30   2C:             SEQUENCE {
> 0110 04   14:               OCTET STRING
>             :                 F7 9A 6C A8 7A 7C 74 1C F4 0A EB AA A8
91
> 80 55
>             :                 F8 58 10 EA
> 0126 04   14:               OCTET STRING '..........'
>             :               }
>             :             }
>             :           }



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2NNEO2U017065; Thu, 23 Mar 2006 16:14:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2NNEOdM017064; Thu, 23 Mar 2006 16:14:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2NNENBk017058 for <ietf-ltans@imc.org>; Thu, 23 Mar 2006 16:14:23 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: LTANS summary, IETF 65
Date: Thu, 23 Mar 2006 15:14:10 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901DE9FAB@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: LTANS summary, IETF 65
thread-index: AcZOz34tplrDHu8hS0C3R2cJn8aKYA==
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>, <saag@mit.edu>
Cc: <housley@vigilsec.com>, <hartmans-ietf@mit.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2NNENBk017059
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

During the LTANS session, three drafts were discussed, WG milestones
were reset and work on notarization was suspended.

The ERS status briefing highlighted changes that will be present in the
upcoming -06 draft.  These changes primarily address clarity with regard
to the encryption mechanisms in the spec as well as support for multiple
timestamp formats.  A defect in the encoding of a sample message posted
to the mailing list was discussed.  The corresponding structure may be
refactored for clarity (without changing the wire representation of the
structures).  The specification will be submitted for WG last call upon
release.  An XML corollary may be prepared after WG last call.  No
algorithm agility issues have been noted with regard to ERS.

The LTAP specification was discussed.  A high level system design was
provided along with an abstract view of the contents of an archived data
object.  The specification currently features syntax in both XML and
ASN.1.  Work is ongoing with current focus on defining the data
necessary for archiving and ensuring lifecycle requirements are
accurately identified and addressed.  Algorithm agility will be
addressed as work on this specification progresses.

A new draft that defines directory-based mechanisms for preserving PKI
artifacts was discussed.  Coordination with the PKIX working group is
required if work defining extensions and semantics for use of an
"historical CRL" is to proceed.

The milestones for the WG will be reset.  WG Last Call for ERS will
commence immediately upon the release of version -06.  A new version of
LTAP will be produced by the end of April with WG Last Call sought by
the end of the year.  The PKI Artifact Retention and SCVP/ERS drafts
will be revised by the end of April with WG Last Call targeted for
August.  Work on notary specifications has been suspended due to lack of
interest.  Assuming these goals are achieved, the working group will
shutdown by April 2007.

A summary of action items can be found in the meeting minutes here:
http://tools.ietf.org/wg/ltans/minutes.  The Jabber log for the session
can be found here:
http://www.ietf.org/meetings/ietf-logs/ltans@rooms.jabber.ietf.org/2006-
03-20.html.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LInNKW083776; Tue, 21 Mar 2006 11:49:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LInNKu083775; Tue, 21 Mar 2006 11:49:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from advantage-security.com ([201.148.139.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LInLu5083760 for <ietf-ltans@imc.org>; Tue, 21 Mar 2006 11:49:22 -0700 (MST) (envelope-from gwerner@advantage-security.com)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C64D18.1DC8A155"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: Why are the hash values sorted?
Date: Tue, 21 Mar 2006 12:49:12 -0600
Message-ID: <1815FE0A4A30A44BA2F9E367E1B00AB13626CD@corporativo.production.local>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Why are the hash values sorted?
Thread-Index: AcZM5+EjQslSKYnmQ4ufyye8oEkCEAAKzRBA
From: "Greg Werner" <gwerner@advantage-security.com>
To: "Tilo Kienitz" <tk-tlslist@seccommerce.de>, <ietf-ltans@imc.org>
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

How about sorting the hash values in XML?

Additionally generating an RFC 3161 time stamp request (or other time =
stamp mechanism) would be simple since all one would have to do is =
generate a TSQ for the "final" document and add the TSR to the document =
itself. (greg3.exp.tsr).

The above example has the "partial" documents (testdocs.txt.sig and =
testdocs2.txt.sig) which would have: the name of the document itself, =
the data type and the content of the document (in the example is coded =
in base64). A digital signature could be added as an option. The "final" =
document (greg3.exp) would have an index of the "partial" documents, the =
name of the "partial" document and it=B4s corresponding hash.=20

We realize this example does not take many of the definitions set forth =
in the draft; we are currently modifying our application in order to do =
so.

What do you think?

Greg

-----Mensaje original-----
De: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] =
En nombre de Tilo Kienitz
Enviado el: martes, 21 de marzo de 2006 7:02
Para: ietf-ltans@imc.org
Asunto: Why are the hash values sorted?


Hello working group,

I'm afraid I'm quite late with my question, but what is the
advantage of sorting the hash values?

Paragraph "3.2. Generation" of draft-ietf-ltans-ers-05 states:
   "3.  For each data group containing more than one document, its
        respective document hashes are binary sorted in ascending
        order, concatenated and hashed."

The order of the documents in the data object group could already
have some meaning in an external application and it would be nice
if the hash tree preserved this existing order. Without the binary
sorting not only the existence of the hashes could be proven after
years but also their order.

The binary sorting is not needed to get a unique hash value, since
the reducedHashtree uses ASN-sequences. If the hash algorithm
processed the hash values in the same order in which they appear
in the sequences in the reducedHashtree then the root hash would be
uniquely determined without the need to sort anything in between.

What do you think?

Kind regards
Tilo Kienitz


--=20
Tilo Kienitz
SecCommerce Informationssysteme GmbH
Obenhauptstr. 5
D - 22335 Hamburg                       http://www.seccommerce.de
Germany


------_=_NextPart_001_01C64D18.1DC8A155
Content-Type: application/octet-stream;
	name="testdocs.txt.sig"
Content-Transfer-Encoding: base64
Content-Description: testdocs.txt.sig
Content-Disposition: attachment;
	filename="testdocs.txt.sig"

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0K
PGRvY3VtZW50IGRhdGVDcmVhdGlvbj0iMjAwNi0wMy0wNlQxNzowOTo0OC42NDMtMDY6MDAiIGRv
Y3VtZW50TmFtZT0idGVzdGRvY3MudHh0IiBkb2N1bWVudFR5cGU9InR4dCI+DQogICAgPENvbnRl
bnQ+DQogICAgICAgIDxkb2N1bWVudD5lV0ZvYjI4TkNtZHZiMmRzWlEwS2JYTnU8L2RvY3VtZW50
Pg0KICAgIDwvQ29udGVudD4NCjwvRG9jdW1lbnQ+DQoNCg==

------_=_NextPart_001_01C64D18.1DC8A155
Content-Type: application/octet-stream;
	name="greg3.exp"
Content-Transfer-Encoding: base64
Content-Description: greg3.exp
Content-Disposition: attachment;
	filename="greg3.exp"

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0K
PERhdGEgZ3JvdXAgbmFtZT0iZ3JlZzMuZXhwIj4NCiAgICA8SW5kZXg+DQogICAgICAgIDxkYXRh
IG51bWJlcj0iMCI+DQogICAgICAgICAgICA8bmFtZT50ZXN0ZG9jczIudHh0PC9uYW1lPg0KICAg
ICAgICAgICAgPGhhc2g+ZjQyOTg1MzIwNmMyMDIxZWQzN2Q3MWRlMTZlZDI3Yzg8L2hhc2g+DQog
ICAgICAgIDwvZGF0YSBudW1iZXI+DQogICAgICAgIDxkYXRhIG51bWJlcj0iMSI+DQogICAgICAg
ICAgICA8bmFtZT50ZXN0ZG9jcy50eHQ8L25hbWU+DQogICAgICAgICAgICA8aGFzaD5jZTE2ZjE0
YTYzMzBhODA1MDQ4ZjZmZmEyMjNhNTI0ZjwvaGFzaD4NCiAgICAgICAgPC9kYXRhIG51bWJlcj4N
CiAgICA8L0luZGV4Pg0KICAgIDxEYXRhU2lnbmF0dXJlIENlcnRpZmljYXRlU2VyaWFsTnVtYmVy
PSI2NTBDQ0ZDNjIyRjFCMkVDRkY1N0NCM0UyQjkyRTQxQyI+DQogICAgICAgIDxDZXJ0aWZpY2F0
ZT5NSUlFU3pDQ0E3U2dBd0lCQWdJUVpRelB4aUx4c3V6L1Y4cytLNUxrSERBTkJna3Foa2lHOXcw
QkFRUUZBRENCNHpFWE1CVUdBMVVFQ2hNT1ZtVnlhVk5wWjI0c0lFbHVZeTR4SHpBZEJnTlZCQXNU
RmxabGNtbFRhV2R1SUZSeWRYTjBJRTVsZEhkdmNtc3hRekJCQmdOVkJBc1RPbFJsY20xeklHOW1J
SFZ6WlNCaGRDQm9kSFJ3Y3pvdkwzZDNkeTUyWlhKcGMybG5iaTVqYjIwdlkzQnpMM1JsYzNSallT
OGdLR01wTURJeEh6QWRCZ05WQkFzVEZrWnZjaUJVWlhOMElGQjFjbkJ2YzJWeklFOXViSGt4UVRB
L0JnTlZCQU1UT0ZabGNtbFRhV2R1SUVOc1lYTnpJRE1nVDI1VGFYUmxJRVZ1ZEdWeWNISnBjMlVn
UVdSdGFXNXBjM1J5WVhSdmNpQkRRU0F0SUVjeU1CNFhEVEExTURZd01qQXdNREF3TUZvWERUQTJN
RFl3TWpJek5UazFPVm93Z2NneEZEQVNCZ05WQkFvVUMxVk9RVTBnVFdWNGFXTnZNUkl3RUFZRFZR
UUxGQWxUWldkMWNtbGtZV1F4UmpCRUJnTlZCQXNUUFhkM2R5NTJaWEpwYzJsbmJpNWpiMjB2Y21W
d2IzTnBkRzl5ZVM5RFVGTWdTVzVqYjNKd0xpQmllU0JTWldZdUxFeEpRVUl1VEZSRUtHTXBPVFl4
SlRBakJnTlZCQU1USEZCRlVFVWdVRVZRUlMxTlVFdEpJRU5NU1VWT1ZDMVFWVUpNU1VNeExUQXJC
Z2txaGtpRzl3MEJDUUVXSG1kM1pYSnVaWEpBWVdSMllXNTBZV2RsTFhObFkzVnlhWFI1TG1OdmJU
Q0JuekFOQmdrcWhraUc5dzBCQVFFRkFBT0JqUUF3Z1lrQ2dZRUF2bUM4V1VvMXVGZ0JYYzEvU1Vj
Q01HQ002Nk1HK3pQZUE5dzhGQTZJMldCeTI1TkcwYUZFcmxhc0xIZkdZNkc5ckNQTFdqSklzWXFm
eEZPemppZERWdUlKUlpuVTZEZWNvSlcxQUJMWmdSaDVvanNBTk5MQlBoYk5VMkF4MHp0enNNVjYv
U3ZLOFdTOU1xZGJHRTFqV3VSQ09ONHRhRHNQeGdoeGN6VVltZVVDQXdFQUFhT0NBUmN3Z2dFVE1B
a0dBMVVkRXdRQ01BQXdnYXdHQTFVZElBU0JwRENCb1RDQm5nWUxZSVpJQVliNFJRRUhGd013Z1k0
d0tBWUlLd1lCQlFVSEFnRVdIR2gwZEhCek9pOHZkM2QzTG5abGNtbHphV2R1TG1OdmJTOURVRk13
WWdZSUt3WUJCUVVIQWdJd1ZqQVZGZzVXWlhKcFUybG5iaXdnU1c1akxqQURBZ0VCR2oxV1pYSnBV
MmxuYmlkeklFTlFVeUJwYm1OdmNuQXVJR0o1SUhKbFptVnlaVzVqWlNCc2FXRmlMaUJzZEdRdUlD
aGpLVGszSUZabGNtbFRhV2R1TUJFR0NXQ0dTQUdHK0VJQkFRUUVBd0lIZ0RBd0JncGdoa2dCaHZo
RkFRWUxCQ0lXSUdOak1qTTJZbU5pWm1GaE1qRXpNREZsTVdabU1XWTJZekEyTlRRNFlUUXlNQklH
Q21DR1NBR0crRVVCQmcwRUJBTUNBd2d3RFFZSktvWklodmNOQVFFRUJRQURnWUVBYW1tNmg5azEz
N0REbm5FOHcrOUNTczBoRWEzbWR0WS9HZW5FaFpqL2RPRkVPQlVWdm8xblVVSXpTVHZjTmliR0lq
RnJOejZvWCs0dnlHY20rTE5oWGp6N2ZGUnA2QmVzaHQveThhQ3ZvcklNZHdqVCtwWXJEUUdwMjZD
U0NJWkZVbWpMRHkwOSs5eXVWL3BXOUgzZUdoWG4rU0lFa3dCdkRnUGVVdVptR1IwPTwvQ2VydGlm
aWNhdGU+DQogICAgICAgIDxTaWduYXR1cmU+b3dDMkNTN3lEVmdXRFF3bTRLZDBWc1FVNFV1bEpV
YmlSZVFCZVovQ1YyTVlOYW8xZ2IzaFFzcm04dVBTaWN0L3BGWnlXNkNlcmVZSXdsbysvZ3JYTW5o
dXBUVWM4R3VzOUNQdkNEazJLYlBDZXpVMFdWSUEwbWU5cUkzMGZSRC9icG95V2o1VkZ5MlhMWk1v
Z3U0MHAxNGI0WmtmTGFtWEliRnNIangxcTNZPTwvU2lnbmF0dXJlPg0KICAgIDwvRGF0YVNpZ25h
dHVyZT4NCjwvRGF0YSBncm91cD4NCg0K

------_=_NextPart_001_01C64D18.1DC8A155
Content-Type: application/octet-stream;
	name="greg3.exp.tsr"
Content-Transfer-Encoding: base64
Content-Description: greg3.exp.tsr
Content-Disposition: attachment;
	filename="greg3.exp.tsr"

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0K
PERvY3VtZW50IGRhdGVHZW5lcmF0aW9uPSIyMDA2LTAzLTA2VDE3OjExOjQwLjk4OC0wNjowMCIg
ZG9jdW1lbnROYW1lPSJncmVnMy5leHAiIGRvY3VtZW50VHlwZT0iZXhwIj4NCiAgICA8Q29udGVu
dD4NCiAgICAgICAgPGRvY3VtZW50PlBEOTRiV3dnZG1WeWMybHZiajBpTVM0d0lpQmxibU52Wkds
dVp6MGlWVlJHTFRnaUlITjBZVzVrWVd4dmJtVTlJbmxsY3lJL1BnbzhSWGh3WldScFpXNTBaU0Iw
YVhSMWJHODlJbWR5WldjekxtVjRjQ0krQ2lBZ0lDQThTVzVrYVdObFBnb2dJQ0FnSUNBZ0lEeGxi
blJ5WVdSaElHVjRjR1ZrYVdWdWRHVTlJakFpUGdvZ0lDQWdJQ0FnSUNBZ0lDQThibTl0WW5KbFBu
UmxjM1JrYjJOek1pNTBlSFE4TDI1dmJXSnlaVDRLSUNBZ0lDQWdJQ0FnSUNBZ1BISmxjM1Z0Wlc0
K1pqUXlPVGcxTXpJd05tTXlNREl4WldRek4yUTNNV1JsTVRabFpESTNZemc4TDNKbGMzVnRaVzQr
Q2lBZ0lDQWdJQ0FnUEM5bGJuUnlZV1JoUGdvZ0lDQWdJQ0FnSUR4bGJuUnlZV1JoSUdWNGNHVmth
V1Z1ZEdVOUlqRWlQZ29nSUNBZ0lDQWdJQ0FnSUNBOGJtOXRZbkpsUG5SbGMzUmtiMk56TG5SNGRE
d3ZibTl0WW5KbFBnb2dJQ0FnSUNBZ0lDQWdJQ0E4Y21WemRXMWxiajVqWlRFMlpqRTBZVFl6TXpC
aE9EQTFNRFE0WmpabVptRXlNak5oTlRJMFpqd3ZjbVZ6ZFcxbGJqNEtJQ0FnSUNBZ0lDQThMMlZ1
ZEhKaFpHRStDaUFnSUNBOEwwbHVaR2xqWlQ0S0lDQWdJRHhHYVhKdFlWVnpkV0Z5YVc4Z2JtOURa
WEowYVdacFkyRmtiejBpTmpVd1EwTkdRell5TWtZeFFqSkZRMFpHTlRkRFFqTkZNa0k1TWtVME1V
TWlQZ29nSUNBZ0lDQWdJRHhEWlhKMGFXWnBZMkZrYno1TlNVbEZVM3BEUTBFM1UyZEJkMGxDUVdk
SlVWcFJlbEI0YVV4NGMzVjZMMVk0Y3l0TE5VeHJTRVJCVGtKbmEzRm9hMmxIT1hjd1FrRlJVVVpC
UkVOQ05IcEZXRTFDVlVkQk1WVkZRMmhOVDFadFZubGhWazV3V2pJMGMwbEZiSFZaZVRSNFNIcEJa
RUpuVGxaQ1FYTlVSbXhhYkdOdGJGUmhWMlIxU1VaU2VXUllUakJKUlRWc1pFaGtkbU50YzNoUmVr
SkNRbWRPVmtKQmMxUlBiRkpzWTIweGVrbEhPVzFKU0ZaNldsTkNhR1JEUW05a1NGSjNZM3B2ZGt3
elpETmtlVFV5V2xoS2NHTXliRzVpYVRWcVlqSXdkbGt6UW5wTU0xSnNZek5TYWxsVE9HZExSMDF3
VFVSSmVFaDZRV1JDWjA1V1FrRnpWRVpyV25aamFVSlZXbGhPTUVsR1FqRmpia0oyWXpKV2VrbEZP
WFZpU0d0NFVWUkJMMEpuVGxaQ1FVMVVUMFphYkdOdGJGUmhWMlIxU1VWT2MxbFlUbnBKUkUxblZE
STFWR0ZZVW14SlJWWjFaRWRXZVdOSVNuQmpNbFZuVVZkU2RHRlhOWEJqTTFKNVdWaFNkbU5wUWtS
UlUwRjBTVVZqZVUxQ05GaEVWRUV4VFVSWmQwMXFRWGROUkVGM1RVWnZXRVJVUVRKTlJGbDNUV3BK
ZWs1VWF6RlBWbTkzWjJObmVFWkVRVk5DWjA1V1FrRnZWVU14Vms5UlZUQm5WRmRXTkdGWFRuWk5V
a2wzUlVGWlJGWlJVVXhHUVd4VVdsZGtNV050Ykd0WlYxRjRVbXBDUlVKblRsWkNRWE5VVUZoa00y
UjVOVEphV0Vwd1l6SnNibUpwTldwaU1qQjJZMjFXZDJJelRuQmtSemw1WlZNNVJGVkdUV2RUVnpW
cVlqTktkMHhwUW1sbFUwSlRXbGRaZFV4RmVFcFJWVWwxVkVaU1JVdEhUWEJQVkZsNFNsUkJha0pu
VGxaQ1FVMVVTRVpDUmxWRlZXZFZSVlpSVWxNeFRsVkZkRXBKUlU1TlUxVldUMVpETVZGV1ZVcE5V
MVZOZUV4VVFYSkNaMnR4YUd0cFJ6bDNNRUpEVVVWWFNHMWtNMXBZU25WYVdFcEJXVmRTTWxsWE5U
QlpWMlJzVEZoT2JGa3pWbmxoV0ZJMVRHMU9kbUpVUTBKdWVrRk9RbWRyY1docmFVYzVkekJDUVZG
RlJrRkJUMEpxVVVGM1oxbHJRMmRaUlVGMmJVTTRWMVZ2TVhWR1owSllZekV2VTFWalEwMUhRMDAy
TmsxSEszcFFaVUU1ZHpoR1FUWkpNbGRDZVRJMVRrY3dZVVpGY214aGMweElaa2RaTmtjNWNrTlFU
RmRxU2tseldYRm1lRVpQZW1wcFpFUldkVWxLVWxwdVZUWkVaV052U2xjeFFVSk1XbWRTYURWdmFu
TkJUazVNUWxCb1lrNVZNa0Y0TUhwMGVuTk5Wall2VTNaTE9GZFRPVTF4WkdKSFJURnFWM1ZTUTA5
T05IUmhSSE5RZUdkb2VHTjZWVmx0WlZWRFFYZEZRVUZoVDBOQlVtTjNaMmRGVkUxQmEwZEJNVlZr
UlhkUlEwMUJRWGRuWVhkSFFURlZaRWxCVTBKd1JFTkNiMVJEUW01bldVeFpTVnBKUVZsaU5GSlJS
VWhHZDAxM1oxazBkMHRCV1VsTGQxbENRbEZWU0VGblJWZElSMmd3WkVoQ2VrOXBPSFprTTJRelRH
NWFiR050YkhwaFYyUjFURzFPZG1KVE9VUlZSazEzV1dkWlNVdDNXVUpDVVZWSVFXZEpkMVpxUVZa
R1p6VlhXbGhLY0ZVeWJHNWlhWGRuVTFjMWFreHFRVVJCWjBWQ1Iyb3hWMXBZU25CVk1teHVZbWxr
ZWtsRlRsRlZlVUp3WW0xT2RtTnVRWFZKUjBvMVNVaEtiRnB0Vm5sYVZ6VnFXbE5DYzJGWFJtbE1h
VUp6WkVkUmRVbERhR3BMVkdzelNVWmFiR050YkZSaFYyUjFUVUpGUjBOWFEwZFRRVWRISzBWSlFr
RlJVVVZCZDBsSVowUkJkMEpuY0dkb2EyZENhSFpvUmtGUldVeENRMGxYU1VkT2FrMXFUVEpaYlU1
cFdtMUdhRTFxUlhwTlJFWnNUVmRhYlUxWFdUSlpla0V5VGxSUk5GbFVVWGxOUWtsSFEyMURSMU5C
UjBjclJWVkNRbWN3UlVKQlRVTkJkMmQzUkZGWlNrdHZXa2xvZG1OT1FWRkZSVUpSUVVSbldVVkJZ
VzF0Tm1nNWF6RXpOMFJFYm01Rk9IY3JPVU5UY3pCb1JXRXpiV1IwV1M5SFpXNUZhRnBxTDJSUFJr
VlBRbFZXZG04eGJsVlZTWHBUVkhaalRtbGlSMGxxUm5KT2VqWnZXQ3MwZG5sSFkyMHJURTVvV0dw
Nk4yWkdVbkEyUW1WemFIUXZlVGhoUTNadmNrbE5aSGRxVkN0d1dYSkVVVWR3TWpaRFUwTkpXa1pW
YldwTVJIa3dPU3M1ZVhWV0wzQlhPVWd6WlVkb1dHNHJVMGxGYTNkQ2RrUm5VR1ZWZFZwdFIxSXdQ
VHd2UTJWeWRHbG1hV05oWkc4K0NpQWdJQ0FnSUNBZ1BFWnBjbTFoUG05M1F6SkRVemQ1UkZablYw
UlJkMjAwUzJRd1ZuTlJWVFJWZFd4S1ZXSnBVbVZSUW1WYUwwTldNazFaVG1Gdk1XZGlNMmhSYzNK
dE9IVlFVMmxqZEM5d1JscDVWelpEWlhKbFdVbDNiRzhyTDJkeVdFMXVhSFZ3VkZWak9FZDFjemxE
VUhaRFJHc3lTMkpRUTJWNlZUQlhWa2xCTUcxbE9YRkpNekJtVWtRdlluQnZlVmRxTlZaR2VUSllU
RnBOYjJkMU5EQndNVFJpTkZwclpreGhiVmhKWWtaelNHcDRNWEV6V1QwOEwwWnBjbTFoUGdvZ0lD
QWdQQzlHYVhKdFlWVnpkV0Z5YVc4K0Nqd3ZSWGh3WldScFpXNTBaVDRLQ2c9PTwvZG9jdW1lbnQ+
DQogICAgPC9Db250ZW50Pg0KICAgIDxUaW1lIFN0YW1wcz4NCiAgICAgICAgPFRpbWUgU3RhbXA+
DQogICAgICAgICAgICA8dG9rZW4+TUlBR0NTcUdTSWIzRFFFSEFxQ0FNSUlNUHdJQkF6RUxNQWtH
QlNzT0F3SWFCUUF3Z2ZVR0N5cUdTSWIzRFFFSkVBRUVvSUhsQklIaU1JSGZBZ0VCQmdzckJnRUVB
WmRWTnQwa05qQWhNQWtHQlNzT0F3SWFCUUFFRlBuWE1hbEZxUy9QYlFlUVFlQlhuWElZRDRvVkFn
SU8zQmdQTWpBd05qQXpNRFl5TXpFeE5EUmFNQU1DQVR3QkFmOENBV1NnZ1lta2dZWXdnWU14Q3pB
SkJnTlZCQVlUQWtoVk1SSXdFQVlEVlFRSUV3bERieTRnUW1WclpYTXhFekFSQmdOVkJBY1RDa0ps
YTJWelkzTmhZbUV4RURBT0JnTlZCQW9UQjA5d1pXNVVVMEV4RlRBVEJnTlZCQU1UREU5d1pXNVVV
MEVnWkdWdGJ6RWlNQ0FHQ1NxR1NJYjNEUUVKQVJZVGVtZHNiM3BwYTBCdmNHVnVkSE5oTG05eVo2
Q0NDTVl3Z2dRaE1JSURDYUFEQWdFQ0FnRU1NQTBHQ1NxR1NJYjNEUUVCQlFVQU1JR0FNUXN3Q1FZ
RFZRUUdFd0pKUlRFVE1CRUdBMVVFQ0JNS1EyOHVJRVIxWW14cGJqRVBNQTBHQTFVRUJ4TUdSSFZp
YkdsdU1SQXdEZ1lEVlFRS0V3ZFBjR1Z1VkZOQk1SZ3dGZ1lEVlFRREV3OVBjR1Z1VkZOQklGSnZi
M1FnUTBFeEh6QWRCZ2txaGtpRzl3MEJDUUVXRUdsdVptOUFiM0JsYm5SellTNXZjbWN3SGhjTk1E
VXdOakV5TVRJMU5qQXhXaGNOTURjd05qRXlNVEkxTmpBeFdqQ0JnekVMTUFrR0ExVUVCaE1DU0ZV
eEVqQVFCZ05WQkFnVENVTnZMaUJDWld0bGN6RVRNQkVHQTFVRUJ4TUtRbVZyWlhOamMyRmlZVEVR
TUE0R0ExVUVDaE1IVDNCbGJsUlRRVEVWTUJNR0ExVUVBeE1NVDNCbGJsUlRRU0JrWlcxdk1TSXdJ
QVlKS29aSWh2Y05BUWtCRmhONloyeHZlbWxyUUc5d1pXNTBjMkV1YjNKbk1JR2ZNQTBHQ1NxR1NJ
YjNEUUVCQVFVQUE0R05BRENCaVFLQmdRRFdUTzlmSVJzUmQ0ZiszeFNtUHdtalJheVFnd1lSc1pN
K2tHQmVpR2xEZnRFZlhGOWdXUERxTjdXd0RxMXQ5cjByRlNxOHVCWlRMMXdsN3AxZm1hMEVvTkxu
Y3kvdzlZZVgzaitsZVJPZkR2akV2ci92ZG1RNTBrdjlYRDVOTTZhTXdRVWpuak5oanJJYjZOZXVi
dEMxdjFLOEtYckJmaVMyM2ozeld2Y3c3d0lEQVFBQm80SUJJekNDQVI4d0NRWURWUjBUQkFJd0FE
QUxCZ05WSFE4RUJBTUNCc0F3SFFZRFZSME9CQllFRk00Ukl5eEI0cFpNNkJZTjJtcjhKRmZDSytw
NE1JR3RCZ05WSFNNRWdhVXdnYUtBRkMyZDl4MStaWGVhOU5tMG1iRVhPOFF2eUsybG9ZR0dwSUdE
TUlHQU1Rc3dDUVlEVlFRR0V3SkpSVEVUTUJFR0ExVUVDQk1LUTI4dUlFUjFZbXhwYmpFUE1BMEdB
MVVFQnhNR1JIVmliR2x1TVJBd0RnWURWUVFLRXdkUGNHVnVWRk5CTVJnd0ZnWURWUVFERXc5UGNH
VnVWRk5CSUZKdmIzUWdRMEV4SHpBZEJna3Foa2lHOXcwQkNRRVdFR2x1Wm05QWIzQmxiblJ6WVM1
dmNtZUNBUUF3SGdZRFZSMFJCQmN3RllFVGVtZHNiM3BwYTBCdmNHVnVkSE5oTG05eVp6QVdCZ05W
SFNVQkFmOEVEREFLQmdnckJnRUZCUWNEQ0RBTkJna3Foa2lHOXcwQkFRVUZBQU9DQVFFQWtjU1gx
dHVSTHNEM09UUEorRGRkSExwSmpUR0RvQkJPV0o0V3IrbHYyZW1pRWZpa3FlcWJRbFIwTWtjZXVh
bzFjaDhobjUwcU1lK2duTDlDcitoWGVudzFuTXJpSGZWSHVtb2E4aUlTMUJvLzNvUnV6OUlvcmtj
d3FjS1RnSUdRTWxVak1tRXlSQWozclF6MGpvK21VOVgyeDlGeE5UMlJ6M0ZnVVltU3JzUjFDaW1r
OUhxV3ZkWDZKRGFWQUh1Mm82SHZVZ21CczBqYlVwUThkZzZSdTgwZEpDZUlQejh3ZVRNbnBnV1pn
VDR5bGRIbGdOL3FqSHdHVzJ5R0htY1lrby96OVFwUGp6WmVYc2MvNlhlVGtFTmpNM1FqOEdZMVVi
bzBOczNBaUpmRlFDT1NrK1pCaTlrRitGWE83dFFoTVVwbVlMZzlRbmVidHdXWWtQSVhmakNDQkow
d2dnT0ZvQU1DQVFJQ0FRQXdEUVlKS29aSWh2Y05BUUVGQlFBd2dZQXhDekFKQmdOVkJBWVRBa2xG
TVJNd0VRWURWUVFJRXdwRGJ5NGdSSFZpYkdsdU1ROHdEUVlEVlFRSEV3WkVkV0pzYVc0eEVEQU9C
Z05WQkFvVEIwOXdaVzVVVTBFeEdEQVdCZ05WQkFNVEQwOXdaVzVVVTBFZ1VtOXZkQ0JEUVRFZk1C
MEdDU3FHU0liM0RRRUpBUllRYVc1bWIwQnZjR1Z1ZEhOaExtOXlaekFlRncwd01qRXdNVGN5TURV
eE16UmFGdzB3TmpFd01UWXlNRFV4TXpSYU1JR0FNUXN3Q1FZRFZRUUdFd0pKUlRFVE1CRUdBMVVF
Q0JNS1EyOHVJRVIxWW14cGJqRVBNQTBHQTFVRUJ4TUdSSFZpYkdsdU1SQXdEZ1lEVlFRS0V3ZFBj
R1Z1VkZOQk1SZ3dGZ1lEVlFRREV3OVBjR1Z1VkZOQklGSnZiM1FnUTBFeEh6QWRCZ2txaGtpRzl3
MEJDUUVXRUdsdVptOUFiM0JsYm5SellTNXZjbWN3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJ
QkR3QXdnZ0VLQW9JQkFRRGQ3VHJuWUVnMVhENk9IckxGL3RZbkREb1JTOHA0dUE1WGtrb1FuWHJl
TkJMQWhrRlpUdkdwbkY2UGV6am1MaHNpYTZMQWk1a2htZzhIMmU4Y2lRSkFKV2J3Vmw0alExTXVy
MURJVGxla3Axc1BEWm5MNjdKNnl6VmlxNzV5TCtHWG1NNzRsd3ovSmsrU1dXU2FjVllTRnllWkJ6
YU9qM0hBcDkxdUIyb1h1Uk53cFVCNWh4aVVTLzM4eld6S3J6aFlkUDBsaEMzODN3UFduVHhUZ3Jh
ZnEycGhyWFJINCtUVEh6VnZISlI0Tk8zL1FVbi9nN0dnM0Zyc3VrV0VIdVhZaUZ6NWQrdjR5anZj
SSt2blY1NmRaV2VGeVpZUVhFb0o5VTFSanpTbDdYNVArZWdNQ0ZMOEdsRytWOVhhM3ZDMkU0bTkz
MmRra1dWSGtGelpTcFYvQWdNQkFBR2pnZ0VlTUlJQkdqQWRCZ05WSFE0RUZnUVVMWjMzSFg1bGQ1
cjAyYlNac1JjN3hDL0lyYVV3Z2EwR0ExVWRJd1NCcFRDQm9vQVVMWjMzSFg1bGQ1cjAyYlNac1Jj
N3hDL0lyYVdoZ1lha2dZTXdnWUF4Q3pBSkJnTlZCQVlUQWtsRk1STXdFUVlEVlFRSUV3cERieTRn
UkhWaWJHbHVNUTh3RFFZRFZRUUhFd1pFZFdKc2FXNHhFREFPQmdOVkJBb1RCMDl3Wlc1VVUwRXhH
REFXQmdOVkJBTVREMDl3Wlc1VVUwRWdVbTl2ZENCRFFURWZNQjBHQ1NxR1NJYjNEUUVKQVJZUWFX
NW1iMEJ2Y0dWdWRITmhMbTl5WjRJQkFEQU1CZ05WSFJNRUJUQURBUUgvTUFzR0ExVWREd1FFQXdJ
QkJqQVJCZ2xnaGtnQmh2aENBUUVFQkFNQ0FRWXdHd1lEVlIwUkJCUXdFb0VRYVc1bWIwQnZjR1Z1
ZEhOaExtOXlaekFOQmdrcWhraUc5dzBCQVFVRkFBT0NBUUVBSnFrdFFYNXhFdHE3aWE0TWhPVDgv
SEZyRXg1QkxJV2dVYnFCa0V5YUxLUmg3WHRocktRVHgyd0g2VWJrOXNNRk1aYkNRdnc1TFVNM05D
U0w2ejZRL1BYK1pEY2ZqQ1NZNXZ4aS9Kd3NCYlIvV1U0bzJpSmtDMXcxdWd2ZWdWTUxnSnM2L2I2
bjdXTUo3cXRTdDk2V0VoNVloOTdBWVRGV2hydVRtdDhnWXlEMjcvbTRLQnR1RGpZMXZxS0swdm5S
VkFRcEdGNG5jbVdMWXlLblF5cXJPYTd2ejlYLzBad2grNHlXMVJMUlVSSVZNOXVXbHFwZVZaMnl4
ZWlESXZvSTc0eFJnS2haYSt5QUdmZHVhOGlBVTQ4dzJQaXpnekh0NDF6T1hFZllMM0hJaUhqUWtM
VFdPV1FOQllxR3hHTzFtMk0vMzZMbUtEblFaeWQxVGVMUEhqR0NBbWt3Z2dKbEFnRUJNSUdHTUlH
QU1Rc3dDUVlEVlFRR0V3SkpSVEVUTUJFR0ExVUVDQk1LUTI4dUlFUjFZbXhwYmpFUE1BMEdBMVVF
QnhNR1JIVmliR2x1TVJBd0RnWURWUVFLRXdkUGNHVnVWRk5CTVJnd0ZnWURWUVFERXc5UGNHVnVW
Rk5CSUZKdmIzUWdRMEV4SHpBZEJna3Foa2lHOXcwQkNRRVdFR2x1Wm05QWIzQmxiblJ6WVM1dmNt
Y0NBUXd3Q1FZRkt3NERBaG9GQUtDQ0FUZ3dHZ1lKS29aSWh2Y05BUWtETVEwR0N5cUdTSWIzRFFF
SkVBRUVNQndHQ1NxR1NJYjNEUUVKQlRFUEZ3MHdOakF6TURZeU16RXhORFJhTUNNR0NTcUdTSWIz
RFFFSkJERVdCQlFudHFvOHRzY3lMR2NEUzBObk9Lemo0My9NNERDQjFnWUxLb1pJaHZjTkFRa1FB
Z3d4Z2NZd2djTXdnY0F3RmdRVTcxSDI3aVl2emJ2L3pxN1RRdXczaVFMZ21YOHdnYVVFRkZwNU1F
dmgvUHpNQjFHTmhhYXNPRnRjNCtWQk1JR01NSUdHcElHRE1JR0FNUXN3Q1FZRFZRUUdFd0pKUlRF
VE1CRUdBMVVFQ0JNS1EyOHVJRVIxWW14cGJqRVBNQTBHQTFVRUJ4TUdSSFZpYkdsdU1SQXdEZ1lE
VlFRS0V3ZFBjR1Z1VkZOQk1SZ3dGZ1lEVlFRREV3OVBjR1Z1VkZOQklGSnZiM1FnUTBFeEh6QWRC
Z2txaGtpRzl3MEJDUUVXRUdsdVptOUFiM0JsYm5SellTNXZjbWNDQVFBd0RRWUpLb1pJaHZjTkFR
RUJCUUFFZ1lBR1VVbGhZU1lzV0p2UlgrNjlTS1NqaVo5S053TWdPUUdXSkx4UXNPM204L1c5UlI2
b2NpSm9halpzN1NxUjhtR3NWTU5jL3dBUzlFd0w2ajkvdDJ1cmZHVzhxTTdubFZOMUVBbFRsbm5J
Si9CUmVKTWJGc3h6bUdhUkFqR2FBb2dSdnJyREFIbVNXR2N0RXBDdFJodXRKRUJYVE9kVjNlS2pL
S2dCNWZ2NjlBQUFBQUE9PC90b2tlbj4NCiAgICAgICAgICAgIDxoYXNoPitkY3hxVVdwTDg5dEI1
QkI0RmVkY2hnUGloVT08L2hhc2g+DQogICAgICAgIDwvVGltZSBTdGFtcD4NCiAgICA8L1RpbWUg
U3RhbXBzPg0KPC9Eb2N1bWVudD4=

------_=_NextPart_001_01C64D18.1DC8A155
Content-Type: application/octet-stream;
	name="testdocs2.txt.sig"
Content-Transfer-Encoding: base64
Content-Description: testdocs2.txt.sig
Content-Disposition: attachment;
	filename="testdocs2.txt.sig"

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0K
PERvY3VtZW50IGRhdGVDcmVhdGlvbj0iMjAwNi0wMy0wNlQxNzowOTo0OC42MzMtMDY6MDAiIGRv
Y3VtZW50TmFtZT0idGVzdGRvY3MyLnR4dCIgZG9jdW1lbnRUeXBlPSJ0eHQiPg0KICAgIDxDb250
ZW50Pg0KICAgICAgICA8ZG9jdW1lbnQ+YjNSeVlTQndjblZsWW1FPTwvZG9jdW1lbnQ+DQogICAg
PC9Db250ZW50Pg0KPC9Eb2N1bWVudD4NCg0K

------_=_NextPart_001_01C64D18.1DC8A155--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LD2W1K068899; Tue, 21 Mar 2006 06:02:32 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LD2WgL068898; Tue, 21 Mar 2006 06:02:32 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mail.seccommerce.de (mail.seccommerce.de [62.109.87.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LD2Uu3068891 for <ietf-ltans@imc.org>; Tue, 21 Mar 2006 06:02:31 -0700 (MST) (envelope-from tk-tlslist@seccommerce.de)
Received: (qmail 16087 invoked from network); 21 Mar 2006 13:05:10 -0000
Received: from unknown (HELO ?10.1.0.170?) (10.1.0.170) by 0 with RC4-MD5 encrypted SMTP; 21 Mar 2006 13:05:10 -0000
Message-ID: <441FF949.8000509@seccommerce.de>
Date: Tue, 21 Mar 2006 14:02:01 +0100
From: Tilo Kienitz <tk-tlslist@seccommerce.de>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-ltans@imc.org
Subject: Why are the hash values sorted?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello working group,

I'm afraid I'm quite late with my question, but what is the
advantage of sorting the hash values?

Paragraph "3.2. Generation" of draft-ietf-ltans-ers-05 states:
   "3.  For each data group containing more than one document, its
        respective document hashes are binary sorted in ascending
        order, concatenated and hashed."

The order of the documents in the data object group could already
have some meaning in an external application and it would be nice
if the hash tree preserved this existing order. Without the binary
sorting not only the existence of the hashes could be proven after
years but also their order.

The binary sorting is not needed to get a unique hash value, since
the reducedHashtree uses ASN-sequences. If the hash algorithm
processed the hash values in the same order in which they appear
in the sequences in the reducedHashtree then the root hash would be
uniquely determined without the need to sort anything in between.

What do you think?

Kind regards
Tilo Kienitz


-- 
Tilo Kienitz
SecCommerce Informationssysteme GmbH
Obenhauptstr. 5
D - 22335 Hamburg                       http://www.seccommerce.de
Germany



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KMOvTE031816; Mon, 20 Mar 2006 15:24:57 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KMOvJI031815; Mon, 20 Mar 2006 15:24:57 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KMOrVE031799 for <ietf-ltans@imc.org>; Mon, 20 Mar 2006 15:24:56 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: ERS comments
Date: Mon, 20 Mar 2006 14:24:46 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901CDBA82@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS comments
thread-index: AcZMHG3m0P4vqCgTRE2YPCSswIk1cAADQ8cQABBTQSA=
From: "Carl Wallace" <cwallace@orionsec.com>
To: "Tobias Gondrom" <tgondrom@opentext.com>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2KMOuVE031810
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

<snip>
> > The syntax has no extensibility mechanism.  For a spec with 
> long-term 
> > goals, lack of extensibility could be problem.  One 
> possible approach 
> > would be to replace the reduced hashtree with a CMS attribute bucket
> and
> > refactor reduced hashtree as an attribute.
> 
> Maybe I am not seeing the point: I don't see a real advantage of that.
> In fact I believe that a strict specification is better. (the 
> less room for (mis)interpretation and individual 
> modifications the better)

I'll defer to other comments during the last call.  Generally I agree
with the idea that a strict spec is preferable.  However, with the
timestamp flexibility already there and given the need to accommodate
change over a long period of time, leaving wiggle room for things we
haven't thought of is probably a good idea.

> > What came of the policy discussions during the Paris 
> meeting?  Should 
> > policy be an output of verification?  Does the structure need to 
> > accommodate expression of policy?
> 
> Policy should not be an output of the verification but an 
> input for the storage system and an input fort he 
> verification (for only the system and the auditor can know 
> which algs are acceptable for them.)
>
> > What are the inputs to the verification algorithm?  How does a 
> > verification implementation know a crypto algorithm was secure at a 
> > particular time?  Where digital signatures are used, must all 
> > certificates in the path to the TSA be valid at the time the
> subsequent
> > timestamp was generated?  Verification for at least one timestamp
> option
> > should be described in detail in this doc (RFC3161?) with other 
> > timestamp types addressed in this spec or in related docs.
> 
> A system should be provided with a policy (it can also be 
> only one policy that is configured for the system globally) 
> that will define which alg has been recognized as secure 
> until which date.) This will have to be an implicit part of 
> the verification but not a necessary part of the 
> specification for these criteria can be configured 
> individually for each system based on local restrictions and 
> parameters.

I think we should define a validation algorithm a la 3280, with a
required minimal set of inputs and expected outputs.  This would also
help sort out the policy question.
 
> > Should the hash of preceding Archive Time-Stamp be incorporated into
> the
> > structure to allow each Archive Time-Stamp to stand alone?  Perhaps
> this
> > could be included as an attribute and checked only when 
> validation of 
> > ancestors is desired.
> 
> The verification of the ERS can be split into several parts: 
> one can already verify every ArchiveTimeStamp, 
> ArchiveTimeStampChain and ArchiveTimeStampSequence on its own 
> and puzzle together the results in the end by simply closing 
> the gaps/links of the chain by comparing hash-values of the 
> top and the bottom of each ArchiveTimeStamp.

Unless I am misreading bullets 4 and 5 in section 4.2, you must have the
chain in order to calculate the hash when verifying an evidence record
that has been renewed.  The hash in the first SEQ OF OCTET STRINGs is
not the hash of the original document using a new hash alg but is a hash
of the document + hash of the chain.  Each chain in a sequence does not
stand alone.  If the chain hash were included as an attribute one could
perform a shallow verification, or (possibly) could discard the older
portions of the chain at some point, by concatenating the value from the
attribute with the document hash.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KJnMKu025691; Mon, 20 Mar 2006 12:49:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KJnMXl025690; Mon, 20 Mar 2006 12:49:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KJnL92025684 for <ietf-ltans@imc.org>; Mon, 20 Mar 2006 12:49:22 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: Meeting minutes
Date: Mon, 20 Mar 2006 11:49:14 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901CDB77A@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meeting minutes
thread-index: AcZMV12NkKIKvvsCTzyg/65DnWrztA==
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2KJnM92025685
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

The meeting minutes from today's session can be found at:
http://www3.ietf.org/proceedings/06mar/minutes/ltans.txt.  Let me know
if there are any errors or omissions.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KEbMeI013247; Mon, 20 Mar 2006 07:37:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KEbMo9013246; Mon, 20 Mar 2006 07:37:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KEbKVP013240 for <ietf-ltans@imc.org>; Mon, 20 Mar 2006 07:37:21 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2KEbI9N002376; Mon, 20 Mar 2006 15:37:18 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: ERS comments
Date: Mon, 20 Mar 2006 15:37:17 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A786810265D@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS comments
Thread-Index: AcZMHG3m0P4vqCgTRE2YPCSswIk1cAADQ8cQ
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Carl Wallace" <cwallace@orionsec.com>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2KEbLVP013241
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Carl,

no problem and thanks fort he review. I will change the spelling and
format issues today right after the meeting. 

- concerning 2119 language: it is intended that some of the musts are
not capital MUST - exactly because of the 2119 language specifications.

The rest of the answers inline....

Tobias



> -----Original Message-----
> From: Carl Wallace [mailto:cwallace@orionsec.com]
> Sent: Monday, March 20, 2006 1:47 PM
> To: ietf-ltans@imc.org
> Cc: Tobias Gondrom
> Subject: ERS comments
> 
> Below are comments for -05 of ERS.  I apologize for the late posting
> relative to the WG meeting.  Most are nits.  My two primary concerns
are
> lack of extensibility and underspecification of the validation
> algorithm.
> 
> NITS
> In the definitions section, change "a Archive..." to "an Archive...".
> 
> Definitions should be alphabetical.
> 
> In section 2.1, change "necesarry" to necessary".
> 
> In section 4.2, "if the Time-Stamp of an Archive Time-Stamp becomes
> invalid" should be "before the Time-Stamp of an Archive Time-Stamp
> becomes invalid".
> 
> In section 4.3, add "at the time verification is performed" to the end
> of the sentence immediately following the three bullets.
> 
> The draft does not consistently use 2119 language.  In particular, the
> verification algorithm in section 4.3 needs to have capitalization
> applied to some of the MUSTs.
> 
> In the definitions section, why were parentheses added to "Archived
data
> object" and "Archived data object group"?
> 
> COMMENTS/QUESTIONS
> What is the IMPORT for AlgorithmIdentifier?  Shouldn't this be
imported
> from RFC3280?  Similarly, id-ERS-1 should be defined in this module,
not
> imported.

I would go with this, other comments from the WG?


> The syntax has no extensibility mechanism.  For a spec with long-term
> goals, lack of extensibility could be problem.  One possible approach
> would be to replace the reduced hashtree with a CMS attribute bucket
and
> refactor reduced hashtree as an attribute.

Maybe I am not seeing the point: I don't see a real advantage of that.
In fact I believe that a strict specification is better. (the less room
for (mis)interpretation and individual modifications the better)

> What came of the policy discussions during the Paris meeting?  Should
> policy be an output of verification?  Does the structure need to
> accommodate expression of policy?

Policy should not be an output of the verification but an input for the
storage system and an input fort he verification (for only the system
and the auditor can know which algs are acceptable for them.)

> What are the inputs to the verification algorithm?  How does a
> verification implementation know a crypto algorithm was secure at a
> particular time?  Where digital signatures are used, must all
> certificates in the path to the TSA be valid at the time the
subsequent
> timestamp was generated?  Verification for at least one timestamp
option
> should be described in detail in this doc (RFC3161?) with other
> timestamp types addressed in this spec or in related docs.

A system should be provided with a policy (it can also be only one
policy that is configured for the system globally) that will define
which alg has been recognized as secure until which date.) This will
have to be an implicit part of the verification but not a necessary part
of the specification for these criteria can be configured individually
for each system based on local restrictions and parameters.

> Should the hash of preceding Archive Time-Stamp be incorporated into
the
> structure to allow each Archive Time-Stamp to stand alone?  Perhaps
this
> could be included as an attribute and checked only when validation of
> ancestors is desired.

The verification of the ERS can be split into several parts: one can
already verify every ArchiveTimeStamp, ArchiveTimeStampChain and
ArchiveTimeStampSequence on its own and puzzle together the results in
the end by simply closing the gaps/links of the chain by comparing
hash-values of the top and the bottom of each ArchiveTimeStamp.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KDbjQV010689; Mon, 20 Mar 2006 06:37:45 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KDbj0R010688; Mon, 20 Mar 2006 06:37:45 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KDbj1N010681 for <ietf-ltans@imc.org>; Mon, 20 Mar 2006 06:37:45 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: ERS tagging
Date: Mon, 20 Mar 2006 05:37:31 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901CDB041@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS tagging
thread-index: AcZMI3A3NxoNF7pDSmy+vsm/pS6tOg==
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Cc: "Tobias Gondrom" <tgondrom@opentext.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2KDbj1N010683
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

In the ERS example that Tobias posted a few months back
(flight-ats.der), the tagging on the reducedHashtree field does not
appear to be IMPLICIT.  The module has IMPLICIT tags by default.  Is
there an encoding rule that forces this tag to be EXPLICIT or should it
be encoded as IMPLICIT?  Here's a partially annotated excerpt from that
evidence record:

0000 30 1BEE: SEQUENCE {		-- EvidenceRecord
0004 02    1:   INTEGER 1		--	version
0007 30   1A:   SEQUENCE {		--	digestAlgs
0009 30    D:     SEQUENCE {		--		digestAlg
000B 06    9:       OBJECT IDENTIFIER '2 16 840 1 101 3 4 2 3'
0016 05    0:       NULL
            :       }
0018 30    9:     SEQUENCE {		--		digestAlg
001A 06    5:       OBJECT IDENTIFIER ripemd160 (1 3 36 3 2 1)
0021 05    0:       NULL
            :       }
            :     }
0023 30 1BCB:   SEQUENCE {		-- 	ArchiveTimestampSequence
0027 30 109E:     SEQUENCE {		--
ArchiveTimestampChain
002B 30  8CC:       SEQUENCE {	--			ArchiveTimestamp
002F 30    9:         SEQUENCE {	--
digestAlg
0031 06    5:           OBJECT IDENTIFIER ripemd160 (1 3 36 3 2 1)
0038 05    0:           NULL
            :           }
003A A0   FF:         [0] {		--
reducedHashtree (first SEQ OF should be masked by [0])
003D 30   FC:           SEQUENCE {	--
SEQ OF OCTET STRING
0040 30   42:             SEQUENCE {	--
???
0042 04   14:               OCTET STRING
            :                 51 B1 78 B4 A0 95 92 D4 25 B7 09 72 BA 44
8E B0
            :                 22 1D 39 D9
0058 04   14:               OCTET STRING
            :                 5B D0 24 7C 9F 86 B4 B1 FA D7 50 0F 61 FC
D9 E6
            :                 22 65 1A D2
006E 04   14:               OCTET STRING
            :                 60 BB C5 70 69 49 FC 4D 19 17 71 B9 A7 74
34 16
            :                 A3 40 F7 EE
            :               }
0084 30   2C:             SEQUENCE {
0086 04   14:               OCTET STRING
            :                 B8 37 FB D6 1B 1C 82 64 4F D1 96 89 2C F9
FB 1E
            :                 E1 6A 24 73
009C 04   14:               OCTET STRING
            :                 46 D8 FC 30 3B ED 6C FA 43 3E 8F 09 14 6A
CC 2F
            :                 2C 32 A5 1C
            :               }
00B2 30   2C:             SEQUENCE {
00B4 04   14:               OCTET STRING
            :                 CF 18 DD A2 1B 8D 71 D7 C4 3E 11 B6 03 B3
C0 C3
            :                 09 98 6B D8
00CA 04   14:               OCTET STRING
            :                 6B A0 A0 BB 6C F4 3C B7 66 5B 18 76 AB A9
DB 4F
            :                 90 32 56 B1
            :               }
00E0 30   2C:             SEQUENCE {
00E2 04   14:               OCTET STRING
            :                 C4 14 A0 0A 8E 57 9E 49 CE C5 BA AB 06 AB
B5 77
            :                 A6 EF FE A3
00F8 04   14:               OCTET STRING
            :                 34 13 E3 37 A9 DB FD 82 0A 32 15 50 EF 0B
F8 22
            :                 70 B5 E8 45
            :               }
010E 30   2C:             SEQUENCE {
0110 04   14:               OCTET STRING
            :                 F7 9A 6C A8 7A 7C 74 1C F4 0A EB AA A8 91
80 55
            :                 F8 58 10 EA
0126 04   14:               OCTET STRING '..........'
            :               }
            :             }
            :           }



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KClZII009054; Mon, 20 Mar 2006 05:47:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KClZvp009053; Mon, 20 Mar 2006 05:47:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KClZAk009046 for <ietf-ltans@imc.org>; Mon, 20 Mar 2006 05:47:35 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: ERS comments
Date: Mon, 20 Mar 2006 04:47:21 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901CDAFE7@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ERS comments
thread-index: AcZMHG3m0P4vqCgTRE2YPCSswIk1cA==
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Cc: "Tobias Gondrom" <tgondrom@opentext.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2KClZAk009048
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Below are comments for -05 of ERS.  I apologize for the late posting
relative to the WG meeting.  Most are nits.  My two primary concerns are
lack of extensibility and underspecification of the validation
algorithm.

NITS
In the definitions section, change "a Archive..." to "an Archive...".

Definitions should be alphabetical.

In section 2.1, change "necesarry" to necessary".

In section 4.2, "if the Time-Stamp of an Archive Time-Stamp becomes
invalid" should be "before the Time-Stamp of an Archive Time-Stamp
becomes invalid".    

In section 4.3, add "at the time verification is performed" to the end
of the sentence immediately following the three bullets.

The draft does not consistently use 2119 language.  In particular, the
verification algorithm in section 4.3 needs to have capitalization
applied to some of the MUSTs.

In the definitions section, why were parentheses added to "Archived data
object" and "Archived data object group"?

COMMENTS/QUESTIONS
What is the IMPORT for AlgorithmIdentifier?  Shouldn't this be imported
from RFC3280?  Similarly, id-ERS-1 should be defined in this module, not
imported.

The syntax has no extensibility mechanism.  For a spec with long-term
goals, lack of extensibility could be problem.  One possible approach
would be to replace the reduced hashtree with a CMS attribute bucket and
refactor reduced hashtree as an attribute.  

What came of the policy discussions during the Paris meeting?  Should
policy be an output of verification?  Does the structure need to
accommodate expression of policy?

What are the inputs to the verification algorithm?  How does a
verification implementation know a crypto algorithm was secure at a
particular time?  Where digital signatures are used, must all
certificates in the path to the TSA be valid at the time the subsequent
timestamp was generated?  Verification for at least one timestamp option
should be described in detail in this doc (RFC3161?) with other
timestamp types addressed in this spec or in related docs.

Should the hash of preceding Archive Time-Stamp be incorporated into the
structure to allow each Archive Time-Stamp to stand alone?  Perhaps this
could be included as an attribute and checked only when validation of
ancestors is desired.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FHinwR058723; Wed, 15 Mar 2006 10:44:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FHinOA058722; Wed, 15 Mar 2006 10:44:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FHilAY058716 for <ietf-ltans@imc.org>; Wed, 15 Mar 2006 10:44:48 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2FHijg0014267 for <ietf-ltans@imc.org>; Wed, 15 Mar 2006 18:44:46 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Jabber service for IETF meetings  - configuration recommendation for users behind firewalls
Date: Wed, 15 Mar 2006 18:44:44 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A7868102143@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Jabber service for IETF meetings  - configuration recommendation for users behind firewalls
Thread-Index: AcZH6cp+e8NbIbAYTQuCwG4nnrX5bAAPQxAgAAwsgpA=
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2FHimAY058717
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello,

I just tested the Jabber site and it worked fine.
Only problem I had is that I am sitting behind a firewall and it was
hard for me to find a server that accepts connections at 443 instead of
5223. (our company firewall didn't let me out at 5222 or 5223)

As others might experience the same: 
I found that swissjabber.ch worked fine for me with PSI as a client -
just configure manually the server "swissjabber.ch" port 443 and enable
SSL encryption. The rest works fine.

Tobias


-----Original Message-----
From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
Sent: Wednesday, March 15, 2006 1:00 PM
To: ietf-ltans@imc.org
Subject: FW: Jabber service for IETF meetings 


The Jabber details have changed.  Please see below for details.  Note,
on this server there is an LTANS room.

Carl 

> -----Original Message-----
> From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] 
> Sent: Tuesday, March 14, 2006 11:26 PM
> To: Working Group Chairs
> Subject: Jabber service for IETF meetings 
> 
> Dear IETF WG Chairs,
> 
> The Secretariat is pleased to announce a new Instant 
> Messaging service.  This service will provide jabber chat 
> rooms to all IETF working groups for their text conferencing 
> at IETF 65 and future meetings.
> 
> The new jabber server is located at jabber.ietf.org and is 
> currently accessible.  For those who are interested, please 
> visit the above location to join any of the available chat rooms.
> 
> Over the next few days, please take the time to test this new 
> service and provide us with all questions, comments, and 
> suggestions.  Your feedback is key to our success!
> 
> Please note:
> 
> All traffic within the defined rooms (except "noc") is being 
> logged and updated every 5 minutes to the ietf.org website.
> 
> To view the log directories, point your browser to 
> http://www.ietf.org/meetings/ietf-logs/.
> 
> If you click on a room directory, you will see one or more 
> files named "YYYY-MM-DD.html", e.g. 2006-03-14.html.  If you 
> click on one of those files, you will see all logged traffic 
> for that day.
>  
> Please visit the IETF Text Conferencing Web page
> (http://www.ietf.org/meetings/text_conf.html) for more information.
> 
> The IETF Secretariat.
> 
> 
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FC9Dpt045628; Wed, 15 Mar 2006 05:09:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FC9DGH045627; Wed, 15 Mar 2006 05:09:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FC9CT0045621 for <ietf-ltans@imc.org>; Wed, 15 Mar 2006 05:09:12 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr)
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k2FC9Ai05090; Wed, 15 Mar 2006 13:09:10 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Wed, 15 Mar 2006 13:09:10 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA06623; Wed, 15 Mar 2006 13:09:09 +0100 (MET)
Message-ID: <44180389.4050308@edelweb.fr>
Date: Wed, 15 Mar 2006 13:07:37 +0100
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: Larry Masinter <LMM@acm.org>
CC: "'Tobias Gondrom'" <tgondrom@opentext.com>, ietf-ltans@imc.org
Subject: Re: IS&T Archiving 2006
References: <001601c647aa$5c894430$46832099@corp.adobe.com>
In-Reply-To: <001601c647aa$5c894430$46832099@corp.adobe.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040501090704010601020606"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

--------------ms040501090704010601020606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


If there is a point to discuss how encryption is used in an LTANS context,
then, yes, I think the same considerations canbe given to the approach 
to split data
among several services:

In the context of an LTAP protocol, there are two ways to have these 
security features
implemented. Either the client before talking LTAP, or at the server 
end, in fact,
both, a client can talk to a proxy type server that performs the 
security and then talk
to one or more backends. The proxy creates whatever metatdata are necessary
to "recover" the data, and stores this with the data and/or returns the 
information
to the client.

In case of encryption, one encapsulates the data with S/MIME 
encapsulatedData
or XML-ENC.

What would be required is one or two format for the encapsulation of 
splitted data.
This detailed format discussion may be out of scope for ltans to some
degree, it could be done in smime and some oasis/w3c group, but it may 
not be worth
to create a new group and also the goal of the formats is long term 
stability ...



Larry Masinter wrote:
> I'm not sure the LTANS mailing list is the right place to discuss
> my paper, 


--------------ms040501090704010601020606
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMzE1MTIwNzM3WjAjBgkqhkiG9w0B
CQQxFgQUqRNavwdIWUvWEWIOM6AEx3pHfIswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAnVxub/vdgc+emQ+I
MaYqWeeFwB+08dyVZRaar0DvmGVfzC/+FIigmebcRmS6LbwYxkSP/ToBsHTYKo5jOo/ST6Vb
B7XUblNgzN9Mp5on37nx8uDWY4Sp0kVE6DjuHUCNu+kFMgXar29otJbC+6eTrM799KkhBVV8
wYPUY1jgm3gAAAAAAAA=
--------------ms040501090704010601020606--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBqwCK045069; Wed, 15 Mar 2006 04:52:58 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FBqwtG045068; Wed, 15 Mar 2006 04:52:58 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBqw1C045062 for <ietf-ltans@imc.org>; Wed, 15 Mar 2006 04:52:58 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: FW: Jabber service for IETF meetings 
Date: Wed, 15 Mar 2006 04:00:09 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901B92FF5@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Jabber service for IETF meetings 
Thread-Index: AcZH6cp+e8NbIbAYTQuCwG4nnrX5bAAPQxAg
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2FBqw1C045063
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

The Jabber details have changed.  Please see below for details.  Note,
on this server there is an LTANS room.

Carl 

> -----Original Message-----
> From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] 
> Sent: Tuesday, March 14, 2006 11:26 PM
> To: Working Group Chairs
> Subject: Jabber service for IETF meetings 
> 
> Dear IETF WG Chairs,
> 
> The Secretariat is pleased to announce a new Instant 
> Messaging service.  This service will provide jabber chat 
> rooms to all IETF working groups for their text conferencing 
> at IETF 65 and future meetings.
> 
> The new jabber server is located at jabber.ietf.org and is 
> currently accessible.  For those who are interested, please 
> visit the above location to join any of the available chat rooms.
> 
> Over the next few days, please take the time to test this new 
> service and provide us with all questions, comments, and 
> suggestions.  Your feedback is key to our success!
> 
> Please note:
> 
> All traffic within the defined rooms (except "noc") is being 
> logged and updated every 5 minutes to the ietf.org website.
> 
> To view the log directories, point your browser to 
> http://www.ietf.org/meetings/ietf-logs/.
> 
> If you click on a room directory, you will see one or more 
> files named "YYYY-MM-DD.html", e.g. 2006-03-14.html.  If you 
> click on one of those files, you will see all logged traffic 
> for that day.
>  
> Please visit the IETF Text Conferencing Web page
> (http://www.ietf.org/meetings/text_conf.html) for more information.
> 
> The IETF Secretariat.
> 
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ENInhG019621; Tue, 14 Mar 2006 16:18:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ENImH4019620; Tue, 14 Mar 2006 16:18:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ENImYX019613 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 16:18:48 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: IS&T Archiving 2006
Date: Tue, 14 Mar 2006 15:25:55 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901B47542@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IS&T Archiving 2006
Thread-Index: AcZFhNESP5fgCiFcS1af0lzVqweqlQB2kimQABJ6xJAABJrCAA==
From: "Carl Wallace" <cwallace@orionsec.com>
To: "Larry Masinter" <LMM@acm.org>, "Tobias Gondrom" <tgondrom@opentext.com>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2ENImYX019615
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

> I'm not sure the LTANS mailing list is the right place to 
> discuss my paper, but I wanted to point out that you might 
> have long-term security without using encryption, and 
> long-term notary without timestamp evidence chains.

Secret sharing has been discussed as an alternative to refreshed
timestamps in the WG before and seems like an appropriate topic.  ERS
recently made accommodations for non-3161 timestamps.  Perhaps there's
an opportunity to define a structure that provides an alternative based
on secret sharing for integrity in a similar way (with confidentiality
as a bonus).  




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EL16wt012642; Tue, 14 Mar 2006 14:01:06 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EL16IA012641; Tue, 14 Mar 2006 14:01:06 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from exprod6og8.obsmtp.com (exprod6og8.obsmtp.com [64.18.1.128]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2EL15Dn012631 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 14:01:05 -0700 (MST) (envelope-from LMM@acm.org)
Received: from source ([192.150.20.142]) by exprod6ob8.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 14 Mar 2006 13:01:04 PST
Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k2EL1A46022871 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 13:01:11 -0800 (PST)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k2EL11rs018828 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 13:01:02 -0800 (PST)
Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IW4008O4YDPEK@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Tue, 14 Mar 2006 13:01:01 -0800 (PST)
Received: from MasinterT43p (c-131-70.corp.adobe.com [153.32.131.70]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IW4003KWYDOLR@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Tue, 14 Mar 2006 13:01:01 -0800 (PST)
Date: Tue, 14 Mar 2006 13:00:44 -0800
From: Larry Masinter <LMM@acm.org>
Subject: RE: IS&T Archiving 2006
In-reply-to: <2666EB2A846BAC4BB2D7F593301A7868101EEE@MUCXGC2.opentext.net>
To: "'Tobias Gondrom'" <tgondrom@opentext.com>
Cc: ietf-ltans@imc.org
Message-id: <001601c647aa$5c894430$46832099@corp.adobe.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcZFhNESP5fgCiFcS1af0lzVqweqlQB2kimQABJ6xJA=
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

I'm not sure the LTANS mailing list is the right place to discuss
my paper, but I wanted to point out that you might have long-term
security without using encryption, and long-term notary without
timestamp evidence chains.


> Unfortunately for my understanding the shared secret concept has one
> severe weakness: it does not prevent the owner of the system 
> to retrieve data and read it.

This is not the case. Maybe it isn't really a topic for
this list, though. There's an active literature on secret
sharing. Most use secret sharing as a way of managing encryption
keys, but I think it is practical now for the data itself,
without using encryption at all, and appropriate to do so
for a long-term archive.

Larry




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EKFTZa010300; Tue, 14 Mar 2006 13:15:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EKFTVZ010299; Tue, 14 Mar 2006 13:15:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EKFTAS010293 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 13:15:29 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: comments on draft-ietf-ltans-pki-retention-00.txt
Date: Tue, 14 Mar 2006 12:22:31 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C87901B47156@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: comments on draft-ietf-ltans-pki-retention-00.txt
Thread-Index: AcZHoYaynk8RBxeERx+tz6oNWsJ8QgAAarTQ
From: "Carl Wallace" <cwallace@orionsec.com>
To: <aljosa@e5.ijs.si>, "Tobias Gondrom" <tgondrom@opentext.com>
Cc: <bruno@wildhaber.com>, <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2EKFTAS010294
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

<snip>
> > Do you think LTANS specs can play a role here, i.e., ERS?  If not, 
> > what specs apply?  The retention spec defines an optional binding 
> > between certs and evidence records that enables you to fulfill your 
> > responsibility of preserving the necessary verification data.
> 
> No, I don't thnik ERS should have anything to do with 
> retetnion. IMO, this is pure process managerial issue and 
> should be binded to the archive objects build of several 
> parts (see the LTAP slides for Dallas), namely:
> 
> - archive data
> - metainformation (including operation information, sec. 
> attributes, etc.)
> - ERS

In this case, ERS is used as part of a managerial process to make the
verification data available.  ERS itself has nothing to do with the
retention.

>   It's not
> > clear to me that certs must be preserved as part of a signed data 
> > object especially since not doing this has significant 
> benefit, e.g., 
> > storage savings and decoupling trust anchors from signed data.
> > </snip>
> 
> Law requirments usually clearly specify the availability of 
> 'complementary'
> information needed for security attributes validation in time 
> (and this issue is addressed by by RFC3126 and its XML 
> interpretation (XAdES), however from different perspective 
> than ERS). Such information may be obtained on request or be 
> part of the archive object. The problem is the availability 
> and integrity.
> Such information may cease to exist for whatever reason, 
> including decomposing CA. Henece the need to place it next to 
> archive data. But you are right, this is storage saving issue 
> also. So one may simply use pointers for example, while use 
> ERS to demonstrate integrity.

Is it desireable to freeze the verification context when data is
archived (or moreover, to only be able to freeze context)?  Some
artifacts may serve multiple communities.  Using the approach described
in the retention draft and in the ERS/SCVP draft enables verification of
data to vary independent from the preservation of the data.  
 
> >
> > Not an answer but a comment to this question:
> > I agree with Carl in the point that the retention of 
> certificates etc.
> > is important and that it would be good to have this at a 
> central point.
> > At the first glance it might even be better located in PKIX 
> - on the 
> > other side  the charter of LTANS "Long term archiving and notary 
> > services" does in my eyes not exclude such a spec AND which is most 
> > important it is an important (at the moment not really 
> specified part) 
> > of the puzzle for an application for long term storage of signed 
> > documents.
> 
> Another problem with retention period is that it may change. 
> So placing this information on a specific place does rise 
> some issues. This is why I think it is an archive data 
> handling information.
> 
> Aleksej
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EJoMp1008790; Tue, 14 Mar 2006 12:50:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EJoMjM008788; Tue, 14 Mar 2006 12:50:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2EJoI8Z008777 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 12:50:19 -0700 (MST) (envelope-from aljosa@e5.ijs.si)
Received: (qmail 27230 invoked by uid 48); 14 Mar 2006 19:50:17 -0000
Received: from host66.miarm.hyatthsia.com (host66.miarm.hyatthsia.com [12.149.86.66])  by kekec.e5.ijs.si (IMP) with HTTP  for <aljosa@127.0.0.1>; Tue, 14 Mar 2006 20:50:17 +0100
Message-ID: <1142365817.44171e79c98b8@kekec.e5.ijs.si>
Date: Tue, 14 Mar 2006 20:50:17 +0100
From: aljosa@e5.ijs.si
To: Tobias Gondrom <tgondrom@opentext.com>
Cc: Carl Wallace <cwallace@orionsec.com>, bruno@wildhaber.com, ietf-ltans@imc.org
Subject: RE: comments on draft-ietf-ltans-pki-retention-00.txt
References: <2666EB2A846BAC4BB2D7F593301A7868101F8A@MUCXGC2.opentext.net>
In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868101F8A@MUCXGC2.opentext.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.6
X-Originating-IP: 12.149.86.66
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Haven't yet got the time to read the draft but some comments inline.

>
> <snip>
> > So the first thing will be to define the adequate
> > certificate/PKI/ policy  for your needs and then decide abou
> > the necessary cert.
> > management structure. Legally spoken: it is my responsibility
> > to store the necessary verification data, how I will do that,
> > should remain in my responsibility. Having said this, I do
> > not think this should be part of the LTANS standard.
>
> Do you think LTANS specs can play a role here, i.e., ERS?  If not, what
> specs apply?  The retention spec defines an optional binding between
> certs and evidence records that enables you to fulfill your
> responsibility of preserving the necessary verification data.

No, I don't thnik ERS should have anything to do with retetnion. IMO, this is
pure process managerial issue and should be binded to the archive objects build
of several parts (see the LTAP slides for Dallas), namely:

- archive data
- metainformation (including operation information, sec. attributes, etc.)
- ERS

  It's not
> clear to me that certs must be preserved as part of a signed data object
> especially since not doing this has significant benefit, e.g., storage
> savings and decoupling trust anchors from signed data.
> </snip>

Law requirments usually clearly specify the availability of 'complementary'
information needed for security attributes validation in time (and this issue
is addressed by by RFC3126 and its XML interpretation (XAdES), however from
different perspective than ERS). Such information may be obtained on request or
be part of the archive object. The problem is the availability and integrity.
Such information may cease to exist for whatever reason, including decomposing
CA. Henece the need to place it next to archive data. But you are right, this
is storage saving issue also. So one may simply use pointers for example, while
use ERS to demonstrate integrity.

>
> Not an answer but a comment to this question:
> I agree with Carl in the point that the retention of certificates etc.
> is important and that it would be good to have this at a central point.
> At the first glance it might even be better located in PKIX - on the
> other side  the charter of LTANS "Long term archiving and notary
> services" does in my eyes not exclude such a spec AND which is most
> important it is an important (at the moment not really specified part)
> of the puzzle for an application for long term storage of signed
> documents.

Another problem with retention period is that it may change. So placing this
information on a specific place does rise some issues. This is why I think it
is an archive data handling information.

Aleksej



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EJoMd7008791; Tue, 14 Mar 2006 12:50:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EJoM8R008789; Tue, 14 Mar 2006 12:50:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2EJoIQF008776 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 12:50:19 -0700 (MST) (envelope-from aljosa@e5.ijs.si)
Received: (qmail 27223 invoked by uid 48); 14 Mar 2006 19:50:17 -0000
Received: from host66.miarm.hyatthsia.com (host66.miarm.hyatthsia.com [12.149.86.66])  by kekec.e5.ijs.si (IMP) with HTTP  for <aljosa@127.0.0.1>; Tue, 14 Mar 2006 20:50:17 +0100
Message-ID: <1142365817.44171e791c327@kekec.e5.ijs.si>
Date: Tue, 14 Mar 2006 20:50:17 +0100
From: aljosa@e5.ijs.si
To: Tobias Gondrom <tgondrom@opentext.com>
Cc: Carl Wallace <cwallace@orionsec.com>, bruno@wildhaber.com, ietf-ltans@imc.org
Subject: RE: comments on draft-ietf-ltans-pki-retention-00.txt
References: <2666EB2A846BAC4BB2D7F593301A7868101F8A@MUCXGC2.opentext.net>
In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868101F8A@MUCXGC2.opentext.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.6
X-Originating-IP: 12.149.86.66
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Haven't yet got the time to read the draft but some comments inline.

>
> <snip>
> > So the first thing will be to define the adequate
> > certificate/PKI/ policy  for your needs and then decide abou
> > the necessary cert.
> > management structure. Legally spoken: it is my responsibility
> > to store the necessary verification data, how I will do that,
> > should remain in my responsibility. Having said this, I do
> > not think this should be part of the LTANS standard.
>
> Do you think LTANS specs can play a role here, i.e., ERS?  If not, what
> specs apply?  The retention spec defines an optional binding between
> certs and evidence records that enables you to fulfill your
> responsibility of preserving the necessary verification data.

No, I don't thnik ERS should have anything to do with retetnion. IMO, this is
pure process managerial issue and should be binded to the archive objects build
of several parts (see the LTAP slides for Dallas), namely:

- archive data
- metainformation (including operation information, sec. attributes, etc.)
- ERS

  It's not
> clear to me that certs must be preserved as part of a signed data object
> especially since not doing this has significant benefit, e.g., storage
> savings and decoupling trust anchors from signed data.
> </snip>

Law requirments usually clearly specify the availability of 'complementary'
information needed for security attributes validation in time (and this issue
is addressed by by RFC3126 and its XML interpretation (XAdES), however from
different perspective than ERS). Such information may be obtained on request or
be part of the archive object. The problem is the availability and integrity.
Such information may cease to exist for whatever reason, including decomposing
CA. Henece the need to place it next to archive data. But you are right, this
is storage saving issue also. So one may simply use pointers for example, while
use ERS to demonstrate integrity.

>
> Not an answer but a comment to this question:
> I agree with Carl in the point that the retention of certificates etc.
> is important and that it would be good to have this at a central point.
> At the first glance it might even be better located in PKIX - on the
> other side  the charter of LTANS "Long term archiving and notary
> services" does in my eyes not exclude such a spec AND which is most
> important it is an important (at the moment not really specified part)
> of the puzzle for an application for long term storage of signed
> documents.

Another problem with retention period is that it may change. So placing this
information on a specific place does rise some issues. This is why I think it
is an archive data handling information.

Aleksej



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EFoeSg096837; Tue, 14 Mar 2006 08:50:40 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EFoeKs096836; Tue, 14 Mar 2006 08:50:40 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EFocxc096830 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 08:50:39 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2EFobLt016515; Tue, 14 Mar 2006 16:50:37 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: comments on draft-ietf-ltans-pki-retention-00.txt
Date: Tue, 14 Mar 2006 16:50:36 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A7868101F8A@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: comments on draft-ietf-ltans-pki-retention-00.txt
Thread-Index: AcYtUsOrmebO7tOLTbKwELOR1y4rVgAGsmEgBoQwF4A=
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Carl Wallace" <cwallace@orionsec.com>, <bruno@wildhaber.com>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2EFodxc096831
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

<snip>
> So the first thing will be to define the adequate 
> certificate/PKI/ policy  for your needs and then decide abou 
> the necessary cert.  
> management structure. Legally spoken: it is my responsibility 
> to store the necessary verification data, how I will do that, 
> should remain in my responsibility. Having said this, I do 
> not think this should be part of the LTANS standard.

Do you think LTANS specs can play a role here, i.e., ERS?  If not, what
specs apply?  The retention spec defines an optional binding between
certs and evidence records that enables you to fulfill your
responsibility of preserving the necessary verification data.  It's not
clear to me that certs must be preserved as part of a signed data object
especially since not doing this has significant benefit, e.g., storage
savings and decoupling trust anchors from signed data.
</snip>


Not an answer but a comment to this question:
I agree with Carl in the point that the retention of certificates etc.
is important and that it would be good to have this at a central point. 
At the first glance it might even be better located in PKIX - on the
other side  the charter of LTANS "Long term archiving and notary
services" does in my eyes not exclude such a spec AND which is most
important it is an important (at the moment not really specified part)
of the puzzle for an application for long term storage of signed
documents.

Tobias




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EFWvEO095741; Tue, 14 Mar 2006 08:32:57 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EFWvOl095740; Tue, 14 Mar 2006 08:32:57 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EFWuqQ095734 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 08:32:56 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2EFWsLt016277; Tue, 14 Mar 2006 16:32:55 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: LTANS: Examples of ERS data - cross checking of implementations
Date: Tue, 14 Mar 2006 16:32:53 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A7868101F80@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: LTANS: Examples of ERS data - cross checking of implementations
Thread-Index: AcYwnZ5TQg7NNeQuTnacKZYSVMrhWgW3XTcQ
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>, "Adrian Frei" <frr@zhwin.ch>
Cc: "Tilo Kienitz" <tk-tlslist@seccommerce.de>, <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2EFWvqQ095735
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

And again sorry for the late answer.

At first: Adrian is completely right: just for simplicity IXOS
homogenized the tree to binary, ternary, or whatever is configured.
(in the server it can usually be configured special attributes of the
tree (size, number of objects, number of levels, magnitude, ...) 
(note: although we found no significant reason for more than binary
trees at the higher levels)

Second: as Thomas pointed out, it can not be distinguished whether the
hash values in the first sequence form a semantically important group or
are just by coincident members of a data object group (e.g. because the
system by default collects a certain number (e.g. here 3) of objects to
groups.

Actually I see here no problem. Semantic must be handled by the
client/application any way: It will be up to the verification client to
decide whether it wants to verify a single or multiple single objects or
a complete data group.

Tobias



-----Original Message-----
From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz
Sent: Monday, February 13, 2006 1:56 PM
To: Adrian Frei
Cc: Tilo Kienitz; ietf-ltans@imc.org
Subject: Re: LTANS: Examples of ERS data - cross checking of
implementations


Adrian Frei wrote:
> Thomas Kunz wrote:
> 
>>Tilo Kienitz wrote:
>>
>>>Hello,
>>>
>>>Frei Adrian (frr) wrote:
>>>
>>>
>>>>Hmm, I think you misunderstood the generation of the reduced hash
tree
>>>>(I-D 3.2). The five lists in IXOS' hash tree are not five data
object
>>>>groups; they are five levels of the hash tree. The tree looks like 
>>>
>>> > this:
>>>
>>>
>>>>                    ROOT
>>>>                      |                                      \   \
>>>>                    YYYY                                   f79a 0000
>>>>                      |                            \   \    /|\
>>>>                    YYYY                          c414 3413 
>>>>                      |                    \   \   /|\ /|\
>>>>                    YYYY                 cf18 6ba0
>>>>       /              |             \     /|\ /|\
>>>>     YYYY (c4a8)    b837           46d8
>>>>  /    |   \     /    |   \     /    |   \
>>>>51b1 5bd0 60bb XXXX XXXX XXXX XXXX XXXX XXXX
>>>>data obj grp 1 data obj grp 2 data obj grp 3
>>>
>>>
>>>Thank you for the explanation. If it is really meant to encode this
>>>tree in the way the Ixos-example dit it, then how would it be
possible
>>>to encode the tree if I wanted to include the complete "data obj grp
2"
>>>too? In the simple case that I only want to proove that a certain,
>>>single data object exists in the tree, only a single data object
group
>>>has to be included in the reduced hash tree and the Ixos-encoding
works
>>>fine. But let "data obj grp 1" contain the hash over the signature of
>>>a document and "data obj grp 2" the hash over the OCSP response for
the
>>>certificate of the person who signed the document. Then I would like
>>>to have both hashes in the same reduced hash tree. Of course I could
>>>create two independent evidence records where each contains the
reduced
>>>hash tree for one of the hashes. But it would be good to have every-
>>>thing relating to one document (sig hash and OCSP response hash) in
the
>>>same evidence record.
>>>
>>
>>You have always different evidence records for every data object group

>>in the hash tree. If you would like to have the hash over the
signature 
>>and the hash over the ocsp response in the same reduced hash tree, you

>>should build a data object group containing these two hashes. In the 
>>example above, "data obj grp 1" consists of three (data object)
hashes, 
>>but a data object group can be of arbitrary size, independent of
having 
>>a binary tree, a ternary tree or whatever tree.
> 
> 
> Ok, sorry, actually the three leafs in the IXOS tree are all single
> object groups with only a single object, which means the text in my
> diagram is wrong. However, it could have been otherwise.
> 
The text in your diagram is not necessarily wrong. As I pointed out in 
another thread in this mailing list, if you have a ternary tree and the 
first list of hash values in the reduced hashtree contains three hashes,

you can't unambiguously detemine if you have a object group containing 
only one data object hash (and the other two hashes a simply siblings) 
or a data object group containing three data object hashes (the same 
e.g. in the case of a binary tree and two hash values in the first
list).
Of course, since IXOS provided only one document together with the 
evidence record, we can assume that the group consists only of one 
document hash.

Regards,
Thomas





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EEv1wj094249; Tue, 14 Mar 2006 07:57:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EEv1lE094248; Tue, 14 Mar 2006 07:57:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EEuxWw094242 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 07:57:00 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2EEuw2Y007938; Tue, 14 Mar 2006 15:56:58 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: LTANS-ERS: Verification and data groups
Date: Tue, 14 Mar 2006 15:56:57 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A7868101F57@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: LTANS-ERS: Verification and data groups
Thread-Index: AcYrAkl+sM2T+wb5Txu0CEFsUdtfEAcc2t8w
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2EEv0Ww094243
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello Thomas, Greg and Susanne,

and sorry for the delayed answer.

Yes, it is up to the client to decide which data should be pooled.
In fact all the client needs to know is that a data object group needs to be verified. Because verification procedure states in section 3.3
" If an additional proof is necessary that the Archive Time-Stamp relates to
   a data object group (e.g. a document and all its signatures) it can
   be verified additionally, that only the hash values of the given data
   objects are in the first hash value list."

This clearly gives an exact information about the needed number of the members in case of the verification of a data object group: equals exactly the number of objects in the first sequence.
First it is possible to verify the integrity of every single object independently, which is the most important issue and also possible to verify a data object group if this is wished. Of course the client needs to know that he wants to verify a complete data object group (in one atomic call) and not only every single object individually)

Tobias


Ps.: note: please note that the specification does EXPLICITLY leave it to the system to organize the number of hash values in each sequence. (and it is also NOT specified how many are in each layer of the tree - so in the maximum variety, the tree is not limited e.g. to binary tree, but could be of sequences of different length at every level and even within every level could have different number of hash values grouped together.



-----Original Message-----
From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz
Sent: Monday, February 06, 2006 10:39 AM
To: ietf-ltans@imc.org
Subject: Re: LTANS-ERS: Verification and data groups


Of course it is up to the client to decide which data object should be 
pooled into a group and which not. But a verification component should 
be able to unambiguously decide if a document group is complete or not.
With the structure I sketched, verification of a single data object is 
still possible, but additionally it can be verified if the group is 
complete.

Regards,
Thomas


Greg Werner wrote:
> In Mexico several banks, such as BBVA and HSBC, for example, have expressed interest in using a system that allows them to batch several documents into one group and segregate other documents, such as sensitive contracts, as single objects. As Jerman states below their reason to count on a system to verify single objects will depend on their specific needs, in this case it would be to mitigate legal risks.
> 
> Regards,
> 
> Greg Werner CISSP
> Advantage Security
> Tel. +52 55 5081 4366
> 
> -----Mensaje original-----
> De: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] En nombre de A. Jerman Blazic
> Enviado el: viernes, 03 de febrero de 2006 7:26
> Para: 'Carl Wallace'; 'Thomas Kunz'; 'Susanne Okunick'
> CC: ietf-ltans@imc.org
> Asunto: RE: LTANS-ERS: Verification and data groups
> 
> 
> That is correct. It is up to the client to decide which data should be
> grouped or not and this is included in the LTAP specification. Please bare
> in mind that grouping can happen for whatever reason: logically,
> semantically or any particular reason defined by a client (e.g. data
> accompanied with the meta data). However, verification of a single object
> MUST be possible at any time. Otherwise a service might hit scalability and
> confidentiality problems (imagine a case focused on specific document to be
> presented to the court and a case when such document is a group member...). 
> 
> 
>>-----Original Message-----
>>From: owner-ietf-ltans@mail.imc.org 
>>[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
>>Sent: 3. februar 2006 13:00
>>To: Thomas Kunz; Susanne Okunick
>>Cc: ietf-ltans@imc.org
>>Subject: RE: LTANS-ERS: Verification and data groups
>>
>>
>>If I recall correctly, this was to have been a feature of 
>>LTAP, i.e., at submission time a client could request that 
>>the data being submitted not be lumped into a larger 
>>grouping.  This is a different than what you've suggested but 
>>achieves a similar end.  If LTAP is foregone in favor of a 
>>binding to an existing protocol, like WebDAV, or 
>>directly-managed ERS structures, like in the ERS/SCVP draft 
>>where the SCVP server performs all of the maintenance, then 
>>the sort of structure you propose makes more sense to meet 
>>the grouping requirement.  I'm not sure it's a good idea to 
>>verify an evidence record without verifying each document in 
>>the group.
>>
>>
>>>-----Original Message-----
>>>From: owner-ietf-ltans@mail.imc.org
>>>[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz
>>>Sent: Friday, February 03, 2006 3:15 AM
>>>To: Susanne Okunick
>>>Cc: ietf-ltans@imc.org
>>>Subject: Re: LTANS-ERS: Verification and data groups
>>>
>>>
>>>Hello,
>>>
>>>I agree with Susanne. A solution could be to change the ASN.1 
>>>structure of the ArchiveTimestamp. The hash values of the data 
>>>object(s) could be stored in a separate sequence of octet 
>>
>>strings and 
>>
>>>the first list of the reduced hashtree only holds the hash 
>>
>>values of 
>>
>>>the siblings of the data object node. So the size of the 
>>
>>data object 
>>
>>>group can unambiguously determined.
>>>Perhaps the authors of the draft can give an opinion to 
>>
>>that problem?
>>
>>>Best regards,
>>>Thomas
>>>
>>>
>>>Susanne Okunick wrote:
>>>
>>>>Hello,
>>>>
>>>>At the verification of evidence records I get into difficulty. I 
>>>>think, sometimes the verification for data groups is not
>>>
>>>practicable!
>>>
>>>>For data groups consisting of more than one documents the 
>>
>>following 
>>
>>>>points have to be checked (compare example in the draft;
>>>
>>>page 10,11):
>>>
>>>>a) check whether the hash value of each data object is within the 
>>>>first sequence SEQ(h2b,h2c,h2a) in the reduced hashtree (
>>>
>>>h2b,h2c,h2a)
>>>
>>>>b) check whether the document group is complete. That
>>>
>>>means: All data
>>>
>>>>objects have to be available at the time of verification
>>>
>>>(d2a,d2b,d2c).
>>>
>>>>If a data group consits of five documents, I will need all five 
>>>>documents for the entire successfull verification.
>>>>
>>>>The first sequence of every reduced binary hashtree 
>>
>>consists of *at
>>
>>>>least* two hash values.
>>>>This is for 1) one data object or 2) a data group consisting of 
>>>>exactly two data objects!
>>>>My question: How to identify the right case?
>>>>
>>>>Assuming the following simple reduced binary hashtree:
>>>>[[h1a,h1b][h2][h3]]
>>>>
>>>>For verification you have to calculate the root of hash (h123):
>>>>h123=H( binary sorted and concatenated (h12, h3) ) h12=H( binary 
>>>>sorted and concatenated (h1ab, h2) ) | h3 h1ab = H( binary
>>>
>>>sorted and
>>>
>>>>concatenated (h1a, h1b) ) | h2 h1a | h1b
>>>>
>>>>Now there are two possibilities:
>>>>1) h1a and h1b don't build a data group => for whole
>>>
>>>verification you
>>>
>>>>need the data object "d1a" to show that the data object's
>>>
>>>hash value
>>>
>>>>is "h1a"
>>>>2) h1a and h1b are data objects of one data group => for
>>>
>>>verification
>>>
>>>>both data objects d1a and d1b must be available and you
>>>
>>>have to show
>>>
>>>>that both hash values are correctly computed
>>>>
>>>>Thus you never know (in case of having two hash values in 
>>
>>the first 
>>
>>>>sequence of reduced binary hashtree), whether one or two 
>>
>>documents 
>>
>>>>needed for verification.
>>>>
>>>>Best regards,
>>>>Susanne
>>>>
>>>>P. S. In case of ternary hashtrees there is the same
>>>
>>>problem: Do you
>>>
>>>>need one or three documents for correct verification?
>>>>
>>>
>>>
>>>--
>>>------------------------------------------------------------
>>>Dipl. Inf. Thomas Kunz
>>>Fraunhofer-Institut für Sichere Informationstechnologie SIT 
>>>Rheinstrasse 75
>>>D-64295 Darmstadt (Germany)
>>>Tel: +49-6151-869-60204
>>>------------------------------------------------------------
>>>e-mail: thomas.kunz@sit.fraunhofer.de
>>>
>>>http://www.sit.fraunhofer.de
>>>------------------------------------------------------------
>>>
>>>
>>
> 
> 
> 


-- 
------------------------------------------------------------
Dipl. Inf. Thomas Kunz
Fraunhofer-Institut für Sichere Informationstechnologie SIT
Rheinstrasse 75
D-64295 Darmstadt (Germany)
Tel: +49-6151-869-60204
------------------------------------------------------------
e-mail: thomas.kunz@sit.fraunhofer.de

http://www.sit.fraunhofer.de
------------------------------------------------------------




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EDc2Sq090723; Tue, 14 Mar 2006 06:38:02 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EDc2cn090722; Tue, 14 Mar 2006 06:38:02 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EDc0eZ090716 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 06:38:01 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2EDbhMR014521; Tue, 14 Mar 2006 14:37:59 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Agenda slot
Date: Tue, 14 Mar 2006 14:30:29 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A7868101F29@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Agenda slot
Thread-Index: AcY+NSr04Oijzx9wQ6ukCNc5GuxyqwJNS4UA
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: <ietf-ltans@imc.org>
Cc: "Carl Wallace" <cwallace@orionsec.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2EDc1eZ090717
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Thanks a lot.

This is great and I will be happy to participate via Jabber at our
meeting next Monday!

9:00 - 11:30 Dallas local time (CST) (UTC-6)
16:00 - 18:30 Alpha-time (CET, MET) (UTC+1)  - Central Europe
15:00 - 17:30 Zulu-time (GMT) (UTC+0)  - UK

Tobias




-----Original Message-----
From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
Sent: Thursday, March 02, 2006 9:16 PM
To: ietf-ltans@imc.org
Subject: Agenda slot


Folks,

The LTANS slot for the upcoming IETF meeting has been moved.  It is now
scheduled for the 1850-1950 time slot on Monday, March 20th.  The draft
agenda has been posted.  FYI, for the first time, we will have someone
acting as a Jabber scribe so remote participation is feasible.  

Carl




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ECJbbt087683; Tue, 14 Mar 2006 05:19:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ECJbG2087682; Tue, 14 Mar 2006 05:19:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ECJZUN087675 for <ietf-ltans@imc.org>; Tue, 14 Mar 2006 05:19:36 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k2ECJKU1003570; Tue, 14 Mar 2006 13:19:20 +0100 (MET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: IS&T Archiving 2006
Date: Tue, 14 Mar 2006 13:19:19 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A7868101EEE@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IS&T Archiving 2006
Thread-Index: AcZFhNESP5fgCiFcS1af0lzVqweqlQB2kimQ
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Larry Masinter" <LMM@acm.org>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k2ECJaUN087677
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello Larry,

thanks for the link to your Archiving presentation. 
Reads very interesting. 

Your point about how to avoid the problems with encrypted confidential
(private) document in an archive by using the concept of the secret
sharing (N, K) for confidential data sounds interesting, though at the
moment I am not sure I fully understand the implications, because in
this case you have to find the balance between secure the availability
of the data (protection against data loss) and confidentiality -
preventing access to too many stores....

Unfortunately for my understanding the shared secret concept has one
severe weakness: it does not prevent theowner of the system to retrieve
data and read it. (in case of encrypted data the key can be disclosed
only to the document owner and NOT to the system owner. Of course for
indefinite times of confidentiality (or even starting with 10 years
plus) it is not sure the the encryption is strong and secure enough for
this requirement. Maybe it also makes sense to combine encryption with
shared secret (respective distributed content)?

Second and interesting thing is that you mention the collection of
metadata before sending documents and their metadata in an atomar blob
to a long term archive (for notary and other services). I encountered
this requirement for metadata in nearly all other use cases and it seems
to me a very important point for long term archive systems. 

Tobias




-----Original Message-----
From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry Masinter
Sent: Sunday, March 12, 2006 4:27 AM
To: ietf-ltans@imc.org
Subject: IS&T Archiving 2006


Sorry I won't be in Dallas...

FYI, you might be interested in Archiving 2006 conference,
   http://www.imaging.org/conferences/archiving2006/
Preliminary program has been posted.

My paper is
 http://larry.masinter.net/0603-archiving.pdf


Larry




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2C3RR1s045404; Sat, 11 Mar 2006 20:27:27 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2C3RRSY045403; Sat, 11 Mar 2006 20:27:27 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from exprod6og11.obsmtp.com (exprod6og11.obsmtp.com [64.18.1.23]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2C3RQM5045395 for <ietf-ltans@imc.org>; Sat, 11 Mar 2006 20:27:26 -0700 (MST) (envelope-from LMM@acm.org)
Received: from source ([192.150.20.142]) by exprod6ob11.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 11 Mar 2006 19:27:25 PST
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k2C3RU46003746 for <ietf-ltans@imc.org>; Sat, 11 Mar 2006 19:27:31 -0800 (PST)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k2C3RGHV001328 for <ietf-ltans@imc.org>; Sat, 11 Mar 2006 19:27:22 -0800 (PST)
Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IVZ00IBUW9GIJ@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Sat, 11 Mar 2006 19:27:16 -0800 (PST)
Received: from MasinterT43p ([10.7.241.95]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IVZ00IQ4W9GX9@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Sat, 11 Mar 2006 19:27:16 -0800 (PST)
Date: Sat, 11 Mar 2006 19:26:57 -0800
From: Larry Masinter <LMM@acm.org>
Subject: IS&T Archiving 2006
To: ietf-ltans@imc.org
Message-id: <000c01c64584$d15c6210$04000200@corp.adobe.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT
Thread-index: AcZFhNESP5fgCiFcS1af0lzVqweqlQ==
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Sorry I won't be in Dallas...

FYI, you might be interested in Archiving 2006 conference,
   http://www.imaging.org/conferences/archiving2006/
Preliminary program has been posted.

My paper is
 http://larry.masinter.net/0603-archiving.pdf


Larry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k26L0K1F026294; Mon, 6 Mar 2006 14:00:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k26L0KiN026293; Mon, 6 Mar 2006 14:00:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k26L0Krr026285 for <ietf-ltans@imc.org>; Mon, 6 Mar 2006 14:00:20 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Agenda slot
Date: Mon, 6 Mar 2006 13:07:17 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C879018FF78D@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Agenda slot
Thread-Index: AcZBKLzSgAUPrwX3SWiJnoQk2NsrHgAN3iMg
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k26L0Krr026288
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Note, the meeting time has changed.  The LTANS session is now scheduled
for 0900-1130 on Monday.  This change should enable more remote
participation.  Note, the time slot is more than 1 hour now, so if
discussions run long there's no problem and there's plenty of time for
additional presentations.  Let me know if you'd like some time on the
agenda.

> -----Original Message-----
> From: Young H. Etheridge [mailto:yhe@yhetheridge.org] 
> Sent: Monday, March 06, 2006 9:11 AM
> To: Carl Wallace
> Cc: ietf-ltans@imc.org
> Subject: Re: Agenda slot
> 
> Thanks, Carl.
> 
> As instructed everything works very well.  I look forward to 
> the session.
> 
> yhe
> 
> Carl Wallace wrote:
> > http://www.xmpp.org/ietf-chat.html has the details for 
> participating 
> > via Jabber.  Note, the LTANS room is currently mis-identified as 
> > LTRANS. The published time (18:50) is CST, which is GMT-6.  
> I'm still 
> > trying to get us an earlier slot but that seems unlikely.
> >
> >   
> >> -----Original Message-----
> >> From: Young H. Etheridge [mailto:yhe@yhetheridge.org]
> >> Sent: Friday, March 03, 2006 9:32 AM
> >> To: Carl Wallace
> >> Cc: ietf-ltans@imc.org
> >> Subject: Re: Agenda slot
> >>
> >> Carl,
> >>
> >> I assume that the published time is CST (GMT - 6:00)?  
> Will someone 
> >> publish a Jabber logistic for this session?
> >>
> >> Thanks,
> >>
> >> yhe
> >>     
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k26Ko9KV025551; Mon, 6 Mar 2006 13:50:09 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k26Ko9Tg025550; Mon, 6 Mar 2006 13:50:09 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k26Ko8GF025534 for <ietf-ltans@imc.org>; Mon, 6 Mar 2006 13:50:09 -0700 (MST) (envelope-from ietf@ietf.org)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko20e011145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMeY-00057c-BD; Mon, 06 Mar 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: ietf-ltans@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ltans-ltap-01.txt 
Message-Id: <E1FGMeY-00057c-BD@stiedprstage1.ietf.org>
Date: Mon, 06 Mar 2006 15:50:02 -0500
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--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		: Long-term Archive Protocol (LTAP)
	Author(s)	: A. Jerman-Blazic, et al.
	Filename	: draft-ietf-ltans-ltap-01.txt
	Pages		: 39
	Date		: 2006-3-6
	
This document describes a service operated as a trusted third party
   to securely archive electronic document called a long-term archive
   service (LTA).  We describe an architecture framework and a protocol
   allowing clients to interact with such a service.  Bindings to
   concrete transport and security protocol layers are given.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org 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-ltap-01.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-ltap-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2006-3-6114430.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2006-3-6114430.I-D@ietf.org>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k26EAlEl005884; Mon, 6 Mar 2006 07:10:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k26EAlQZ005883; Mon, 6 Mar 2006 07:10:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from burrens.yandk.org (yhetheridge.org [64.139.78.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k26EAk9t005876 for <ietf-ltans@imc.org>; Mon, 6 Mar 2006 07:10:46 -0700 (MST) (envelope-from yhe@yhetheridge.org)
Received: from [192.168.1.11] (moors.yandk.org [192.168.1.11]) by burrens.yandk.org (Postfix) with ESMTP id 4A7D99DCB; Mon,  6 Mar 2006 09:10:43 -0500 (EST)
Message-ID: <440C42E3.9040405@yhetheridge.org>
Date: Mon, 06 Mar 2006 09:10:43 -0500
From: "Young H. Etheridge" <yhe@yhetheridge.org>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Carl Wallace <cwallace@orionsec.com>
Cc: ietf-ltans@imc.org
Subject: Re: Agenda slot
References: <82D5657AE1F54347A734BDD33637C879018FEBE0@EXVS01.ex.dslextreme.net>
In-Reply-To: <82D5657AE1F54347A734BDD33637C879018FEBE0@EXVS01.ex.dslextreme.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Thanks, Carl.

As instructed everything works very well.  I look forward to the session.

yhe

Carl Wallace wrote:
> http://www.xmpp.org/ietf-chat.html has the details for participating via
> Jabber.  Note, the LTANS room is currently mis-identified as LTRANS. The
> published time (18:50) is CST, which is GMT-6.  I'm still trying to get
> us an earlier slot but that seems unlikely.
>
>   
>> -----Original Message-----
>> From: Young H. Etheridge [mailto:yhe@yhetheridge.org] 
>> Sent: Friday, March 03, 2006 9:32 AM
>> To: Carl Wallace
>> Cc: ietf-ltans@imc.org
>> Subject: Re: Agenda slot
>>
>> Carl,
>>
>> I assume that the published time is CST (GMT - 6:00)?  Will 
>> someone publish a Jabber logistic for this session?
>>
>> Thanks,
>>
>> yhe
>>     



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k25D1mIm043942; Sun, 5 Mar 2006 06:01:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k25D1lc9043941; Sun, 5 Mar 2006 06:01:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k25D1lRC043929 for <ietf-ltans@imc.org>; Sun, 5 Mar 2006 06:01:47 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Agenda slot
Date: Sun, 5 Mar 2006 05:08:18 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C879018FEBE0@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Agenda slot
Thread-Index: AcY+0CC5QH2DR77aSvmX+5B8qCq34QBga9ZQ
From: "Carl Wallace" <cwallace@orionsec.com>
To: "Young H. Etheridge" <yhe@yhetheridge.org>
Cc: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k25D1lRC043936
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

http://www.xmpp.org/ietf-chat.html has the details for participating via
Jabber.  Note, the LTANS room is currently mis-identified as LTRANS. The
published time (18:50) is CST, which is GMT-6.  I'm still trying to get
us an earlier slot but that seems unlikely.

> -----Original Message-----
> From: Young H. Etheridge [mailto:yhe@yhetheridge.org] 
> Sent: Friday, March 03, 2006 9:32 AM
> To: Carl Wallace
> Cc: ietf-ltans@imc.org
> Subject: Re: Agenda slot
> 
> Carl,
> 
> I assume that the published time is CST (GMT - 6:00)?  Will 
> someone publish a Jabber logistic for this session?
> 
> Thanks,
> 
> yhe



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23EVlmQ047472; Fri, 3 Mar 2006 07:31:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k23EVlOb047471; Fri, 3 Mar 2006 07:31:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from burrens.yandk.org (yhetheridge.org [64.139.78.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k23EVjAq047465 for <ietf-ltans@imc.org>; Fri, 3 Mar 2006 07:31:46 -0700 (MST) (envelope-from yhe@yhetheridge.org)
Received: from [192.168.1.11] (moors.yandk.org [192.168.1.11]) by burrens.yandk.org (Postfix) with ESMTP id 3719410477; Fri,  3 Mar 2006 09:31:45 -0500 (EST)
Message-ID: <44085351.70601@yhetheridge.org>
Date: Fri, 03 Mar 2006 09:31:45 -0500
From: "Young H. Etheridge" <yhe@yhetheridge.org>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Carl Wallace <cwallace@orionsec.com>
Cc: ietf-ltans@imc.org
Subject: Re: Agenda slot
References: <82D5657AE1F54347A734BDD33637C8790184B7F1@EXVS01.ex.dslextreme.net>
In-Reply-To: <82D5657AE1F54347A734BDD33637C8790184B7F1@EXVS01.ex.dslextreme.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Carl,

I assume that the published time is CST (GMT - 6:00)?  Will someone 
publish a Jabber logistic for this session?

Thanks,

yhe

Carl Wallace wrote:
> Folks,
>
> The LTANS slot for the upcoming IETF meeting has been moved.  It is now
> scheduled for the 1850-1950 time slot on Monday, March 20th.  The draft
> agenda has been posted.  FYI, for the first time, we will have someone
> acting as a Jabber scribe so remote participation is feasible.  
>
> Carl
>
>   



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22K9HDY008484; Thu, 2 Mar 2006 13:09:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k22K9HKL008483; Thu, 2 Mar 2006 13:09:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22K9H1M008476 for <ietf-ltans@imc.org>; Thu, 2 Mar 2006 13:09:17 -0700 (MST) (envelope-from cwallace@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Agenda slot
Date: Thu, 2 Mar 2006 12:15:38 -0800
Message-ID: <82D5657AE1F54347A734BDD33637C8790184B7F1@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Agenda slot
thread-index: AcY+NSr04Oijzx9wQ6ukCNc5Guxyqw==
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k22K9H1M008478
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Folks,

The LTANS slot for the upcoming IETF meeting has been moved.  It is now
scheduled for the 1850-1950 time slot on Monday, March 20th.  The draft
agenda has been posted.  FYI, for the first time, we will have someone
acting as a Jabber scribe so remote participation is feasible.  

Carl