Network Working Group E. Rescorla
`Request for Comments: 2660 RTFM, Inc.
`Category: Experimental A. Schiffman
` Terisa Systems, Inc.
` August 1999
`
` The Secure HyperText Transfer Protocol
`
`Status of this Memo
`
` This memo defines an Experimental Protocol for the Internet
` community. It does not specify an Internet standard of any kind.
` Discussion and suggestions for improvement are requested.
` Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1999). All Rights Reserved.
`
`Abstract
`
` This memo describes a syntax for securing messages sent using the
` Hypertext Transfer Protocol (HTTP), which forms the basis for the
` World Wide Web. Secure HTTP (S-HTTP) provides independently
` applicable security services for transaction confidentiality,
` authenticity/integrity and non-repudiability of origin.
`
` The protocol emphasizes maximum flexibility in choice of key
` management mechanisms, security policies and cryptographic algorithms
` by supporting option negotiation between parties for each
` transaction.
`
`Table of Contents
`
` 1. Introduction .................................................. 3
` 1.1. Summary of Features ......................................... 3
` 1.2. Changes ..................................................... 4
` 1.3. Processing Model ............................................ 5
` 1.4. Modes of Operation .......................................... 6
` 1.5. Implementation Options ...................................... 7
` 2. Message Format ................................................ 7
` 2.1. Notational Conventions ...................................... 8
` 2.2. The Request Line ............................................ 8
` 2.3. The Status Line ............................................. 8
` 2.4. Secure HTTP Header Lines .................................... 8
` 2.5. Content .....................................................12
` 2.6. Encapsulation Format Options ................................13
`
`Rescorla & Schiffman Experimental [Page 1]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` 2.6.1. Content-Privacy-Domain: CMS ...............................13
` 2.6.2. Content-Privacy-Domain: MOSS ..............................14
` 2.6.3. Permitted HTTP headers ....................................14
` 2.6.3.2. Host ....................................................15
` 2.6.3.3. Connection ..............................................15
` 3. Cryptographic Parameters ......................................15
` 3.1. Options Headers .............................................15
` 3.2. Negotiation Options .........................................16
` 3.2.1. Negotiation Overview ......................................16
` 3.2.2. Negotiation Option Format .................................16
` 3.2.3. Parametrization for Variable-length Key Ciphers ...........18
` 3.2.4. Negotiation Syntax ........................................18
` 3.3. Non-Negotiation Headers .....................................23
` 3.3.1. Encryption-Identity .......................................23
` 3.3.2. Certificate-Info ..........................................23
` 3.3.3. Key-Assign ................................................24
` 3.3.4. Nonces ....................................................25
` 3.4. Grouping Headers With SHTTP-Cryptopts .......................26
` 3.4.1. SHTTP-Cryptopts ...........................................26
` 4. New Header Lines for HTTP .....................................26
` 4.1. Security-Scheme .............................................26
` 5. (Retriable) Server Status Error Reports .......................27
` 5.1. Retry for Option (Re)Negotiation ............................27
` 5.2. Specific Retry Behavior .....................................28
` 5.3. Limitations On Automatic Retries ............................29
` 6. Other Issues ..................................................30
` 6.1. Compatibility of Servers with Old Clients ...................30
` 6.2. URL Protocol Type ...........................................30
` 6.3. Browser Presentation ........................................31
` 7. Implementation Notes ..........................................32
` 7.1. Preenhanced Data ............................................32
` 7.2. Note:Proxy Interaction ......................................34
` 7.2.1. Client-Proxy Authentication ...............................34
` 8. Implementation Recommendations and Requirements ...............34
` 9. Protocol Syntax Summary .......................................35
` 10. An Extended Example ..........................................36
` Appendix: A Review of CMS ........................................40
` Bibliography and References ......................................41
` Security Considerations ..........................................43
` Authors’ Addresses ...............................................44
` Full Copyright Statement..........................................45
`
`Rescorla & Schiffman Experimental [Page 2]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
`1. Introduction
`
` The World Wide Web (WWW) is a distributed hypermedia system which has
` gained widespread acceptance among Internet users. Although WWW
` browsers support other, preexisting Internet application protocols,
` the native and primary protocol used between WWW clients and servers
` is the HyperText Transfer Protocol (HTTP) [RFC-2616]. The ease of
` use of the Web has prompted its widespread employment as a
` client/server architecture for many applications. Many such
` applications require the client and server to be able to authenticate
` each other and exchange sensitive information confidentially. The
` original HTTP specification had only modest support for the
` cryptographic mechanisms appropriate for such transactions.
`
` Secure HTTP (S-HTTP) provides secure communication mechanisms between
` an HTTP client-server pair in order to enable spontaneous commercial
` transactions for a wide range of applications. Our design intent is
` to provide a flexible protocol that supports multiple orthogonal
` operation modes, key management mechanisms, trust models,
` cryptographic algorithms and encapsulation formats through option
` negotiation between parties for each transaction.
`
`1.1. Summary of Features
`
` Secure HTTP is a secure message-oriented communications protocol
` designed for use in conjunction with HTTP. It is designed to coexist
` with HTTP’s messaging model and to be easily integrated with HTTP
` applications.
`
` Secure HTTP provides a variety of security mechanisms to HTTP clients
` and servers, providing the security service options appropriate to
` the wide range of potential end uses possible for the World-Wide Web.
` The protocol provides symmetric capabilities to both client and
` server (in that equal treatment is given to both requests and
` replies, as well as for the preferences of both parties) while
` preserving the transaction model and implementation characteristics
` of HTTP.
`
` Several cryptographic message format standards may be incorporated
` into S-HTTP clients and servers, particularly, but in principle not
` limited to, [CMS] and [MOSS]. S-HTTP supports interoperation among a
` variety of implementations, and is compatible with HTTP. S-HTTP
` aware clients can communicate with S-HTTP oblivious servers and
` vice-versa, although such transactions obviously would not use S-HTTP
` security features.
`
` S-HTTP does not require client-side public key certificates (or
` public keys), as it supports symmetric key-only operation modes.
`
`Rescorla & Schiffman Experimental [Page 3]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` This is significant because it means that spontaneous private
` transactions can occur without requiring individual users to have
` an established public key. While S-HTTP is able to take advantage
` of ubiquitous certification infrastructures, its deployment does
` not require it.
`
` S-HTTP supports end-to-end secure transactions, in contrast with the
` original HTTP authorization mechanisms which require the client to
` attempt access and be denied before the security mechanism is
` employed. Clients may be "primed" to initiate a secure transaction
` (typically using information supplied in message headers); this may
` be used to support encryption of fill-out forms, for example. With
` S-HTTP, no sensitive data need ever be sent over the network in the
` clear.
`
` S-HTTP provides full flexibility of cryptographic algorithms, modes
` and parameters. Option negotiation is used to allow clients and
` servers to agree on transaction modes (e.g., should the request be
` signed or encrypted or both -- similarly for the reply?);
` cryptographic algorithms (RSA vs. DSA for signing, DES vs.
` RC2 for encrypting, etc.); and certificate selection
` (please sign with your "Block-buster Video certificate").
`
` S-HTTP attempts to avoid presuming a particular trust model, although
` its designers admit to a conscious effort to facilitate
` multiply-rooted hierarchical trust, and anticipate that principals may
` have many public key certificates.
`
` S-HTTP differs from Digest-Authentication, described in [RFC-2617] in
` that it provides support for public key cryptography and consequently
` digital signature capability, as well as providing confidentiality.
`
`1.2. Changes
`
` This document describes S-HTTP/1.4. It differs from the previous
` memo in that it differs from the previous memo in its support of
` the Cryptographic Message Syntax (CMS) [CMS], a successor to PKCS-7;
` and hence now supports the Diffie-Hellman and the (NIST) Digital
` Signature Standard cryptosystems. CMS used in RSA mode is bits on the
` wire compatible with PKCS-7.
`
`Rescorla & Schiffman Experimental [Page 4]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
`1.3. Processing Model
`
`1.3.1. Message Preparation
`
` The creation of an S-HTTP message can be thought of as a a function
` with three inputs:
`
` 1. The cleartext message. This is either an HTTP message
` or some other data object. Note that since the cleartext message
` is carried transparently, headers and all, any version of HTTP
` can be carried within an S-HTTP wrapper.
` 2. The receiver’s cryptographic preferences and keying material.
` This is either explicitly specified by the receiver or subject
` to some default set of preferences.
` 3. The sender’s cryptographic preferences and keying material.
` This input to the function can be thought of as implicit
` since it exists only in the memory of the sender.
`
` In order to create an S-HTTP message, then, the sender integrates the
` sender’s preferences with the receiver’s preferences. The result of
` this is a list of cryptographic enhancements to be applied and keying
` material to be used to apply them. This may require some user
` intervention. For instance, there might be multiple keys available to
` sign the message. (See Section 3.2.4.9.3 for more on this topic.)
` Using this data, the sender applies the enhancements to the message
` clear-text to create the S-HTTP message.
`
` The processing steps required to transform the cleartext message into
` the S-HTTP message are described in Sections 2 and 3. The processing
` steps required to merge the sender’s and receiver’s preferences are
` described in Sections 3.2.
`
`1.3.2. Message Recovery
`
` The recovery of an S-HTTP message can be thought of as a function of
` four distinct inputs:
`
` 1. The S-HTTP message.
` 2. The receiver’s stated cryptographic preferences and keying
` material. The receiver has the opportunity to remember what
` cryptographic preferences it provided in order for this
` document to be dereferenced.
` 3. The receiver’s current cryptographic preferences and
` keying material.
` 4. The sender’s previously stated cryptographic options.
` The sender may have stated that he would perform certain
` cryptographic operations in this message. (Again, see
` sections 4 and 5 for details on how to do this.)
`
`Rescorla & Schiffman Experimental [Page 5]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` In order to recover an S-HTTP message, the receiver needs to read the
` headers to discover which cryptographic transformations were
` performed on the message, then remove the transformations using some
` combination of the sender’s and receiver’s keying material, while
` taking note of which enhancements were applied.
`
` The receiver may also choose to verify that the applied enhancements
` match both the enhancements that the sender said he would apply
` (input 4 above) and that the receiver requested (input 2 above) as
` well as the current preferences to see if the S-HTTP message was
` appropriately transformed. This process may require interaction with
` the user to verify that the enhancements are acceptable to the user.
` (See Section 6.4 for more on this topic.)
`
`1.4. Modes of Operation
`
` Message protection may be provided on three orthogonal axes:
` signature, authentication, and encryption. Any message may be signed,
` authenticated, encrypted, or any combination of these (including no
` protection).
`
` Multiple key management mechanisms are supported, including
` password-style manually shared secrets and public-key key exchange.
` In particular, provision has been made for prearranged (in an earlier
` transaction or out of band) symmetric session keys in order to send
` confidential messages to those who have no public key pair.
`
` Additionally, a challenge-response ("nonce") mechanism is provided to
` allow parties to assure themselves of transaction freshness.
`
`1.4.1. Signature
`
` If the digital signature enhancement is applied, an appropriate
` certificate 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.
`
`1.4.2. Key Exchange and Encryption
`
` In support of bulk encryption, S-HTTP defines two key transfer
` mechanisms, one using public-key enveloped key exchange and another
` with externally arranged keys.
`
` In the former case, the symmetric-key cryptosystem parameter is
` passed encrypted under the receiver’s public key.
`
`Rescorla & Schiffman Experimental [Page 6]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` In the latter mode, we encrypt the content using a prearranged
` session key, with key identification information specified on one of
` the header lines.
`
`1.4.3. Message Integrity and Sender Authentication
`
` Secure HTTP provides a means to verify message integrity and sender
` authenticity for a 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 ’inband’ key
` management. This technique requires neither the use of public key
` cryptography nor encryption.
`
` This mechanism is also useful for cases where it is appropriate to
` allow parties to identify each other reliably in a transaction
` without providing (third-party) non-repudiability for the
` transactions themselves. The provision of this mechanism is motivated
` by our bias that the action of "signing" a transaction should be
` explicit and conscious for the user, whereas many authentication
` needs (i.e., access control) can be met with a lighter-weight
` mechanism that retains the scalability advantages of public-key
` cryptography for key exchange.
`
`1.4.4. Freshness
`
` 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
` implementations to consider the Date: header allowable in HTTP
` messages as a freshness indicator, where appropriate (although this
` requires implementations to make allowances for maximum clock skew
` between parties, which we choose not to specify).
`
`1.5. Implementation Options
`
` In order to encourage widespread adoption of secure documents for the
` World-Wide Web in the face of the broad scope of application
` requirements, variability of user sophistication, and disparate
` implementation constraints, Secure HTTP deliberately caters to a
` variety of implementation options. See Section 8 for implementation
` recommendations and requirements.
`
`2. Message Format
`
` Syntactically, Secure HTTP messages are the same as HTTP, consisting
` of a request or status line followed by headers and a body. However,
` the range of headers is different and the bodies are typically
`
`Rescorla & Schiffman Experimental [Page 7]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` cryptographically enhanced.
`
`2.1. Notational Conventions
`
` This document uses the augmented BNF from HTTP [RFC-2616]. You should
` refer to that document for a description of the syntax.
`
`2.2. Request Line
`
` In order to differentiate S-HTTP messages from HTTP messages and
` allow for special processing, the request line should use the special
` Secure" method and use the protocol designator "Secure-HTTP/1.4".
` Consequently, Secure-HTTP and HTTP processing can be intermixed on
` the same TCP port, e.g. port 80. In order to prevent leakage of
` potentially sensitive information Request-URI should be "*". For
` example:
`
` Secure * Secure-HTTP/1.4
`
` When communicating via a proxy, the Request-URI should be consist of
` the AbsoluteURI. Typically, the rel path section should be replaced
` by "*" to minimize the information passed to in the clear. (e.g.
` http://www.terisa.com/*); proxies should remove the appropriate
` amount of this information to minimize the threat of traffic
` analysis. See Section 7.2.2.1 for a situation where providing more
` information is appropriate.
`
`2.3. The Status Line
`
` S-HTTP responses should use the protocol designator "Secure-
` HTTP/1.4". For example:
`
` Secure-HTTP/1.4 200 OK
`
` Note that the status in the Secure HTTP response line does not
` indicate anything about the success or failure of the unwrapped HTTP
` request. Servers should always use 200 OK provided that the Secure
` HTTP processing is successful. This prevents analysis of success or
` failure for any request, which the correct recipient can determine
` from the encapsulated data. All case variations should be accepted.
`
`2.4. Secure HTTP Header Lines
`
` The header lines described in this section go in the header of a
` Secure HTTP message. All except ’Content-Type’ and ’Content-Privacy-
` Domain’ are optional. The message body shall be separated from the
` header block by two successive CRLFs.
`
`Rescorla & Schiffman Experimental [Page 8]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` All data and fields in header lines should be treated as case
` insensitive unless otherwise specified. Linear whitespace [RFC-822]
` should be used only as a token separator unless otherwise quoted.
` Long header lines may be line folded in the style of [RFC-822].
`
` This document refers to the header block following the S-HTTP
` request/response line and preceding the successive CRLFs collectively
` as "S-HTTP headers".
`
`2.4.1. Content-Privacy-Domain
`
` The two values defined by this document are ’MOSS’ and ’CMS’. CMS
` refers to the privacy enhancement specified in section 2.6.1. MOSS
` refers to the format defined in [RFC-1847] and [RFC-1848].
`
`2.4.2. Content-Type for CMS
`
` Under normal conditions, the terminal encapsulated content (after all
` privacy enhancements have been removed) would be an HTTP message. In
` this case, there shall be a Content-Type line reading:
`
` Content-Type: message/http
`
` The message/http content type is defined in RFC-2616.
`
` If the inner message is an S-HTTP message, then the content type
` shall be ’application/s-http’. (See Appendix for the definition of
` this.)
`
` It is intended that these types be registered with IANA as MIME
` content types.
`
` The terminal content may be of some other type provided that the type
` is properly indicated by the use of an appropriate Content-Type
` header line. In this case, the header fields for the encapsulation of
` the terminal content apply to the terminal content (the ’final
` headers’). But in any case, final headers should themselves always be
` S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers are
` never passed unenhanced.
`
` S-HTTP encapsulation of non-HTTP data is a useful mechanism for
` passing pre-enhanced data (especially presigned data) without
` requiring that the HTTP headers themselves be pre-enhanced.
`
`Rescorla & Schiffman Experimental [Page 9]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
`2.4.3. Content-Type for MOSS
`
` The Content-Type for MOSS shall be an acceptable MIME content type
` describing the cryptographic processing applied. (e.g.
` multipart/signed). The content type of the inner content is described
` in the content type line corresponding to that inner content, and for
` HTTP messages shall be ’message/http’.
`
`2.4.4. Prearranged-Key-Info
`
` This header line is intended to convey information about a key which
` has been arranged outside of the internal cryptographic format. One
` use of this is to permit in-band communication of session keys for
` return encryption in the case where one of the parties does not have
` a key pair. However, this should also be useful in the event that the
` parties choose to use some other mechanism, for instance, a one-time
` key list.
`
` This specification defines two methods for exchanging named keys,
` Inband, Outband. Inband indicates that the session key was exchanged
` previously, using a Key-Assign header of the corresponding method.
` Outband arrangements imply that agents have external access to key
` materials corresponding to a given name, presumably via database
` access or perhaps supplied immediately by a user from keyboard input.
` The syntax for the header line is:
`
` Prearranged-Key-Info =
` "Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID
` CoverKey-ID = method ":" key-name
` CoveredDEK = *HEX
` method = "inband" | "outband"
`
` While chaining ciphers require an Initialization Vector (IV) [FIPS-
` 81] to start off the chaining, that information is not carried by
` this field. Rather, it should be passed internal to the cryptographic
` format being used. Likewise, the bulk cipher used is specified in
` this fashion.
`
` <Hdr-Cipher> should be the name of the block cipher used to encrypt
` the session key (see section 3.2.4.7)
`
` <CoveredDEK> is the protected Data Encryption Key (a.k.a. transaction
` key) under which the encapsulated message was encrypted. It should be
` appropriately (randomly) generated by the sending agent, then
` encrypted under the cover of the negotiated key (a.k.a. session key)
` using the indicated header cipher, and then converted into hex.
`
`Rescorla & Schiffman Experimental [Page 10]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` In order to avoid name collisions, cover key namespaces must be
` maintained separately by host and port.
`
` Note that some Content-Privacy-Domains, notably likely future
` revisions of MOSS and CMS may have support for symmetric key
` management.
`
` The Prearranged-Key-Info field need not be used in such
` circumstances. Rather, the native syntax is preferred. Keys
` exchanged with Key-Assign, however, may be used in this situation.
`
`2.4.5. MAC-Info
`
` This header is used to supply a Message Authenticity Check, providing
` both message authentication and integrity, computed from the message
` text, the time (optional -- to prevent replay attack), and a shared
` secret between client and server. The MAC should be computed over the
` encapsulated content of the S-HTTP message. S-HTTP/1.1 defined that
` MACs should be computed using the following algorithm (’||’ means
` concatenation):
`
` MAC = hex(H(Message||[<time>]||<shared key>))
`
` The time should be represented as an unsigned 32 bit quantity
` representing seconds since 00:00:00 GMT January 1, 1970 (the UNIX
` epoch), in network byte order. The shared key format is a local
` matter.
`
` Recent research [VANO95] has demonstrated some weaknesses in this
` approach, and this memo introduces a new construction, derived from
` [RFC-2104]. In the name of backwards compatibility, we retain the
` previous constructions with the same names as before. However, we
` also introduce a new series of names (See Section 3.2.4.8 for the
` names) that obey a different (hopefully stronger) construction. (^
` means bitwise XOR)
`
` HMAC = hex(H(K’ ^ pad2 || H(K’ ^ pad1 ||[<time>]|| Message)))
` pad1 = the byte 0x36 repeated enough times to fill out a
` hash input block. (I.e. 64 times for both MD5 and SHA-1)
` pad2 = the byte 0x5c repeated enough times to fill out a
` hash input block.
` K’ = H(<shared key>)
`
` The original HMAC construction is for the use of a key with length
` equal to the length of the hash output. Although it is considered
` safe to use a key of a different length (Note that strength cannot be
` increased past the length of the hash function itself, but can be
` reduced by using a shorter key.) [KRAW96b] we hash the original key
`
`Rescorla & Schiffman Experimental [Page 11]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` to permit the use of shared keys (e.g. passphrases) longer than the
` length of the hash. It is noteworthy (though obvious) that this
` technique does not increase the strength of short keys.
`
` The format of the MAC-Info line is:
`
` MAC-Info =
` "MAC-Info" ":" [hex-time],
` hash-alg, hex-hash-data, key-spec
` hex-time = <unsigned seconds since Unix epoch represented as HEX>
` hash-alg = <hash algorithms from section 3.2.4.8>
` hex-hash-data = <computation as described above represented as HEX>
` Key-Spec = "null" | "dek" | Key-ID
`
` Key-Ids can refer either to keys bound using the Key-Assign header
` line or those bound in the same fashion as the Outband method
` described later. The use of a ’Null’ key-spec implies that a zero
` length key was used, and therefore that the MAC merely represents a
` hash of the message text and (optionally) the time. The special
` key-spec ’DEK’ refers to the Data Exchange Key used to encrypt the
` following message body (it is an error to use the DEK key-spec in
` situations where the following message body is unencrypted).
`
` If the time is omitted from the MAC-Info line, it should simply not
` be included in the hash.
`
` Note that this header line can be used to provide a more advanced
` equivalent of the original HTTP Basic authentication mode in that the
` user can be asked to provide a username and password. However, the
` password remains private and message integrity can be assured.
` Moreover, this can be accomplished without encryption of any kind.
`
` In addition, MAC-Info permits fast message integrity verification (at
` the loss of non-repudiability) for messages, provided that the
` participants share a key (possibly passed using Key-Assign in a
` previous message).
`
` Note that some Content-Privacy-Domains, notably likely future
` revisions of MOSS and CMS may have support for symmetric integrity
` protection The MAC-Info field need not be used in such circumstances.
` Rather, the native syntax is preferred. Keys exchanged with Key-
` Assign, however, may be used in this situation.
`
`2.5. Content
`
` The content of the message is largely dependent upon the values of
` the Content-Privacy-Domain and Content-Transfer-Encoding fields.
`
`Rescorla & Schiffman Experimental [Page 12]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` For a CMS message, with ’8BIT’ Content-Transfer-Encoding, the content
` should simply be the CMS message itself.
`
` If the Content-Privacy-Domain is MOSS, the content should consist of
` a MOSS Security Multipart as described in RFC1847.
`
` It is expected that once the privacy enhancements have been removed,
` the resulting (possibly protected) contents will be a normal HTTP
` request. Alternately, the content may be another Secure-HTTP message,
` in which case privacy enhancements should be unwrapped until clear
` content is obtained or privacy enhancements can no longer be removed.
` (This permits embedding of enhancements, such as sequential Signed
` and Enveloped enhancements.) Provided that all enhancements can be
` removed, the final de-enhanced content should be a valid HTTP request
` (or response) unless otherwise specified by the Content-Type line.
`
` Note that this recursive encapsulation of messages potentially
` permits security enhancements to be applied (or removed) for the
` benefit of intermediaries who may be a party to the transaction
` between a client and server (e.g., a proxy requiring client
` authentication). How such intermediaries should indicate such
` processing is described in Section 7.2.1.
`
`2.6. Encapsulation Format Options
`
`2.6.1. Content-Privacy-Domain: CMS
`
` Content-Privacy-Domain ’CMS’ follows the form of the CMS standard
` (see Appendix).
`
` Message protection may proceed on two orthogonal axes: signature and
` encryption. Any message may be either signed, encrypted, both, or
` neither. Note that the ’auth’ protection mode of S-HTTP is provided
` independently of CMS coding via the MAC-Info header of section 2.3.6
` since CMS does not support a ’KeyDigestedData’ type, although it does
` support a ’DigestedData’ type.
`
`2.6.1.1. Signature
`
` This enhancement uses the ’SignedData’ type of CMS. When digital
` signatures are used, an appropriate certificate may either be
` attached to the message (possibly along with a certificate chain) as
` specified in CMS or the sender may expect the recipient to obtain its
` certificate (and/or chain) independently. Note that an explicitly
` allowed instance of this is a certificate signed with the private
` component corresponding to the public component being attested to.
` This shall be referred to as a self-signed certificate. What, if any,
` weight to give to such a certificate is a purely local matter. In
`
`Rescorla & Schiffman Experimental [Page 13]
`
`MANGROVE 1024
`
`

`
`
`RFC 2660 The Secure HyperText Transfer Protocol August 1999
`
` either case, a purely signed message is precisely CMS compliant.
`
`2.6.1.2. Encryption
`
`2.6.1.2.1. Encryption -- normal, public key
`
` This enhancement is performed precisely as enveloping (using either ’
` EnvelopedData’ types) under CMS. A message encrypted in this fashion,
` signed or otherwise, is CMS compliant. To have a message which is
` both signed and encrypted, one simply creates the CMS SignedData
` production and encapsulates it in EnvelopedData as described in CMS.
`
`2.6.1.2.2. Encryption -- prearranged key
`
` This uses the ’EncryptedData’ type of CMS. In this mode, we encrypt
` the content using a DEK encrypted under cover of a prearranged
` session key (how this key may be exchanged is discussed later), with
` key identification information s