RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS

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

Steve,

There are two aspects of requirements that I suggest need to be identified
separately in the requirements document

a) Requirements for a time-stamp or time-mark to be applied to a digitial
signature (which is currently addressed in the requirements document)

b) Requirements for a service which provides a time-stamp similar to RFC
3161 (which needs to be added).

Nick

> -----Original Message-----
> From: Gray Steve [mailto:steve.gray@upu.int]
> Sent: 10 July 2003 08:34
> To: 'Trevor Perrin'; Edward Shallow; dss@lists.oasis-open.org
> Subject: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis
> the OASIS DSS
>
>
> Trevor
>
> I apologise for not commenting on the Time-stamping discussion previously,
> but there are so many emails flying around, I struggle to get to read them
> all.
>
> Therefore, I am certainly relying on the requirements document and any
> changes that are made there. My current interpretation is that
> Timestamping/Timemarking is a distinct requirement in section
> 2.12 and 3.7.4
>
> Is my interpretation correct or are you proposing to change this based on
> your's and Nick's proposal.
>
>
> Steve
>
> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Thursday, July 10, 2003 6:58 AM
> To: Edward Shallow; dss@lists.oasis-open.org
> Cc: 'Gray Steve'; mwolf@authentidate.com
> Subject: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis
> the OASIS DSS
>
>
> At 10:59 PM 7/9/2003 -0400, Edward Shallow wrote:
>
> >Trevor, ( please post to list )
> >
> >    I believe labelling a TimeStamp a Sign does not do the TimeStamp
> justice
> >and confuses. The verbs are already getting over-loaded, which is why
> you're
> >stuck.
>
> You're raising the same issue Juan Carlos did in his message
> about the F2F:
> "Issue#0. Relationship between the Timestamp protocol and the
> signature protocol."
>
> This has been discussed before, but not thoroughly.  Nick and I supported
> having one Signing protocol to create both signatures and timestamps, and
> one Verify protocol to verify them, and no-one objected:
> http://lists.oasis-open.org/archives/dss/200305/msg00075.html
> http://lists.oasis-open.org/archives/dss/200305/msg00076.html
>
> I pointed out that the current Requirements doc assumes the Signing
> Protocol *is* the time-stamping protocol, though isn't real
> explicit about
> it.  I was thinking that vagueness was a flaw that should be
> corrected, but
> we should probably open the issue again, and try for a firmer consensus.
>
> Anyways, the argument's pretty simple: most of the requirements in the
> signing protocol would also apply to the timestamping protocol:
> 3.4.1 Selective Signing (you might want to selectively timestamp
> parts of a
> document)
> 3.4.2 Signature Placement (where to place the timestamp in the document)
> 3.4.3 Output Delivery (return the timestamped document, or just the
> timestamp)
> 3.4.4 Intended Audience (I just added this per Tim's request -
> who is going
> to process the timestamp)
> 3.4.5 Signing Policy (maybe the TSA has multiple timestamping certs it
> could use)
>
> This isn't surprising.  A long time ago, I argued that a
> timestamp was just
> a signature semantics - if you sign a document and add time as a signed
> attribute, you've "time-stamped" it.  I thought that timestamps and
> time-stamping protocols were just special cases of signatures and
> DSS-like
> signature protocols.  I lost the argument about using plain signatures as
> time-stamps.  But you can see they're pretty similar, so I think
> we can do
> both with the same protocol.
>
> We could also use the "Signing" protocol for symmetric-key MACs, for
> example, particularly with the "Intended Audience" feature.  So it's
> confusing to call it a Signing protocol.  People are encouraged
> to think up
> something better than, you know,
> "document-hash-based-crypto-token-creation
> protocol"..
>
>
> >  Why the reticence to add new operations. Strictly from a clarity
> >perspective, the world understands cryptographic timestamping in genreal.
> >Just add a TimeStamp operation. You are already into operations stacking
> ...
> >A place we were at 2 years ago. We simply added options to the primitives
> >that themselves could be primitives. That is why a Verify with a
> Timestamp
> >option, or a Verify preceded by a Decrypt (I know ... Scope)
>
> I think a "Delegated Confidentiality Service" that's an encrypt/decrypt
> analogue of DSS would be neat.  But yeah, it's out of scope.
>
> >  opertation, or
> >a Sign preceded by a VerifyCertificate (there's one you could add)
>
> ooh, dislike that.  XKMS and SCVP are working on cert- and
> certpath-validation protocols.
>
> >operation
> >are all viable. I fail to see the need in trying to stick to just a Sign
> and
> >a Verify.
>
> If time-stamping is just like signing, why invent another protocol.  And
> those 3 things (Signing, Verifying, Timestamping) are our charter, so I
> don't see what else we'd do.
>
> >  Loosen up, let the use-cases take you were they take you. Much too
> >much constriction so early in the game. Besides, even if you don't do it
> >now, your protocol will be infinetelty more flexible moving forward.
> >
> >    I don't like any of the options. Again, I recommend you add
> extensible
> >option directives to every primitive. Options themselves can be
> primitives.
> >Combinations of options and primitives can constitute your profiles. Only
> in
> >this manner can you truly keep the protocol insulated from the profiles.
>
> This is a different topic.  You're saying our protocols should be
> extensible, so people can add new options to them.  That sounds
> reasonable,
> if we can do it in a way that doesn't add any costs.  Is this something
> that we can consider in the protocol design stage, instead of the
> requirements stage?
>
> Trevor
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php