rlyders wrote:
Once the element has been encrypted and signed, the result is shown below.
The web service that we are integrating with is not a full fledged SOAP WSDL
web service, but rather it simply uses HTTPS and XML. Our existing XML
document format where the XML Signature is enclosed by the EncryptedData
element seems to work well with the with the web service we are integrating
to.
Well, it may "work", but it's completely violating the data model put
forth by the XML Encryption spec. So you/they definitely can't expect
it to interop with clients or other libraries that respect that
specification.
It is only in my local Java unit tests on my development computer that I
am seeing these problems with the Signature's KeyInfo element getting in the
way of decryption. The web service is written in .Net while my stuff is in
Java, so they must be doing something on their side in .Net to allow for a
Signature element enclosed in the EncryptedData element.
I don't know much about .Net libraries for doing XML Signature and XML
Encryption - or perhaps the web service side has rolled its own impl of
those things - but it's definitely taking creative liberties as far as
those specs go, if it's allowing the Signature child of the
EncryptedData element.
I will check with the developer of the web service to see if we can slightly
adjust the encryption method so that the EncryptedData and Signature
elements are siblings contained within the <Orders> element.
That's one option I suppose. It would seem more natural and simpler to
me, however, that you might want to sign the Orders element with an
enveloped Signature, and then encrypt the whole thing. Then on the
receiver reverse the order: decrypt and then verify the signature.
You might also try persuading them to look at the WS-Security
specification, a large part of which is specifically about doing XML
Signature and XML Encryption in conjunction with SOAP web services
messaging. That makes heavy use of SOAP headers, though, which usually
implies some kind of more formal SOAP processing engine.
It would be a great help if you had a URI that I can reference to base a
change request on that mentions our illegal format having the enveloped
Signature as a child element of the EncryptedData element? I haven't been
able to find any information yet that specifically states that it is illegal
to place the Signature inside the EncryptedData element. It would be nice to
have it documented if possible.
Oh, absolutely, that's easy. The XML Encryption data model is defined
by W3C Schema, and it's very clear about what the xenc:EncryptedData
element looks like. The full spec is here:
http://www.w3.org/TR/xmlenc-core/
In particular the schema xsd is here:
http://www.w3.org/TR/xmlenc-core/xenc-schema.xsd
And within that schema, the EncryptedData is defined so:
<element name='EncryptedData' type='xenc:EncryptedDataType'/>
<complexType name='EncryptedDataType'>
<complexContent>
<extension base='xenc:EncryptedType'>
</extension>
</complexContent>
</complexType>
<complexType name='EncryptedType' abstract='true'>
<sequence>
<element name='EncryptionMethod' type='xenc:EncryptionMethodType'
minOccurs='0'/>
<element ref='ds:KeyInfo' minOccurs='0'/>
<element ref='xenc:CipherData'/>
<element ref='xenc:EncryptionProperties' minOccurs='0'/>
</sequence>
<attribute name='Id' type='ID' use='optional'/>
<attribute name='Type' type='anyURI' use='optional'/>
<attribute name='MimeType' type='string' use='optional'/>
<attribute name='Encoding' type='anyURI' use='optional'/>
</complexType>
Thanks for all your help and time.
No problem.
--Brent
