OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] freezing doc, and next steps


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]