[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Validation semantics of time-stamping
Juan-Carlos, I think you are on the right track. I believe UpdateSignatureOnly (i.e. suppress verification) breaks the DSS core Verify processing rules anyways. I was faced with the same issue in the EPM and introduced support for the embedding of timestamps into signatures as part of the extended Sign protocol (no verification), in addition to the support for the embedding of timestamps/receipts into signatures on the Verify protocol (with verification and receipting). In this way viscious Sid (or his descendents) can be held accountable. Ed -----Original Message----- From: Juan Carlos Cruellas Ibarz [mailto:cruellas@ac.upc.es] Sent: July 28, 2004 8:58 AM To: Nick Pope; John Ross; 'OASIS DSS TC' Subject: RE: [dss] Validation semantics of time-stamping Nick, Thank you for the message... What I see is that the cause for all these problems is to allow in the profile to request for just updating a signature without validating it. If this option was not present then we could be certain that the server always validates the signature. I now think, as you do, that the mere dss server response is not enough in those cases where the updated signature is the only thing that it is likely to be stored: although I included the update without validate thinking that the update requests coudl be more than one (in these cases the validation of a signature could be requested the first time), it is true that somebody could not conduct properly and could request several updates without requesting any validation. In the ligth of that, and before going further perhaps it would be good to answer the question whether the mode of updating a signature without validating is worth to be kept or not? And I am doubtful now: I mean, if 70 years later the only thing you have is the updated signature, and nothing more, the only way you can succeed before court is if by proving that the updating was made by a server that always verified the signature before doing the update. If the server could optionaly update without validate, and you do not store the server's response you are not able to prove whether the signature was validated or not.....In other words, from your use case, I think that the only way in these scenarios is to work with servers that always validate before update. Juan Carlos At 10:39 28/07/2004 +0100, Nick Pope wrote: >John, Juan Carlos, > >Consider this scenario (excuse the excursion into Science Fiction but my >mind started wandering when thinking around this issue during my morning >bath): > >In 2053 the Space-station Titanic was launch and hailed as the best in space >technology with latest in strengthening against impact from meteors etc. >In 2124 Captain Kink of space freighter Enterpise owned by Galactic Shipping >was docking in airlock 7. Unfortunately the braking was applied a fraction >too late and as a result the airlock was broken. This resulted in 15 >billion Euros of repair costs and 120 deaths with families suing for equally >large amounts of money. > >Space-station Titanic took Galactic Shipping to court passing all liability >on to Galactic Shipping. Galactic Shipping's lawyers searched through the >Lloyds of London Digitial Archives (LLDA) and found a record of the build >checks on airlock number 5 carried out by Sid Engineering Digitally signed >by Sid Smith on 5th August 2052. The lawyers did a search using Google for >information about Sid Smith and found in the Electronic Times a report on >5th August showing Sid surrounded by pritty girls and an announcement that >he had won the Neasden lottary 1 million Euro jackpot. This lead to the >Galactic Shipping lawyers building up a case claiming that Airlock 7 was in >fact not properly built and this was the cause of the accident, not the >negligent driving of Captain Kink. > >Now (at last you say) to the point: >The case hinges on the validity of the digital signature applied over 70 >years ago. Back in 2053 the LLDA system used a HAL 2345 DSS signature >validation and archive time-stamping server (replaced a long time ago) using >the famous OASIS DSS XAdES profile. The HAL 2345 manuals indicate that it >can operate in two modes: one where it validates before applying the >archive, the other where it doesn't. All the archive contains is the >extended digital signature with the regular archive time-stamps. The >signature was certified by Sid's brother's certification authority (called >Alex's Trusted Services) which has long since gone out of business and the >archived certificates and CRLs cannot be guaranteed because the CA public >key was later revoked because Alex was imprisoned for insider share dealing. > >If the DSS XAdES profile included a means of explicetly knowing which mode >the HAL 2345 server was operating then the Judge can quickly make a ruling >on the validity of the record of the checks carried out by Sid Smith, >otherwise the lawyers carry on arguing for ever more, and all the relatives >have passed on before the get any recompense. > >Nick > >> -----Original Message----- >> From: Juan Carlos Cruellas Ibarz [mailto:cruellas@ac.upc.es] >> Sent: 27 July 2004 12:55 >> To: John Ross; 'Nick Pope'; 'OASIS DSS TC' >> Subject: RE: [dss] Validation semantics of time-stamping >> >> >> Nick >> I agree with John. >> >> Concerning to your question... I have some difficulties in understanding >> the motivation. Could you please to give us something like a >> kind of scenario description? >> >> What I may answer before you further explain is that when somebody >> recieves a dss verification response with an updated signature to >> a request >> requesting verification of the signature, the response itself >> gives this kind >> of information. >> >> What I have in mind is something like: >> >> The relying party "A" receives a signature or even a XAdES signature with >> <xades:SignatureTimeStamp> element including the time-stamp on the >> signature itself. >> >> "A" requests the dss server implementing XAdES profile to verify >> and update >> the signature. Update may perfectly mean to get as much >> validation information >> as possible, and then generate a time-stamp on that. >> >> If the server does not gain access to all the revocation information, it >> returns >> the corresponding response indicating that the signature was not verified >> because >> this lack. So the response already contains the information you request: >> within >> the response there is a time-stamp and there is the indication that the >> signature >> could not be completely verified. >> >> If the server may gain access to all the revocation information and >> everything is >> OK, then the response says that the signature was verified and >> the time-stamp >> added was certainly added after the verification of the signature. >> >> What it seemed not clear for everybody is the case of an unsuccessful >> validation. >> >> In summary, if "A" requests verification and updating to a form >> including a >> time-stamp, >> the response itself contains the answer to your question. >> >> Juan Carlos. >> > - Is there something that can be added to the XAdES profile or >> some part of >> >DSS to enable a party relying on an old signature to be know if the >> >time-stamp was applied immediately subsequent to successful validation? >> > >> >Nick >> > >> > >> > >> > >> >To unsubscribe from this mailing list (and be removed from the >> roster of the >> >OASIS TC), go to >> >http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wo >rkgroup.php >>. >> >> >> >>To unsubscribe from this mailing list (and be removed from the roster of >the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.ph p >. >> >> > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]