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

Hi Trevor, thanks for the comments. Some thoughts in-line

Cheers

Pieter

-----Original Message-----
From:   Trevor Perrin [SMTP:trevp@trevp.net]
Sent:   16 March 2004 22:47
To:     pkasselman@betrusted.com; dss@lists.oasis-open.org
Subject:        Re: [dss] Groups - oasis-dss-1.0-profiles-codesigning-spec-wd-01.doc uploaded

At 04:15 PM 3/16/2004 +0000, pkasselman@betrusted.com wrote:

>The document oasis-dss-1.0-profiles-codesigning-spec-wd-01.doc has been
>submitted by Pieter Kasselman (pkasselman@betrusted.com) to the OASIS
>Digital Signature Services TC document repository.
>
>Document Description:
>Abstract Code-Signing Profile - First Draft
>
>Download Document:
>http://www.oasis-open.org/apps/org/workgroup/dss/download.php/5967/oasis-dss-1.0-profiles-codesigning-spec-wd-01.doc




Hi Pieter,

I see this profile adds asynchronous capabilities to the signing
protcol.  I.e.:
  - client makes 1st request, gets back a RequestReference instead of a
signature
  - client waits some period of time
  - client makes 2nd request, sends RequestReference, gets signature

It's a legitimate scenario, and it was in our Requirements for awhile,
though we decided to remove it at the F2F.

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.

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

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.

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

Would this be a good solution?

[Pieter Kasselman]  I think the additional <ResultMajor> response is a good idea, but I think there is value in the <RequestReference> and would like to see how we can keep that in place. 

Minor Comments
-----------------------
The latest template has some different boilerplate for the Abstract and
Introduction.  In particular, it calls the whole document a profile, as
opposed to denoting "protocol profiles", "signature profiles", etc.
separately.  Don't feel obliged to change, but I think the latest text is
clearer:
http://www.oasis-open.org/apps/org/workgroup/dss/download.php/5985/oasis-dss-1.0-profiles-XYZ-spec-wd-04.pdf

Line 152 - since this profile is abstract, it doesn't need a URI identifier.

Line 154 - remove bracketed "[s]".

Line 156-157 - if you're changing to the new boilerplate, change it from
"the profiles in this document are based on the" to "this profile is based
on the".

[Pieter Kasselman]  I will migrate the abstract profile as we develop it to the latest boilerplate(s) as they develop as well.

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.