[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Validation semantics of time-stamping
Thanks Ed. So, if I have understood, your suggestion is to avoid the UpdateSignatureOnly in the Verify protocol? Juan Carlos. At 11:31 28/07/2004 -0400, Edward Shallow wrote: >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]