Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
On Thu, Jun 4, 2009 at 2:27 PM, Priestley, Mark, VF-Groupmark.priest...@vodafone.com 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. Fixed. 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. Using the definition that appears in PC. ---[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. I've removed them. ECDSA-SHA-256 could be added. Added, but, Fredrick, there seems to be some inconstancy in the spec with regards to the use of the algorithm names. Can you please check. Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specifications? Do they have a corresponding spec? [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. I agree. 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. Right. Frederick, wdyt? -- Marcos Caceres http://datadriven.com.au
RE: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
Hi Marcos, Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specifications? Do they have a corresponding spec? DSA-SHA-1 ANSI X9.57 DSA signature generated with SHA-1 hash (DSA x9.30) http://www.oid-info.com/get/1.2.840.10040.4.3 SHA-1 http://www.itl.nist.gov/fipspubs/fip180-1.htm RSA-SHA-256 RSA http://tools.ietf.org/rfc/rfc2437.txt SHA-256 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf ECDSA-SHA-256 ECDSA is specified in X9.62 http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62%3a2005 (paid resource) In RFCs it is referred to as: [X9.62] American National Standards Institute. ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm. January 1999. SHA-256 as above For SHA-XXX alternatively the following can be used: http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf (includes SHA-1, SHA-256 and more) Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Monday, June 08, 2009 1:08 PM To: Priestley, Mark, VF-Group; Frederick Hirsch Cc: Arthur Barstow; public-webapps; public-xml...@w3.org Subject: Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1 On Thu, Jun 4, 2009 at 2:27 PM, Priestley, Mark, VF-Groupmark.priest...@vodafone.com 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. Fixed. 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. Using the definition that appears in PC. ---[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. I've removed them. ECDSA-SHA-256 could be added. Added, but, Fredrick, there seems to be some inconstancy in the spec with regards to the use of the algorithm names. Can you please check. Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specifications? Do they have a corresponding spec? [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. I agree. 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. Right. Frederick, wdyt? -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5
Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
On Jun 8, 2009, at 2:30 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specifications? Do they have a corresponding spec? DSA-SHA-1 ANSI X9.57 DSA signature generated with SHA-1 hash (DSA x9.30) http://www.oid-info.com/get/1.2.840.10040.4.3 SHA-1 http://www.itl.nist.gov/fipspubs/fip180-1.htm RSA-SHA-256 RSA http://tools.ietf.org/rfc/rfc2437.txt SHA-256 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf ECDSA-SHA-256 ECDSA is specified in X9.62 http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62%3a2005 (paid resource) In RFCs it is referred to as: [X9.62] American National Standards Institute. ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm. January 1999. SHA-256 as above For SHA-XXX alternatively the following can be used: http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf (includes SHA-1, SHA-256 and more) Thanks. Thanks Marcin, that's great! If I get the ok from Frederick, I'll add them in. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org ] On Behalf Of Marcos Caceres Sent: Monday, June 08, 2009 1:08 PM To: Priestley, Mark, VF-Group; Frederick Hirsch Cc: Arthur Barstow; public-webapps; public-xml...@w3.org Subject: Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1 On Thu, Jun 4, 2009 at 2:27 PM, Priestley, Mark, VF-Groupmark.priest...@vodafone.com 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. Fixed. 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. Using the definition that appears in PC. ---[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. I've removed them. ECDSA-SHA-256 could be added. Added, but, Fredrick, there seems to be some inconstancy in the spec with regards to the use of the algorithm names. Can you please check. Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specifications? Do they have a corresponding spec? [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. I agree. 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
Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
XML Signature 1.1 should be referenced. It defines the URI for the algorithms, context for use in XML Signature, and references etc. regards, Frederick Frederick Hirsch Nokia On Jun 8, 2009, at 8:30 AM, ext Marcin Hanclik wrote: Hi Marcos, Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specifications? Do they have a corresponding spec? DSA-SHA-1 ANSI X9.57 DSA signature generated with SHA-1 hash (DSA x9.30) http://www.oid-info.com/get/1.2.840.10040.4.3 SHA-1 http://www.itl.nist.gov/fipspubs/fip180-1.htm RSA-SHA-256 RSA http://tools.ietf.org/rfc/rfc2437.txt SHA-256 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf ECDSA-SHA-256 ECDSA is specified in X9.62 http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62%3a2005 (paid resource) In RFCs it is referred to as: [X9.62] American National Standards Institute. ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm. January 1999. SHA-256 as above For SHA-XXX alternatively the following can be used: http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf (includes SHA-1, SHA-256 and more) Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org ] On Behalf Of Marcos Caceres Sent: Monday, June 08, 2009 1:08 PM To: Priestley, Mark, VF-Group; Frederick Hirsch Cc: Arthur Barstow; public-webapps; public-xml...@w3.org Subject: Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1 On Thu, Jun 4, 2009 at 2:27 PM, Priestley, Mark, VF-Groupmark.priest...@vodafone.com 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. Fixed. 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. Using the definition that appears in PC. ---[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. I've removed them. ECDSA-SHA-256 could be added. Added, but, Fredrick, there seems to be some inconstancy in the spec with regards to the use of the algorithm names. Can you please check. Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specifications? Do they have a corresponding spec? [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. I agree. 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
Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
1) inconsistency question Added, but, Fredrick, there seems to be some inconstancy in the spec with regards to the use of the algorithm names. Can you please check. should be ECDSAwithSHA256 , is that the extent of the inconsistency question? xml signature 1.1 algorithms section http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Algorithms 2) Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specs I believe we should refer to XML SIgnature 1.1 which then provides appropriate material 3) section 6 vs section 7.1 I suggest we keep the language as is. 7.1 says you must use an algorithm in section 6, section 6 says you must support certain ones, and may support others. There is nothing inconsistent or wrong here. Thus if we change the rules in section 6 we do not need to change section 7. (I thought we decided on the last wg call to freeze the spec but I guess not... ) regards, Frederick Frederick Hirsch Nokia On Jun 8, 2009, at 7:07 AM, ext Marcos Caceres wrote: On Thu, Jun 4, 2009 at 2:27 PM, Priestley, Mark, VF-Groupmark.priest...@vodafone.com 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. Fixed. 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. Using the definition that appears in PC. ---[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. I've removed them. ECDSA-SHA-256 could be added. Added, but, Fredrick, there seems to be some inconstancy in the spec with regards to the use of the algorithm names. Can you please check. Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any specifications? Do they have a corresponding spec? [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. I agree. 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. Right. Frederick, wdyt? -- Marcos Caceres http://datadriven.com.au
RE: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
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-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 21 May 2009 18:23 To: public-webapps; public-xml...@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
Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
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-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 21 May 2009 18:23 To: public-webapps; public-xml...@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
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/
