-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 These two documents discuss a technique for two-way anonymous software to software communication by standard interface - SOAP. The first is a new transport binding for SOAP, the second is an adaptation for two-way anonymity.
Respond onlist or privately by post to alt.anonymous.messages ATTN: Sister Tornado. Best, S.T. USENET Transport Binding for SOAP 1.1 10 February 2002 Authors (alphabetically): Sister Tornado Copyright� 2002 Sister Tornado. Reproduce with credit at will. - ---------------------------------------------------------------------- - ---------- Abstract SOAP [1] is a lightweight protocol for exchange of information in a decentralized, distributed environment, using XML. This document details transporting SOAP messages over the USENET. [2] Status This is a draft. Table of Contents 1. Introduction 1.1 Notational Conventions 2. Use Of USENET Message body 2.1 Encoding 3. Identifying USENET transports in WSDL 4. Request / Response semantics 5. Examples 6. Security Considerations 7. References 1. Introduction By binding SOAP to USENET, we can take advantage of USENET's store and forward messaging to provide an asynchronous, broadcast, one way transport for SOAP. Two one way messages can be correlated to provide request / response semantics (this closely follows the SOAP model). This allows SOAP to be used in a number of scenarios where HTTP is not suitable (partially connected nodes, one way notifications etc.) The author wishes to acknowledge that the shameless cribbing of much of the text from "SMTP Transport Binding for SOAP 1.1 " [0]. 1.1 Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. 2. Use of USENET Standard 2.1 Use of USENET Message Headers The USENET Message standard requires the use of a Subject field. This field SHOULD be used to identify the service being called. For example: Subject: SoapRobot 2.2 Use of USENET Message body SOAP payloads in USENET MUST be packaged into the body of the USENET message. 2.3 Encoding A content transfer encoding of base64 is RECOMMENDED. A content transfer encoding of Quoted-Printable MAY be used if the SOAP payload meets the requirements of RFC-1036 [2]. 3. Identifying USENET transports in WSDL The URI http://schemas.xmlsoap.com/soap/usenet/ SHOULD be used to identify USENET transports compliant with this specification in the transport attribute of the soap:binding element of a WSDL [4] document (see section 3.3 of the WSDL spec.) The address of the SOAP service in the soap:address element of a WSDL document SHOULD be the name or handle of the intended recipient and a comma-delimitedlist of newsgroups where a request may be posted. For example: <soap:address location="[EMAIL PROTECTED],example.alt.soap.me ssages.fake"> 4. Request / Response semantics SOAP applications requiring request / response semantics will need to perform some sort of message correlation. This SHOULD be achieved via the standard Message-Id and Followup-To USENET headers [2]. The request will include a Message-Id header, and the associated response should include a Followup-To header that contains the Message-Id of the request, and a new Message-Id header. The responder SHOULD also reflect the incoming subject header into the response, prefixing it with "Re: ". 5. Example A request destined for [EMAIL PROTECTED] Path: [EMAIL PROTECTED]/relay.site.example/ site.example/injector.site.example%jsmith Message-ID: <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] Date: Mon, 11 February 2002 23:27:00 -0700 Subject: SoapRobot Newsgroups: example.alt.comp.rec.foo <?xml version=3D"1.0" encoding=3D"UTF-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle=3D"http://schemas.xmlsoap.org/soap/encoding/"; xmlns:SOAP-ENC=3D"http://schemas.xmlsoap.org/soap/encoding/"; xmlns:SOAP-ENV=3D"http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"; xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance";> <SOAP-ENV:Body> <m:echoString xmlns:m=3D"http://soapinterop.org/";> <inputString>A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. --Robert A. Heinlein</inputString> </m:echoString> </SOAP-ENV:Body> </SOAP-ENV:Envelope> The resulting response from SoapRobot Path: [EMAIL PROTECTED]/relay.site.example/ site.example/injector.site.example%jsmith Message-Id: <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] Date: Mon, 11 February 2002 23:51:00 -0700 Subject: Re: SoapRobot Newsgroups: example.alt.comp.rec.foo References: <[EMAIL PROTECTED]> <?xml version=3D"1.0" encoding=3D"UTF-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle=3D"http://schemas.xmlsoap.org/soap/encoding/"; xmlns:SOAP-ENC=3D"http://schemas.xmlsoap.org/soap/encoding/"; xmlns:SOAP-ENV=3D"http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"; xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance";> <SOAP-ENV:Body> <m:echoStringResponse xmlns:m=3D"http://soapinterop.org/";> <return>A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. --Robert A. Heinlein</return> </m:echoStringResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 6. Security Considerations Clients may wish to authenticate the sender's response in some API-specific way, as there is no direct connection between client and server and the server's response is trivially spoofed. 7. References [0] Cunnings R., Fell S., Kulchenko P., "SMTP Transport Binding for SOAP 1.1", 2001 [1] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", May 2000. [2] Horton M., Adams R., "Standard for Interchange of USENET Messages" RFC1036, December 1987 [3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [4] Christensen E., Curbera F., Meredith G., Weerawarana S. "Web Services Description Language (WSDL) 1.1", March 2001. - ---------------------------------------------------------------------- - --------------------------------------------------- BLACK USENET Transport Binding for SOAP 1.1 11 February 2002 Authors (alphabetically): Sister Tornado Copyright� 2002 Sister Tornado. Reproduce with credit at will. - ---------------------------------------------------------------------- - ---------- Abstract SOAP [1] is a lightweight protocol for exchange of information in a decentralized, distributed environment, using XML. This document details transporting SOAP messages over the USENET [2], as modified by the ideas and techniques of BlackNet [3]. Status This is a draft. Table of Contents 1. Introduction 1.1 Notational Conventions 2. Use Of USENET Message body 2.1 Encoding 3. Identifying USENET transports in WSDL 4. Request / Response semantics 5. Examples 6. Security Considerations 7. References 1. Introduction BlackNet provides a model for two-way anonymous communication over USENET. This document describes an adaptation of the technique for computer-to-computer communication. It is hoped that this technique will allow very high risk Web Services to operate with a reduced risk of exposure to coercive forces. Like the BlackNet model, this SOAP transport hides the identities of both client and server from each other, at the expense of latency. Clients and servers post anonymously to USENET through a chain of anonymous remailers. 1.1 Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. 2. Use of USENET Standard 2.1 Use of USENET Message Headers As USENET SOAP, except servers MAY decrypt every message in the newsgroups it monitors, ignoring Subject headers and Message-IDs. 2.2 Messages should always be ENCRYPTED to the recipient's public key. The server's key is published in WSDL, publicly or by arrangement. The client's key is published publicly or via API call. Encrypted messages should be ARMORED. 3. Identifying BLACK USENET transports in WSDL The URI http://schemas.xmlsoap.com/soap/usenet/black/ SHOULD be used to identify USENET transports compliant with this specification in the transport attribute of the soap:binding element of a WSDL [5] document (see section 3.3 of the WSDL spec.) The address of the SOAP service in the soap:address element of a WSDL document SHOULD be the name or handle of the intended recipient and a comma-delimitedlist of newsgroups where a request may be posted. For example: <soap:address location="[EMAIL PROTECTED],example.alt.soap.me ssages.fake"> 4. Request / Response semantics As in USENET SOAP, but Message-Id header and Subject correlations are not required. 5. Example. As in USENET SOAP transport. 6. Security Considerations It's not clear whether an automated service can reliably choose anonymous remailers in an intelligent and anonymous manner. Can an automated service survive an extended period of message passing in this manner and remain anonymous? How does this affect Traffic Analysis? 7. References [0] Tornado, S. "USENET Transport Binding for SOAP 1.1", February 2002 [1] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", May 2000. [2] Horton M., Adams R., "Standard for Interchange of USENET Messages" RFC1036, December 1987 [3] May T., "True Nyms and Crypto Anarchy", 2001 [4] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [5] Christensen E., Curbera F., Meredith G., Weerawarana S. "Web Services Description Language (WSDL) 1.1", March 2001. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> iQA/AwUBPGn1Cde1eESVabrmEQKXWgCgoDqHt5w23ZXhF4rd21S/pHMGv8UAnRzD cNPON5ns+VGDZJ0V9FXkuVj7 =ibLA -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> mQGiBDxp8fsRBAD9wby4eGP/JRka2YGpB/zyvE0fgrheJ1bThWR9jkNmKzXcDRpE 70Yufxh+hU8TBWnk0YKX/3zznzx2NJSee245MLc/8JShG4OhzAIk39y2kwjNYTiJ xDExaQMIFrTydkYSkgHPLqZCFlhJJlrudpxmK9tZnkloe2PT5ZariW3LCwCg/2Xq q9yUffpE8iEByrxp3WRPpbcEAPTZ3lcVIDqXAP0ZJBtAOLOVbBfTiNU9decuaR/8 anwLvvMm48fNk3akjWwsVIDqgS761PjFZ4meQHF0ajCUVRtn9pwsqbEII2F/ceSV cmPu6ox6K5Zcy92V+kMEPguuRlJF7vOL1oMHWcBZdNhrFrezaW43uKaK0RUWXB/x RvSvA/4uXxkZhG/LdJ4XOV7Pe5nHfs0Gi3D2+xnAnYaFW/DNDMKd9Go1aHq2OYNi XyEkCKWHDNsMhLS3/MmTSapEtBADoFxmcd0Cw2FIoaWliIDuy9xcW5RXkKzuuY+Z xcsF24G/oNgPXmIP81JRKdM4pNPzypo+4/bOaH6BkTzLC3BJX7QkU2lzdGVyIFRv cm5hZG8gPG5vd2hlcmVAZXhhbXBsZS5jb20+iQBOBBARAgAOBQI8afH7BAsDAgEC GQEACgkQ17V4RJVpuuYiYQCfZtRJEZQl9rcLWHAtBJg26+cGZ6kAoIKCFoeIBu/J uPiF6o5Cbsw4SXrDuQQNBDxp8fsQEAD5GKB+WgZhekOQldwFbIeG7GHszUUfDtjg o3nGydx6C6zkP+NGlLYwSlPXfAIWSIC1FeUpmamfB3TT/+OhxZYgTphluNgN7hBd q7YXHFHYUMoiV0MpvpXoVis4eFwL2/hMTdXjqkbM+84X6CqdFGHjhKlP0YOEqHm2 74+nQ0YIxswdd1ckOErixPDojhNnl06SE2H22+slDhf99pj3yHx5sHIdOHX79sFz xIMRJitDYMPj6NYK/aEoJguuqa6zZQ+iAFMBoHzWq6MSHvoPKs4fdIRPyvMX86RA 6dfSd7ZCLQI2wSbLaF6dfJgJCo1+Le3kXXn11JJPmxiO/CqnS3wy9kJXtwh/CBdy orrWqULzBej5UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9 ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7 /ZFexwGq01uejaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yI sxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAY EY18hKcKctaGxAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuqui XsNV6z3WFwACAhAAp7T/Hm8b5gbwrVe7eS5OW2rTt5zYwCiKVGNq8151Mlmzo5q3 N+sRAHrfyGTOkqpzkuoF4dmGDoF3xPM7g7lcchC8had/4LCdBHfEreVn2f5YRWV/ Fht9qHlMtTQRbeOvFpHIYvocr+uipi8VqROEX4l/xq8ULhpeT1T1FwlUcH+JsBBM BM9Ijaaw5Cg5tXWxCalnaZYofAQ+NkUfcrG7fsMBuckPtw46ZYlWtTvRP2NATamp 4g5n4GookwFOZyRXfy3XyNz7cDhkwo/jaVSJJWboNZWXPGxuDnIS2hjO0lWpZV6u GDfy9gWq+AwKLZxQzCngTNTYNWFD7mq/XVGQ1CXCqNKdzc/fjRsU21XPbcW3UwDl Z5EBSGbT36Nb+1rYPpmegPrHmN3LS7toNmH3ogXF0mzSnMQf9o5s4EBTxrvwmtS0 XxiGzfEaTjaMyxu5jFQLQRNbu2exumjU8E+/cZy4/QLSmmIoEq8GYVUcFwmw47DD zjn9Y0+V+S1VNAxqCSShDqzverERHTsJgv2fQSwx484PbfX0nDcx96HVoeh0Jd6j Rj6walR7gyVgpeQz35Hv+5g6iQ/t+wpXOOJCvJB+eH3KstUcCOisPc0ybDfNTIo+ omOIFOAnSEUkbpYRCJRfjkAYPpGSiEmCwYfmceH0VPutuOsEu8chat8eHiWJAEYE GBECAAYFAjxp8fsACgkQ17V4RJVpuuaw2QCg7ISCiLorP3YdAuzl5K51z9O1tmYA oJXCDkBZ+CrXlUxhuuiVXktbKb5l =X1Ml -----END PGP PUBLIC KEY BLOCK-----
