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-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