OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] Comments by Konrad Lanz


Juan Carlos and all,

Regarding Konrad's first comment on on Canonicalization, I suggest that we
do not be over presecriptive.  Rather than mandating exclusive
canonicalization, I suggest that we make this a recommendation but allow a
conformant server to apply canonicalization as it sees fit.

If the transforms already being applied by the server already include any
necessary canonicalization it is only adding unnecessary overhead, which
could significantly impact on performance to apply an additional exclusive
canonicalization.  I do not see this in any way effecting interopability as
the verifier would apply the are identified in the signature.

Nick

> -----Original Message-----
> From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu]
> Sent: 04 April 2005 10:22
> To: DSS TC List
> Subject: [dss] Comments by Konrad Lanz
>
>
> Dear all,
>
> After looking at Konrad's comments
> It seems to me that he is right in his comments.
>
> The first comment deals with canonicalization management as
> it is expressed in the CD. As Konrad mentions, if the
> <XMLData> is  canonicalized using the regular Canonicalization
> algorithm, it will inherit namespaces defined in any of the ancestors
> including the namespace of the dss, bringing undesired ambiguities...
> I would say that his suggestion of going for exclusive canonicalization
> seems to be correct: in fact, this exclusive canonicalization has been
> defined for dealing with data that may be signed and in turn may be
> enveloped.
>
> Concerning the second comment, I have been looking the XML Schema
> specification
> and it also seems to me that he is correct. I guess that we blindly
> applied verification
> by tools that seem not to uncover this kind of mistakes, but the
> XML Schema
> spec seems to say that the presence of xs:any with process lax within a
> choice
> with other elements breaks this prinicple of uniqueness.
> I guess that we would correct this mistake if we substitute the
> elements <xs:any> by <dss:otherXX type="dss:AnyType">....because then
> there is no
> need to look into the attributes or the content of the element for
> identifying that
> it is the dss:otherXX element and not any of the others present in the
> choice.
>
> Any comment?
>
> Regards
>
> Juan Carlos.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
> TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]