W3 Consortium                                                Rohit Khare
WORKING DRAFT                                               khare@w3.org
<WD-http-sea-960108.html>                            W3 Consortium / MIT
Expires: June 8, 1996                                    January 8, 1996

SEA: A Security Extension Architecture for HTTP/1.x

Status of This Document

This draft is for the Fifth W3C Security WG Meeting on January 22, 1996. Future revisions will be made available as public W3C Working Drafts. Distribution of this draft is restricted to attendees and W3C Member organizations ONLY at this time.

Table of Contents

1. Abstract

This document sketches an architecture for securing HTTP/1.x messages using protocol extensions. We propose three classes of extensions, Signature, Encryption, and Key-Exchange, as well as requirements for their secure combination.

2. Introduction

W3C is interested in developing flexible, evolvable security for the World Wide Web infrastructure. In particular, solutions should incorporate:

Our proposal for a Security Extension Architecture (SEA) identifies just three classes of cryptographic processes, and we show how those can be combined, safely and securely, to meet common requirements.

2.1 Other Web Security Approaches

The first generation of Web security solutions have approached the problem at different layers:

Secure Sockets Layer provides channel security underneath applications, such as FTP, HTTP, etc. Other facilities achieve the same ends: IPsec and GSSAPI preambles to HTTP. Since they are link-level approaches, they are hard-pressed to provide solutions for message security, i.e. the ability to extract messages from the stream as complete, secured documents.

Secured Content is the approach of transporting externally-secured data over oblivious applications, such as PGP encrypted documents over HTTP. This technology is usually implemented with MIME `viewers', which can be deployed successfully [NCSA]. Obscuring the ultimate contents from the application layer prevents seamless integration of security and secure markup and UI within the agent.

Secure HTTP is a parallel mechanism to HTTP. It adds hardwired security features to HTTP and HTML to create an outer, enveloping layer for `regular' HTTP/1.x messages. There are no measures for backward compatibility, since S-HTTP is essentially a new application. Also, there are several proposed extensions to HTTP that cannot be represented `within' another protocol, such as chunked-transfer-encoding and multiplexing. SEA attempts to bring S-HTTP's logical security model into HTTP/1.x development.

In addition, there have been proposals to add secure facilities for state management and authentication. SEA does not address these concerns (except insofar as signed HTTP requests are a strong form of authentication).

3. SEA Elements

We began by adopting the model behind S-HTTP and attempt to render its facilities into a modular architecture atop PEP, W3C's extension proposal for HTTP. During the debate last October at the Fourth W3C Security WG Meeting, participants identified two extension architectures.

One was a W3C strawman to promote each algorithm and feature into a protocol extension, yielding fine-grained negotiation and combination (e.g. separating signature functions from hash functions). This was rejected because of its complexity and vulnerability to interaction effects and negotiation attacks. At the other end was the semi-monolithic approach of describing `S-HTTP' as a single extension with many parameters. This approach recapitulated a layer of S-HTTP-specific negotiation within PEP neogotiation. SEA is a compromise proposal that identifies three extension classes:

Note that the semantics of these operations are underspecified. There is no assumption of `what assertion' is being signed; of `what security policy' a document is being encrypted under; or `which certificate infrastructure' is used to identify principals.

What is specified, though, is that these three modules can only be used in the exact order specified. Encryption and Key-Exchange may only be used once per message. Encryption writes its key material out to two headers, Session-Key: and Session-Key-Clear:. Key-Exchange reads this material and protects the key for the intended recipient alone. This kind of commonsense simplification was identified as a `recipe' by attendees at the Fourth W3C Security WG Meeting. In combination, we believe SEA is a reasonable security solution.

3.1 Signature

Signature generally is used to denote nonrepudiable claims of authorship or assent. Other kinds of assertions are often bound into the text, as in "I the undersigned believe that...". Thus, we believe for Web-related purposes, we need only use the weakest abstraction of signature: an operation on the entire body of an HTTP message, not involving any assertions bound into the signature or the signing certificate. This reduces signature to an algorithmic transformation, of which several are in common use today: RSA-MD5, DSS-SHA, etc.

Each of these techniques is a protocol extension which can be applied to a message. This maps neatly onto an implementation and negotiation model for PEP modules. In addition, compared with S-HTTP or MOSS signatures:

Backward Compatibility Servers can emit `pre-signed' documents that incompatible clients can continue to display. The message body remains clear, unenveloped, so old clients continue to work, paranoid proxies can still scan message contents.

Unmodified Body The HTTP message body can be compared directly against disk, since there is no intervening encapsulation or canonicalization. This also means that it can sign any data, not just HTML.

Minimal Footprint The actual signature data is in HTTP headers, so clients can simply key off of their presence. No multipart or ASN.1 parser is called for; the signature can be attached by CGI programs and verified by simple client hooks. With these claims in mind, we can sketch the extension specifications for the Signature 'class' and the RSA-MD5 instance:

Protocol: http://w3.org/SEA/Signature

Protocol: http://w3.org/SEA/Signature/RSA-MD5

In the same manner, one can specify Signature modules for a few other well-known approaches, such as DSS-SHA. In each case, proper attention should be paid to existing standards in the arena for encoding values and algorithms, such as the PKCS-1 packings and PEM/MOSS names.

It is only appropriate to sign cleartext [Anderson], but multiple parties may sign a document using different techniques, so the recipe allows for multiple application of Signature-class extensions.

3.2 Encryption

Encryption is a process that protects the entity-body, and places the a complete copy of the key in "Session-Key:" and optionally a partial copy in "Session-Key-Clear:". A message cannot be encrypted twice, practically because of the header collisions), and cryptographically because of the weaknesses of reencryption. This is an abstraction that provides the necessary decoupling between this phase and the next, Key-Exchange.

The general approach of putting all keying material, in any appropriate packing, in one header and optionally divulging additional amounts in a parallel header, seems reasonable. This mechanism does not allow for key-escrow, though; additional LEAF-style fields (Clipper's Law Enforcement Access Field) can be generated by Encryption and Key-Exchange modules, though.

The initial set of reasonable encryption algorithm can be taken from S-HTTP's selection. The inclusion of additional ciphers, such as IDEA, should be carefully weighed before being placed in the "/SEA/" namespace, but can still be readily deployed for experimental purposes.

Protocol: http://w3.org/SEA/Encryption

Protocol: http://w3.org/SEA/Encryption/DES

Triple-DES, for example, could be added as an option to the DES protocol, or by proposing a separate Triple-DES extension. The encoding of other bulk ciphers will be fairly similar. Nevertheless, this kind of exercise is vulnerable to the `sole-instance bug' of designing around what we know rather than what might also solve the problem. We posit, though, that even more exotic ciphers, e.g. with key-vectors &c, will still follow the form of a single chunk of keying material that can be partially exposed. Now, there may be cryptographic risks particular to various ciphers, such as their vulnerability to known, structured plaintext (as is common with HTTP) that constitute challenges to extensibility, but that is solved by the naming authority and recipe.

There is an implicit statement in all Encryption extensions that it is incorrect to use Encryption without a succeeding Key-Exchange phase.

3.3 Key-Exchange

Key-Exchange is the trickiest protocol of the three, since it covers both the cryptographic algorithms for doing so and the cryptographic policy for identifying keys and using them appropriately.

In general K-E protocol extensions replace the "Session-Key" with some protected material — either the "name" of the key (for secret-key systems), the session key under some public-key cryptosystem, or the data for a Diffie-Hellman style exchange. Note that an implementation model might in practice join particular Encryption and Key-Exchange extensions into a single piece of code, e.g. a single-step DES-based secret key system.

Protocol: http://w3.org/SEA/Key-Exchange

Protocol: http://w3.org/SEA/Key-Exchange/Outband

Protocol: http://w3.org/SEA/Key-Exchange/RSA

The implementation model is that these Key-Exchange processes are reversible; that a corresponding extension on the opposite end can regenerate the Session-Key: header, which, in turn, is all that the corresponding Encryption process needs.

3.4 Certification

While the balance of SEA is moot on this point, there is a need to specify a certificate chain within a secure HTTP message. A possible hook to do so, separately from the cryptographic processing, is to define a suite of certification protocols that define the contents of associated headers. For example, both PGP signed-keys and X509 certificates are appropriate name-PK bindings. How/Whether an agent chooses to trust such assertions, and exchange such knowledge is beyond the scope of an SEA spec.

Protocol: http://w3.org/SEA/Certificate

Protocol: http://w3.org/SEA/Certificate/X509

4. Examples

With SEA, we can address many common security requirements: we can sign documents, sign and encrypt, or encrypt for integrity alone. SEA also supports a measure of backward compatibility and implementation flexibility.

In these examples, user U running client C accesses Candidate A's server S. On S, A has prepared some documents about Candidate B's sworn statements.

4.1 Requesting a Signed Document

U asks S for a signed platform statement from A. 

C->S:	GET /Platform.html HTTP/1.1
	Accept-Protocol: {http://w3.org/SEA/Signature {str req}}
S->C:	200 OK
	Protocol: {http://w3.org/SEA/Signature/RSA-MD5 
			{params {pk Base64(A's PK)} {name "A@S"}} 
			{headers Signature-37}}
	Signature-37: Base64(the signature of the reply, PKCS-1 packed)
	...

In this exchange, U assumes C implements all the known Signature algorithms, so instead of sending a few specific preferences, U requests the generic "Signature" and hopes S replies with a specific algorithm C knows. If not, U can always try again with more detailed instructions. Note that the response contains unmodified text/html, and no Content-Encoding: information, since the signature is implicitly checked only after all the unwrapping and decoding.

The same mechanism could be used by U to sign the user's requests for information, by wrapping a GET message. Suppose U wanted to access A's records of U's campaign contributions, and U wanted to ensure the response was encrypted to U's taste: 

C->S:	WRAPPED * HTTP/1.1
	Protocol: {http://w3.org/SEA/Signature/RSA-MD5 
			{params {pk Base64(U's PK)} {name "U@C"}} 
			{headers Signature-54}}
	Signature-54: Base64(the signature of the request, PKCS-1 packed)
	Content-Type: message/http
	
	GET /Contributions/U HTTP/1.1
	Accept-Protocol: {http://w3.org/SEA/Signature/RSA-MD5 {str req}}
	Accept-Protocol: {http://w3.org/SEA/Encryption/DES {str req} 
				{params {keylen [40-56]}}}
	Accept-Protocol: {http://w3.org/SEA/Key-Exchange/Outband {str req}
				{params {keyname "TopSecret" "DonationKey"}}}

4.2 Encrypted Conversation

[The following design discussion is meant to provoke thinking about what kind of key-management controls need to be accommodated in the initial releases of SEA.]

Suppose instead that we have the "typical" encrypted-channel scenario: U has no well-known public key, and wishes to browse a secure site Y. One solution is an initial round-trip where Y sends its certificate and key; then U can then choose a session key and encrypt for Y its chosen keypair. This is akin to the `Assign-Key' functionality of S-HTTP. Typically, though, a server may wish to assign a session-key to a client, not the other way around. SEA has no exact analogue for this role-reversal, though one could be created.

In summary, SEA works unmodified if the client has a keypair, whether certified or not. If a client wishes only to use a session key, there is no direct facility to name that session key and reuse it. A solution may be to, within the separate Encryption extensions, define some names like "LastKey", or add a new attribute, keyname, to the generation and use of keys. The latter would be: 

C->Y:	GET / HTTP/1.1
Y->C:	200 OK
	Accept-Protocol: {http://w3.org/SEA/Key-Exchange/RSA 
				{params {pk Base64(Y's PK)} {name "Y's PK"}}}
C->Y:	WRAPPED * HTTP/1.1
	Protocol: {http://w3.org/SEA/Encryption/DES {str req}
			{params {IV Base64(iv)} {keylen 56} {pad n} {mode cfb}
				{keyname "C's New Key"}}}
	Protocol: {http://w3.org/SEA/Key-Exchange/RSA {str req} 
			{params {pad n}} {headers DEK-Info-15}}
	DEK-Info-15: Base64(C's New Key encrypted by Y's PK)
	Content-Type: text/html
	Content-Encoding: rsa, des
	
E	GET /SensitiveData HTTP/1.1

Notes: The line marked `E' in the margin is encrypted. C can elide Y's PK in the RSA protocol line. The keyname attribute has been added to DES; presumably, a response from Y to C could use that keyname in an outband key-exchange.

This hypothetical exchange highlights an additional difference from S-HTTP's Assign-Key design: in SEA, only keys used to encrypt can be named. There is no syntax for referring to keys not used in the present message and not already known to both sides. The /Certificate/ facilities only allow advertising of public-keys (although it also possible to envision `Assign-Key' as a type of Key-Name certificate only valid within encrypted messages).

4.3 Detailed Negotiation

While SEA is designed so that many agents can compactly state they have or offer one of the three core SEA protocols, there are many scenarios where agents will have to perform detailed negotiations because one end supports only a subset.

Consider an export-only client F. Rather than stating "Accept-Protocol: {.../Encryption}", F would state specifically "Accept-Protocol: {.../DES {params {keylen 40}}}, {.../RC4 {params {keylen [40-48]}}}" or state just one and mark it "{str req}".

There is a separate, as yet unsolved, syntactic question about client G, which supports precisely two of the three most popular signature protocols: there is no PEP syntax to say G supports X and Y, and that the server is required to respond using one of X or Y. The only reliable solution is for G to try both separately, or choose from the list the server chooses to advertise.

5. SEA Features in HTML

At the October meeting and in several ERB discussions, W3C was asked to investigate proposals for security markup in HTML. In S-HTTP, for example, the CRYPTOPTS facility allows authors to label links with a fixed set of security features to be expected when dereferencing a link. Using a proposed HTML facility for labeling resources, we demonstrate how SEA attributes might be encoded in a similar manner.

5.1 Motivation

The logic behind security markup for hypertext is as follows:

  1. A source document should be able to include assertions about a target resource
  2. Assertions can be limited to the set of link types {REL, REV, etc...} and HTTP entity headers {Content-Type, Content-Length, Content-MD5, etc...}
  3. Security properties of a resource can be expressed using PEP/SEA

This would imply that the PEP headers, of the entity or of the transmission, would suffice, if embeddable in HTML. The first question, then, is `Which kind of PEP header? Offers (Accept-Protocol:) or particular instances (Protocol:)?'.

The scenario: Candidate A has a statement on her server attacking an authentic statement of B's. Her staff wants to prepare a page citing the exact passage of B so that user U knows what to expect (say an MD5, a length, and a signature).

Note that A wants to make a binding statements: `U must ask for signatures and they must match what A believes'; if U chooses to disregard A (by not asking B for signed copies, for example), it contradicts A's beliefs, but it is not a protocol violation.

This sets the scene for the following discussion: A can choose to copy B's signature in her document (Protocol:) or direct U to request its own signed copy from B.

5.2 RESOURCE Tag

The Resource tag is a mechanism separate from the <INSERT> proposal. Essentially, wherever you use a link (HREF, SRC, ACTION), you can use a pointer to a "resource description" in the same file (usually stored in the HEAD, where old browsers won't display it). Within the Resource, an author can use the META tag to indicate headers present when accessing the resource, or use predefined shortcuts for many entity headers. 

	<A HREF="http://B.org/B-doc">CandidateA believes B-doc may change</A>
	...
	<RESOURCE="http://B.org/B-doc" Content-MD5="hex(MD5)">
		<META NAME="Protocol" VALUE="{.../RSA-MD5 {params {name "B's PK"} 
					{pk Base64(B's PK)}} {headers Signature-9}">
		<META NAME="Signature-9" VALUE="Base64(B's sig of B-doc)">
	</RESOURCE>

The syntax above shows A copying over headers she got when she accessed B-doc. Alternatively, she could specify headers she used to access B-doc: 

	<A HREF="http://B.org/B-doc"> A says, `make B sign his promises' </A>
	...
	<RESOURCE="http://B.org/B-doc" Content-MD5="hex(MD5)">
		<META NAME="Protocol-Offer" VALUE="{.../Signature {str req}}">
	</RESOURCE>

Since RESOURCE can be used to annotate any link, it can be use to solve several problems:

  1. It can be used to prevent a FORM from being posted as cleartext
  2. It can be used to prevent an initial round-trip to a secure server to acquire public keys, negotiable set, etc.
  3. It can be used to make assertions about any protocol extension at any resource

This mechanism is not a solution for all secure markup problems, though. For example, a facility to selectively encrypt only certain fields of a form can only be provided by developing a new ENCTYPE, a multipart to replace text/x-www-form-url-encoded. A new multipart could selectively apply SEA extensions to each part, achieving the desired effect.

Another kind of "secure markup" request is to sign or encrypt HTML documents, etc, in advance. It is worth noting that instead of storing such data within opaque PKCS-7 envelopes, PEP/SEA messages can be stored whole, as message/http; the data remains intact, while a few headers can be precomputed (Signature, Encryption — only Key-Exchange has to be done for each connection).

6. PEP/SEA Security Considerations

SEA provides implementors a lot of rope — it is possible to combine modules in unsafe and insecure order. In practice, there are several additional considerations for building secure solutions with SEA. Recipes are a technique for restricting the order in which extensions are applied. Implementation considerations address some PEP-related vulnerabilities of special note. Finally, as SEA evolves, there is the potential for cryptographic vulnerability among combinations as well.

6.1 Recipes

Apparently first named by Mark Manasse and Martin Abadi at last October's meetings, recipes codify intuition about restricting the eligible order or application for certain extensions. For example, all safe SEA combinations match the following type-expression:

(.../SEA/Signature)* , [.../SEA/Encryption , .../SEA/Key-Exchange]

Note that Certificates are not allowed in the Encoding, so they are only processed at the end, in unspecified order. Note that Encryption and Key-Exchange are optional, but must be used together.

For a particular Content-Encoding: line, verification must follow the "Conforms To:" declarations of each protocol specification. Note that the W3C and the W3C Security ERB, in this example, control the http://w3.org/SEA/ name space and all conformance assertions.

Recipes provide concrete guidance on acceptable combinations, but need not be implemented directly in agents. Instead, agents may choose their own heuristics, or only accept more restricted patterns. The value of a recipe is that it makes explicit the deisgner's intentions about which combinations are expected to be safe. The recipe above, for example, dictates what is and is not safe to install within the "/SEA/" namespace.

6.2 Implementation Considerations

It is particularly worth noting that the information passed between SEA modules is sensitive information. The information being signed must be tamper-proof, and the channel passing the Session-Key: must be private. This means that some platforms will have to pay special attention to the security of available IPC idioms. It may be appropriate to implement some or all of these SEA protocols within a single program, reducing the possibility of compromise.

Implementations will have to go beyond PEP compliance to verify recipes and provide a user-interface channel for reporting security status. Implementations will also have to be careful about the trust categories of various extensions; after a message has been decrypted, it is likely inappropriate to invoke the MailACopyToEve extension.

PEP also exposes clients to negotiation attacks, where two parties are convinced by a man-in-the-middle to use weaker security than desired. In practical fact, this sort of attack can be forestalled by:

  1. Signing requests and responses.
  2. Indicating security capabilities in some other, trusted medium (PEP-HTML on CD-ROM, separate port numbers).
  3. Servers being careful to never vend documents with weaker-than-appropriate security.

6.3 Cryptographic Considerations

It is possible that certain cryptosystems may interact poorly with certain applications, especially one in such broad use as the Web. Particular SEA extensions will likely have to be accompanied by usage restrictions. Some ciphers may be inappropriate for structured, highly regular plaintext like HTTP messages. Some may be inappropriate for sequential (predicted-plaintext) messages, like counters and status messages.

All of this means that naming authorities must exercise care in adding methods to the SEA repertoire. One must consider not only interactions between the cryptosystem and Web applications, but also with existing SEA facilities.

7. Development Path

The SEA proposal is the culmination of several months'SEA: A Security Extension Architecture for HTTP/1.x effort at the W3C into designing an extensible security architecture. Member organizations will have to come forward to help define and realize these ideas now. We believe this is a reasonable path to Web security at the application layer, and want to take the Consortium further along this path. Please direct comments and questions to Rohit Khare, khare@w3.org.

8. References

[Abadi+]
M. Abadi and R. Needham. "Prudent Engineering Practice for Cryptographics Protocols." Digital Systems Research Center: Report 125, Digital, June 1994.

[Anderson]
R. Anderson and R. Needham. "Robustness principles for public key protocols." ftp://ftp.cl.cam.ac.uk/users/rja14/robustness.ps.Z [in proceedings of Crypto '95], Cambridge University Computer Laboratory, 1995.

[PEP]
R. Khare. "PEP: An Extension Mechanism for HTTP" W3C Working Draft , W3 Consortium, November 1995 (Work In Progress).

[MOSS]
S. Crocker, N. Freed, J. Galvin & S. Murphy "MIME Object Security Services." RFC 1848, October 1995.

[NCSA]
J. D. Weeks, A. Cain, & B. Sanderson. "CCI-Based Web Security: A Design Using PGP" In proceedings of the Fourth International World Wide Web Conference , NCSA, December 1995 (Work In Progress).

[S-HTTP]
E. Rescorla, and A. Schiffman, "The Secure Hypertext Transfer Protocol", Internet Draft, July 1995 (Work in Progress).

Appendix A: Comparison to S-HTTP

A checklist of several notable S-HTTP facilites and similar SEA accomodations, if any:

  1. Encapsulation Formats 
       Several cryptographic message format standards may be incorporated
   into S-HTTP clients and servers, particularly, but in principle not
   limited to, PKCS-7 and PEM.
    SEA does not envision directly including these encapsulations. For example, a DES encryption could use a PKCS-7 envelope format, but would likely be treated as a sequence of bytes with an indicated pad length (rather than as ASN.1). PGP used to be another encapsulation format in earlier drafts; SEA may support it, or more likely a PGP protocol extension will be developed separately.

  2. Secret Key Systems 
       S-HTTP does not require client-side public key certificates (or pub-
   lic keys), supporting symmetric session key operation modes.
    SEA supports this in the same way as S-HTTP: a bulk cipher with outband key exchange

  3. HTML Security Markup 
       Clients may be "primed" to initiate a secure transaction
   (typically using information supplied in an HTML anchor); this may be
   used to support encryption of fill-out forms, for example.
    The RESOURCE tag for PEP/SEA headers is a credible solution.

  4. Negotiating Keys 
       Option negotiation is used to allow clients and
   servers to agree on transaction modes (should the request be signed?
   encrypted?  both? what about the reply?); cryptographic algorithms
   (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and cer-
   tificate selection (please sign with your "Mastercard certificate").
    Modes and algorithms: SEA relies on PEP semantics for requesting and offering extensions. Certificate selection: SEA as proposed above has no mechanism for this. It could be incorporated into particular Signature extensions as a negotiable parameter (which key? which name?). Note that S-HTTP defines a key to be a certificate, while SEA takes MOSS's looser stance that a 'key' is merely a key-name pair.

  5. "3-Axis" model 
       Message protection may be provided on three orthogonal axes: signa-
   ture, authentication, and encryption. Any message may be signed,
   authenticated, encrypted, or any combination of these (including no
   protection).
    SEA attempts to mirror this structure, though the current proposal does not accomodate authentication separately.

  6. Kerberos Tickets 
       Multiple key management mechanisms are provided, including password-
   style manually shared secrets, public-key key exchange and Kerberos
   [19] ticket distribution.
    Kerberos has not been defined as a Key-Exchange protocol extension in the current SEA draft, though there is no reason to expect it cannot be added.

  7. Nonces 
       Additionally, a challenge-response (``nonce'') mechanism is provided
   to allow parties to assure themselves of transaction freshness.
    The current SEA draft should be modified to use nonces where appropriate, as negotiable parameters.

  8. Sending Certificates 
       If the digital signature enhancement is applied, an appropriate cer-
   tificate may either be attached to the message (possibly along with a
   certificate chain) or the sender may expect the recipient to obtain
   the required certificate (chain) independently.
    In SEA, the same behavior applies: the signer can separately choose to send a cerificate chain using a /Certificate/ extension.

  9. Message Authentication 
       Secure HTTP provides a means to verify message integrity and sender
   authenticity for a HTTP message via the computation of a Message
   Authentication Code (MAC), computed as a keyed hash over the document
   using a shared secret -- which could potentially have been arranged
   in a number of ways, e.g.: manual arrangement or Kerberos.
    The current SEA draft does not offer a parallel mechanism. It remains to be seen if a Keyed-MD5 hash is an appropriate entry under /Signature/.

  10. Freshness Guarantees 
       The protocol provides a simple challenge-response mechanism, allowing
   both parties to insure the freshness of transmissions. Additionally,
   the integrity protection provided to HTTP headers permits implementa-
   tions to consider the Date: header allowable in HTTP messages as a
   freshness indicator, where appropriate
    The challenge-response mechanism is missing from SEA; see #7 above.

    In S-HTTP, the normal mode of operation is to wrap an HTTP message in an S-HTTP message. When SEA enhancements are applied without wrapping, the outermost set of HTTP headers are vulnerable to tampering. If HTTP headers must be relied on, the message must be wrapped and then signed or encrypted.

  11. More to come...