RE: [dss] Validation semantics of time-stamping

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

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.php
.
>
>