throbber
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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket