[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ers-02.txt] Questions



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:aljosa@xxxxxxxxx]
> > Envoyé : vendredi 29 avril 2005 11:48
> > À : HOUSSIER Loic RD-MAPS-ISS; ietf-ltans@xxxxxxx
> > 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:loic.houssier@xxxxxxxxxxxxxxxxx]
> > > Sent: 29. april 2005 11:24
> > > To: A. Jerman Blazic; ietf-ltans@xxxxxxx
> > > 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:aljosa@xxxxxxxxx] Envoyé :
> > > vendredi 29
> > > > avril 2005 11:08 À : HOUSSIER Loic RD-MAPS-ISS;
> > ietf-ltans@xxxxxxx
> > > > 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: owner-ietf-ltans@xxxxxxxxxxxx
> > > > > [mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of
> > HOUSSIER Loic
> > > > > RD-MAPS-ISS
> > > > > Sent: 29. april 2005 10:46
> > > > > To: ietf-ltans@xxxxxxx
> > > > > 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 : owner-ietf-ltans@xxxxxxxxxxxx
> > > > > > [mailto:owner-ietf-ltans@xxxxxxxxxxxx] De la part de
> > > > > > Internet-Drafts@xxxxxxxx Envoyé : vendredi 8 avril 2005
> > > 21:29 À :
> > > > > > i-d-announce@xxxxxxxx Cc : ietf-ltans@xxxxxxx 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
> > > > > > i-d-announce-request@xxxxxxxx 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:
> > > > > > 	mailserv@xxxxxxxxx
> > > > > > 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.
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >