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

[Pieter Kasselman <PKasselman@betrusted.com>]

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

Thanks Trevor, in general I like the idea of fitting as much as possible into the exisiting framework. I guess a key question is if the code-signing profile is the only profile that will require asynchronous support, or if there are other profiles that require this as well?

Some comments and thoughts in-line :).

Cheers

Pieter

-----Original Message-----
From:   Trevor Perrin [SMTP:trevp@trevp.net]
Sent:   18 March 2004 21:01
To:     Pieter Kasselman; dss@lists.oasis-open.org
Subject:        RE: [dss] Groups - oasis-dss-1.0-profiles-codesigning-spec-wd-01. doc uploaded

>   - 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.

[Pieter Kasselman]  Right, so perhaps we need to think about asynchronous support at a higher level?

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

[Pieter Kasselman]  Maybe from an implementation perspective, but the server has to do more work and more bandwidth is consumed.

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".

[Pieter Kasselman]  This is still more work than taking a reference and checking it. On a busy server this will add up.

  - "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.

[Pieter Kasselman]  OK, in this model the request reference is fixed as the hash of the document, which precludes other types of request references that may include additional information (e.g. authorization assertions etc). Granted these can also be found by indexing of the hash value. If we take this approach, can we include some kind of an <OptionalInput> element to indicate that this is a retrieval request rather than a new request?

  - "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>.

[Pieter Kasselman]  If the code-signing portal accepts source code, inspects the code, compiles and then signs, it has to return the signature and the compiled program. I think the this will be different for different profiles and I would like to allow for both. The RequestReference has the advantage that it removes the requirement from the client to repeatedly send large messages (using DocumentHash as you suggested will achieve the same).

>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.

[Pieter Kasselman]  OK, so lets go for the small token (such as using the DocumentHash) and see how we can fit it into the exisiting framework :).

Trevor

This e-mail, and any attachments hereto, is intended only for use by the named addressee(s) and may contain legally privileged and/or confidential information.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments hereto, is strictly prohibited.  If you have received this transmission in error, please notify me immediately and permanently delete the original and all copies and printouts of this e-mail.