At 01:28 PM 5/23/2003 -0400, Robert Zuccherato wrote:
>Nick;
>
>It seems to me that at least for the signature verification and timestamping
>protocols, a number of the submissions, including Entrust's comes fairly
>close. Of course, nothing is going to have all of the requirements exactly,
>but they could be used as good starting points.
>
>I guess the question then is, do we want to have three separate protocols
>(one for signature generation, one for signature verification and one for
>timestamping), or do we want to have one protocol that includes
>functionality to support all three?
I was hoping the timestamp could be retrieved through the Signature
Generation protocol. I.e., despite its name, this protocol could work for
retrieving any sort of cryptographic token that's based on an input
document or hash (i.e. you can send a hash, then receive back a public-key
signature, symmetric-key MAC, simple time-stamp, linked time-stamp,
etc..). Similarly, you could check any of these through the Signature
Verification protocol.
The requirements doc kinda implies this in a few ways:
- "3.1.2 Signature Format" mentions XML-DSIG, XML Timestamp Tokens, and
CMS, the idea being that these 3 formats will be supported within our
single Request/Response Signing and Verifying protocols.
- 3.2.2 says "A time-stamp may be retrieved through the use of the DSS
protocol"
- 3.10.2 mentions an "XML Time-Stamp Binding", the idea being we'd commit
to a single Binding of the Request/Response protocol so that any XML
Timestamp Service could be accessed by any client
Should we change nomenclature and not speak of Signing and Verification
Protocols, but just of more general "Token Creation/Validation
Protocols"? But Token isn't a great term, maybe we should just stick with
"Signature" but keep in mind that in the context of the Request/Response
protocol we're using it *very* loosely to mean any value cryptographically
derived from the hash of a document.
Trevor
