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