RE: [dss] Approach to code-signing profile

[Trevor Perrin <trevp@trevp.net>]

At 06:37 AM 1/22/2004 -0500, Pieter Kasselman wrote:

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

Agreed.

>-----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?).
Yeah, I think we want to factor "generally useful" stuff back into the 
core, as we discover it.

>  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
Good question: in particular, which of the 2 things you describe should we 
call a profile?  The 1st I'd call an "abstract protocol profile" of DSS, 
the second an "application profile" which brings together:
  - a concrete protocol profile (with features specific to JARs, CABs, etc.).
  - a binding

How do we carve these up into documents?  We could have:
  - abstract protocol profile documents - e.g. code-signing
  - concrete protocol profile documents - e.g. code-signing(JARs)
  - application profile documents - e.g. code-signing(JARs)/SOAP-HTTP-TLS

That's a lot of documents, though.  Alternatively we could just have 
self-contained "profile documents" that each fully describe an application 
profile (concrete protocol profile & binding).

The downside is that this doesn't separate the protocol profiles into 
separate, reference-able documents.  We could still write informative 
documents describing the commonality amongst a family of profile documents, 
but these would be purely descriptive, the "profile documents" would be 
implementable without them.

Anyways, I think this might be simpler for implementors, since they just 
have to look at a single profile document, and if we reserve the term 
"profile" for these documents, then any implementations of the same profile 
would interoperate.  Which would make things easy to talk about.

(One more twist: we could separate "application profiles" into client-side 
and server-side, with the idea that there might be a one-to-many 
relationship between client application profiles and server application 
profiles: for example, a time-stamping client could get different types of 
time-stamps.  We could include all these in a single profile document, 
which would thus have a single client profile and one or more server profiles).

>  (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.
I agree that the bindings should be defined in their own document, or as 
part of the core.  I'm not sure how/where we should combine the bindings 
with the "protocol profiles" though.

>  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.
Since agreeing on a binding is necessary for interop, at some level we'll 
need to combine the bindings with the protocols (though can give secure and 
unsecure bindings options).

I'm also just curious whether people would prefer to use SOAP, or just HTTP 
POSTs; and if SOAP, whether WS-Security or TLS is preferable.

I ask cause HTTP POST and TLS seems the simplest to me, so I'm curious if 
we need bindings for SOAP and WS-Security.

>      - 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)
Yeah, that last part's what I'm wondering - to what extent can 
client-verification of the signature substitute for a secure binding.


Trevor