[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]