RE: [dss] Validation semantics of time-stamping

["Nick Pope" <pope@secstan.com>]

If I understand corrct the proposed approach is that:

a) Fromn the TSA identity I know that this is created by a server that has
the (policy?) rules that the time-stamp is only applied as part of a DSS
validation
b) The DSS validation protocol does not allow for time-stamping to be added
without validation.

Thinking further is my requirement best met througha signature policy
identifier that applies well defined rules that includes archive time-stamps
only being applied if the signature is valid?

Nick

> -----Original Message-----
> From: Juan Carlos Cruellas Ibarz [mailto:cruellas@ac.upc.es]
> Sent: 28 July 2004 14:58
> 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_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_wor
> kgroup.php.
>
>
>