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

[Gray Steve <steve.gray@upu.int>]

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