[fwd] Re: [widgets] Digital Signatures (from: tlr@w3.org)

FYI, I've done a quick review of the current state of the widget
signing spec:

  http://dev.w3.org/2006/waf/widgets-digsig/
  http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0025.html

If you have substantive follow-up, I would recommend sending it to
public-appformats@w3.org as well.

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





----- Forwarded message from Thomas Roessler <tlr@w3.org> -----

From: Thomas Roessler <tlr@w3.org>
To: Marcos Caceres <marcosscaceres@gmail.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Date: Fri, 4 Apr 2008 15:30:17 +0200
Subject: Re: [widgets] Digital Signatures
X-Spam-Level: 
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6

Hi Marcos,

some observations while going through the document...

- Introduction: signing doen't necessarily involve encrypting a hash
  value, so don't say it does.  (E.g., you could cast an RSA
  signature into an encryption / decryption process, but you can't
  do that with a DSA signature.)

- What does "hashing the directories" mean?

- Signature profile: "All resources must be  ... included with the
  signature.xml file" -- does that mean that all resources are
  enveloped within the signature?  I suspect you mean that all
  resources must be signed.  Say that.

- You write: "All digests must be calculated using RSA-SHA1".  You
  prbably mean that the signature is calculated using RSA-SHA1, and
  that the individual Reference elements will use SHA1 as the digest
  mechanism.  Note that it is possible to use RSA-SHA1 as the
  SignatureMethod, and a hash algorithm different from SHA1 for a
  reference element.

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

- Conformance: You say that the only product class that can claim
  performance is a digital signature document; yet, a bit later, you
  claim that "a widget user agent must behave as described by this
  specification."  There's a bit of inconsistency here.

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

  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.

  (I suspect that the idea is that the URI parameter is input to a
  Zip extractor, and that extractor is identified as a transform.
  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.  I'd suggest that, instead, you say how
  relative URI references within a signature that conforms to this
  profile are interpreted.)

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

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

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

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





On 2008-03-19 16:28:22 +1000, Marcos Caceres wrote:
> From: Marcos Caceres <marcosscaceres@gmail.com>
> To: "WAF WG (public)" <public-appformats@w3.org>
> Date: Wed, 19 Mar 2008 16:28:22 +1000
> Subject: [widgets] Digital Signatures
> List-Id: <public-appformats.w3.org>
> X-Spam-Level: 
> Archived-At: <http://www.w3.org/mid/b21a10670803182328i57a52be2va471dff2f5e0e01e@mail.gmail.com>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
> 
> Hi All,
> I've updated the digital signature spec [1]. I've modified the
> verification algorithm so that literal comparisons of file/folder
> names are done in UTF-8. I also checked what happens when you sign an
> empty directory (nothing special happens:)), so all file/folder
> entries are treated equally.
> 
> Any feedback is greatly appreciated.
> 
> Kind regards,
> Marcos
> [1]   http://dev.w3.org/2006/waf/widgets-digsig/
> -- 
> Marcos Caceres
> http://datadriven.com.au
> 
> 



----- End forwarded message -----

Received on Friday, 4 April 2008 13:54:26 UTC