[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 the list.
At 04:07 PM 9/16/2003 -0400, Rich Salz wrote: >[...] >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. Agreed, that's why I push for making things implicit in the endpoint. >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. So the idea is to make most everything optional? I agree with that. The schemas we started *do* leave most things optional. In the schema I started, everything is optional except <InputDocuments> and <OutputOptions>. That is, at a bare minimum you have to say: - here's some documents - give me the signature (by itself, or inserted in a document) You can leave everything else up to the server. There is the *option* for clients to control various things. But a profile could chop out that optionality, and restrict clients to just sending the above. I guess the rationale for adding features into the core, and letting profiles remove them, is that these are features that different profiles might want to use, so we might as well tackle the problems once and solve them in a consistent way. Also, if the core was simple enough that toolkit developers could implement the whole thing, then application developers could use that toolkit with any particular profile. >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. If requesting a timestamp is just an optional part of core, isn't that equivalent to a <dss:Parameter>? What's the difference between having an optional ProcessingOptions/Timestamp element that takes one of the values Timestamp/Don'tTimestamp, and having an optional <dss:Parameter URI="#TimeStamp> element that takes one of the same values? Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]