santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Putman <putm...@georgetown.edu>
Subject Re: Still stuck with problem. Re: Problem decrypting elements
Date Mon, 03 Dec 2007 20:10:30 GMT


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

Mime
View raw message