RE: security issue in archive timestamp chain?

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

Hi Julien, 
I agree. 

And maybe one additional comments:
ERS also recommends to use 2 or more redundant ERS (in parallel) with different TSAs to even further reduce this already small risk. (Of course assuming that not all of the different TSAs' keys will be compromised at the very same time....)

- Tobias





> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Julien Stern
> Sent: Wednesday, September 12, 2007 6:47 PM
> To: [e-mail]
> Subject: Re: security issue in archive timestamp chain?
> 
> 
> Hello Vittek and all,
> 
> I'm getting more and more confused by the discussion :)
> 
> If I understand correctly, you are concerned by the fact that the
> "re-timestamping" of a timestamp does not include a "grace period"
> in a way similar to the original XAdES or CAdES signature that you
> want to protect.
> 
> If this is indeed your concern, my humble opinion is that:
> 
> 1) You are perfectly correct
> 
>     if the inner timestamp certificate is revoked minutes before the
>     "re-timestamping", you may not be able to catch it.
> 
> 2) There is nothing that can be done about it
> 
>     The grace period of the original signature is made possible with
>     a first timestamp. A grace period on a timestamp would imply the
>     need to timestamp the timestamp as soon as possible, resulting
>     in a infinite chain of timestamps ;)
> 
> 3) It is not a big issue
> 
>     A timestamp or CA compromise is a very rare and drastic event. View
> ERS
>     as a way to automatically maintain trust after expiration of some
>     certificates and after cryptanalysis of some algorithms. In the case
>     of a compromise, a manual or semi-manual process will probably be
> needed
>     anyway (at least to input the date of the compromise in the system).
> 
> 4) So do your best
> 
>     The "best" you can do is to gather all verification information at
>     the date of your latest timestamp and to "protect" them, either
>     inside the ERS or by an other ERS. Hence the sentence in the RFC:
>     "the last Archive Timestamp has to be valid at the time the
>      verification is performed."
> 
> Regards,
> 
> --
> Julien
> 
> On Wed, Sep 12, 2007 at 06:12:15PM +0200, Tobias Gondrom wrote:
> > 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:owner-ietf-
> [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:owner-ietf-
> [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]
> > >
> >