Re: [ebxmlms-develop] Digital signature interoperability

[Gait B. <gai...@ti...>]

Just checked REC-xml-c14n-20010315.
running the c14n transform will take care of attribute reordering, from the
spec:
(1.1)
The canonical form of an XML document is physical representation of the
document produced by the method described in this specification. The changes
are summarized in the following list:

  a.. The document is encoded in UTF-8
  b.. Line breaks normalized to #xA on input, before parsing
  c.. Attribute values are normalized, as if by a validating processor
  d.. Character and parsed entity references are replaced
  e.. CDATA sections are replaced with their character content
  f.. The XML declaration and document type declaration (DTD) are removed
  g.. Empty elements are converted to start-end tag pairs
  h.. Whitespace outside of the document element and within start and end
tags is normalized
  i.. All whitespace in character content is retained (excluding characters
removed during line feed normalization)
  j.. Attribute value delimiters are set to quotation marks (double quotes)
  k.. Special characters in attribute values and character content are
replaced by character references
  l.. Superfluous namespace declarations are removed from each element
  m.. Default attributes are added to each element
  n.. Lexicographic order is imposed on the namespace declarations and
attributes of each element
....
2.2 Document Order
Although an XPath node-set is defined to be unordered, the XPath 1.0
Recommendation [XPath] defines the term document order to be the order in
which the first character of the XML representation of each node occurs in
the XML representation of the document after expansion of general entities,
except for namespace and attribute nodes whose document order is
application-dependent.

The XML canonicalization method processes a node-set by imposing the
following additional document order rules on the namespace and attribute
nodes of each element:

  a.. An element's namespace and attribute nodes have a document order
position greater than the element but less than any child node of the
element.
  b.. Namespace nodes have a lesser document order position than attribute
nodes.
  c.. An element's namespace nodes are sorted lexicographically by local
name (the default namespace node, if one exists, has no local name and is
therefore lexicographically least).
  d.. An element's attribute nodes are sorted lexicographically with
namespace URI as the primary key and local name as the secondary key (an
empty namespace URI is lexicographically least).
Lexicographic comparison, which orders strings from least to greatest
alphabetically, is based on the UCS codepoint values, which is equivalent to
lexicographic ordering based on UTF-8.

c14n-20010315 will reorder the attributes and NS declarations to lex. order
prior to digest generation. This rules out order problems...

----- Original Message ----- 
From: "Ng Chi Yuen" <cy...@cs...>
To: <ebx...@li...>
Sent: Tuesday, July 15, 2003 8:33 AM
Subject: Re: [ebxmlms-develop] Digital signature interoperability


> Hi,
>
> > I wrote a small standalone Java utility that does signature verification
> > just like Hermes (with the Apache xmlsec classes), and it predicatably
> > verifies Hermes messages but not Tibco messages.
>
>          Digital signature has been a problem for a very long time since
> Hermes was developed. Some observations had also been discussed in this
list
> before. We, including Gait Boxman, have been working on this problem again
> and tracing the xmlsec source codes recently.
>
>          Up to now, what I can say is that Hermes should have already
> followed the signing and verification mechanism as bundled in the xmlsec
> examples. For signing, *given* xmlsec is correct, Hermes should produce a
> correct and predictable message since an EbxmlMessage is just serialized
to
> obtain the bytes and fed into xmlsec for signing.
>
>          For verification, the situation may be more complicated. The key
> point of my finding is: when a message byte stream is received, it is
parsed
> to become EbxmlMessage object. However, in this process, JAXM re-orders
the
> namespace declaration! That is to say, EbxmlMessage.writeTo() would give
you
> a message different from that of the received bytes. There is uncertainty
if
> such re-ordering breaks the signature. We may have to feed the original
> bytes into xmlsec. Given xmlsec handles correctly the namespaces (no
matter
> for what SOAP prefix), it should finally validate the message.
>
> > How has Hermes performed in interoperability tests when it comes to
> > digital signatures? What can we do to assist Tibco in sorting this out?
>
>          Digital signature has not yet undergone interoperability test in
> ebXML Asia. In order to figure out the problem, is possible for Tibco to
do
> the signature step-by-step such that the intermediate signing output can
be
> recorded? We are facing the problem which DS implementation can be
"trusted"
> in the sense that it is proved to be correct. You may now have to trace,
say
> the transformed output and then the canonicalized output manually, in
order
> to figure the problem.
>
> Regards,
> CY
>
> --------------------------------------------------------------------------
--
> Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
> Technology Officer,
> Centre for E-Commerce Infrastructure Development,
> The University of Hong Kong
> --------------------------------------------------------------------------
--
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop