`
` E. Rescorla, A. Schiffman
`INTERNET-DRAFT Enterprise Integration Technologies
`<draft-ietf-wts-shttp-01.txt> Feb 1996 (Expires August-96)
`
` The Secure HyperText Transfer Protocol
`Status of this Memo
` This document is an Internet-Draft. Internet-Drafts are working
` documents of the Internet Engineering Task Force (IETF), its areas,
` and its working groups. Note that other groups may also distribute
` working documents as Internet-Drafts.
` Internet-Drafts are draft documents valid for a maximum of six months
` and may be updated, replaced, or obsoleted by other documents at any
` time. It is inappropriate to use Internet-Drafts as reference
` material or to cite them other than as ``work in progress.''
` To learn the current status of any Internet-Draft, please check the
` ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
` Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
` munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
` ftp.isi.edu (US West Coast).
` This document describes S-HTTP version 1.2. The original draft of
` this specification, defining S-HTTP version 1.0, was distributed by
` the CommerceNet Consortium in June 1994; in December 1994 a revised
` specification describing S-HTTP version 1.1 was published as an
` Internet Draft (draft-rescorla-shttp-00.txt). In July 1995, an
` updated version of that draft was published as an Internet Draft.
` That document deprecated some unimplemented facilities, provides
` additional clarifying material, and made minor corrections to the
` 12/94 version.
` This document implements a decision reached at the December 1995 IETF
` WTS meeting to break up the single S-HTTP document into two docu-
` ments, one describing the S-HTTP messaging protocol and negotiation
` syntax and one describing extensions to HTML to facilitate the use of
` S-HTTP. The companion document is draft-ietf-wts-shtml-00.txt [23].
`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) is an extension of HTTP, provid-
` ing independently applicable security services for transaction confi-
` dentiality, authenticity/integrity and non-repudiability of origin.
`
`Rescorla, Schiffman [Page 1]
`
`Internet-Draft Secure HTTP
`
` The protocol emphasizes maximum flexibility in choice of key manage-
` ment mechanisms, security policies and cryptographic algorithms by
` supporting option negotiation between parties for each transaction.
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`1
`
`MICROSOFT 1012
`
`Petitioner Apple Inc. - Exhibit 1012, p. 1
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman [Page 2]
`
`Internet-Draft Secure HTTP
`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) [18]. The ease of use of
` the Web has prompted widespread interest in its employment as a
` client/server architecture for many applications. Many such applica-
` tions 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, crypto-
` graphic algorithms and encapsulation formats through option negotia-
` tion between parties for each transaction.
`1.1. Summary of Features
` Secure HTTP supports 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, PKCS-7 and PEM. 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 pub-
` lic keys), supporting symmetric session key operation modes. This is
` significant because it means that spontaneous private transactions
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`2
`
`Petitioner Apple Inc. - Exhibit 1012, p. 2
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
` 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.
`
`Rescorla, Schiffman [Page 3]
`
`Internet-Draft Secure HTTP
`
` 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 an HTML anchor); 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 (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").
` 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.
`1.2. Changes
` This document describes S-HTTP/1.2. The prior draft described S-
` HTTP/1.1. This version adds a number of minor changes, including a
` new hash construction and a new way of binding cryptographic parame-
` ters to HTML anchors. S-HTTP/1.2 messages will be readable by S-
` HTTP/1.1 agents and vice versa, provided that compatible algorithms
` are used.
`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
` data object.
` 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 merges the
`
`Rescorla, Schiffman [Page 4]
`
`Internet-Draft Secure HTTP
`
` 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 inter-
` vention. For instance, there might be multiple keys available to sign
` the message. (See Section 7 for more on this topic.) Using this data,
` the sender applies the enhancements to the message cleartext 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 4 and 5.
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`3
`
`Petitioner Apple Inc. - Exhibit 1012, p. 3
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`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.)
`
` In order to recover an S-HTTP message, the receiver needs to read the
` headers and discover what sorts of cryptographic transformations were
` performed on the message, then remove them using some combination of
` the sender's and receiver's keying material, in the process while
` taking note of what 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 7 for more on this topic.)
`1.4. Modes of Operation
` Message protection may be provided on three orthogonal axes:
`
`Rescorla, Schiffman [Page 5]
`
`Internet-Draft Secure HTTP
`
` signature, authentication, and encryption. Any message may be signed,
` authenticated, encrypted, or any combination of these (including no
` protection).
` Multiple key management mechanisms are provided, including password-
` style manually shared secrets, public-key key exchange and Kerberos
` [19] ticket distribution. In particular, provision has been made for
` prearranged (in an earlier transaction) symmetric session keys in
` order to send confidential messages to those who have no 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 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.
`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.
` In the latter mode, we encrypt the content using a prearranged ses-
` sion key, with key identification information specified on one of the
` header lines. Keys may also be extracted from Kerberos tickets.
`1.4.3. Message Integrity and Sender 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
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`4
`
`Petitioner Apple Inc. - Exhibit 1012, p. 4
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
` using a shared secret -- which could potentially have been arranged
` in a number of ways, e.g.: manual arrangement or Kerberos. 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 transac-
` tions themselves. The provision of this mechanism is motivated by our
` bias that the action of "signing" a transaction should be explicit
`
`Rescorla, Schiffman [Page 6]
`
`Internet-Draft Secure HTTP
`
` 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 implementa-
` tions to consider the Date: header allowable in HTTP messages as a
` freshness indicator, where appropriate (although this requires imple-
` mentations 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 cryptographic facilities
` for the World-Wide Web, Secure HTTP deliberately caters to a variety
` of implementation options despite the fact that the resulting varia-
` bility makes interoperation potentially problematic.
` We anticipate that some implementors will choose to integrate an out-
` board PEM program with a WWW client or server; such implementations
` will not be able to use all operation modes or features of S-HTTP,
` but will be able to interoperate with most other implementations.
` Other implementors will choose to create a full-fledged PKCS-7 imple-
` mentation (allowing for all the features of S-HTTP); in which case
` PEM support will be only a modest additional effort. Without com-
` pletely prescribing a minimum implementation profile (although see
` section 8) then, we recommend that all S-HTTP implementations support
` the PEM message format.
`2. HTTP Encapsulation
` A Secure HTTP message consists of a request or status line (as in
` HTTP) followed by a series of RFC-822 style headers followed by an
` encapsulated content. Once the content has been decoded, it should
` either be another Secure HTTP message, an HTTP message, or simple
` data.
` For the purposes of compatibility with existing HTTP implementations,
` we distinguish S-HTTP transaction requests and replies with a dis-
` tinct protocol designator ('Secure-HTTP/1.2'). However, if a future
` version of HTTP (i.e., 'HTTP/2.0') subsumes this document use of a
` new protocol HTTP designator would provide the same backwards compa-
` tibility function and a distinction between such a future version of
` HTTP and Secure-HTTP would be unnecessary.
`
`Rescorla, Schiffman [Page 7]
`
`Internet-Draft Secure HTTP
`2.1. The Request Line
` For HTTP requests, we define a new HTTP protocol method, 'Secure'.
` All secure requests (using this version of the protocol) should read:
` Secure * Secure-HTTP/1.2
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`5
`
`Petitioner Apple Inc. - Exhibit 1012, p. 5
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
` All case variations should be accepted. The asterisk shown here is a
` placeholder and should be ignored by servers; proxy-aware clients
` should substitute the URL (and must provide at least the host+port
` portion) of the request when communicating via proxy, as is the
` current HTTP convention; (e.g. http://www.terisa.com/*) proxies
` should remove the appropriate amount of this information to minimize
` the threat of traffic analysis. See Section 8.2.2.1 for a situation
` where providing more information is appropriate.
`2.2. The Status Line
` For server responses, the first line should be:
` Secure-HTTP/1.2 200 OK
` whether the request succeeded or failed. This prevents analysis of
` success or failure for any request. All case variations should be
` accepted.
`2.3. Secure HTTP Header Lines
` We define a series of new header lines to go in the header of the
` 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.
` All data and fields in header lines should be treated as case insen-
` sitive unless otherwise specified. Linear whitespace [6] should be
` used only as a token separator unless otherwise quoted. Long header
` lines may be line folded in the style of RFC822 [6].
` 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.3.1. Content-Privacy-Domain
` This header line exists to provide compatibility with PEM-based
` Secure HTTP systems. The two values defined by this document are
` 'PEM' and 'PKCS-7'. PKCS-7 [2] refers to the privacy enhancement
` specified in section 3. PEM refers to standard PEM message format as
`
`Rescorla, Schiffman [Page 8]
`
`Internet-Draft Secure HTTP
`
` defined in RFC1421 [1]. Note that MOSS[25] could be accomodated sim-
` ply by adding a Content-Privacy-Domain: MOSS.
`2.3.2. Content-Transfer-Encoding
` The PKCS-7 message format is designed for an 8-bit clear channel, but
` may be passed over other channels using base-64 encoding (see RFC1421
` [1] for a description of base-64).
` For 'Content-Privacy-Domain: PKCS-7', acceptable acceptable values
` for this field are 'BASE64','8BIT', or 'BINARY'. Unless such a line
` is included, the rest of the message is assumed to be 'BINARY'. (Note
` that the difference between 'BINARY' and '8BIT' has to do with line
` length.)
` For 'Content-Privacy-Domain: PEM', the only acceptable value for this
` field is '7BIT', since PEM messages are already encoded for RFC-822
` (and hence 7-bit) transport.
`2.3.3. Content-Type
` Under normal conditions, the terminal encapsulated content (after all
` privacy enhancements have been removed) shall be considered to be an
` HTTP/1.0 message. In this case, there shall be a Content-Type line
` reading:
` Content-Type: application/http
` It is intended that this type be registered with IANA as a MIME con-
` tent type. For backwards compatibility, 'application/x-http' is also
` acceptable.
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`6
`
`Petitioner Apple Inc. - Exhibit 1012, p. 6
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
` However, the terminal content may be of some other type provided that
` that type is properly indicated by the use of an appropriate
` Content-Type header line. In this case, the header fields for the
` last (most deeply encapsulated) HTTP or S-HTTP message should be
` applied to the terminal content. It should be noted that unless the
` (S-)HTTP message from which the headers are taken is itself
` enveloped, then some possibly sensitive information has been passed
` in the clear.
` This is a useful mechanism for passing pre-enhanced data (especially
` presigned data) without requiring that the HTTP headers themselves be
` pre-enhanced.
`2.3.4. Prearranged-Key-Info
` This header line is intended to convey information about a key which
`
`Rescorla, Schiffman [Page 9]
`
`Internet-Draft Secure HTTP
`
` 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 three methods for exchanging named keys,
` Inband, Kerberos and Outband. Inband and Kerberos 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: <Hdr-Cipher>','<CoveredDEK>','<CoverKey-ID>
` <CoverKey-ID> := <method>':'<key-name>
` <CoveredDEK> := <hex-digits>
` <method> := 'inband' | 'krb-'<kv> | 'outband'
` <kv> := '4' | '5'
`
` While chaining ciphers require an Initialization Vector (IV) [16] to
` start off the chaining, that information is not carried by this
` field. Rather, it should be passed internal to the cryptographic for-
` mat 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 4.4.7).
` <CoveredDEK> is the protected Data Exchange 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.
` In order to avoid name collisions, cover key namespaces must be main-
` tained separately by host and port.
`2.3.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
`
`Rescorla, Schiffman [Page 10]
`
`Internet-Draft Secure HTTP
`
` concatenation):
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`7
`
`Petitioner Apple Inc. - Exhibit 1012, p. 7
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
` 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 [21] has demonstrated some insecurities in this
` approach, and this draft introduces a new construction. 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 2.3.5 for the names) that obey a different (hope-
` fully stronger) construction.
`
` MAC = 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. 48 times for MD5, 44 for
` SHA)
` 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 security cannot be
` increased past the length of the hash function itself, but can be
` reduced by using a shorter key.) [22] we hash the original key to
` permit the use of shared keys (e.g. passphrases) longer than the
` length of the hash. It is noteworthy (though obvious) that this tech-
` nique does not increase the security of short keys.
` The format of the MAC-Info line is:
` MAC-Info: [hex(<time>)],<hash-alg>, hex(<hash-data>),<key-spec>
` <time> := "unsigned seconds since Unix epoch"
` <hash-alg> := "hash algorithms from section 4.4.5"
` <hash-data> := "computation as described above"
` <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
`
`Rescorla, Schiffman [Page 11]
`
`Internet-Draft Secure HTTP
`
` 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 this key-spec in situa-
` tions 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
` version of the original HTTP Basic authentication mode in that the
` user can be made to provide a username and password. However, the
` password remains private and message integrity can be assured. More-
` over, 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 parti-
` cipants share a key (possibly passed using Key-Assign).
`2.4. Content
` The content of the message is largely dependent upon the values of
` the Content-Privacy-Domain and Content-Transfer-Encoding fields.
` For a PKCS-7 message, with '8BIT' Content-Transfer-Encoding, the con-
` tent should simply be the PKCS-7 message itself.
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`8
`
`Petitioner Apple Inc. - Exhibit 1012, p. 8
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
` If the Content-Transfer-Encoding is 'BASE64', the content should be
` preceded by a line that reads:
` -----BEGIN PRIVACY-ENHANCED MESSAGE-----
` and followed by a line that reads
` -----END PRIVACY-ENHANCED MESSAGE-----
` (see RFC1421) with the content simply being the base-64 representa-
` tion of original content. If the inner (protected) content is itself
` a PKCS-7 message, than the ContentType of the outer content should be
` set appropriately. Else, the ContentType should be represented as
` 'Data'.
` If the Content-Privacy-Domain is PEM, the content should consist of a
` normal encapsulated message, beginning with:
` -----BEGIN PRIVACY-ENHANCED MESSAGE-----
` and ending with
`
`Rescorla, Schiffman [Page 12]
`
`Internet-Draft Secure HTTP
`
` -----END PRIVACY-ENHANCED MESSAGE-----
` as defined in RFC1421.
` 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, as in, for instance, sequen-
` tial Signed and Enveloped enhancements.) Provided that all enhance-
` ments 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 per-
` mits 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 6.2.4.
`3. Message Format Options
`3.1. Content-Privacy-Domain: PKCS-7
` Content-Privacy-Domain 'PKCS-7' follows the form of the PKCS-7 stan-
` dard (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 PKCS-7 coding via the MAC-Info header of section
` 2.3.5 since PKCS-7 does not support a 'KeyDigestedData' type,
` although it does support a 'DigestedData' type.
`3.1.1. Signature
` This enhancement uses the 'SignedData' (or 'SignedAndEnvelopedData')
` type of PKCS-7. When digital signatures are used, an appropriate
` certificate may either be attached to the message (possibly along
` with a certificate chain) as specified in PKCS-7 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
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01[4/9/2014 7:56:54 PM]
`
`9
`
`Petitioner Apple Inc. - Exhibit 1012, p. 9
`
`
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman [Page 13]
`
`Internet-Draft Secure HTTP
`
` certificate is a purely local matter. In either case, a purely
` signed message is precisely PKCS-7 compliant.
`3.1.2. Encryption
`3.1.2.1. Encryption -- normal, public key
` This enhancement is performed precisely as enveloping (using either
` 'EnvelopedData' or 'SignedAndEnvelopedData' types) under PKCS-7. A
` message encrypted in this fashion, signed or otherwise, is PKCS-7
` compliant.
`3.1.2.2. Encryption -- prearranged key
` This uses the 'EncryptedData' type of PKCS-7. In this mode, we
` encrypt the content using a DEK encrypted under cover of a prear-
` ranged session key (how this key may be exchanged is discussed
` later), with key identification information specified on one of the
` header lines. The IV is in the EncryptedContentInfo type of the
` EncryptedData element. To generate signed, encrypted data, it is
` necessary to generate the 'SignedData' production and then encrypt it
` (since PKCS-7 does not support a 'SignedAndEncryptedData' type).
`3.2. Content-Privacy-Domain: PEM
` This Content-Privacy-Domain simply refers to using straight PEM mes-
` sages as per section 2.3.1. Note that clients and servers which
` implement the original HTTP access authorization protocols (as pro-
` posed by Tony Sanders and originally implemented by Rob McCool) can
` be converted to use S-HTTP (using this Content-Privacy-Domain) simply
` by changing the request/results lines to match S-HTTP and by adding
` the following three lines to the header:
` Content-Privacy-Domain: PEM
` Content-Type: application/http
` Content-Transfer-Encoding: 7BIT
` It would be helpful (but not necessary) to remove the 'authorization'
` line. No cryptographic transformations are necessary.
`3.2.1. Correspondence of PEM and S-HTTP Modes
` S-HTTP message protection modes for the PEM Content-Pr