[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] FW: Here is the TimeStamp scope question to post to thelist.
> 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