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

Re: security issue in archive timestamp chain?

Title: RE: security issue in archive timestamp chain?
This next comment is formally spoken as an Industry Forensics Specialist...
 
Its not the grace period - its the issue with "that without the history parts of that document's Chain-Of-Custody information is missing" and as such its not what you may think it is... 
 
Todd Glassey
(as a Certified Information Forensics Investigator).
----- Original Message -----
Sent: Friday, September 07, 2007 8:57 AM
Subject: RE: security issue in archive timestamp chain?

Yes, that would be my next question - how to incorporate "grace period" to process of verification of TS validation data to be fully compliant with requirement of section 5.3 of ERS. :-)
 
I think that protecting the TS validation data independently but nevertheless by another TS only raises the number of necessary time stamps exponentially.

From: Carl Wallace [mailto:CWallace@xxxxxxxxxxxx]
Sent: Tuesday, September 04, 2007 7: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
>