Re: [dss] FW: Here is the TimeStamp scope question to post to thelist.

[Rich Salz <rsalz@datapower.com>]

> You assume a smart client.  I tend to assume stupid clients - a business 
> will do a careful analysis and will decide what type of signatures it 
> needs for a particular task.  Then it will deploy a server to produce 
> that type.

Strongly agree.  Smart clients will have client-side signing and all the 
overhead that entails.

> But to get concrete, how many choices do you think we need in the core 
> protocol for time-stamping?

The more choices we have -- the more dials the client(s) have to set -- 
the more this is going to require big complicated clients.  The more 
choices in the protocol, the harder it is to both (a) implement and (b) 
deploy.

Digital signatures are not widespread.  Hell, you could even say they've 
failed to get acceptance.  If I can't deploy a client with one or two 
registry entries -- "where is the server that handles corporate 
signatures" -- then we'll add to the list of failures and make things worse.

Here is what I propose.  A signing request has two parameters, and both 
are optional.
     dss:policy -- optional URI (DSS server's MUST have a default) that 
specifies the set of parameters controlling the signing
     ds:KeyInfo -- optional element to identify the key to be used for 
signing.  Servers MUST support ds:Keyinfo/ds:KeyName and MAY support any 
other elements from the XML DSIG spec.

Additional, optional, parameters look like XML DSIG transforms
     <dss:Parameter uri=".....">...content...</dss:Parameter>
The content of the dss:Parameter depends on the dss:Parameter/@uri 
(URI?) value.  Just like dsig:Transform.  We could define some and say 
that if a server supports blahblah (a particular URI) then it MUST 
implement it according to the semantics defined in the standard.

Our job is to *enable* everything, not *require* everything.

> C) 3 choices = Signature Timestamp / Content Timestamp / No Timestamp
> D) More choices = RefsTimeStamp, SigAndRefsTimestamp, ArchiveTimestamp, 
> etc...

With all due respect, you're out of your freakin minds.

	/r$

-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html