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 Carl
Wallace
Sent: Tuesday, September 04, 2007
1:45 PM
To: Vittek Robert; ietf-ltans@xxxxxxx
Subject: RE: security issue in
archive timestamp chain?
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-----
> From:
owner-ietf-ltans@xxxxxxxxxxxx
> [mailto:owner-ietf-ltans@xxxxxxxxxxxx]
On Behalf Of Vittek Robert
> Sent: Tuesday, September 04,
2007 1:23 PM
> To: ietf-ltans@xxxxxxx
> Subject: security issue in
archive timestamp chain?
>
>
> We are currently implementing
a long term electronic
> signature based on XAdES, so I
went through TS 101 903, TS
> 101 733 and other RFCs that
led me finaly to LTANS group
> because XAdES does not address
the problem of validation of
> TSA certificates ("Rules
for acceptance of the validity of
> the signature within the
time-stamp, involving trust
> decisions, are out of the
scope of the present document.").
>
> I am interested in solving the
following problem.
>
> http://tools.ietf.org/html/rfc4998#section-5.3
states that:
> Each Archive Timestamp MUST be
valid relative to the time of
> the following Archive
Timestamp.
>
> Let's assume that we have
Archive Time-Stamp 1 (ATS1) and we
> need to renew it and safeguard
the validation data for ATS1
> at the same time. But the next
Archive Time-Stamp 2 (ATS2)
> can prove existence only of
the CRLs issued before time T2
> (from ATS2). ATS2 does NOT
give any evidence that there was
> not another CRL2 (issued by CA
that issued TSA1 certificate)
> which contained information on
revocation of TSA1 certificate.
>
> I think that arbitration on
validity of ATS1 might take place
> long after the archive of
relevant CRLs is available and long
> after the used cryptography is
strong enough, so the attacker
> might produce such CRL2
himself just to cast doubt upon the
> archived data.
>
> In other words: while T2 -
safeguardedCRLforTSA1.thisUpdate >
> 0, arbitrator can not be sure
that there was not another CRL2
> that listed TSA1 certificate.
>
> Am I missing something or is
it a security issue?
>
>
> Mgr. Robert Vittek
>
> DITEC, a.s.
> Bratislava Business Center V
> Plynárenská 7/C
> 821 09 Bratislava
>
> voice: +421 2 58 222 487
> fax: +421 2 58 222 777
> cell: +421 908 797 827
> mailto:vittek@xxxxxxxx
>