Re: [widgets] Digital Signatures

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

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.

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.

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.

I've added a red block to say that we are considering adding what you
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?

The Widgets P&C spec is written in such a way that the zip archive
should never need to be physically unpacked onto the file system.
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.

Ok, but I'm not sure why you would unpack it to the file system. The
spec does not deny the widget engine from doing that, but it does
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.

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

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

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

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

I don't know what the "outer zip layer" is? Do you mean going from
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.

Ok. That also makes sense. But like you said, it does mean extracting
the files somewhere which I thought we were trying to avoid. It does
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.

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.

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

<snip>

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

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 11 April 2008 05:19:14 UTC