|
Hello Vittek, I am not sure I fully
understand your problem. Maybe this recommendation
helps: in real world usage an initial ATS-1 is applied ASAP (right after any
potential grace period), which I personally would assume as a very short time
span. This means by applying a
first ATS initially after archiving you keep t5 very near to t4 and also have
the advantage that you do not need to watch over all the signatures and their
cryptographic algorithms individually but rather watch the algorithms used in
ATS-1. We had a validate draft, which
recently expired, which also describes a bit how to handle these things, but I
did not find the time to update the draft yet: http://tools.ietf.org/html/draft-ietf-ltans-validate-01
greetings, Tobias From:
owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of Vittek Robert Thank all of you for
answers. Well, first I have to explain why I submitted my question to
LTANS group. I know that LTANS
does not deal with electronic signatures or XAdES but in fact it addresses very
similar problem of long term archiving. XAdES itself does not
address verification of validation data of signature time-stamps or archive
time-stamps, it only requires to protect these data together with previous
time-stamps by next archive time-stamp. As I wanted to get
inspired how to do it, I read the ERS specification but I did not find the
answer anyway. Verification of TS validation data seems to be out od scope of
every document. This is the scenarion
which I considered: t1. contract document D
is electronically signed resulting in ES (D states e.g. that 10 years
from signature somebody is due to pay a lot of money). t2. TS is applied
to ES to prove its existence in time t2 (countdown of 10 years
begins). t3. all validation data
for signer's certificate (certificates, revocations) are gathered after grace
period and the contract signature ES is proved valid in time t2. t4. all validation data
for TS certificate are gathered and TS is found valid in t4. t5. archive ATS is
applied to bundle (D, ES, TS, validation data for signer's certificate,
validation data for TS certificate) to safeguard D, ES, TS and all
validation data used. Question is: How can I be
sure that TS certificate is still valid in t5? Next CRL can list TS certificate
with revocationDate (or perhaps even invalidityDate) < t5!! And if TS
certificate is NOT valid, then it may be even possible that ES did
not exist in t2 but only later. There is no mean how to incorporate Next CRL
into XAdES structures. t6. long after the CA
(which issued signer's certificate) and TSA (which issued TS) ceased operation
and availability of the issued CRLs is history, D and ES come under dispute,
but arbitrator (a very wise human) can only say: There is a valid archive ATS (issued
e.g. by another TSA, still operating) applied to the bundle of data but truly I
am not sure about the validity of TS certificate as the evidence - "Next
CRL" - is not available to me anymore. So there is a possibility that TS
certificate was revoked before ATS to safeguard bundle of validation data was
issued. From:
Santosh Chokhani [mailto:chokhani@xxxxxxxxxxxx] In the last sentence, I
meant tc > t2 (t2 being the time stamp time). From:
Carl, While what you say is
correct, I do not think this answers the question Robert has. Let us
consider the following scenario Time t1 is the thisUpdate
for a CRL used to verify the time stamp applied at time t2. Time t3 is when the time
stamp is renewed. We know t3 > t2 >
t1. Time tr is thisUpdate for
a CRL when the TSA first appear as compromised. tr > t1. Time tc is the actual
time of compromise. tr > tc As long as CRL for t1 is
produced using ERS as Carl says, the claimant can prove the legitimacy of the
time stamp. If CRL for tr is also
produced, the time stamp can come under dispute. If there is an
invalidity date associated with the TSA entry and that date is past t2, the
time stamp is legitimate. Note that checking revocation
status of TSA at time t3 technically does not help since tr can come at any
time, including after t3. Also, if one were to
check the revocation status of TSA at time t3, legitimate time stamps that were
applied prior to tc or tr may be rejected. It is tc that is hard to deal
with. That is why we have humans and courts and other supporting evidence
to ferret things out. I have not purposely
included nextUpdate analysis in this since compromise of TSA may or may not be
detected by the nextUpdate. In summary, there will be
situations when TSA is compromised, some of the time stamps will come under
dispute and that dispute will need to be resolved using other evidence. This also points to the
value of having invalidity date in CRL for TSA entries. As long as tc is
present in tr and tc > t1, the time stamp will not come under dispute. From:
owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of There's
no need to safeguard the validation data for ATS1 at the time ATS2 is
applied. The validation data can be preserved independently of the data
and retrieved using SCVP/ERS. Amongst other benefits, this allows for a
grace period to be applied between the time ATS2 was generated and the time of
interest for validating the TSA1 credentials. >
-----Original Message----- |