RE: [dss] Groups - oasis-dss-1.0-profiles-codesigning-spec-wd-01. doc uploaded

[Trevor Perrin <trevp@trevp.net>]

At 05:03 AM 3/18/2004 -0500, Pieter Kasselman wrote:
>Anyways, adding this functionality through a profile sorta twists 
>the  intent, if not the letter, of the core protocol: [Pieter 
>Kasselman]  My apologies, I was not intent on twisting things, but I think 
>we do need the functionality when dealing with code-signing and was 
>looking for the simplest way to include it :). If it can be included in 
>the core that would be great, if not we need a way to deal with it, at 
>least for the code-signing profiles.
I shouldn't've said "twist"... let's just say it shows some individuality 
:-).  There's nothing wrong with that, but the more the profiles conform to 
each other and the core, the more code reuse is possible.

So I'm just trying to see if we can move this profile in that 
direction.  But if not that's okay.



>   - The 1st request returns a "success" but not a signature [Pieter 
> Kasselman]  This can be addressed as you suggest below with a new 
> <ResultMajor> code.   - the 2nd request doesn't contain any input 
> documents (technically  illegal, given the current schema). [Pieter 
> Kasselman]  May the <InputDocuments> element be left empty (i.e. it is 
> included, but contains no document)? Can we change the schema to indicate 
> that this is follow-up on a pending request, rather than a new request 
> and consequently am not required to include <InputDocuments>? If we can 
> not change the schema, perhaps we can specify the <RequestReference> as a 
> valid form of <InputDocuements>?
Sure, we could do either of those.  Changing the schema to allow the 1st 
approach is probably better.



>These aren't show-stoppers, but I wonder if there's a 
>cleaner  approach.  Suppose we add a "Pending" or "TryAgainLater" 
>ResultMajor code  in the core, meaning that the client should try the 
>exact same request at  some later time.
>
>[Pieter Kasselman]  I have no objection to adding the "Pending" 
><ResultMajor> code. However, requiring the same request to be re-submitted 
>is only a partial solution. Effectively the entire request becomes the 
><RequestReference> object, which is sub-optimal in terms of processing on 
>the server as well as bandwidth consumption (think about signing really 
>big applications). It also implies that the developer has to keep a copy 
>of the application/message saved somewhere, which can be quite bulky. 
>Using an abbreviated <RequestReference> allows the server to quickly track 
>the status of the request, conserve bandwidth and reduces the information 
>the client has to maintain.
That's a good summary of the benefits of this.  The cost is that the 
code-signing profile becomes somewhat idiosyncratic; generic DSS 
implementations will need re-tooling before they can be used for code-signing.

So I still like re-submission, since it accomplishes much of the 
functionality of <RequestReference> at less cost.

Looking at the proposed benefits in detail:
  - "allows the server to quickly track the status of the request" - it 
seems not too hard for the server to canonicalize and hash the request, and 
use that as a "request reference".
  - "conserve bandwidth" - Bandwidth can be reduced by using <DocumentHash> 
input documents.  If it's important for the server to have the whole 
application to review, you could use <Document> for the 1st request, and 
<DocumentHash> for the 2nd.
  - "reduces the information the client has to maintain" - if the client 
doesn't keep the whole application around, then the server has to return 
it.  If the application is as large as you mention, it would probably be 
better for the client to keep it around, and for the server just to return 
a signature.  So I'm not sure you can achieve this benefit even with 
<RequestReference>.



>This would be simpler for the end-user:  the software developer would 
>just  re-run his command-line tool, without having to keep track of 
>the  RequestReference.  It would also have less impact on the protocol: 
>we  wouldn't need RequestReference, nor would we need to stretch the rules 
>as  above.
>
>[Pieter Kasselman]  I am not so sure, have you ever met a software 
>developer that can withstand the temptation of twiddling with the code 
>(even if it is just to get the curly braces perfectly aligned).
okay.  That strikes close to home :-)...

>  what if the developer is requesting signatures on two or three different 
> versions of the same application? Re-submitting the entire request is 
> sub-optimal, handing back a reference or ticket to come back later is 
> more optimal for both the developer and the server.
In that case, I imagine the developer would make snapshots of the 
application to different directories, and run the tool from those 
directories.

Is it easier for the developer to manage a small token?  Maybe, but it 
doesn't seem a big deal either way.


Trevor