RE: [dss] Approach to code-signing profile

[Pieter Kasselman <PKasselman@betrusted.com>]

Title: RE: [dss] Approach to code-signing profile

Hi Trevor, see in-line

Generally I think a lot of these questions will be answered by looking at the use-cases for code-signing (I will make a stab at this as part of the more detailed profile). I would also like to propose that each profile has a "security considerations" section, basically serving the same purpose as found in IETF RFCs - this will help readers/implementors as much as the authors to focus on appropriate security models that goes with each profile.

-----Original Message-----
From:   Trevor Perrin [SMTP:trevp@trevp.net]
Sent:   20 January 2004 22:08
To:     Pieter Kasselman; dss@lists.oasis-open.org
Subject:        Re: [dss] Approach to code-signing profile

At 11:10 AM 1/20/2004 +0000, Pieter Kasselman wrote:

>Hi, here is an outline on the approach to the code-signing profile.




Hi Pieter,

a comment and a couple questions:

  - The code-signing profile seems to be an "abstract" or "meta"-profile,
just like the policy-based server profile.  So they face similar issues of
terminology, document organization, and relationships to other profiles.

[Pieter Kasselman]  To some extent, although based on my current understanding of the policy based server profile there are differences. In this case we may need the odd extension (perhaps this can be rolled back into the core?). I would like to see a distinction between "here is how DSS works for code-signing" and "here is how to get a jar/cab file signed using DSS". The first will ensure that there is some commonality across the various specific code-signing schemes that have to be handled by a DSS server. Perhaps we need a good definition of what constitues a profile (e.g. it is an interpretation of the core document for a specific application or collection of applications?). The diagram in the doc reflects to a large extent how I see profiles (e.g. as extended sub-sets of the core, re-using as much as possible, including bindings).

  - Have you thought about how transport/security bindings fit into here?

[Pieter Kasselman]  I was hoping to simply leverage of the bindings as defined elsewhere, possibly profiling them if required (hopefully not).

     - Would the code-signing profile be attached to a specific binding
(e.g. SOAP over HTTPS), or would the attachment to a binding be part of the
schemes?
[Pieter Kasselman]  I would like to see the bindings handled seperately from the profiles. There should be only one way to bind DSS to SOAP (for instance) regardless of the profile. This allows new bindings to be added/modified without changing a profile and it allows other profiles to benefit from exisiting bindings.

     - Have you given any thought to the specific bindings that would be
preferable (SOAP vs. plain HTTP; WS-Security vs. SSL)?
[Pieter Kasselman]  The use of a secure vs unsecured binding may be governed by the bussiness case, so we should allow all, but recommend secure bindings.

     - Would clients be required to verify the returned
code-signatures?  If so, would this eliminate the need for a secure binding?
[Pieter Kasselman]  Presumably the returned code-signed result will be tested by the software developer before releasing it (stop sniggering at the back there). Part of this test will be to ensure that the signature can be verified. To some extent this falls outside the scope of what we can standardise in DSS (we can not mandate, or test for compatibility, whether there is a QE process involved). This out-of-protocol process may also be insufficient to address all security concerns, so a secure binding may still be required (for instance confidentiality may be a requirement in some cases)

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.