Subject: LTANS-ERS: Verification and data groups
From: Susanne Okunick <[email-masked]>
To: [email-masked]
Date: Wed, 25 Jan 2006 15:43:10 +0100
List-Id: <ietf-ltans.imc.org>

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.-Math.(FH) Susanne Okunick
Fraunhofer Institute for Secure Information Technology
Department Transaction and Document Security
Rheinstraße 75, 64295 Darmstadt, Germany
phone ++49 / (0)6151 869 60220, fax ++49 / (0)6151 869 322
email: [email-masked]
homepage: http://www.sit.fraunhofer.de
__________________________________________________________

Content-class: urn:content-classes:message
Subject: AW: LTANS: Examples of ERS data - cross checking of implementations
Date: Fri, 20 Jan 2006 14:53:59 +0100
From: "Frei Adrian \(frr\)" <[email-masked]>
To: "Thomas Kunz" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hello,

Thomas Kunz wrote:
> >>>- How did the concatenation and hashing of the values in the
reduced
> >>>hash tree happen? When I concatenate the three values (51B1...,
> 5BD0...,
> >>>60BB...) in the first list in ascending order an hash them with
> >>>ripemd160, I get no value of the second list (B537..., 46D8...)
> 
> >
> > Are you (or Susanne) the one who wrote the implementation which
> > generated the evidence record or did you try to verify the record
with
> > your own implementation? My Problem is, that if I concatenate and
hash
> > the 3 values of the first level of the hash tree I don't get a value
of
> > the second level.
> >
> The procedure how to concatenate and hash the values in the reduced
> hashtree is decribed in section 3.3 of the I-D.
> You concatenate the three values (51B1..., 5BD0..., 60BB...) in the
> first list in ascending order an hash them with ripemd160. This hash
> becomes member of the second list (B537..., 46D8...). Now you
> concatenate these three hash values (the two in the list and the
> calculated one) and hash them, etc. Continue this procedure until the
> root hash is calculated. This root hash must correspond to the hashed
> message in the timestamp.
> 

Oh, stupid me. The "must become member of" and the fact that the digest
of the document is included in the hash tree must have confused me a
bit...

Well, thanks a lot; I was able to verify the first archiveTimeStamp.

Unfortunately I can't verify the whole evidence record; it seems that
the .NET cms implementation does only support md5 and sha1 as a hashing
algorithm. Might it be possible for one of you to provide an additional
ER/document-pair? 

Thanks,

Adrian

Content Security by MailMarshal

Date: Thu, 19 Jan 2006 16:53:07 +0100
From: Thomas Kunz <[email-masked]>
To: Adrian Frei <[email-masked]>
CC: [email-masked]
Subject: Re: LTANS: Examples of ERS data - cross checking of implementations
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Adrian,

Adrian Frei wrote:

>>>- How did the concatenation and hashing of the values in the reduced
>>>hash tree happen? When I concatenate the three values (51B1..., 5BD0...,
>>>60BB...) in the first list in ascending order an hash them with
>>>ripemd160, I get no value of the second list (B537..., 46D8...)

> 
> Are you (or Susanne) the one who wrote the implementation which
> generated the evidence record or did you try to verify the record with
> your own implementation? My Problem is, that if I concatenate and hash
> the 3 values of the first level of the hash tree I don't get a value of
> the second level.
> 
The procedure how to concatenate and hash the values in the reduced 
hashtree is decribed in section 3.3 of the I-D.
You concatenate the three values (51B1..., 5BD0..., 60BB...) in the 
first list in ascending order an hash them with ripemd160. This hash 
becomes member of the second list (B537..., 46D8...). Now you 
concatenate these three hash values (the two in the list and the 
calculated one) and hash them, etc. Continue this procedure until the 
root hash is calculated. This root hash must correspond to the hashed 
message in the timestamp.

Regards,

Thomas

------------------------------------------------------------
Dipl. Inf. Thomas Kunz
Fraunhofer-Institut für Sichere Informationstechnologie SIT
Rheinstrasse 75
D-64295 Darmstadt (Germany)
Tel: +49-6151-869-60204
------------------------------------------------------------
e-mail: [email-masked]

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

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

--------------ms090108010303050501090701--

Subject: RE: LTANS: Examples of ERS data - cross checking of implementations
From: Adrian Frei <[email-masked]>
To: [email-masked]
Date: Thu, 19 Jan 2006 15:58:41 +0100
Sender: [email-masked]

Hello,

Thanks for the answers so far.

Santosh Chokhani wrote:
> >- How did the concatenation and hashing of the values in the reduced
> >hash tree happen? When I concatenate the three values (51B1..., 5BD0...,
> >60BB...) in the first list in ascending order an hash them with
> >ripemd160, I get no value of the second list (B537..., 46D8...)
> >
> [Santosh Chokhani] I do not understand this issue.

Are you (or Susanne) the one who wrote the implementation which
generated the evidence record or did you try to verify the record with
your own implementation? My Problem is, that if I concatenate and hash
the 3 values of the first level of the hash tree I don't get a value of
the second level.

Susanne Okunick wrote:
> >- Why doesn't the second ArchivTimeStamp in the first
> >ArchiveTimeStampChain contain a reduced hash tree? According to 4.3.2 in
> >the draft "The first hash value list of each ArchiveTimeStamp must
> >contain the hash value of the timestamp of the Archive Time-Stamp
> >before".
> >  
> I think, generally every ArchiveTimeStamp contains a reducedHashtree. 
> But if there is only one data object, the data object hash = hashed 
> message in the timestamp and no reducedHashtree is needed, so 
> reducedHashtree=NULL.

Ok, I thought that too. But then 4.3.2. should be changed. And speaking
of the absence of a reducedHashTree; 3.1 (last sentence in
reducedHashtree paragraph) is also a bit unclear.

> >- As a more general question: How is 4.2.3 in the draft meant? Do I have
> >to hash the ArchiveTimeStampSequence or just the concatenated
> >ArchiveTimeStampChains? I think there is a difference between the two
> >things since the encoded ArchiveTimeStampSequence would include
> >additional sequence and length tags.
> >  
> In our implementation we hash the ArchiveTimeStampSequence. (Yes, there 
> is a difference).

Hmm, two answers, two opinions. I also took the complete
ArchiveTimeStampSequence, but I think the draft should clarify this
issue.

Regards,

Adrian

Content Security by MailMarshal

Date: Thu, 19 Jan 2006 13:42:29 +0100
From: Susanne Okunick <[email-masked]>
To: [email-masked]
Subject: RE: LTANS: Examples of ERS data - cross checking of implementations
Sender: [email-masked]

Hello,

my answer to the questions:

>- Why doesn't the second ArchivTimeStamp in the first
>ArchiveTimeStampChain contain a reduced hash tree? According to 4.3.2 in
>the draft "The first hash value list of each ArchiveTimeStamp must
>contain the hash value of the timestamp of the Archive Time-Stamp
>before".
>  
>
I think, generally every ArchiveTimeStamp contains a reducedHashtree. 
But if there is only one data object, the data object hash = hashed 
message in the timestamp and no reducedHashtree is needed, so 
reducedHashtree=NULL.

>- As a more general question: How is 4.2.3 in the draft meant? Do I have
>to hash the ArchiveTimeStampSequence or just the concatenated
>ArchiveTimeStampChains? I think there is a difference between the two
>things since the encoded ArchiveTimeStampSequence would include
>additional sequence and length tags.
>  
>
In our implementation we hash the ArchiveTimeStampSequence. (Yes, there 
is a difference).

Best regards
Susanne

-- 
__________________________________________________________

Dipl.-Math.(FH) Susanne Okunick
Fraunhofer Institute for Secure Information Technology
Department Transaction and Document Security
Rheinstraße 75, 64295 Darmstadt, Germany
phone ++49 / (0)6151 869 60220, fax ++49 / (0)6151 869 322
email: [email-masked]
homepage: http://www.sit.fraunhofer.de
__________________________________________________________

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-pki-retention-00.txt 
Date: Wed, 18 Jan 2006 15:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Infrastructure Support for Retention of PKI Artifacts
	Author(s)	: C. Wallace
	Filename	: draft-ietf-ltans-pki-retention-00.txt
	Pages		: 14
	Date		: 2006-1-18
	
   In most PKIs, directory servers are used to provide current
   certificates and revocation information to relying parties.  In
   situations where certificates must be validated relative to a time in
   the past, relying parties often have no means of obtaining the
   necessary PKI artifacts.  This specification defines several
   directory attributes to support validation using historical PKI
   artifacts.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ltans-pki-retention-00.txt

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

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

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: LTANS: Examples of ERS data - cross checking of implementations
Date: Wed, 18 Jan 2006 08:02:10 -0800
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I would rather see the answers come from the I-D authors.

That said, see my reading of the I-D and security requirements below.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Frei Adrian (frr)
Sent: Tuesday, January 17, 2006 12:04 PM
To: [email-masked]
Subject: RE: LTANS: Examples of ERS data - cross checking of
implementations

Hello,

I'm currently working on my own implementation of ERS and I would be
glad to cross check my implementation with others. 

For now, I've tried to validate the attached data, but had no luck so
far. So I've a few questions:

- How did the concatenation and hashing of the values in the reduced
hash tree happen? When I concatenate the three values (51B1..., 5BD0...,
60BB...) in the first list in ascending order an hash them with
ripemd160, I get no value of the second list (B537..., 46D8...)
[Santosh Chokhani] I do not understand this issue.

- Why doesn't the second ArchivTimeStamp in the first
ArchiveTimeStampChain contain a reduced hash tree?
[Santosh Chokhani] The reason is that since the hash algorithm is still
secure, including the hash of the current time stamp chain

 According to 4.3.2 in
the draft "The first hash value list of each ArchiveTimeStamp must
contain the hash value of the timestamp of the Archive Time-Stamp
before".

- As a more general question: How is 4.2.3 in the draft meant? Do I have
to hash the ArchiveTimeStampSequence or just the concatenated
ArchiveTimeStampChains?
[Santosh Chokhani] I would think that you would need to hash the time
stamp chains.  I agree that the I-D needs to be lot more clearer in
order to ensure interoperability.

 I think there is a difference between the two
things since the encoded ArchiveTimeStampSequence would include
additional sequence and length tags.

Thanks,

Adrian
Content Security by MailMarshal

Content-class: urn:content-classes:message
Subject: RE: LTANS: Examples of ERS data - cross checking of implementations
Date: Tue, 17 Jan 2006 18:04:15 +0100
From: "Frei Adrian \(frr\)" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hello,

I'm currently working on my own implementation of ERS and I would be
glad to cross check my implementation with others. 

For now, I've tried to validate the attached data, but had no luck so
far. So I've a few questions:

- How did the concatenation and hashing of the values in the reduced
hash tree happen? When I concatenate the three values (51B1..., 5BD0...,
60BB...) in the first list in ascending order an hash them with
ripemd160, I get no value of the second list (B537..., 46D8...)

- Why doesn't the second ArchivTimeStamp in the first
ArchiveTimeStampChain contain a reduced hash tree? According to 4.3.2 in
the draft "The first hash value list of each ArchiveTimeStamp must
contain the hash value of the timestamp of the Archive Time-Stamp
before".

- As a more general question: How is 4.2.3 in the draft meant? Do I have
to hash the ArchiveTimeStampSequence or just the concatenated
ArchiveTimeStampChains? I think there is a difference between the two
things since the encoded ArchiveTimeStampSequence would include
additional sequence and length tags.

Thanks,

Adrian
Content Security by MailMarshal

Content-class: urn:content-classes:message
Subject: Comments on draft-ietf-ltans-ers-04
Date: Thu, 5 Jan 2006 11:57:10 -0800
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61232.37208DBC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks,

=20

They say it is better late than never.  The following are my comments on
the version 4 of the ERS draft.  I have provided additional edits (nits
as well as material) to the I-D authors.

=20

Section 1.2, It would be helpful to explain that hash tree is that of
the data only and not time-stamp, albeit, the data could include time
stamp due to hash tree renewal.

=20

Section 1.3, Terminology, The terms "data object" and "data object
group" should be defined in this section.

=20

Section 1.3, Terminology, In the definition of "Archive Time-Stamp
Chain", it should be pointed out that the Archive Time-Stamp Chain is
part of evidence record.

=20

Section 1.3, Terminology, In the definition of "Archive Time-Stamp
Sequence", it should be pointed out that the Archive Time-Stamp Sequence
is part of evidence record.

=20

Section 3.2, Last Sentence (repeated in quotes): "Note [ANSX995],
[I180142] and [I180143] specify irrefutably verifiable time-stamps which
do not depend on certificates, CRLS, or OCSP-Responses for digital
signature verification."  The sentence does not seem correct.  The
phrase "for digital signature verification" should be deleted since in
symmetric key MAC and hash trees, you may not have public keys and hence
PKI artifacts.

=20

Section 3.3, The variable "h" is used to denote different values.  For
example see item 3 in the section.  Other variable names should be
chosen for different variables.

=20

Section 4.2, 3rd paragraph, last sentence (repeated in quotes): The new
Archive Time-Stamp must use the same hash algorithm within its hash-tree
as the old one, which is specified in the hash algorithm field of the
Archive Time-Stamp or within the time-stamp itself".  This is confusing
at two levels.  One, it does not seem that the hash tree needs to be
re-hashed.  The root Hash can be hashed with the time stamp sequence.
Two, it would seem that we would use the hash algorithm defined for the
hash tree as opposed to one for calculating the hash for the time stamp
token signing.

=20

Section 5, This section is still unclear and the implementers will have
problems.  More clarity is needed in all three subsections to ensure
interoperability and security.

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
1489 Chain Bridge Road, Suite 300=20
McLean, Virginia 22101=20
(703) 917-0060  Ext. 35 (voice)=20
(703) 917-0260 (Fax)=20
[email-masked]=20
Visit our Web site=20
http://www.orionsec.com <http://www.orionsec.com> =20

=20

________________________________

------_=_NextPart_001_01C61232.37208DBC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]--><![if !supportAnnotations]>
<style id=3D"dynCom" type=3D"text/css"><!-- --></style>
<script language=3D"JavaScript"><!--
function msoCommentShow(anchor_id, com_id)
{
	if(msoBrowserCheck())=20
		{
		c =3D document.all(com_id);
		a =3D document.all(anchor_id);
		if (null !=3D c && null =3D=3D c.length && null !=3D a && null =3D=3D =
a.length)
			{
			var cw =3D c.offsetWidth;
			var ch =3D c.offsetHeight;
			var aw =3D a.offsetWidth;
			var ah =3D a.offsetHeight;
			var x  =3D a.offsetLeft;
			var y  =3D a.offsetTop;
			var el =3D a;
			while (el.tagName !=3D "BODY")=20
				{
				el =3D el.offsetParent;
				x =3D x + el.offsetLeft;
				y =3D y + el.offsetTop;
				}
			var bw =3D document.body.clientWidth;
			var bh =3D document.body.clientHeight;
			var bsl =3D document.body.scrollLeft;
			var bst =3D document.body.scrollTop;
			if (x + cw + ah / 2 > bw + bsl && x + aw - ah / 2 - cw >=3D bsl )=20
				{ c.style.left =3D x + aw - ah / 2 - cw; }
			else=20
				{ c.style.left =3D x + ah / 2; }
			if (y + ch + ah / 2 > bh + bst && y + ah / 2 - ch >=3D bst )=20
				{ c.style.top =3D y + ah / 2 - ch; }
			else=20
				{ c.style.top =3D y + ah / 2; }
			c.style.visibility =3D "visible";
}	}	}
function msoCommentHide(com_id)=20
{
	if(msoBrowserCheck())
		{
		c =3D document.all(com_id);
		if (null !=3D c && null =3D=3D c.length)
		{
		c.style.visibility =3D "hidden";
		c.style.left =3D -1000;
		c.style.top =3D -1000;
		} }=20
}
function msoBrowserCheck()
{
	ms =3D navigator.appVersion.indexOf("MSIE");
	vers =3D navigator.appVersion.substring(ms + 5, ms + 6);
	ie4 =3D (ms > 0) && (parseInt(vers) >=3D 4);
	return ie4;
}
if (msoBrowserCheck())
{
	document.styleSheets.dynCom.addRule(".msocomanchor","background: =
infobackground");
	document.styleSheets.dynCom.addRule(".msocomoff","display: none");
	document.styleSheets.dynCom.addRule(".msocomtxt","visibility: hidden");
	document.styleSheets.dynCom.addRule(".msocomtxt","position: absolute");
	document.styleSheets.dynCom.addRule(".msocomtxt","top: -1000");
	document.styleSheets.dynCom.addRule(".msocomtxt","left: -1000");
	document.styleSheets.dynCom.addRule(".msocomtxt","width: 33%");
	document.styleSheets.dynCom.addRule(".msocomtxt","background: =
infobackground");
	document.styleSheets.dynCom.addRule(".msocomtxt","color: infotext");
	document.styleSheets.dynCom.addRule(".msocomtxt","border-top: 1pt solid =
threedlightshadow");
	document.styleSheets.dynCom.addRule(".msocomtxt","border-right: 2pt =
solid threedshadow");
	document.styleSheets.dynCom.addRule(".msocomtxt","border-bottom: 2pt =
solid threedshadow");
	document.styleSheets.dynCom.addRule(".msocomtxt","border-left: 1pt =
solid threedlightshadow");
	document.styleSheets.dynCom.addRule(".msocomtxt","padding: 3pt 3pt 3pt =
3pt");
	document.styleSheets.dynCom.addRule(".msocomtxt","z-index: 100");
}
// --></script>
<![endif]>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo4;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo4;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
p.MsoCommentText, li.MsoCommentText, div.MsoCommentText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:Tahoma;}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle23
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>They
say it is better late than never.&nbsp; The following are my comments on =
the
version 4 of the ERS draft.&nbsp; I have provided additional edits (nits =
as
well as material) to the I-D authors.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Section
1.2, It would be helpful to explain that hash tree is that of the data =
only and
not time-stamp, albeit, the data could include time stamp due to hash =
tree
renewal.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Section
1.3, Terminology, The terms &#8220;data object&#8221; and &#8220;data =
object
group&#8221; should be defined in this =
section.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Section
1.3, Terminology, In the definition of &#8220;Archive Time-Stamp =
Chain&#8221;,
it should be pointed out that the Archive Time-Stamp Chain is part of =
evidence
record.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Section
1.3, Terminology, In the definition of &#8220;Archive Time-Stamp
Sequence&#8221;, it should be pointed out that the Archive Time-Stamp =
Sequence
is part of evidence record.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Section
3.2, Last Sentence (repeated in quotes): &#8220;</span></font><font =
size=3D2><span
style=3D'font-size:10.0pt'>Note [ANSX995], [I180142] and [I180143] =
specify
irrefutably verifiable time-stamps which do not depend on certificates, =
CRLS,
or OCSP-Responses for digital signature verification.&#8221;&nbsp; The =
sentence
does not seem correct.&nbsp; The phrase &#8220;for digital signature
verification&#8221; should be deleted since in symmetric key MAC and =
hash
trees, you may not have public keys and hence PKI =
artifacts.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Section
3.3, The variable &#8220;h&#8221; is used to denote different =
values.&nbsp; For
example see item 3 in the section.&nbsp; Other variable names should be =
chosen
for different variables.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Section
4.2, 3<sup>rd</sup> paragraph, last sentence (repeated in quotes): The =
new
Archive Time-Stamp must use the same hash algorithm within its hash-tree =
as the
old one, which is specified in the hash algorithm field of the Archive
Time-Stamp or within the time-stamp itself&#8221;.&nbsp; This is =
confusing at
two levels.&nbsp; One, it does not seem that the hash tree needs to be
re-hashed.&nbsp; The root Hash can be hashed with the time stamp
sequence.&nbsp; Two, it would seem that we would use the hash algorithm =
defined
for the hash tree as opposed to one for calculating the hash for the =
time stamp
token signing.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Section
5, This section is still unclear and the implementers will have =
problems.&nbsp;
More clarity is needed in all three subsections to ensure =
interoperability and
security.</span></font><font size=3D2><span =
style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p><st1:PersonName w:st=3D"on"><font size=3D2 face=3DArial><span =
style=3D'font-size:
 10.0pt;font-family:Arial'>Santosh =
Chokhani</span></font></st1:PersonName> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Orion
Security Solutions, Inc.</span></font> <br>
<st1:address w:st=3D"on"><st1:Street w:st=3D"on"><font size=3D2 =
face=3DArial><span
  style=3D'font-size:10.0pt;font-family:Arial'>1489 Chain Bridge Road, =
Suite 300</span></font></st1:Street>
 <br>
<st1:City w:st=3D"on"><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
  font-family:Arial'>McLean</span></font></st1:City><font size=3D2 =
face=3DArial><span
 style=3D'font-size:10.0pt;font-family:Arial'>, <st1:State =
w:st=3D"on">Virginia</st1:State>
 <st1:PostalCode =
w:st=3D"on">22101</st1:PostalCode></span></font></st1:address> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>(703)</span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>917-0060</span></font>&nbsp;=
<font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <font
color=3Dred><span style=3D'color:red'>Ext. =
35</span></font></span></font> <font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>(voice)</span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>(703)</span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>917-0260
(Fax)</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>[email-masked]</span>=
</font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Visit
our Web site</span></font> <br>
<a href=3D"http://www.orionsec.com"><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>http://www.orionsec.com</spa=
n></font></a>
<o:p></o:p></p>

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

</div>

<div style=3D'mso-element:comment-list'><![if !supportAnnotations]>

<hr class=3Dmsocomoff align=3Dleft size=3D1 width=3D"33%">

<![endif]></div>

</body>

</html>

------_=_NextPart_001_01C61232.37208DBC--