OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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]