[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Timestamping Profile Q 1/3: Type of "SignatureObject"
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]