On 8/12/2011 8:25 AM, Istvan Zsolt BERTA wrote:
Dear Todd,
2011.08.10. 15:13 keltezéssel, todd glassey írta:
In Hungary, the authentic long-term
archival of electronically signed
documents is included in the e-signature law. Aside qualified
CAs, we
also have qualified archiving service providers.
Is there a Design Specification available?
What do you mean on Design Specification? We have the archiving
service listed in our e-signature law, and this law prescribes the
requirements a qualified archiving service provider must fulfill.
There is an English version here:
http://www.docshare.com/doc/199777/hungary
yes!
Our authorities also released some 'guidance' on the technical
requirements and policy requirements, but I think they are going
to be superseded by the recently released ETSI specifications:
ETSI TS 101 533-1 Information Preservation Systems Security; Part
1: Requirements for Implementation and Management
http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=31009
ETSI TR 101 533-2 Information Preservation Systems Security; Part
2: Guidelines for Assessors
http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=34232
http://pda.etsi.org/exchangefolder/ts_10153301v010101p.pdf
This is really funny - it was written by Engineers and not Audit
professionals. Its the problem with all of the ETSI Guidance about
time and evidence as far as I can tell.
What actually is UTC?
Look for instance at A.10.10.6 - the Clock
Synchronization. I bet most of the engineers who wrote this have no
idea what UTC is. I mean they know it comes from the BIPM but the
have no idea how the UTC values are computed or when they are
computed.
For instance I DONT MEAN THIS AS A NASTY COMMENT - but I bet the
LTANS group (as a whole) generally doesn't know that UTC is a
computed value which is produced in arrears of the moment that it is
actually stated to represent. The problem is that most of the NTP
team don't know this either.
UTC is not a notice of now then but rather an instance in time which
will be (or was) agreed to by a group of Metrological Wizards when
the Circular-T work is completed and the next UTC time fixing is
completed. In fact most all have no idea that the instant in the
now which we think of as UTC is actually the last instance of UTC +
some number of Atomic Second of incremental time.
The actual UTC instant is derived from the log data submitted
monthly (and that is the key concept here - monthly) by the 55
Master Timing Laboratories who participate in the generation of
Schedule-T... So here is how it works - the master timing labs all
submit the last months timing data to the BIPM's CIPM and the UTC
team then queries IERS.ORG and a couple of other entities and poof -
about thirty (30) days later - they declare a UTC timing fixing for
a point in time which functionally was probably about 50 to 60 days
ago...
What's funnier is how spoofable GPS or even basic NTP is... these
are the highly reliable transports talked about in the ETSI guidance
excerpt which follows:
-----------------------------------------------------
A.10.10.6 Clock synchronization
Long Term Preservation specific controls:
- The IPSP shall have in force an auditable procedure, based the
outcomes of the Risk Assessment, ensuring that all the applied
time references, in relation to the IPS, are reliably fetched
from a trusted UTC time source and maintained unaltered
throughout the entire IPS.
- All IPSP time references shall be UTC based, e.g. "UTC+1,
"UTC+2", etc., to make it possible to reconcile all of them to a
consistent chronology.
- The IPSP shall ensure that all logging records express the
time in a unique manner, even when the IPSP systems are located
in different time zones.
NOTE: This can be achieved either by synchronising all IPS related
systems on the same time zone or by
explicitly stating the systems time through UTC based notation (e.g.
"UTC-6").
-----------------------------------------------------
What that means is in the world of Metrology there are time-frames
about what and when in the UTC process which no one sees. So how
does this affect long term document storage? - Simple the timestamps
need to be rewritable.
None of these requirements go into details like prescribing
certain formats, etc.
Which is why zI pushed back to hard against the ETSI methods - they
also were written by people who refused to put practice statements
into them meaning they are functionally worthless. OK not worthless
but pretty close. Look no use guidelines means they are incomplete
standards since they leave it up to the end users to come up with
their own operating models. This was always the issue with any IETF
models - they simply dont come with "you use it this way"
documentation which would constrain the design and its use fully.
Regards,
István
The Hungarian Chamber of Notaries is running an archival
project since
2007. Certain classes of notarial deeds are archived
electronically.
The notary creates the notarial deed on paper, scans it (as
PDF),
signs it with her qualified electronic signature and sends it
to the
archives (our company is a qualified archiving service
provider, we
run these archives). A few million notarial deeds are archived
this
way currently.
Notaries create their signatures in XAdES-A format, and in the
archives these signatures are archived in an LTANS ERS -like
format.
We do not use ERS because when our system was started, ERS
RFCs were
not available yet, but our logic is very similar to ERS.
Electronically signed documents are also used (and archived)
in
context of the Hungarian registry of businesses. If you want
to found
a company in Hungary, you need to turn to a lawyer, and your
lawyer
submits the necessary electronically signed documents to the
business
registry court. The judge at the registry court also creates
an
electronically signed resolution.
Lawyers are required to archive these electronically signed
documents,
e.g. using a qualified archiving provider. This system also
involves
millions of documents, but only a small fraction of them is
archived
currently. (There are already certain resolutions that were
not
archived properly and their timestamps expired. They are
problematic.)
Unfortunately I have very little written information on this
in
English (our English website is rather just a placeholder):
http://www.berta.hu/publications/Berta2007efpe.pdf (of year
2007)
http://www.berta.hu/publications/Berta2011efpe.pdf (of year
2011)
http://srv.e-szigno.hu/menu/index.php?lap=english_archiving
http://srv.e-szigno.hu/menu/index.php?lap=english_firm_registry
If you have any further questions, feel free to ask, and I
shall do my
best to answer.
Regards,
István
2011.08.04. 18:21 keltezéssel, Martin Augusto G. Vigil írta:
Hi,
I am a PhD student and I have been working on a survey on
long-term
authenticity and proof of existence. I have found many
solutions
(e.g. ERS, Patricia Trees, etc), projects (e.g. ArchiSig,
Prokopius,
HP's Content Integrity Service) and even acts
(Sarbanes-Oxley Act,
Directive 2001/115/EC) but few real life examples in which
long-term
archiving is required and was already used.
May someone point some concrete examples?
Kind regards, ---- Martín A. Gagliotti Vigil Technische
Universität
Darmstadt Cryptography and Computer Algebra Hochschulstraße
10 64289
Darmstadt, Germany Room: S2/02 B216 Tel.: +49 6151 16-5416
_______________________________________________ ltans
mailing list
ltans at ietf.org https://www.ietf.org/mailman/listinfo/ltans
_______________________________________________
ltans mailing list
ltans at ietf.org
https://www.ietf.org/mailman/listinfo/ltans
_______________________________________________
ltans mailing list
ltans at ietf.org
https://www.ietf.org/mailman/listinfo/ltans
--
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers.
Further I OPT OUT of any and all commercial emailings.
|