Re: [widgets] Digital Signatures

Additionally, I don't think the current document says what to do
with absolute URI references in Reference elements.  Are these
dereferenced?   And how do you deal with references to resouces
that are external to the widget resource from indiivdual elements --
e.g., a <script> tag in the main widget element?

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






On 2008-04-04 15:30:17 +0200, Thomas Roessler wrote:
> 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
> > 
> > 
> 
>

Received on Friday, 4 April 2008 14:32:47 UTC