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

Re: security issue in archive timestamp chain?


Robert -
there is another issue and that NO ONE inside the IETF except me has ever taken a legal look at RFC3161 to see if it can be legally rolled out , and since I am not a lawyer, I can only give a lay opinion as an Auditor, but as an Auditor, and someone formally responsible for audit integrity's of my client's, I am publicly stating that it is my belief that RFC3161 may be illegal to implement in the form its codified in now since it forces certain new RFC3161 specific process rules on Financial Service providers which are constrained by previously existing regulatory framework.
Further any Country which also has a Mutual Recognition Agreement (MRA) with the US is also constrained by that same rule of law... so that means Germany, France, Switzerland, Norway, Holland, and Great Britain, oh hell - it means all of the EU for that matter...
Yes it's true - and it has been for about 100 years or more. That being that all of the Countries involved have formal legal agreements regarding which source of time data is used, and which will prohibit the release and use of RFC3161 technologies or the recommendation from ETSI for TSA's which some other part of the EU thought would be a good idea to codify in violation of those other free standing MRA's between our government's.
Hell the same Legal Metrological Agreements also constrain this and they likewise were shut out of this effort by the Technological Resources groups that codified RFC3161 and prevented the other TS processes (which did honor those agreement's) from being implemented.
Dont believe me - see www.oiml.org (the Organization International Metrology du Legal).
Notice for instance in the language of TS 101 903 (the link follows) that there is NO REFERENCE TO LEGAL METROLOGICAL COMPLIANCE but the government's of the country's where this work was produced are all constrained by those said same treaties and agreement's, in addition to their own local Metrological Regulatory requirements. As noted above - the link follows... http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf 



More in response inline below...
----- Original Message ----- From: "Vittek Robert" <vittek@xxxxxxxx> 
To: <ietf-ltans@xxxxxxx>
Sent: Tuesday, September 04, 2007 10:23 AM
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.
Which means what? - that there is some chain-of-custody and releative relationship between the two time stamps? Why is this true or necessary?
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.
Uh from a use standpoint why would this EVER need to be done? - all that needs to be done is some record of all active stamps in a given timeframe be generated and maintained. Its then that record of the timestamps and not the original timestamp that needs to be continuously maintained...
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.
The role of the original timestamp dualy is to prove its validity at the time of its issuance and the content at the stamping time. The time of the on-going TS Storage Report is to verify that there was a timestamp (the original or restamped TS Token) issued at some point with some policy/technology involved. Nothing more. The idea that the original TS should be good forever is crazy... and potentially a total waste of time and effort IMHO...
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?
yes, the actual usage model is not one which permanently document's the current timestamp of the document, but that its original TS was accurate and reliable. We are not trying to implement a policy decision here, but rather one of 'that the document was controlled and its content provable at the time of its filing, and that the process of proving that original filing can be continuously proven as accurate at the time of the filing.
The ultimate solution here is actually a Technology that can prove that a document is reliable readable and authenticatable continuously, no matter what time-specific policies or time-controls were placed on that document.
So Document A is filed on DATE 1 (A1) and now needs to be proven at DATE 2 (A2 in this instance) and the KEYS or POLICIES for A1 were set to expire prior to A2's coming on line. The problem is that Authentication/Entitlement and Content Assurance are being controlled through the same set of signings and that is a problem since the policies are differing.
Entitlement will likely change over time with any digital document's use, but the original Content or Current Content Assurance process shouldnt. That is something that LTANS needs to address and its one of the reasons' that the uses and interaction procedures with LTANS need to be hammered out before the code is built to operate these features IMHO. 

//Todd Glassey CIFI, CISM