W3C

Disposition of comments for the XML Security Working Group

Single page view

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2372 Juan Carlos Cruellas <cruellas@ac.upc.edu> (archived comment)
resend to public list for the record.

regards, Frederick

Frederick Hirsch
Nokia



Begin forwarded message:

> From: ext Juan Carlos Cruellas <cruellas@ac.upc.edu>
> Date: January 29, 2010 10:17:11 AM EST
> To: "member-xmlsec@w3.org" <member-xmlsec@w3.org>, Juan Carlos
> Cruellas <cruellas@ac.upc.edu>
> Subject: Concerns on WD for signature properties
>
> Dear all,
>
> I guess that the first thing that I must do is to apologize for
> raising
> concerns on the Signature Properties draft at this point of time after
> these months when, due to private reasons I have been not active.
> Nevertheless, I feel that it would be worse not to raise them.
>
> I personally have strong problems for accepting the document as it is
> because it actually partly overlaps with XAdES specification, which
> has
> become an international standard fully supported by the European Union
> and has a wide acceptance outside Europe (Asia for instance).
>
> I remember that at the very beginning of this work the remark was
> raised
> that XAdES had already defined both: a set of signed and unsigned
> properties, and a way to incorporate them into XMLDSIG signatures. It
> was also claimed that in case that certain properties were identified
> that had already been specified within XAdES, it would be better to
> reference XAdES before introducing duplication and overlapping.
>
> Before going forward I copy below two links from where anyone
> interested
> may freely download XAdES spec and also an specification of a XML
> format
> for Signature Policy, which seems to me related to the Profile concept
> developed in the WD:
>
> XAdES:
> http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf
>
> Signature Policy report:
> http://www.etsi.org/deliver/etsi_tr/102000_102099/102038/01.01.01_60/tr_102038v010101p.pdf
>
>
> At this stage of the work I have identify clear overlap in the
> following
> property:
>
> 1. Created. This seems to indicate the claimed time of signing. First
> XAdES specifies xades:SigningTime for exactly the same purpose, except
> that in XAdES it is clear that it is only a claimed time by the
> signer,
> and the trust to be put on it depends on the trust put on the signer
> itself. Below follows the specification of this XAdES element:
>
> <xsd:element name="SigningTime" type="xsd:dateTime"/>
>
> I would suggest to drop this property from the document and make
> reference to XAdES.
>
> 2. Role. Well, here the overlap would depend on the situation....in
> XAdES there is a xades:SignerRole property defined. Its
> specification is
> restricted only to qualify the list of roles of the signer, as its
> name indicates, not the role of the signature (although this concept
> is
> not clearly specified in the document, and in fact the only examples
> given are roles of the signatory). In addition to that the
> specification
> goes beyond and distinguishes between claimed role and a certified
> role
> (through the inclusion of an attribute certificate). The claimed role
> may be of any type.
>
> <xsd:element name="SignerRole" type="SignerRoleType"/>
>
> <xsd:complexType name="SignerRoleType">
> <xsd:sequence>
> <xsd:element name="ClaimedRoles" type="ClaimedRolesListType"
> minOccurs="0"/>
> <xsd:element name="CertifiedRoles" type="CertifiedRolesListType"
> minOccurs="0"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexType name="ClaimedRolesListType">
> <xsd:sequence>
> <xsd:element name="ClaimedRole" type="AnyType"
> maxOccurs="unbounded"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexType name="CertifiedRolesListType">
> <xsd:sequence>
> <xsd:element name="CertifiedRole" type="EncapsulatedPKIDataType"
> maxOccurs="unbounded"/>
> </xsd:sequence>
> </xsd:complexType>
>
> Also, in this property two roles given as example (author or
> distributor
> signed) seem to me more aligned with the semantics of another XAdES
> property: xades:CommitmentTypeIndication, for which some standardized
> values are: Proof of origing, Proof of creation of the data object,
> proof of Receipt, proof of approval of the signed content). In XAdES
> the
> property is more complicated as it takes into account that an XMLSIG
> may
> actually sign more than one data object and it allows that each
> commitment is associated to one data object or to all of them.
> Following
> that issue, this is something that the property defined in the WD
> misses
> so it does not cover situations where there are more than one data
> object signed and the role or the commitment expressed by the
> signature
> is not the same for all of them.
>
> My suggestion is to first clarify whether we are talking of signer
> roles
> or commitments or what, second assert whether xades:SignerRole and
> xades:CommitmentTypeIndication cover all the semantics required and if
> not, then go for a property that covers the semantics not covered by
> these two; otherwise, if the semantics are covered by XAdES, drop the
> property and make references to XAdES.
>
> 3. Profile. XAdES uses the concept of Signature Policy as the set of
> rules that govern generation and verification of an electronic
> signature. XAdES specifies the property
> xades:SignaturePolicyIdentifier
> which, in its simpler form is an URI that identifies a signature
> policy
> and contains a digest of the electronic version of the document that
> specifies it; in its more complicated form it also contains pointers
> to
> places where recover the document etc. I see here partial overlaping
> with Profile property, although it seems to me not as formal as a
> signature policy. ETSI has also proposed XML formats for signature
> policies and in such structures things like the algorithms to be
> used in
> the signature, paths in the DIstinguished names of the certificates to
> support the signaure, the properties to be included in the signature,
> etc may be placed, the document put in some place and be referenced
> from
> any signature adhering to that signature policy. .... I would
> suggest to
> reasses the profile property, compare its semantics with the semantics
> of signature policy and then decide. In addition to all this, I think
> that the inclusion of the digest of the electronic document defining
> the
> signature policy is a good thing in terms of security.
>
> Generaly speaking I personaly think that it is not good for the
> comunity
> to have standards overlaping ...
>
> Again, I appologize for raising this so late but again, private and
> professional reasons have kept me away from being active during these
> months but yet feel the need to warn about these facts.
>
> Obviously, I may volunteer to help in any rearrangement that the group
> decides on the document.
>
>
> Regards
>
> Juan Carlos.
>
Proposal as in http://lists.w3.org/Archives/Public/public-xmlsec/2010Feb/0022.html

agreed
http://lists.w3.org/Archives/Public/public-xmlsec/2010Feb/0029.html

but with additional changes in wording approved at meeting:

"The XAdES specification defines signature property formats for advanced electronic signatures that remain valid over long periods, are compliant with the European Directive and incorporate additional useful information in common uses cases."

RESOLUTION: wording accepted

http://www.w3.org/2010/02/16-xmlsec-minutes.html#item04
yes

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:45:27 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org