|
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] Sent: Wednesday, September 05, 2007 12:15 AM To: Carl Wallace; Vittek Robert; ietf-ltans@xxxxxxx Subject: RE: security issue in archive timestamp chain? 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----- |