RE: security issue in archive timestamp chain?

["Tobias Gondrom" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Vittek Robert
Sent: Friday, September 07, 2007 5:57 PM
To: [e-mail]
Cc: Santosh Chokhani; Carl Wallace; todd glassey
Subject: RE: security issue in archive timestamp chain?

 

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

In the last sentence, I meant tc > t2 (t2 being the time stamp time).

 

________________________________

From: Santosh Chokhani 
Sent: Tuesday, September 04, 2007 6:12 PM
To: 'Carl Wallace'; Vittek Robert; [e-mail]
Subject: RE: security issue in archive timestamp chain?

 

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: [e-mail] [mailto:[e-mail]] On Behalf Of Carl Wallace
Sent: Tuesday, September 04, 2007 1:45 PM
To: Vittek Robert; [e-mail]
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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Vittek Robert 
> Sent: Tuesday, September 04, 2007 1:23 PM 
> To: [e-mail] 
> 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: [phone] 
> fax: [phone] 
> cell: [phone] 
> mailto:[e-mail] 
>