Re: [widgets] Digital Signatures

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.

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

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

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?

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

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

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

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.

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.

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

> >  - Section 5 sounds like it has a user agent as the conforming
> >   product, not a document.  That said, I suspect that this section
> >   basically says "for each file in the widget, generate a Reference
> >   element that holds a digest of that file."  That's unnecessarily
> >   obscured by the detailed step-by-step instructions for creating
> >   the document.
> >
> >   -1 to writing pseudocode here.

> I agree, I'll change the pseudocode later. The pseudocode makes it
> easier (for me) to work out the logic at this point...  (though I am
> not claiming it has helped!;)).

ok

> >  - Why use ds:Manifest?  Thats for holding ds:Reference elements that
> >   you don't necessarily want to dereference, e.g., because you've
> >   several signatures for the same URI reference (signing multiple
> >   representations), or because you've signature semantics that make
> >   verifying signatures on certain resources optional.  I don't think
> >   that's the case here.

> You are right. I had misunderstood the function of manifest. Manifest
> is gone. Everything is in Signed info now.

ok

> >   On the other hand, if you just use a collection ds:Reference
> >   elements which are direct children of ds:SignedInfo, XML Signature
> >   core validation will ensure that all resources are signed.
> 
> Yes. This is what we want: core validation on the entries.
> 
> >  - In the verification procedure, you say:
> >
> >      1.  If the widget user agent does not contain the root
> >      certificate that allows it to verify the <KeyInfo> certificate,
> >      then the widget user agent should warn the user that the
> >      certificate is not trusted.
> >
> >   What does "contain" mean here?  Is a certificate "contained" when
> >   it's on a list of explicitly untrusted root certificates?  Is the
> >   certificate to be trusted when the user agent has the root
> >   certificate's hash stored somewhere, but the certificate is only
> >   included with KeyInfo?
> >
> >   Please be precise about what you mean here.  Also, I'd rather say
> >   that the signature MUST be considered invalid than go into
> >   detailed UA behavior (for the purposes of this particular
> >   specification, at least).
> 
> I've said this:
> "If the widget user agent cannot verify the certificate from its list
> of explicitly trusted root certificates, then the certificate must be
> treated as invalid."

close enough for the FPWD, I'd say.

> Hopefully that is good enough for the FPWD.

I'm mostly happy with these changes (modulo not having read the
draft, due to being at a conference this week), but would hope that
you could have another look (before FWPD) at the way you interpret
references.  I fear that's rather confused right now, and apologize
if I was contributing to the confusion.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Tuesday, 8 April 2008 16:58:54 UTC