RESCORLA, E., AND SCHIFFMAN, A. The Secure HyperText Transfer Protocol. RFC 2660, Network Working Group, 1999.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....it) Key Management In the current version of this report, the key management to obtain keys to protect the integrity of the fmicro DESC, coupong pair and the delivery are considered orthogonal to the technical problem described . This task is delegated, for example, to SSL [17] or SHTTP [18]. If a future iKP coupon based micro payment system experiences wide spread use, significant efficiency gains might be realizable if the pertinent key management is integrated into the protocols. 7 Conclusion This report has shown that iKP is well amenable to support micro payments with coupons ....

E. Rescorla and A. Schiffman. The Secure HyperText Transfer Protocol. Internet Draft, July 1995. version 1.1, Expires 1/96.

....data stream. It may not be desirable for the iNIC to implement IPsec due to privacy issues, however, since the data could be read by the iNIC, and therefore, potentially by the network administrators as well. In this case, the user could use some alternative encryption method such as secure HTTP [36] or PGP [43] so that the iNIC would not have the necessary encryption keys. By allowing the iNIC to perform IPsec, we can make it possible to distinguish between data which is private to individuals, and data which is private for a workgroup or an entire company. There are further bene ts from ....

E. Rescorla and A. Schiman. The Secure HyperText Transfer Protocol, RFC{2660, August 1999.

....(but does not require) that user agents display Warning headers[10] section 14.46) and requires that a user agent can be configured never to send Cookier headers[21] section 6. 1) The Secure HTTP specification requires browsers to provide a visual indication of the security of the transaction [29] (section 6.3.1) typically displayed as a lock icon. However, these constraints are phrased timidly, as if this were inappropriate for a protocol specification. As a result, we are again stuck in a situation where service designers are forced to rely on inferences about poorly specified ....

E. Rescorla and A. M. Schiffman. The Secure HyperText Transfer Protocol. RFC 2660, IETF, Aug. 1999.

....to represent content instead of the basic HTML. In the future, browsers are therefore expected to implement Signed XML [10] which speci es how XML documents should be digitally signed. Note that an alternative protocol to secure the communication on the WWW has been proposed in the past: S HTTP [26]. This protocol is situated at the application layer, and is speci cally intended for HTTP. It secures HTTP messages in a very similar way to the protocols for secure email, and provides non repudiation. SSL TLS has however become the de facto standard on the web, and S HTTP was not a success. ....

E. Rescorla and A. Schiman. The Secure HyperText Transfer Protocol. IETF Request for Comments, RFC 2660, August 1999.

....19 deployment issues, which are not addressed in other systems. In addition, Gemini nodes support dynamic content, which, to the best of our knowledge, is not supported in the other systems. There have been several efforts to bring increased security to the web. These include SSL [19] SHTTP [14, 16], and the Digital Signature Initiative (DSig) 5] All three of these protocols provide end toend security between the publisher and client, whereas the thrust of our work is in providing security even when a third party is generating content. Gemini can be viewed as a special type of active ....

E. Rescorla and A. Schiffman. The Secure HyperText Transfer Protocol. IETF RFC 2660, August 1999. Available at http://www.ietf.org/rfc/rfc2660.txt.

....seem possible, because account initiation is less a technical scaling problem than a social one. 3. 2 Authenticating the CA It is a telling and ominous fact that every electroniccommerce protocol specification explicitly disavows all responsibility for the validation of the Root CA s public key [14, 16, 22, 23]. Outside the scope of this document is a typical waiver. 14] Before using a public key certificate, a user must authenticate it by checking its certifying signature and the signature on each public key in its chain of certifying authorities. It s commonly forgotten that public key ....

E. Rescorla and A. Schiffman, "Secure Hypertext Transfer Protocol," Internet Draft RFC, May '95.

....deployment issues, which are not addressed in other systems. In addition, Gemini nodes support dynamic content, which, to the best of our knowledge, is not supported in these other systems. There have been several efforts to bring increased security to the web. These include SSL [10] S HTTP [17], 18] and the Digital Signature Initiative (DSig) 19] All three of these protocols provide end to end security between the publisher and client, whereas the thrust of our work is in providing security even when a third party is generating content. Gemini can be viewed as a special type of ....

E. Rescorla and A. Schiffman, "The Secure HyperText Transfer Protocol, " IETF RFC 2660, August 1999, Available at http://www.ietf.org/rfc/ rfc2660.txt.

....output. On error, the script returns an appropriate diagnostic. Executing scripts on a remote server poses several security problems concerning message security and authentication of users and applications. These security issues are addressed by several teams (see for instance [23] 1] 18] 19] [35] [36] and the solutions they propose should be integrated into Alliance. In order to cope with the specific constraints of the Internet, each instance of Alliance is now divided into two processes (see Fig. 9) All editing functions for which the user is expecting an immediate feedback, and ....

E. Rescorla and A. Schiffman, The secure Hypertext Transfer Protocol, Internet Draft, http://www.comerce.net/information/standards/drafts/shttp.txt, December 1994.

....only the server needs a public key certificate. This approach pre Affiliations: Independent Consultant, 1318 Comm. Ave #16 Allston, MA 02134; don mit.edu vents the Web server from detecting credit card fraud, which puts all credit card holders at risk. CommerceNet s proposed standard, S HTTP [10], provides for full mutual authentication, and supports several varieties of public key and private key cryptography. However, S HTTP cannot do anything to bring these several varieties into cooperative communion; it enables public key clients to shop at publickey authenticated Web pages, and ....

E. Rescorla and A. Schiffman, "Secure Hypertext Transfer Protocol," Internet Draft RFC (May '95).

....are available on many platforms and are interoperable. On the presentation layer (i.e. layer 6 of the ISO OSI reference model) high level protocols can be employed in order to tailor the security mechanisms to the respective needs and to realize end to end encryption. Secure HTTP (S HTTP, [21]) allows for different modes of protection depending on the kind of transported data. The Protocol Extension Protocol (PEP, 27] and the Security Extension Architecture (SEA, 26] of the World Wide Web Consortium offer mechanisms to communicate that transportation security and authentication ....

Rescorla, E.; Schiffman, A.: The Secure HyperText Transfer Protocol, Enterprise Integration Technologies, 1995. Available at http:// www.eit.com/ creations/ shttp / draft-ietf-wts-shttp-00.txt

....then, secure communication services should allow the tradeoff between the level and the cost of the guarantee to be explicitly managed. The value of customizing communication security in this way has been recognized in recent Internet security protocols such as IPSec [KA98] SSL [FKK96] S HTTP [RS98] and TLS [DA99] For example, IPSec, a set of protocols developed by the IETF to support secure packet exchange at the IP layer, provides two security options. The authentication header (AH) option does not encrypt the data contents of the packet, but provides optional authenticity, integrity, ....

....certificates to authenticate the server and potentially the client. A number of key exchange options are supported. Similar types of customization is provided in other Internet protocol proposals, including Privacy Enhanced Mail (PEM) Lin93] and the Secure HyperText Transfer Protocol (S HTTP) RS98] The Secure Electronic Marketplace for Europe (SEMPER) proposal provides optional non repudiation and anonymity for financial transactions in addition to privacy, authenticity, and integrity [Sem99] IPSec, TLS, and SecComm have a similar goal of customizable secure communication, but with ....

E. Rescorla and A. Schiffman. The secure hypertext transfer protocol. Internet-draft, Terisa Systems, Inc., Jun 1998.

....policies. However, DCE Web requires that both browsers and servers be DEC capable, i.e. capable of using a set of sophisticated distributed computing technologies, based on OSF DCE. Some security solutions provide user authentication and encryption but not group access control, e.g. Secure HTTP [8] and SSL [2] Others focus on group access control but lack encryption of communication, e.g. CERN httpd [5] a capability based authorization model by Kahan [3] No single approach provides adequate protection for group based collaborative information sharing. Although one could use a ....

E. Rescorla and A. Schiffman. The secure hypertext transfer protocol. Internet Draft, May 1996.

....and servers thus need to be adapted. Webseal s advantages include the possibility for a nely granulated access control system and the performance boost due to the use of symmetric key systems. Its main negative is the lack of non repudiation. The Secure HyperText Transfer Protocol (S HTTP) RS96] was an alternative proposal for securing the World Wide Web. In contrast to TLS, S HTTP is situated in the application layer, and therefore provides non repudiation. However, S HTTP does not provide authorization, the same as TLS. SSL became the de facto standard for securing the WWW, while ....

E. Rescorla and A. Schiman. The Secure Hypertext Transfer Protocol, May 1996. Internet Draft (expired).

....access control (RBAC) San98] has rapidly emerged in the 1990s as a promising technology for managing and enforcing security in large scale enterprise wide systems. The 1 For secure communications on the Web, we may consider using other existing technologies, such as, SHTTP (Secure HTTP [RS98, SR98] and SSL (Secure Socket Layer [WS96] However, these technologies cannot solve the stateless problem of HTTP. Furthermore, none of these can prevent end system threats to cookies. basic notion of RBAC is that permissions are associated with roles, and users are assigned to appropriate roles. ....

A. Schiffman and E. Rescorla. The Secure HyperText Transfer Protocol, June 1998. draft-ietf-wts-shttp-06.txt.

....Finally, we look at the performance of the system. 2 Protocols There are currently four proposals for providing security services to the WWW: Netscape s Secure Sockets Layer (SSL) 9] Microsoft s Private Communication Technology (PCT) 22] Secure HyperText Transfer Protocol (S HTTP) [20], from Enterprise Integration Technologies and Terisa Systems; Transport Layer Security (TLS) 7] an IETF working group. All four protocols provide entity authentication, data authentication and data confidentiality. In contrary to SSL and PCT, which are both situated in the transport layer, ....

E. Rescorla and A. Schiffman. The Secure Hypertext Transfer Protocol, May 1996. Internet Draft.

....communications platform 1 Introduction Secure telecommunications is a subject which has been addressed extensively in the past; the same is true for the secure World Wide Web. An overview of this topic may be found in the paper by P. Lipp and V. Hassler [10] Protocol realizations such as SHTTP [14] or SSLeay [13] an implementation of SSL [5] are examples of the prior art in this field. Yet even in 1996 B. Fernandez noted in [3] that these works concentrated primarily on low level security; these approaches do not address the multimedia or structural elements of the application documents. ....

E. Rescorla, A. Schiffman (1996) The Secure HyperText Transfer Protocol. IETF draft.

....Internet security protocols being designed by the IPSEC working group of the IETF (it replaces as a mandatory transform the one described in [10] For this purpose HMAC is described in the Internet Draft [9] and in an upcoming RFC. Other Internet protocols are adopting HMAC as well (e.g. s http [14], SSL [7] The rationale We now briefly explain some of the rationale used in [1] to justify the HMAC construction. As we indicated above, hash functions were not originally designed to be used for message authentication. In particular they are not keyed primitives, and it is not clear how best ....

E. Rescorla and A. Schiffman. The Secure HyperText Transfer Protocol. Internet draft draft-ietf-wts-shttp-01.txt, February 1996.

No context found.

RESCORLA, E., AND SCHIFFMAN, A. The Secure HyperText Transfer Protocol. RFC 2660, Network Working Group, 1999.

No context found.

E. Rescorla and A. Schiffman. The Secure HyperText Transfer Protocol. IETF Internet projects/s-http, July 1996.

No context found.

E. Rescorla and A. Schiffman. - The secure hypertext transfer protocol. - Internet Draft - May 1996

No context found.

Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.

No context found.

E. Rescorla, RTFM, Inc., A. Schimann, and Terisa Systems, Inc. The Secure HyperText Transfer Protocol, August 1999. Experimental RFC 2660.

No context found.

E. Rescorla and A. Schiffman, `The secure hypertext transfer protocol', Technical Report, Enterprise Integration Technologies, (June 1994). Available as <URL:http://www.commerce.net/information/standards/drafts/shttp.txt>.

No context found.

E. Rescorla, A. Schiffman, June 1998, The Secure HyperText Transfer Protocol, Internet Draft

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC