[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Validation semantics of time-stamping
Yes, solely based on the semantic inconsistency and the very fact that the application of a timestamp is fundamentally Sign operation. When timestamps are applied as "stacked" operations they follow the main operation being performed (i.e. Verify then Timestamp). This discussion is old. The only issue affecting core is that <SignatureObject> is not defined as an OptionalInput on the Sign, and clearly would be required if we are simply adding timestamps to incoming signatures (w/o verification). Because timestamping was potentially appearing in both Sign and Verify protocols, we debated very early on whether a 3rd core protocol was required or not. We subsequently ended up developing the Timestamp profile of Sign, yet here we are performing Timestamps under both. All that aside, my suggestion is to fromally allow timestamping under both Sign and Verify. The key and obvious delineator would be that - standalone timestamp creation belongs under the Timestamping profile of Sign - timestamps blindly added to signatures also belongs under the Timestamping profile of Sign - and lastly, timestamps conditionally added as a result of successful verification belong under Verify Among other things, we might have to allow <SignatureObject> as a valid input to Sign (optional in core, or profiled are the 2 choices) Ed -----Original Message----- From: Juan Carlos Cruellas Ibarz [mailto:cruellas@ac.upc.es] Sent: July 29, 2004 6:07 AM To: ed.shallow@rogers.com; 'Nick Pope'; 'John Ross'; 'OASIS DSS TC' 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_workgro >>up.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_workgrou >p.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.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]