Re: [widgets] Digital Signatures

Hello Thomas

Have the edits that Marcos made to widgets Digital Signatures spec satisfied you? It seems to me that your major points have been addressed.

If the overall approach is basically sound, I want to approve FPWD even if there are small details where you disagree. refinement is a job for future drafts. Only if the whole thing was screwwy would we withold FPWD.

Given the upcoming publishing moratorium, I want to approve the FPWD today.

On Friday, April 11, 2008, 7:11:34 AM, Marcos wrote:

MC> Hi Thomas,
MC> Please review the comments below and let Chris known if we can go
MC> forth and publish a FPWD.

MC> On Wed, Apr 9, 2008 at 2:57 AM, Thomas Roessler <tlr@w3.org> wrote:
>> On 2008-04-08 16:31:51 +1000, Marcos Caceres wrote:

>>  > "Digitally signing a widget resource involves signing all of its file
>>  > entries using a unique private key that is known only to the signer.
>>  > The resulting encrypted signature, along with the signer's digital

>>  strike "encrypted", it's wrong.

MC> Done.

>>  > certificate, is structured into an XML document, and included at the
>>  > root of a widget resource under the name signature.xml."
>>  >
>>  > >  - What does "hashing the directories" mean?
>>  >
>>  > Nothing.  All file entries are treated equally.

>>  In that case, please strike it.

MC> Done.

>>  > >  - You might want to actually force a SignatureProperties element to
>>  > >   be present, to identify the version of the profile that's used by
>>  > >   a given signature.

>>  > What would this look like?

>>  You'd define a pretty minimal XML vocabulary -- maybe just one
>>  element, say, WidgetSigningProfile, with a version parameter.
>>  That's then dropped into SignatureProperties, and the
>>  SignatureProperties element is signed.

MC> I've added a red block to say that we are considering adding what you
MC> suggested.

>>  In any event, that's something we can sort out after FPWD.


>>  > >  - I don't understand the deflate transform.  Do you assume (for the
>>  > >   example) that a file index.html is part of the widget resource,
>>  > >   but actually holds compressed content that needs to be deflated,
>>  > >   in addition to any unpacking of an outer packaging layer that
>>  > >   would hold signature.xml and index.html?
>>  >
>>  > I will remove it.
>>  >
>>  > >   Also, note that signing the deflated content means that conforming
>>  > >   user agents would have to perform an additional deflation step,
>>  > >   possibly leading to additional attack surface.
>>  >
>>  > Yeah, it's a risk. Signing now happens on the raw data found in a file
>>  > entry's data field, regardless of it being compressed or not.

>>  I'm not sure I understand what this means (but note I didn't read
>>  the latest editor's draft, yet) -- are you talking about the file as
>>  it would sit in a file system when the zip archive is unpacked, or
>>  about whatever part of the zip archive is associated with the file?

MC> The Widgets P&C spec is written in such a way that the zip archive
MC> should never need to be physically unpacked onto the file system.
MC> However, nothing stops an implementation from doing so.

>>  My read of the spec would be that it means (and probably should mean)
>>  the file as unpacked into a file system.  Sorry if my earlier
>>  comment was confusing.

MC> Ok, but I'm not sure why you would unpack it to the file system. The
MC> spec does not deny the widget engine from doing that, but it does
MC> discourage it.


>>  > >   (I suspect that the idea is that the URI parameter is input to a
>>  > >   Zip extractor, and that extractor is identified as a transform.
>>  >
>>  > Yes.
>>  >
>>  > >   That actually doesn't fit well into xmldsig-core's reference
>>  > >   processing and transform model, as that model means that you
>>  > >   dereference the URI and then pass the information retrieved into
>>  > >   the transform chain.
>>  >
>>  > Yeah, I tried to do this with the Java implementation and got stuck.
>>  > That's why I thought the Deflate Transform might solve the problem...
>>  > guess not.

>>  umhh...  see below.


>>  > >I'd suggest that, instead, you say how
>>  > >   relative URI references within a signature that conforms to this
>>  > >   profile are interpreted.)
>>  >
>>  > I've added a note that says: "ISSUE: path must be checked and
>>  > normalized to a valid uri for this specification."

>>  I'm not sure that's what we really want to say.  It might be enough
>>  to say that the relative URI references are evaluated with respect
>>  to a (possibly hypothetical, possibly file://) base URI that points
>>  at the root of the widget resource, as unpacked.

MC> Ok, there are two parts to this problem. Signing and verifying.

MC> 1. signing, for now, I'll say:
MC>   "Verify that path (URI) is a valid zip-relative-path."

MC> The "path" is the filename as it appears inside the file entry (its
MC> "file name field"), and that is what become the <Reference URI>. Only
MC> once the path is verified, it will be included in the signature.
MC> Amongst other things, a zip relative path does not allow for the
MC> formulation of full URIs because ":" is not allowed. However, I need
MC> you to have a look at the zip-relative-path (in the Widgets P&C spec)
MC> and make sure that it is ok from a security standpoint.

MC> 2. To Verifying, I now say (based on what you said above and below):
MC> "1. Let base-URI be the absolute path to where the widget archive was
MC> extracted (eg. file:///temp/widget/)
MC> 2. Validate against the matched file entry's decompressed
MC> representation. The relative URI references are evaluated with respect
MC> to a base URI that points at where the widget resource was
MC> demcompressed."

>>  > In the verification process, I've said:
>>  > "Apply the Reference Validation algorithm as defined in [XMLDsig], by
>>  > taking each Reference element and exactly matching the value of the
>>  > URI attribute to the file name field of a file entry. Validate against
>>  > the matched file entry's data field (do not use the decompressed
>>  > representation)."
>>  >
>>  > So, no extraction is done and matching of the URI must be exact to
>>  > something in the Zip file ( /config.xml !=  "/test/../config.xml")

>>  Ouch, no, that's not what I tried to suggest.  It's an interesting
>>  approach toward signing a zip file, but I'm not sure it's a good
>>  idea for this particular use case -- among other things, it would
>>  make exchanging the outer zip layer by something else pretty much
>>  impossible.

MC> I don't know what the "outer zip layer" is? Do you mean going from
MC> Zip, to, say, TAR?

>>  So, as I said above, the counterproposal would be to
>>  (hypothetically) extract the archive, add security considerations
>>  about the impacts that that can have, and then interpret the URI
>>  references relative to the zip archive's root.

MC> Ok. That also makes sense. But like you said, it does mean extracting
MC> the files somewhere which I thought we were trying to avoid. It does
MC> make life a lot simpler, however.

>>  I could see one or two alternative designs (e.g., enabling discovery
>>  of a detached signature of the zip archive, with additional
>>  structural information in that signature resource), but I'm happy to
>>  defer discussion of that till after FPWD.

MC> That sounds a bit more complicated. However, I'd be like to hear the details.

>>  Overall, I think that the approach I outlined above is the most
>>  straightforward one, and would suggest taking it for now.

MC> Ok. Hopefully I've captured your recommendations. Please see the spec.

MC> <snip>

MC> I've updated the signing and verification parts. If you think they are
MC> OK, please give this document your approval for FPWD.

MC> Kind regards,
MC> Marcos





-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Friday, 11 April 2008 12:23:45 UTC