Subject: RE: draft-ietf-ltans-ers-02 comments

From: "Tobias Gondrom" <[email-masked]>
Date: Fri, 20 May 2005 19:54:18 +0200

Carl, 
fully agree to all formal aspects!
Further comments below:

> Below are some questions and comments on the -02 draft of ERS.
> Administrative
>         - EVS in section 1.1, section 1.2 should be ERS
>         - EV should be ER in "EV as file format" and "EV as part of
> another syntax specification".
>         - ETS in section 1.2 should be ERS
>         - "Reduce hash-tree" should be "Reduced hash-tree" in Terminology
>         - "Trusted archiving" is not referenced in the body of the
> specification.  Suggest removing it from the Terminology section.  Same
> applies to "archived data object group" and "trusted archive authority".
>         - In section 2.1, remove comma from "contains data, necessary".
>         - In section 2.1, change "if necessary" to "as necessary" or "when
> necessary" in bullet 3.
>         - In section 3, change "to verify" to "verification of".
>         - In section 3.1, change "not existent" to "not present, "
>         - In section 3.1, change "identically" to "identical"
>         - Throughout section 4, change "first Initial" to "first
> ArchiveTimeStamp in the first ArchiveTimeStampChain".
>         - In section 4.1, change "must be ordered" to "MUST be ordered"
>         - Suggest renaming ArchiveTimeStampSequence to
> ArchiveTimeStampChainSequence
>         - In section 4.2, "ASN.1 encoded" to "DER encoded".
>         - In figure 4 and associated text, h123, h12 and h2abc should be
> h123', h12' and h2abc'.
>         - In 5.2, update the CMS reference and omit requirement for RSA
> algorithm.
>         - Section 5.2 requires encrypted data to be encapsulated but
> Appendix A permits detached data.
>         - id-ATS is not defined in the ASN.1 module.
>         - In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, h1}

As above: I agree.

> Non-administrative
>         - In section 2.1, how would a partial document be archived, i.e.
> how can the structures be used to archive the "essential parts" of a
> document?

I am not sure why we need partial documents? Where do they come from?

>         - The verification algorithm needs a sorting step before
> concatenation (section 3.3, bullet 3).

You are right we need the same sorting as when building the hash-tree: 
"in binary ascending order" refer to top of page 9
" 2. Select all hash values, which have the same father node as h. 
      Generate the first list of hash values by arranging these hashes,
      in binary ascending order. Repeat this step for the father node
      of these hashes until the root hash is reached. The father nodes
      are not saved in the hash lists - they are computable."

>         - In 4.1, why must all ArchiveTimestamps in an
> ArchiveTimestampChain use the same hash algorithm?  Seems like this should
> refer to the algorithm used within the hash tree not the hash algorithm
> used for the timestamp.

The problem is that an ArchiveTimeStampChain is only a Sequence of ArchiveTimeStamps due to the fact of simple timestamp renewals, i.e. the timestamps have lost their value, but the has-algorith of the hash-trees of the Archivetimestamps is still valid.
If the hash-algorithm of the trees is broken (more precisely "before") you have to open a new ArchiveTimeStampChain with hash-values calculated with the new algorithm as the seed. See section 4.2

>         - For timestamp renewal, why not obtain a timestamp for the entire
> previous ArchiveTimeStamp (i.e. complete sequence including hash alg,
> reduced hashtree and timestamp) instead of the timestamp field only?  This
> would simplify processing (and would facilitate covering verification data
> - see below).  Also, it's not clear in the current text if the entire
> ContentInfo is timestamped or the content field of the timestamp object
> (in section 4.2).

The timestamp (containing the hash-value of the highest node) does represent the complete hash-tree and is with this fully sufficient - so one can spare additional operations.

>         - In section 4.2, bullet 3, is the hash calculated over a
> concatenation or over the encoded ArchiveTimeStampChainSequence?

You are right this is unclear: I will come up with a proposal for the precise solution in the next few days.

>         - In Appendix A, given a detached set of signatures, what
> constitutes the first signature?
>         - In Appendix A, why define two OIDs for the attribute?  One could
> do with context determining how the attribute is processed.
>         - Appendix A should also account for ContentWithAttributes
> structure (see RFC4073).  This may be the cleanest way to associate an
> EvidenceRecord attribute with any type of CMS object and avoid the need to
> strip out attributes and reencode at verification time.
>         - Suggest pushing cryptoInfos down a level.  This would allow
> cryptoInfos to be protected by subsequent timestamps.
>         - Need to define some cryptoInfo types.
>         - Suggest adding SIZE (1...MAX)  to each SEQUENCE OF in the
> reducedHashtree definition.  Also on Chain object definitions.

No comment at this time - I hope the authors can also comment on that.

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 20 May 2005 15:48:56 -0400

> > ArchiveTimeStamp in the first ArchiveTimeStampChain".

This change makes no sense as a literal replacement.  I just found the term
"first Initial" difficult and intended to suggest replacing instances of
"first Initial Archive Time-Stamps".  

> I am not sure why we need partial documents? Where do they come from?

Perhaps the "essential parts" clause should simply be deleted.
 
> "in binary ascending order" refer to top of page 9 " 2. 
> Select all hash values, which have the same father node as h. 

Right.  However, bullet 3 would benefit from a statement of this, in my
opinion.

> > ArchiveTimestampChain use the same hash algorithm?  Seems like this 
> > should refer to the algorithm used within the hash tree not 
> the hash 
> > algorithm used for the timestamp.
> 
> The problem is that an ArchiveTimeStampChain is only a 
> Sequence of ArchiveTimeStamps due to the fact of simple 
> timestamp renewals, i.e. the timestamps have lost their 
> value, but the has-algorith of the hash-trees of the 
> Archivetimestamps is still valid.
> If the hash-algorithm of the trees is broken (more precisely 
> "before") you have to open a new ArchiveTimeStampChain with 
> hash-values calculated with the new algorithm as the seed. 
> See section 4.2

Exactly.  So why must all ArchiveTimestamps within an ArchiveTimestampChain
use the same hash algorithm?  The hash algorithms could vary in an
ArchiveTimestampChain as long as the hash used for the hash tree doesn't
change, which would result in a new ArchiveTimestampChain featuring a
recalculated hash tree using a new hash algorithm.
 
> >         - For timestamp renewal, why not obtain a timestamp for the 
> > entire previous ArchiveTimeStamp (i.e. complete sequence including 
> > hash alg, reduced hashtree and timestamp) instead of the timestamp 
> > field only?  This would simplify processing (and would facilitate 
> > covering verification data
> > ContentInfo is timestamped or the content field of the timestamp 
> > object (in section 4.2).
> 
> The timestamp (containing the hash-value of the highest node) 
> does represent the complete hash-tree and is with this fully 
> sufficient - so one can spare additional operations.

Renewal can't target the entire ArchiveTimestamp due to the inclusion of the
reduction.  I withdraw the question regarding targeting ArchiveTimestamp.
Still not clear whether timestamp or timestamp.content is timestamped at
renewal time.
 
> > cryptoInfos to be protected by subsequent timestamps.

This suggestion is OBE, given that ArchiveTimestamp can't be the target.
The cert bag and unsigned attributes of the timestamp could serve to hold
additional information.

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: RE: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 15:48:56 -0400
Sender: [email-masked]

> > ArchiveTimeStamp in the first ArchiveTimeStampChain".

This change makes no sense as a literal replacement.  I just found the term
"first Initial" difficult and intended to suggest replacing instances of
"first Initial Archive Time-Stamps".  

> I am not sure why we need partial documents? Where do they come from?

Perhaps the "essential parts" clause should simply be deleted.
 
> "in binary ascending order" refer to top of page 9 " 2. 
> Select all hash values, which have the same father node as h. 

Right.  However, bullet 3 would benefit from a statement of this, in my
opinion.

> > ArchiveTimestampChain use the same hash algorithm?  Seems like this 
> > should refer to the algorithm used within the hash tree not 
> the hash 
> > algorithm used for the timestamp.
> 
> The problem is that an ArchiveTimeStampChain is only a 
> Sequence of ArchiveTimeStamps due to the fact of simple 
> timestamp renewals, i.e. the timestamps have lost their 
> value, but the has-algorith of the hash-trees of the 
> Archivetimestamps is still valid.
> If the hash-algorithm of the trees is broken (more precisely 
> "before") you have to open a new ArchiveTimeStampChain with 
> hash-values calculated with the new algorithm as the seed. 
> See section 4.2

Exactly.  So why must all ArchiveTimestamps within an ArchiveTimestampChain
use the same hash algorithm?  The hash algorithms could vary in an
ArchiveTimestampChain as long as the hash used for the hash tree doesn't
change, which would result in a new ArchiveTimestampChain featuring a
recalculated hash tree using a new hash algorithm.
 
> >         - For timestamp renewal, why not obtain a timestamp for the 
> > entire previous ArchiveTimeStamp (i.e. complete sequence including 
> > hash alg, reduced hashtree and timestamp) instead of the timestamp 
> > field only?  This would simplify processing (and would facilitate 
> > covering verification data
> > ContentInfo is timestamped or the content field of the timestamp 
> > object (in section 4.2).
> 
> The timestamp (containing the hash-value of the highest node) 
> does represent the complete hash-tree and is with this fully 
> sufficient - so one can spare additional operations.

Renewal can't target the entire ArchiveTimestamp due to the inclusion of the
reduction.  I withdraw the question regarding targeting ArchiveTimestamp.
Still not clear whether timestamp or timestamp.content is timestamped at
renewal time.
 
> > cryptoInfos to be protected by subsequent timestamps.

This suggestion is OBE, given that ArchiveTimestamp can't be the target.
The cert bag and unsigned attributes of the timestamp could serve to hold
additional information.

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 19:54:18 +0200
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Carl, 

As above: I agree.

Content-class: urn:content-classes:message
Subject: RE: [ers-02.txt] Questions
Date: Fri, 20 May 2005 18:06:57 +0200
Importance: low
From: "Tobias Gondrom" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Denis, 

Carl and I clarify with the AD (Russ) about the correct procedure whether we need do detailed research on patents or not and how to proceed.

Tobias

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, May 12, 2005 5:25 PM
> To: Tobias Gondrom
> Cc: [email-masked]
> Subject: Re: [ers-02.txt] Questions
> 
> Tobias,
> 
> Surety has a lot of patents that involve the use of hashtrees used
> together
> with time-stamp tokens.
> 
> Do you have any idea if the realisations you have in mind will fall into
> these patents or outside ?
> 
> Denis
> 
> 
> > Loïc,
> >
> > Maybe to provide further info:
> >
> >
> >>Well, it's more clear to me now...
> >>ERS just proposes a syntax for EV that can be used by CSM to kepp
> >>electronic signature valid.
> >>But according to RFC-3126, ES-A is a format that reech the same target
> >>than ERS in CMS.
> >
> >
> > Yes. In some way ES-A in RFC3126 is trying to achieve the same.
> > With ES-A you can try to "re-sign" a signed file with a new layer
> wrapped around it every time a cryptographic algorithm gets weak
> (respectively before) - the concept is quite obvious and well thought for
> the use case to store only a limited number of signed documents.
> >
> > As Aleksej already described ERS also enables the possibility for long-
> term non repudiation and integrity.
> > Second aspect of ERS is that it scales for large volumes of signed
> documents. With ES-A you have to wrap around every file another layer.
> > With ERS you just create new hashtrees - which is if you think of e.g.
> about 10^6 to 10^9 documents a lot better concerning performance.
> (especially if only e.g. a public key algorithm gets weak or a used key
> length is no longer sufficient.)
> >
> > Concerning RFC3126: From my opinion it is not necessary that ERS will
> obsolete ES-A. But I surely expect that many big storage, Document
> Management System and ECM vendors will implement ERS and not ES-A. So in
> B2B and B2C we will most probably seeing a lot of ERS.
> >
> > The coexistence of ES-A and ERS will be something to discuss when ERS is
> finally an RFC.
> >
> > Best regards
> >
> > 	Tobias
> >
> >
> >
> >
> >
> >
> >>So my question is, if i want to archive signature, i have the choice
> >>between RFC3126 ES-A or ERS in CMS. Am I right ?
> >>
> >>If I am, will ES-A be obsoleted by ERS in CSM (as shown in Appendix A in
> >>[ers-02])  ?
> >>
> >>But be sure that I understand ERS is more than just a way to maintain a
> >>singature valid.
> >>
> >>Regards,
> >>
> >>Loïc
> >>
> >>
> >>
> >>
> >>>-----Message d'origine-----
> >>>De : A. Jerman Blazic [mailto:[email-masked]]
> >>>Envoyé : vendredi 29 avril 2005 11:48
> >>>À : HOUSSIER Loic RD-MAPS-ISS; [email-masked]
> >>>Objet : RE: [ers-02.txt] Questions
> >>>
> >>>Loic
> >>>
> >>>This is what I didn't state. You have to distinguish the
> >>>level of the two
> >>>approaches. ERS deals mainly with providing syntax on (time)
> >>>evidence and
> >>>evidence on integrity of a data, while RFC3126 provides data
> >>>strucutre for
> >>>long term validity of a digital signatures. In this case RFC
> >>>can rely on ERS
> >>>for time and integrity evidence of a signature, so it is a
> >>>more low level
> >>>syntax. Or in other words, if you equip CMS with accredited
> >>>time, you can
> >>>ged basic ERS structure (of course ERS is more than that:
> >>>e.g. grouping and
> >>>hash trees). This is why I said the approaches of LTANS vs. XAdES are
> >>>somehow different, while addressing similar problems.
> >>>
> >>>BR
> >>>
> >>>Aleksej
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: HOUSSIER Loic RD-MAPS-ISS
> >>>>[mailto:[email-masked]]
> >>>>Sent: 29. april 2005 11:24
> >>>>To: A. Jerman Blazic; [email-masked]
> >>>>Subject: RE: [ers-02.txt] Questions
> >>>>
> >>>>Aleksej,
> >>>>Thanks for your reply.
> >>>>
> >>>>So, to demonstrate the existantce and stability of signature
> >>>>on particular, there will be two ways in PKIX community:
> >>>>One using rfc3126, one with ERS attribute within a CMS
> >>>>signature object. Am I wrong ?
> >>>>
> >>>>Loïc
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>-----Message d'origine-----
> >>>>>De : A. Jerman Blazic [mailto:[email-masked]] Envoyé :
> >>>>
> >>>>vendredi 29
> >>>>
> >>>>>avril 2005 11:08 À : HOUSSIER Loic RD-MAPS-ISS;
> >>>>
> >>>[email-masked]
> >>>
> >>>>>Objet : RE: [ers-02.txt] Questions
> >>>>>
> >>>>>Dear Loic
> >>>>>
> >>>>>I would be very careful here. XAdES for example is like the
> >>>>
> >>>>name says:
> >>>>
> >>>>>syntax for extended signature, which builds on top of a
> >>>>
> >>>>signature and
> >>>>
> >>>>>includes all needed complementary data to provide long term
> >>>>
> >>>>stability
> >>>>
> >>>>>of digital signatures. The LTANS position, as I understand it,
> >>>>>distances from such approach and deals with long term
> >>>>
> >>>stability of
> >>>
> >>>>>data. ERS in this case defines requirements on how to
> >>>>
> >>>>demonstrate the
> >>>>
> >>>>>existence and stability of data (not signature on
> >>>>
> >>>particular) on a
> >>>
> >>>>>timeline. It does not define the data structure nor the
> >>>>
> >>>>syntax and at
> >>>>
> >>>>>the moment you can freely use any interpretation of an
> >>>>
> >>>>evidence record
> >>>>
> >>>>>including CMS. But XAdES? I am not so sure....
> >>>>>
> >>>>>Best regards
> >>>>>
> >>>>>Aleksej
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [email-masked]
> >>>>>>[mailto:[email-masked]] On Behalf Of
> >>>>>
> >>>HOUSSIER Loic
> >>>
> >>>>>>RD-MAPS-ISS
> >>>>>>Sent: 29. april 2005 10:46
> >>>>>>To: [email-masked]
> >>>>>>Subject: [ers-02.txt] Questions
> >>>>>>
> >>>>>>
> >>>>>>Hi all,
> >>>>>>
> >>>>>>Reading ERS_02, I have question :
> >>>>>>It s said that ER can be part of the Archive or can be
> >>>>>
> >>>stored as
> >>>
> >>>>>>another file. What I understand is that we can (using CMS
> >>>>>
> >>>>or XADES)
> >>>>
> >>>>>>do ER as part of the Archive.
> >>>>>>But Is it compliant with ERS ?
> >>>>>>
> >>>>>>Thanks
> >>>>>>
> >>>>>>Loïc
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>-----Message d'origine-----
> >>>>>>>De : [email-masked]
> >>>>>>>[mailto:[email-masked]] De la part de
> >>>>>>>[email-masked] Envoyé : vendredi 8 avril 2005
> >>>>>>
> >>>>21:29 À :
> >>>>
> >>>>>>>[email-masked] Cc : [email-masked] Objet : I-D
> >>>>>>>ACTION:draft-ietf-ltans-ers-02.txt
> >>>>>>>
> >>>>>>>A New Internet-Draft is available from the on-line
> >>>>>>
> >>>>>Internet-Drafts
> >>>>>
> >>>>>>>directories.
> >>>>>>>This draft is a work item of the Long-Term Archive and
> >>>>>>
> >>>>>>Notary Services
> >>>>>>
> >>>>>>>Working Group of the IETF.
> >>>>>>>
> >>>>>>>	Title		: Evidence Record Syntax (ERS)
> >>>>>>>	Author(s)	: R. Brandner, et al.
> >>>>>>>	Filename	: draft-ietf-ltans-ers-02.txt
> >>>>>>>	Pages		: 25
> >>>>>>>	Date		: 2005-4-8
> >>>>>>>
> >>>>>>>In many scenarios, users need to be able to ensure and
> >>>>>>
> >>>>prove the
> >>>>
> >>>>>>>   existence and integrity of data, especially digitally
> >>>>>>
> >>>>>>signed data,
> >>>>>>
> >>>>>>>in
> >>>>>>>   a common and reproducible way over a long and possibly
> >>>>>>
> >>>>>>undetermined
> >>>>>>
> >>>>>>>   period of time.  This document specifies the syntax and
> >>>>>>
> >>>>>>processing
> >>>>>>
> >>>>>>>of
> >>>>>>>   an Evidence Record, designed for long-term
> >>>>>>
> >>>>non-repudiation of
> >>>>
> >>>>>>>   existence of data, which particularly can be used for
> >>>>>>
> >>>>>>conservation
> >>>>>>
> >>>>>>>of
> >>>>>>>   evidence of digitally signed data.
> >>>>>>>
> >>>>>>>A URL for this Internet-Draft is:
> >>>>>>>
> >>>>>>
> >>>http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-02.txt
> >>>
> >>>>>>>To remove yourself from the I-D Announcement list, send a
> >>>>>>
> >>>>>>message to
> >>>>>>
> >>>>>>>[email-masked] with the word unsubscribe in
> >>>>>>
> >>>>>>the body of
> >>>>>>
> >>>>>>>the message.
> >>>>>>>You can also visit
> >>>>>>>https://www1.ietf.org/mailman/listinfo/I-D-announce
> >>>>>>>to change your subscription settings.
> >>>>>>>
> >>>>>>>
> >>>>>>>Internet-Drafts are also available by anonymous FTP.
> >>>>>>
> >>>>>Login with the
> >>>>>
> >>>>>>>username "anonymous" and a password of your e-mail
> >>>>>>
> >>>>address. After
> >>>>
> >>>>>>>logging in, type "cd internet-drafts" and then
> >>>>>>>	"get draft-ietf-ltans-ers-02.txt".
> >>>>>>>
> >>>>>>>A list of Internet-Drafts directories can be found in
> >>>>>>>http://www.ietf.org/shadow.html or
> >>>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>>>>
> >>>>>>>
> >>>>>>>Internet-Drafts can also be obtained by e-mail.
> >>>>>>>
> >>>>>>>Send a message to:
> >>>>>>>	[email-masked].
> >>>>>>>In the body type:
> >>>>>>>	"FILE /internet-drafts/draft-ietf-ltans-ers-02.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.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >
> >
> 

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 11:44:36 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0041_01C55D31.4F4E7650
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Administrative
	- EV should be ER in "EV as file format" and "EV as part of another
syntax specification".

Non-administrative
	- In section 2.1, how would a partial document be archived, i.e. how
can the structures be used to archive the "essential parts" of a document?
	- The verification algorithm needs a sorting step before
concatenation (section 3.3, bullet 3).  
	- In 4.1, why must all ArchiveTimestamps in an ArchiveTimestampChain
use the same hash algorithm?  Seems like this should refer to the algorithm
used within the hash tree not the hash algorithm used for the timestamp.
	- For timestamp renewal, why not obtain a timestamp for the entire
previous ArchiveTimeStamp (i.e. complete sequence including hash alg,
reduced hashtree and timestamp) instead of the timestamp field only?  This
would simplify processing (and would facilitate covering verification data -
see below).  Also, it's not clear in the current text if the entire
ContentInfo is timestamped or the content field of the timestamp object (in
section 4.2).
	- In section 4.2, bullet 3, is the hash calculated over a
concatenation or over the encoded ArchiveTimeStampChainSequence?  	
	- In Appendix A, given a detached set of signatures, what
constitutes the first signature?  
	- In Appendix A, why define two OIDs for the attribute?  One could
do with context determining how the attribute is processed.
	- Appendix A should also account for ContentWithAttributes structure
(see RFC4073).  This may be the cleanest way to associate an EvidenceRecord
attribute with any type of CMS object and avoid the need to strip out
attributes and reencode at verification time.
	- Suggest pushing cryptoInfos down a level.  This would allow
cryptoInfos to be protected by subsequent timestamps.  
	- Need to define some cryptoInfo types.
	- Suggest adding SIZE (1.MAX)  to each SEQUENCE OF in the
reducedHashtree definition.  Also on Chain object definitions.

------=_NextPart_000_0041_01C55D31.4F4E7650
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>draft-ietf-ltans-ers-02 comments</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Below are some questions and comments =
on the -02 draft of ERS.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Administrative</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- EVS in section 1.1, section 1.2 should be ERS</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- EV should be ER in &quot;EV as file format&quot; and =
&quot;EV as part of another syntax specification&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- ETS in section 1.2 should be ERS</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- &quot;Reduce hash-tree&quot; should be &quot;Reduced =
hash-tree&quot; in Terminology</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- &quot;Trusted archiving&quot; is not referenced in the =
body of the specification.&nbsp; Suggest removing it from the =
Terminology section.&nbsp; Same applies to &quot;archived data object =
group&quot; and &quot;trusted archive authority&quot;.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, remove comma from &quot;contains data, =
necessary&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, change &quot;if necessary&quot; to =
&quot;as necessary&quot; or &quot;when necessary&quot; in bullet =
3.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3, change &quot;to verify&quot; to =
&quot;verification of&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.1, change &quot;not existent&quot; to =
&quot;not present, &quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.1, change &quot;identically&quot; to =
&quot;identical&quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Throughout section 4, change &quot;first Initial&quot; =
to &quot;first ArchiveTimeStamp in the first =
ArchiveTimeStampChain&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.1, change &quot;must be ordered&quot; to =
&quot;MUST be ordered&quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest renaming ArchiveTimeStampSequence to =
ArchiveTimeStampChainSequence</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.2, &quot;ASN.1 encoded&quot; to &quot;DER =
encoded&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In figure 4 and associated text, h123, h12 and h2abc =
should be h123', h12' and h2abc'.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In 5.2, update the CMS reference and omit requirement =
for RSA algorithm.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Section 5.2 requires encrypted data to be encapsulated =
but Appendix A permits detached data.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- id-ATS is not defined in the ASN.1 module.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, =
h1}</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Non-administrative</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, how would a partial document be =
archived, i.e. how can the structures be used to archive the =
&quot;essential parts&quot; of a document?</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- The verification algorithm needs a sorting step before =
concatenation (section 3.3, bullet 3).&nbsp; </FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In 4.1, why must all ArchiveTimestamps in an =
ArchiveTimestampChain use the same hash algorithm?&nbsp; Seems like this =
should refer to the algorithm used within the hash tree not the hash =
algorithm used for the timestamp.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- For timestamp renewal, why not obtain a timestamp for =
the entire previous ArchiveTimeStamp (i.e. complete sequence including =
hash alg, reduced hashtree and timestamp) instead of the timestamp field =
only?&nbsp; This would simplify processing (and would facilitate =
covering verification data - see below).&nbsp; Also, it's not clear in =
the current text if the entire ContentInfo is timestamped or the content =
field of the timestamp object (in section 4.2).</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.2, bullet 3, is the hash calculated over a =
concatenation or over the encoded ArchiveTimeStampChainSequence?&nbsp; =
&nbsp;&nbsp;&nbsp; </FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In Appendix A, given a detached set of signatures, what =
constitutes the first signature?&nbsp; </FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In Appendix A, why define two OIDs for the =
attribute?&nbsp; One could do with context determining how the attribute =
is processed.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Appendix A should also account for =
ContentWithAttributes structure (see RFC4073).&nbsp; This may be the =
cleanest way to associate an EvidenceRecord attribute with any type of =
CMS object and avoid the need to strip out attributes and reencode at =
verification time.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest pushing cryptoInfos down a level.&nbsp; This =
would allow cryptoInfos to be protected by subsequent timestamps.&nbsp; =
</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Need to define some cryptoInfo types.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest adding SIZE (1&#8230;MAX)&nbsp; to each =
SEQUENCE OF in the reducedHashtree definition.&nbsp; Also on Chain =
object definitions.</FONT></P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0041_01C55D31.4F4E7650--

Date: Thu, 12 May 2005 17:24:55 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Tobias Gondrom <[email-masked]>
CC: [email-masked]
Subject: Re: [ers-02.txt] Questions
Sender: [email-masked]

Tobias,

Surety has a lot of patents that involve the use of hashtrees used together 
with time-stamp tokens.

Do you have any idea if the realisations you have in mind will fall into 
these patents or outside ?

Denis

> Loïc,
> 
> Maybe to provide further info:
> 
> 
>>Well, it's more clear to me now...
>>ERS just proposes a syntax for EV that can be used by CSM to kepp
>>electronic signature valid.
>>But according to RFC-3126, ES-A is a format that reech the same target
>>than ERS in CMS.
> 
> 
> Yes. In some way ES-A in RFC3126 is trying to achieve the same. 
> With ES-A you can try to "re-sign" a signed file with a new layer wrapped around it every time a cryptographic algorithm gets weak (respectively before) - the concept is quite obvious and well thought for the use case to store only a limited number of signed documents. 
> 
> As Aleksej already described ERS also enables the possibility for long-term non repudiation and integrity. 
> Second aspect of ERS is that it scales for large volumes of signed documents. With ES-A you have to wrap around every file another layer. 
> With ERS you just create new hashtrees - which is if you think of e.g. about 10^6 to 10^9 documents a lot better concerning performance. (especially if only e.g. a public key algorithm gets weak or a used key length is no longer sufficient.)
> 
> Concerning RFC3126: From my opinion it is not necessary that ERS will obsolete ES-A. But I surely expect that many big storage, Document Management System and ECM vendors will implement ERS and not ES-A. So in B2B and B2C we will most probably seeing a lot of ERS.
> 
> The coexistence of ES-A and ERS will be something to discuss when ERS is finally an RFC.
> 
> Best regards
> 
> 	Tobias
> 
> 
> 
> 
> 
> 
>>So my question is, if i want to archive signature, i have the choice
>>between RFC3126 ES-A or ERS in CMS. Am I right ?
>>
>>If I am, will ES-A be obsoleted by ERS in CSM (as shown in Appendix A in
>>[ers-02])  ?
>>
>>But be sure that I understand ERS is more than just a way to maintain a
>>singature valid.
>>
>>Regards,
>>
>>Loïc
>>
>>
>>
>>
>>>-----Message d'origine-----
>>>De : A. Jerman Blazic [mailto:[email-masked]]
>>>Envoyé : vendredi 29 avril 2005 11:48
>>>À : HOUSSIER Loic RD-MAPS-ISS; [email-masked]
>>>Objet : RE: [ers-02.txt] Questions
>>>
>>>Loic
>>>
>>>This is what I didn't state. You have to distinguish the
>>>level of the two
>>>approaches. ERS deals mainly with providing syntax on (time)
>>>evidence and
>>>evidence on integrity of a data, while RFC3126 provides data
>>>strucutre for
>>>long term validity of a digital signatures. In this case RFC
>>>can rely on ERS
>>>for time and integrity evidence of a signature, so it is a
>>>more low level
>>>syntax. Or in other words, if you equip CMS with accredited
>>>time, you can
>>>ged basic ERS structure (of course ERS is more than that:
>>>e.g. grouping and
>>>hash trees). This is why I said the approaches of LTANS vs. XAdES are
>>>somehow different, while addressing similar problems.
>>>
>>>BR
>>>
>>>Aleksej
>>>
>>>
>>>>-----Original Message-----
>>>>From: HOUSSIER Loic RD-MAPS-ISS
>>>>[mailto:[email-masked]]
>>>>Sent: 29. april 2005 11:24
>>>>To: A. Jerman Blazic; [email-masked]
>>>>Subject: RE: [ers-02.txt] Questions
>>>>
>>>>Aleksej,
>>>>Thanks for your reply.
>>>>
>>>>So, to demonstrate the existantce and stability of signature
>>>>on particular, there will be two ways in PKIX community:
>>>>One using rfc3126, one with ERS attribute within a CMS
>>>>signature object. Am I wrong ?
>>>>
>>>>Loïc
>>>>
>>>>
>>>>
>>>>
>>>>>-----Message d'origine-----
>>>>>De : A. Jerman Blazic [mailto:[email-masked]] Envoyé :
>>>>
>>>>vendredi 29
>>>>
>>>>>avril 2005 11:08 À : HOUSSIER Loic RD-MAPS-ISS;
>>>>
>>>[email-masked]
>>>
>>>>>Objet : RE: [ers-02.txt] Questions
>>>>>
>>>>>Dear Loic
>>>>>
>>>>>I would be very careful here. XAdES for example is like the
>>>>
>>>>name says:
>>>>
>>>>>syntax for extended signature, which builds on top of a
>>>>
>>>>signature and
>>>>
>>>>>includes all needed complementary data to provide long term
>>>>
>>>>stability
>>>>
>>>>>of digital signatures. The LTANS position, as I understand it,
>>>>>distances from such approach and deals with long term
>>>>
>>>stability of
>>>
>>>>>data. ERS in this case defines requirements on how to
>>>>
>>>>demonstrate the
>>>>
>>>>>existence and stability of data (not signature on
>>>>
>>>particular) on a
>>>
>>>>>timeline. It does not define the data structure nor the
>>>>
>>>>syntax and at
>>>>
>>>>>the moment you can freely use any interpretation of an
>>>>
>>>>evidence record
>>>>
>>>>>including CMS. But XAdES? I am not so sure....
>>>>>
>>>>>Best regards
>>>>>
>>>>>Aleksej
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [email-masked]
>>>>>>[mailto:[email-masked]] On Behalf Of
>>>>>
>>>HOUSSIER Loic
>>>
>>>>>>RD-MAPS-ISS
>>>>>>Sent: 29. april 2005 10:46
>>>>>>To: [email-masked]
>>>>>>Subject: [ers-02.txt] Questions
>>>>>>
>>>>>>
>>>>>>Hi all,
>>>>>>
>>>>>>Reading ERS_02, I have question :
>>>>>>It s said that ER can be part of the Archive or can be
>>>>>
>>>stored as
>>>
>>>>>>another file. What I understand is that we can (using CMS
>>>>>
>>>>or XADES)
>>>>
>>>>>>do ER as part of the Archive.
>>>>>>But Is it compliant with ERS ?
>>>>>>
>>>>>>Thanks
>>>>>>
>>>>>>Loïc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Message d'origine-----
>>>>>>>De : [email-masked]
>>>>>>>[mailto:[email-masked]] De la part de
>>>>>>>[email-masked] Envoyé : vendredi 8 avril 2005
>>>>>>
>>>>21:29 À :
>>>>
>>>>>>>[email-masked] Cc : [email-masked] Objet : I-D
>>>>>>>ACTION:draft-ietf-ltans-ers-02.txt
>>>>>>>
>>>>>>>A New Internet-Draft is available from the on-line
>>>>>>
>>>>>Internet-Drafts
>>>>>
>>>>>>>directories.
>>>>>>>This draft is a work item of the Long-Term Archive and
>>>>>>
>>>>>>Notary Services
>>>>>>
>>>>>>>Working Group of the IETF.
>>>>>>>
>>>>>>>	Title		: Evidence Record Syntax (ERS)
>>>>>>>	Author(s)	: R. Brandner, et al.
>>>>>>>	Filename	: draft-ietf-ltans-ers-02.txt
>>>>>>>	Pages		: 25
>>>>>>>	Date		: 2005-4-8
>>>>>>>
>>>>>>>In many scenarios, users need to be able to ensure and
>>>>>>
>>>>prove the
>>>>
>>>>>>>   existence and integrity of data, especially digitally
>>>>>>
>>>>>>signed data,
>>>>>>
>>>>>>>in
>>>>>>>   a common and reproducible way over a long and possibly
>>>>>>
>>>>>>undetermined
>>>>>>
>>>>>>>   period of time.  This document specifies the syntax and
>>>>>>
>>>>>>processing
>>>>>>
>>>>>>>of
>>>>>>>   an Evidence Record, designed for long-term
>>>>>>
>>>>non-repudiation of
>>>>
>>>>>>>   existence of data, which particularly can be used for
>>>>>>
>>>>>>conservation
>>>>>>
>>>>>>>of
>>>>>>>   evidence of digitally signed data.
>>>>>>>
>>>>>>>A URL for this Internet-Draft is:
>>>>>>>
>>>>>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-02.txt
>>>
>>>>>>>To remove yourself from the I-D Announcement list, send a
>>>>>>
>>>>>>message to
>>>>>>
>>>>>>>[email-masked] with the word unsubscribe in
>>>>>>
>>>>>>the body of
>>>>>>
>>>>>>>the message.
>>>>>>>You can also visit
>>>>>>>https://www1.ietf.org/mailman/listinfo/I-D-announce
>>>>>>>to change your subscription settings.
>>>>>>>
>>>>>>>
>>>>>>>Internet-Drafts are also available by anonymous FTP.
>>>>>>
>>>>>Login with the
>>>>>
>>>>>>>username "anonymous" and a password of your e-mail
>>>>>>
>>>>address. After
>>>>
>>>>>>>logging in, type "cd internet-drafts" and then
>>>>>>>	"get draft-ietf-ltans-ers-02.txt".
>>>>>>>
>>>>>>>A list of Internet-Drafts directories can be found in
>>>>>>>http://www.ietf.org/shadow.html or
>>>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>
>>>>>>>
>>>>>>>Internet-Drafts can also be obtained by e-mail.
>>>>>>>
>>>>>>>Send a message to:
>>>>>>>	[email-masked].
>>>>>>>In the body type:
>>>>>>>	"FILE /internet-drafts/draft-ietf-ltans-ers-02.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.
>>>>>>>
>>>>>>
>>>>>
>>>
> 
> 

From: "A. Jerman Blazic" <[email-masked]>
To: <[email-masked]>
Subject: RE: [ers-02.txt] Questions
Date: Thu, 12 May 2005 12:39:46 +0200
Sender: [email-masked]

Technically, you are absolutely right but it has figurative meaning.....

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Giessmann, Ernstg
> Sent: 12. maj 2005 8:33
> To: [email-masked]
> Subject: AW: [ers-02.txt] Questions
> 
> 
> XAdES = XML Advanced Electronic Signatures nothing about 
> /extended/ is said in the name ;-) /EG.
> 
> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked]
> > [mailto:[email-masked]]Im Auftrag von A. 
> Jerman Blazic
> > Gesendet: Freitag, 29. April 2005 11:08
> > An: 'HOUSSIER Loic RD-MAPS-ISS'; [email-masked]
> > Betreff: RE: [ers-02.txt] Questions
> > 
> > Dear Loic
> > 
> > I would be very careful here. XAdES for example is like the 
> name says:
> > syntax for extended signature, which builds on top of a 
> signature and
> ....
> 

From: "Giessmann, Ernstg" <[email-masked]>
To: [email-masked]
Subject: AW: [ers-02.txt] Questions
Date: Thu, 12 May 2005 08:33:26 +0200
Sender: [email-masked]

XAdES = XML Advanced Electronic Signatures
nothing about /extended/ is said in the name ;-)
/EG.

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]]Im Auftrag von A. Jerman Blazic
> Gesendet: Freitag, 29. April 2005 11:08
> An: 'HOUSSIER Loic RD-MAPS-ISS'; [email-masked]
> Betreff: RE: [ers-02.txt] Questions
> 
> Dear Loic
> 
> I would be very careful here. XAdES for example is like the name says:
> syntax for extended signature, which builds on top of a signature and
....