Timestamping Profile Q 1/3: Type of "SignatureObject"

[Trevor Perrin <trevp@trevp.net>]

Here's the 1st of 3 questions about the timestamping profile (but they're 
relevant to other profiles too):


What should our timestamping protocol create and verify?
   A) <dss:Timestamp> containing any type of TimeStampToken (XML, RFC 3161, 
Linking)
   B) <dss:Timestamp> containing any type of <dss:XMLTimeStampToken> 
(X.509-based, PGP-based, XKMS-based, etc.)
   C) <dss:Timestamp> containing a specific type of <dss:XMLTimeStampToken> 
(such as X.509-based)

If we choose (C), the timestamping protocol is tied to a particular type of 
timestamp and a particular type of infrastructure (in the same way that the 
RFC 3161 Timestamping protocol is tied to the RFC 3161, X.509-based 
TimeStampToken).

If we choose (A) or (B), the protocol is more generic.  I vote for (A), 
since it's the most generic - with (A), a client app that uses DSS to 
create and verify timestamps can be plugged into *any* environment that has 
a DSS-compliant timestamping server (or even just a DSS "proxy server" that 
receives DSS requests and forwards them to something like an RFC 3161 
Timestamp server).  If we do (C), then we're just an XML translation of RFC 
3161, which seems a weaker value proposition.

If we do (A), we'll have other work to do:
   - we'll need to define the different types of TimeStampTokens - in 
particular, we may need to profile XMLTimeStampTokens for different 
infrastructures, and define LinkingTimeStampTokens.  Probably these should 
occur in separate documents.
   - we may need to define <SignatureType> optional input values for 
different types of TimeStampTokens, so the client can request a particular 
type, or at least ensure that the server is returning what the client expects.


Relevance to other profiles
-----------------------------------------
Other protocol profiles may want to operate on different types of 
"signature objects".  For example, maybe the codesigning profile could be a 
single protocol profile that can return different types of signature objects.

This only works if 2 conditions are met:
   - the signature objects have the same "top-level" type, so that the 
client can deal with the signature objects uniformly regardless of their 
differences.  For example, in (A), the DSS server always returns signature 
objects of top-level type <dss:Timestamp>.

   - The different signature objects don't impose different requirements on 
the protocol.  If they do, then they probably deserve separate profiles.


Trevor