[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TRP comments by Shimanura-san that MAY apply to TP
> Someone please check to see if the appended set of TRP
> comments apply to
> the TP spec. Please indicate that you are looking into it
> and when you
> will provide an answer. If any changes are needed, it would
> be best if we
> put them in before submitting the spec for the next round of
> QR and Public
> Review.
>
> Comment to line 1735 of TRP spec is a possible problem for
> us regarding
> the ds: prefix and namespace definition. Should we delete the ds:
> prefix anywhere? everywhere? I believe that the comment
> applies only to
> the namespace definition since the TRP spec has the
> ds:prefix everywhere
> else.
I believe that the way this works is that when you
omit a specific namespace prefix, then that namespace
becomes the default namespace for as long as that default
remains in scope. Using an explicit prefix, such as "ds",
is still ok, therefore,
and reflects a different style (and maybe
a use case for which the default namespace needs to be
left unchanged...). I guess I don't see why it hurts
to use the explicit prefix here. Chris may have
a more definitive comment here, but that is my
current working understanding.
One thing does need a fix, namely that the correct URI
should be:
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
because the original URI has a typo in TRP examples. I
am not certain that we made that typo though. That causes
some DSIG APIs to complain, as is to be expected.
As far as the XML Signature _DTD_ not being followed, I think
DTDs may not work well with the namespace attributes such as
<sometag xmlns="URI"> or <sometag xmlns:ds="URI">
because the DTD may not specify these and there may be some
"technical" invalidity in using them. I am looking through
specs trying to find where this general question is
addressed definitively. Anyone know?
[omitted text]
Many of the other issues pertain to using
a more recent URI instead of an older one.
For those elements in the CPP and CPA that
mention namespaces-- under SimplePart within
the Packaging subtree and under a DocExchange
child concerning what namespaces are used,
I would think we would want to allow
participants to agree on what namespace
URIs are to be used.
As far as what we ourselves specify for
doing a CPP or CPA signature, I would
think we would use the most up-to-date
ones in our examples...but even here
these may eventually be superceded. So
this raises an issue of what, if anything,
needs to be said about this form of versioning by
the URIs used to identify various algorithms,
transforms, and schemas...
>
> Thank you for creating the issue list. However it lacks a issue about
> messageOrderSemantics I pointed out. And also I have obtained XML
> Signature related issues from security experts. Can I ask you to add
> attached comments to the list?
>
> ----------------------------------
> Comments on Message Service v0.98b
> ----------------------------------
> Minor Technical
> Line 549-551 says:
> If messageOrderSemantics is set to Guaranteed, the To Party MSH
> MAY correct invalid order of messages using the value of
> ~~~
> SequenceNumber in the conversation specified by the
> ConversationId.
> Comments:
> We decided that "When OnceAndOnlyOnce is specified and
> messageOrderSemantics is set to "Guaranteed",
> SequenceNumber MUST be
> present. In this case, receiving MSH MUST guarantee
> message order."
> The line 549-551 does not follow our decision.
> Suggestions:
> Change the word "MAY" in line 549 to "MUST".
> Reference:
> see discussion <
> http://lists.ebxml.org/archives/ebxml-transport/200103/msg00146.html>.
>
>
> Minor Technical
> Line 569-570 says:
> The SequenceNumber element MUST appear only when deliverySemantics
> is OnceAndOnlyOnce. ...
> Comments:
> This description is still not clear.
> Suggestions:
> Change the description into following to follow our
> decision exactly.
> When deliverySemantics is OnceAndOnlyOnce and
> messageOrderSemantics is Guarantee, the SequenceNumber element
> MUST appear. When deliverySemantics is OnceAndOnlyOnce and
> messageOrderSemantics is NotGuarantee, The SequenceNumber
> element MAY appear. In any other case, this element MUST NOT
> appear.
> Reference:
> see discussion <
> http://lists.ebxml.org/archives/ebxml-transport/200103/msg00104.html>.
>
>
> Minor Technical
> Line 1735 says:
> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmlds#">
> Comments:
> Use of prefix does not follow the W3C XML Signature's DTD.
> Suggestions:
> Remove the prefix "ds" in description on page 52-53, and define
> name space as following in line 1735:
> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
>
>
> Minor Technical
> Line 1692-1694 says:
> The ds:SignatureMethod element SHALL be present and SHALL have an
> Algorithm attribute. The RECOMMENDED value for the Algorithm
> attribute is:
> http://www.w3.org/2000/02/xmldsig#sha1
> Comments:
> The specified URI
<http://www.w3.org/2000/02/xmldsig#sha1> is older
algorithm. The W3C XML Signature spec uses following Algorithm:
<http://www.w3.org/2000/09/xmldsig#dsa-sha1>
<http://www.w3.org/2000/09/xmldsig#rsa-sha1>
(By the way, the sample on page 54 uses
<http://www.w3.org/2000/09/xmldsig#dsa-sha1>).
Suggestions:
Change <http://www.w3.org/2000/02/xmldsig#sha1> in line 1694 into
<http://www.w3.org/2000/09/xmldsig#dsa-sha1>.
Minor Technical
Line 1699-1701 says:
... The ds:Reference element for the ebXML Header document MAY
include a Type attribute that has a value
"http://www.w3.org/2000/02/xmldsig#Object" in accordance with
[XMLDSIG]. ...
Comments:
The specified URI <http://www.w3.org/2000/02/xmldsig#Object> is older
definition. Latest definition is:
<http://www.w3.org/2000/09/xmldsig#Object>
Suggestions:
Change <http://www.w3.org/2000/02/xmldsig#Object> in line 1701 into
<http://www.w3.org/2000/09/xmldsig#Object>.
Minor Technical
Line 1737 says:
<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/TR/2000/WD-xml-c14n-20001011"/>
Comments:
The specified URI is older algorithm. Latest algorithm is:
<http://www.w3.org/TR/2000/CR-xml-c14n-20001026>
Suggestions:
Change <http://www.w3.org/TR/2000/WD-xml-c14n-20001011> in line 1737
into <http://www.w3.org/TR/2000/CR-xml-c14n-20001026>.
----------------------------------
Regards,
--
SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
TEL:+81-45-476-4590(ext.7128-4241) FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC