Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
I've added this to the Widgets Signature specification. regards, Frederick Frederick Hirsch Nokia On Apr 23, 2009, at 3:18 AM, ext Priestley, Mark, VF-Group wrote: Thanks Frederick! -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: 22 April 2009 23:20 To: Priestley, Mark, VF-Group Cc: Frederick Hirsch; marc...@opera.com; Barstow Art (Nokia-CIC/ Boston); public-webapps Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 I think the following items are fine and will add them to the spec: Signing parties are expected to ensure that the dsp:Identifier signature property value is unique for the widgets that they sign 5.5 and 7.2 I don't think there is anything else, though we need to check the blogs and also to see if any new mistakes have been introduced. regards, Frederick Frederick Hirsch Nokia On Apr 22, 2009, at 5:53 PM, ext Priestley, Mark, VF-Group wrote: Thanks Frederick and Marcos - responses inline. Only a couple of questions left :) Regards, Mark -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 22 April 2009 11:46 To: Frederick Hirsch; Priestley, Mark, VF-Group Cc: Barstow Art (Nokia-CIC/Boston); public-webapps Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Mark Please find responses inline. Thanks for the review. regards, Frederick Frederick Hirsch Nokia On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote: Hi Art, All, Please find below my editorial comments and requests for clarifications based on the new WD [1]. While it is a long list the comments are all minor and so hopefully easily addressed. Overall I think the spec is looking good, for which a lot of thanks must go to Frederick and Marcos! That said, I have a couple of more substantive comments that I will send in the next couple of days. Many thanks, Mark [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/ - COMMENTS - 1.0 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, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Change the last sentence for consistency between definitions, ie: ... A widget package can also be signed by one or more distributors change of the widget, producing [XMLDSIG11] /change signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. ok [mp] Thanks - Can we remove the following sentence? This is a general property of signatures which I'm not sure we need to include. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source. ok [mp] Thanks - 1.1 We don't actually define any XML elements in the http://www.w3.org/ns/widgets-digsig; namespace... is this worth noting this and/or removing the wsig prefix? We define URIs using this namespace so we should keep the URI definition. ok with removing prefix since it is not used now but would prefer to keep to avoid errors later. Not a big issue to remove though. [mp] I'm OK either way. - The terms XML elements and resources seem to be used interchangeably? Is there a difference? yes, one is xml elements others are resources as referenced by URI Mark, I'm worried you asked this question? Is there confusion somewhere wrt to the use resource and xml elements? [mp] No, it's mostly a case of me needing to read the text more carefully! My confusion was caused by the fact we only define the namespace prefixes that we use in throughout the spec in the context of resources. - Algorithms used by XML Security are defined in a number of places... - could we tighten up this sentence, eg something like This specification references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ? No, XMLSecAlgs does not define the algs. There are defined in a number of places :) OK - my concern was just that [XMLSecAlgs] cross references lots of algorithms that we don't need but happy to leave as it is. - 1.2 compressed (or Stored) - either remove capitalisation of Stored or add it to compressed I suggest stored. Marcos? Stored should probably be [Stored], with a reference to the RFC for the algorithm. [mp] OK for me - physical file - file ? Marcos? ok with file personally Agree. [mp] Thanks - top-most path level - is there a better way of saying this? don't think so unless you have a proposal without using
Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Mark Please find responses inline. Thanks for the review. regards, Frederick Frederick Hirsch Nokia On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote: Hi Art, All, Please find below my editorial comments and requests for clarifications based on the new WD [1]. While it is a long list the comments are all minor and so hopefully easily addressed. Overall I think the spec is looking good, for which a lot of thanks must go to Frederick and Marcos! That said, I have a couple of more substantive comments that I will send in the next couple of days. Many thanks, Mark [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/ - COMMENTS - 1.0 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, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Change the last sentence for consistency between definitions, ie: ... A widget package can also be signed by one or more distributors change of the widget, producing [XMLDSIG11] /change signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. ok - Can we remove the following sentence? This is a general property of signatures which I'm not sure we need to include. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source. ok - 1.1 We don't actually define any XML elements in the http://www.w3.org/ns/widgets-digsig; namespace... is this worth noting this and/or removing the wsig prefix? We define URIs using this namespace so we should keep the URI definition. ok with removing prefix since it is not used now but would prefer to keep to avoid errors later. Not a big issue to remove though. - The terms XML elements and resources seem to be used interchangeably? Is there a difference? yes, one is xml elements others are resources as referenced by URI Mark, I'm worried you asked this question? Is there confusion somewhere wrt to the use resource and xml elements? - Algorithms used by XML Security are defined in a number of places... - could we tighten up this sentence, eg something like This specification references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ? No, XMLSecAlgs does not define the algs. There are defined in a number of places :) - 1.2 compressed (or Stored) - either remove capitalisation of Stored or add it to compressed I suggest stored. Marcos? Stored should probably be [Stored], with a reference to the RFC for the algorithm. - physical file - file ? Marcos? ok with file personally Agree. - top-most path level - is there a better way of saying this? don't think so unless you have a proposal without using the word root I know it's nasty, but people understand it. Lets play wordsmith only once we have all the tech stuff solved. - which MAY logically contain - if the configuration file is made mandatory then the MAY should be a MUST I think it is a MAY, others? Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY altogether) because this spec does not put conformance criteria on packaging. - Question: is a file entry the same as a file? If so then we should always use file entry in place of file. If not then perhaps we should define file? I don't think they are the same. This is a PC question. Marcos? Depends. A file entry is the representation of file data in a zip archive. A file is a physical uncompressed file as would appear on disk. If we assume that signatures will act on physical files, it will be correct to talk about files. - (i.e., a third party that is distributing the widget on behalf of the author). - in some cases the author may also be (one of) the distributor(s). suggest changing i.e. to e.g. I think i.e. is correct. In the case you suggest they just happen to be the same entity fulfilling two roles. - 3 As well as sections marked as non-normative, examples and notes in this specification are non-normative. Everything else in this specification is normative. The security considerations section is non-normative. Suggest change to the following for readability: As well as sections marked as non-normative, the examples and notes, and security considerations in this specification are non-normative. Everything else in this specification is normative. yes, better. - 4 This section defines how to locate digital signatures in a widget package for processing. An implementation MUST achieve the same result as
Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
Two proposals based on Marcos comments - which MAY logically contain - if the configuration file is made mandatory then the MAY should be a MUST I think it is a MAY, others? Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY altogether) because this spec does not put conformance criteria on packaging. Dropped MAY for reason Marcos mentioned, also since not really appropriate to definition. Question: is a file entry the same as a file? If so then we should always use file entry in place of file. If not then perhaps we should define file? I don't think they are the same. This is a PC question. Marcos? Depends. A file entry is the representation of file data in a zip archive. A file is a physical uncompressed file as would appear on disk. If we assume that signatures will act on physical files, it will be correct to talk about files. I don't think we can always expect creation of a physical file for processing. Suggest not making any change here. regards, Frederick Frederick Hirsch Nokia On Apr 22, 2009, at 6:45 AM, ext Marcos Caceres wrote: On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Mark Please find responses inline. Thanks for the review. regards, Frederick Frederick Hirsch Nokia On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote: Hi Art, All, Please find below my editorial comments and requests for clarifications based on the new WD [1]. While it is a long list the comments are all minor and so hopefully easily addressed. Overall I think the spec is looking good, for which a lot of thanks must go to Frederick and Marcos! That said, I have a couple of more substantive comments that I will send in the next couple of days. Many thanks, Mark [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/ - COMMENTS - 1.0 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, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Change the last sentence for consistency between definitions, ie: ... A widget package can also be signed by one or more distributors change of the widget, producing [XMLDSIG11] /change signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. ok - Can we remove the following sentence? This is a general property of signatures which I'm not sure we need to include. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source. ok - 1.1 We don't actually define any XML elements in the http://www.w3.org/ns/widgets-digsig; namespace... is this worth noting this and/or removing the wsig prefix? We define URIs using this namespace so we should keep the URI definition. ok with removing prefix since it is not used now but would prefer to keep to avoid errors later. Not a big issue to remove though. - The terms XML elements and resources seem to be used interchangeably? Is there a difference? yes, one is xml elements others are resources as referenced by URI Mark, I'm worried you asked this question? Is there confusion somewhere wrt to the use resource and xml elements? - Algorithms used by XML Security are defined in a number of places... - could we tighten up this sentence, eg something like This specification references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ? No, XMLSecAlgs does not define the algs. There are defined in a number of places :) - 1.2 compressed (or Stored) - either remove capitalisation of Stored or add it to compressed I suggest stored. Marcos? Stored should probably be [Stored], with a reference to the RFC for the algorithm. - physical file - file ? Marcos? ok with file personally Agree. - top-most path level - is there a better way of saying this? don't think so unless you have a proposal without using the word root I know it's nasty, but people understand it. Lets play wordsmith only once we have all the tech stuff solved. - which MAY logically contain - if the configuration file is made mandatory then the MAY should be a MUST I think it is a MAY, others? Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY altogether) because this spec does not put conformance criteria on packaging. - Question: is a file entry the same as a file? If so then we should always use file entry in place of file. If not then perhaps we should define file? I don't think they are the same. This is a PC question. Marcos? Depends. A file entry is the representation of file data in a zip
RE: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
Thanks Frederick and Marcos - responses inline. Only a couple of questions left :) Regards, Mark -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 22 April 2009 11:46 To: Frederick Hirsch; Priestley, Mark, VF-Group Cc: Barstow Art (Nokia-CIC/Boston); public-webapps Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Mark Please find responses inline. Thanks for the review. regards, Frederick Frederick Hirsch Nokia On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote: Hi Art, All, Please find below my editorial comments and requests for clarifications based on the new WD [1]. While it is a long list the comments are all minor and so hopefully easily addressed. Overall I think the spec is looking good, for which a lot of thanks must go to Frederick and Marcos! That said, I have a couple of more substantive comments that I will send in the next couple of days. Many thanks, Mark [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/ - COMMENTS - 1.0 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, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Change the last sentence for consistency between definitions, ie: ... A widget package can also be signed by one or more distributors change of the widget, producing [XMLDSIG11] /change signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. ok [mp] Thanks - Can we remove the following sentence? This is a general property of signatures which I'm not sure we need to include. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source. ok [mp] Thanks - 1.1 We don't actually define any XML elements in the http://www.w3.org/ns/widgets-digsig; namespace... is this worth noting this and/or removing the wsig prefix? We define URIs using this namespace so we should keep the URI definition. ok with removing prefix since it is not used now but would prefer to keep to avoid errors later. Not a big issue to remove though. [mp] I'm OK either way. - The terms XML elements and resources seem to be used interchangeably? Is there a difference? yes, one is xml elements others are resources as referenced by URI Mark, I'm worried you asked this question? Is there confusion somewhere wrt to the use resource and xml elements? [mp] No, it's mostly a case of me needing to read the text more carefully! My confusion was caused by the fact we only define the namespace prefixes that we use in throughout the spec in the context of resources. - Algorithms used by XML Security are defined in a number of places... - could we tighten up this sentence, eg something like This specification references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ? No, XMLSecAlgs does not define the algs. There are defined in a number of places :) OK - my concern was just that [XMLSecAlgs] cross references lots of algorithms that we don't need but happy to leave as it is. - 1.2 compressed (or Stored) - either remove capitalisation of Stored or add it to compressed I suggest stored. Marcos? Stored should probably be [Stored], with a reference to the RFC for the algorithm. [mp] OK for me - physical file - file ? Marcos? ok with file personally Agree. [mp] Thanks - top-most path level - is there a better way of saying this? don't think so unless you have a proposal without using the word root I know it's nasty, but people understand it. Lets play wordsmith only once we have all the tech stuff solved. [mp] As I can't think of anything better, happy to leave as is. - which MAY logically contain - if the configuration file is made mandatory then the MAY should be a MUST I think it is a MAY, others? Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY altogether) because this spec does not put conformance criteria on packaging. [mp] proposal of the widget package, which logically contain one or more file entries, as defined Note that reading this again - if a file entry is a file or a folder, then there must be at least one file entry unless the widget is an empty package (and if it's signed it can't be empty because at a minimum there would be a signature file entry!) so I think one one or more is correct. - Question: is a file entry the same
Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
I think the following items are fine and will add them to the spec: Signing parties are expected to ensure that the dsp:Identifier signature property value is unique for the widgets that they sign 5.5 and 7.2 I don't think there is anything else, though we need to check the blogs and also to see if any new mistakes have been introduced. regards, Frederick Frederick Hirsch Nokia On Apr 22, 2009, at 5:53 PM, ext Priestley, Mark, VF-Group wrote: Thanks Frederick and Marcos - responses inline. Only a couple of questions left :) Regards, Mark -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 22 April 2009 11:46 To: Frederick Hirsch; Priestley, Mark, VF-Group Cc: Barstow Art (Nokia-CIC/Boston); public-webapps Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Mark Please find responses inline. Thanks for the review. regards, Frederick Frederick Hirsch Nokia On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote: Hi Art, All, Please find below my editorial comments and requests for clarifications based on the new WD [1]. While it is a long list the comments are all minor and so hopefully easily addressed. Overall I think the spec is looking good, for which a lot of thanks must go to Frederick and Marcos! That said, I have a couple of more substantive comments that I will send in the next couple of days. Many thanks, Mark [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/ - COMMENTS - 1.0 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, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Change the last sentence for consistency between definitions, ie: ... A widget package can also be signed by one or more distributors change of the widget, producing [XMLDSIG11] /change signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. ok [mp] Thanks - Can we remove the following sentence? This is a general property of signatures which I'm not sure we need to include. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source. ok [mp] Thanks - 1.1 We don't actually define any XML elements in the http://www.w3.org/ns/widgets-digsig; namespace... is this worth noting this and/or removing the wsig prefix? We define URIs using this namespace so we should keep the URI definition. ok with removing prefix since it is not used now but would prefer to keep to avoid errors later. Not a big issue to remove though. [mp] I'm OK either way. - The terms XML elements and resources seem to be used interchangeably? Is there a difference? yes, one is xml elements others are resources as referenced by URI Mark, I'm worried you asked this question? Is there confusion somewhere wrt to the use resource and xml elements? [mp] No, it's mostly a case of me needing to read the text more carefully! My confusion was caused by the fact we only define the namespace prefixes that we use in throughout the spec in the context of resources. - Algorithms used by XML Security are defined in a number of places... - could we tighten up this sentence, eg something like This specification references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ? No, XMLSecAlgs does not define the algs. There are defined in a number of places :) OK - my concern was just that [XMLSecAlgs] cross references lots of algorithms that we don't need but happy to leave as it is. - 1.2 compressed (or Stored) - either remove capitalisation of Stored or add it to compressed I suggest stored. Marcos? Stored should probably be [Stored], with a reference to the RFC for the algorithm. [mp] OK for me - physical file - file ? Marcos? ok with file personally Agree. [mp] Thanks - top-most path level - is there a better way of saying this? don't think so unless you have a proposal without using the word root I know it's nasty, but people understand it. Lets play wordsmith only once we have all the tech stuff solved. [mp] As I can't think of anything better, happy to leave as is. - which MAY logically contain - if the configuration file is made mandatory then the MAY should be a MUST I think it is a MAY, others? Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY altogether) because this spec does not put conformance criteria on packaging. [mp
RE: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
Hi Art, All, Please find below my editorial comments and requests for clarifications based on the new WD [1]. While it is a long list the comments are all minor and so hopefully easily addressed. Overall I think the spec is looking good, for which a lot of thanks must go to Frederick and Marcos! That said, I have a couple of more substantive comments that I will send in the next couple of days. Many thanks, Mark [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/ - COMMENTS - 1.0 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, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Change the last sentence for consistency between definitions, ie: ... A widget package can also be signed by one or more distributors change of the widget, producing [XMLDSIG11] /change signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. - Can we remove the following sentence? This is a general property of signatures which I'm not sure we need to include. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source. - 1.1 We don't actually define any XML elements in the http://www.w3.org/ns/widgets-digsig; namespace... is this worth noting this and/or removing the wsig prefix? - The terms XML elements and resources seem to be used interchangeably? Is there a difference? - Algorithms used by XML Security are defined in a number of places... - could we tighten up this sentence, eg something like This specification references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ? - 1.2 compressed (or Stored) - either remove capitalisation of Stored or add it to compressed - physical file - file ? - top-most path level - is there a better way of saying this? - which MAY logically contain - if the configuration file is made mandatory then the MAY should be a MUST - Question: is a file entry the same as a file? If so then we should always use file entry in place of file. If not then perhaps we should define file? - (i.e., a third party that is distributing the widget on behalf of the author). - in some cases the author may also be (one of) the distributor(s). suggest changing i.e. to e.g. - 3 As well as sections marked as non-normative, examples and notes in this specification are non-normative. Everything else in this specification is normative. The security considerations section is non-normative. Suggest change to the following for readability: As well as sections marked as non-normative, the examples and notes, and security considerations in this specification are non-normative. Everything else in this specification is normative. - 4 This section defines how to locate digital signatures in a widget package for processing. An implementation MUST achieve the same result as the following algorithm used to locate digital signatures in a widget package: In the sentence above, change digital signatures to signature files (in both cases) - This MAY be determined by the security policy used by the user agent. Can we say will or, better yet, SHOULD or MUST? Otherwise, what do we mean when we say MAY? Who (what) else may enforce security policy? - Thus the highest numbered distributor signature would be validated first. Change to: Thus in the case that one or more distributor signatures were validated, the highest numbered distributor signature would be validated first. - 5.1 A widget package MAY be digitally signed using XML Signature [XMLDSIG11]. don't we mean: A widget package MAY be digitally signed using the profile of XML Signature [XMLDSIG11] defined by this specification. ? - As this section is talking about generating a signature, I suggest that we remove and validated in the following sentence: Each signature file MUST be generated and validated in - 5.2 As per previous email exchange we need to re-work author signature definition - zero or one author signatures. - remove final s - This represents the digital signature of the author of the widget package. add signature file ie This signature file represents the digital signature of the author of the widget package. - 5.3 This represents the digital signature of a distributor of the widget package. add signature file ie This signature file represents the digital signature of a distributor of the widget package. - 5.3.1 Within a widget package these signature files MUST be ordered based on the numeric portion of the signature file name. Thus, for example, signature2.xml precedes signature11.xml.
