- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 4 Apr 2008 15:53:50 +0200
- To: public-xmlsec-maintwg@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