- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Thu, 4 Jun 2009 08:41:45 -0400
- To: "ext Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
XML Signature 1.1 notes that the order of certificates in X.509Data is not specified. http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-X509Data Is this really expected to be an issue, with long cert chains? regards, Frederick Frederick Hirsch Nokia On Jun 4, 2009, at 8:27 AM, ext Priestley, Mark, VF-Group wrote: > Hi Art, All, > > Vodafone has some late comments which it would like to provide to the > group for consideration and apologise for supplying these after the > deadline. > > We believe that all but one of the comments is editorial and so there > inclusion or otherwise should not affect or delay the decision to go > to > CR status, which we support. In submitting these comments it is not > our > intention or desire to hold up this process, only to provide the > comments for consideration. > > The only comment that doesn't fit into this category is a question > that > has been raised by one of our developers. My hope is that there is > already an answer! > > Thanks, > > Mark > > ----------------------- > Editorial Comments > ----------------------- > > -------[Definition of file entry]------- > > Section: 1.2 > > "A file entry is the compressed (or Stored [ZIP]) representation of a > physical file or folder contained within a widget package, as > defined in > the [Widgets Packaging] specification." > > In Widgets 1.0: Packaging and Configuration [2] the file entry > definition is different. > > "A file entry is the data held by a local file header, file data, and > (optional) data descriptor, as defined in the [ZIP] specification, for > each physical file contained in a Zip archive." > > Comment - the inclusion of folder in the definition in [1] has caused > one reviewer to ask if there should be a reference element for > folders? > I believe this is not the case and "or folder" could be removed from > the > definition. > > -------[Requirements accuracy]------- > > Section: 2 > > "R52. Support for Multiple Signature Algorithms: DSA-SHA-1, RSA-SHA-1, > DSA-SHA-256 and RSA-SHA-256." > > Are these algorithms still correct? DSA-SHA-256 and RSA-SHA-1 should > probably be removed as they are not required algorithms. ECDSA-SHA-256 > could be added. > > [Conflict between mandatory statements] > > "A user agent MAY support additional signature algorithms." (Section: > 6.1) > "A user agent MAY support additional digest methods." (Section: 6.2) > "A user agent MAY support additional XML canonicalization methods." > (Section: 6.3) > > Section: 7.1 > "The Algorithm attribute of the ds:digestMethod MUST be one of the > digest algorithms." > "The Algorithm attribute of the ds:CanonicalizationMethod element MUST > be one of the canonicalization algorithms." > "The ds:SignatureMethod algorithm used in the ds:SignatureValue > element > MUST be one of the signature algorithms." > > Comment - If in section 6 we say "A user agent MAY support additional > XXX algorithms", which seems to be in conflict with section 7 that > states the algorithm used must be one of algorithms listed in > section 6. > This seems to be an open ended requirement. > > Suggestion - Remove the statements in section 7.1. It is down to the > signer to choose the algorithm to use. If they choose to use a > non-recommended algorithm they should understand that user agent > support > cannot be guaranteed. > > ----------------------- > Question / non-editorial > ----------------------- > > -------[Support for certificate chains]------- > > Typically more than one X509 certificate will need to be included in > the > signature in order to construct a certificate chain to an installed > root > certificate. Ideally the widget user agent would be given an > indication > of how to re-construct the certificate chain. This could be done my > recommending that X509Certificate elements be included in certificate > chain order or by including an attribute to the element, e.g. > > <X509Data> > <X509Certificate order="1">...</X509Certificate> > <X509Certificate order="2">...</X509Certificate> > <X509Certificate order="3">...</X509Certificate> </X509Data> > > Maybe this is already solved with other uses of XML Digital > Signatures? > > > [1] http://dev.w3.org/2006/waf/widgets-digsig/ > [2] http://www.w3.org/TR/widgets/#definitions > > > > > > > > > > > > > > -----Original Message----- > From: public-webapps-request@w3.org > [mailto:public-webapps-request@w3.org] On Behalf Of Arthur Barstow > Sent: 21 May 2009 18:23 > To: public-webapps; public-xmlsec@w3.org > Subject: Reminder: Comments for LCWD of Widgets 1.0: Digital > Signatures > due June 1 > > Hi All - a friendly reminder June 1 is the end of the comment period > for > the April 30 Widgets 1.0: Digital Signatures Last Call Working > Draft: > > <http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/> > > Please send all comments by June 1. > > -Regards, Art Barstow > > > On May 1, 2009, at 10:48 AM, Barstow Art (Nokia-CIC/Boston) wrote: > >> On April 30 the WebApps WG published a LCWD of the Widgets 1.0 >> Digital > >> Signatures spec: >> >> [[ >> <http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/> >> >> Introduction >> >> This document defines a profile of the XML Signature Syntax and >> Processing 1.1 specification to allow a widget package to be >> digitally > >> signed. Widget authors and distributors can digitally sign widgets as >> a mechanism to ensure continuity of authorship and distributorship. >> Prior to instantiation, a user agent can use the digital signature to >> verify the integrity of the widget package and to confirm the signing >> key(s). This document specifies conformance requirements on both >> widget packages and user agents. >> >> A widget package can be signed by the author of the widget producing >> an [XMLDSIG11] signature that cryptographically includes all of the >> file entries other than signature files. A widget package can also be >> signed by one or more distributors of the widget, producing >> [XMLDSIG11] signatures that each cryptographically includes all of >> the > >> non-signature file entries as well as any author signature. >> ]] >> >> We explicitly seek comments from the XML Security WG; comments from >> other WGs as well as the TAG are welcome. >> >> The comment period ends 1 June 2009. >> >> All comments should be sent to public-webapps@w3.org [1]. >> >> -Regards, Art Barstow >> >> [1] <http://lists.w3.org/Archives/Public/public-webapps/> >> >> > > >
Received on Thursday, 4 June 2009 12:42:46 UTC