Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_u_z/draft-ietf-wts-shttp-03.txt

Text File | 1996-08-01 | 104KB | 2,644 lines

                                                  E. Rescorla, A. Schiffman
INTERNET-DRAFT                                         Terisa Systems, Inc.
<draft-ietf-wts-shttp-03.txt>                July 1996 (Expires January-97)


                 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. Previous versions of S-
   HTTP numbered 1.0 and 1.1 have also been released as Internet-Drafts.
   A companion draft, draft-ietf-wts-shtml-01.txt, describes extensions
   to HTML to bind S-HTTP negotiation options to HTML anchors.

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 applica-
   ble security services for transaction confidentiality, authenticity/
   integrity and non-repudiability of origin.

   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.










Rescorla, Schiffman                                              [Page 1]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) [BERN95b].  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 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. Consequently, it mimics much of HTTP's style and syn-
   tax.

   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, [PKCS-7] 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



Rescorla, Schiffman                                              [Page 2]Internet-Draft                Secure HTTP


   public keys), as it supports symmetric key-only operation modes. 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?); crypto-
   graphic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypt-
   ing, 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.

1.2.  Changes

   This document describes S-HTTP/1.2. It differs from the previous
   draft in coalescing all option negotiation headers onto a single
   header line and in replacing PEM with MOSS. Also, the relationship
   between S-HTTP and HTTP has been clarified.

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:










Rescorla, Schiffman                                              [Page 3]Internet-Draft                Secure HTTP



           1. The cleartext message. This is either an HTTP message or some
           other 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 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 inter-
   vention. 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.)


   In order to recover an S-HTTP message, the receiver needs to read the
   headers to discover which cryptographic transformations were per-
   formed 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.



Rescorla, Schiffman                                              [Page 4]Internet-Draft                Secure HTTP


   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: signa-
   ture, 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, public-key key exchange and
   Kerberos [RFC-1510] ticket distribution.  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 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



Rescorla, Schiffman                                              [Page 5]Internet-Draft                Secure HTTP


   authenticity for a message via the computation of a Message Authenti-
   cation Code (MAC), computed as a keyed hash over the document using a
   shared secret -- which could potentially have been arranged in a
   number of ways, e.g.: manual arrangement or Kerberos.  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
   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 secure documents for the
   World-Wide Web in the face of the broad scope of application require-
   ments, variability of user sophistication, and disparate implementa-
   tion constraints, Secure HTTP deliberately caters to a variety of
   implementation options.  See Section 8 for implementation recommenda-
   tions and requirements.

2.  Message Format

   Secure HTTP syntax deliberately mimics HTTP syntax in an effort to
   ease integration with systems that already process HTTP. In addition,
   certain HTTP headers are promoted to be Secure HTTP headers because
   they provide useful functionality that has security implications.

   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
   encapsulated content. Once the content has been recovered, it should
   either be another Secure HTTP message, an HTTP message, or simple
   data.




Rescorla, Schiffman                                              [Page 6]Internet-Draft                Secure HTTP


   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').

2.1.  The Request Line

   The S-HTTP request line format is similar to that of HTTP.  However,
   all S-HTTP request use the method, 'Secure'.  All S-HTTP requests
   (using this version of the protocol) should read:

           Secure * Secure-HTTP/1.2

   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 7.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, which the correct recipient can
   determine from the encapsulated data. All case variations should be
   accepted.

2.3.  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.

   All data and fields in header lines should be treated as case insen-
   sitive 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".




Rescorla, Schiffman                                              [Page 7]Internet-Draft                Secure HTTP


2.3.1.  Content-Privacy-Domain

   The two values defined by this document are 'MOSS' and 'PKCS-7'.
   PKCS-7 [PKCS-7] refers to the privacy enhancement specified in sec-
   tion 3. MOSS refers to the format defined in [RFC-1847] and [RFC-
   1848].

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 [RFC-
   1421] for a description of base-64).

   For 'Content-Privacy-Domain: PKCS-7', 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. See [RFC-1521] for details)

   For 'Content-Privacy-Domain: MOSS' all content transfer encodings are
   permitted.

2.3.3.  Content-Type for PKCS7

   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: application/http


   If the inner message is an S-HTTP message, then the content type
   shall be 'application/s-http'.

   It is intended that these types be registered with IANA as MIME con-
   tent 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 pass-
   ing pre-enhanced data (especially presigned data) without requiring
   that the HTTP headers themselves be pre-enhanced.



Rescorla, Schiffman                                              [Page 8]Internet-Draft                Secure HTTP


2.3.4.  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 'application/http'.

2.3.5.  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 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) [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                                              [Page 9]Internet-Draft                Secure HTTP


   In order to avoid name collisions, cover key namespaces must be main-
   tained separately by host and port.

   Note that some Content-Privacy-Domains, notably likely future revi-
   sions of MOSS and PKCS-7 may have support for symmetric key manage-
   ment.  The Prearranged-Key-Info field need not be used in such cir-
   cumstances.  Rather, the native syntax is preferred. Keys exchanged
   with Key-Assign, however, may be used in this situation.

2.3.6.  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 draft introduces a new construction, derived from
   [KRAW96a]. In the name of backwards compatibility, we retain the pre-
   vious 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                                             [Page 10]Internet-Draft                Secure HTTP


   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 strength 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 3.2.4.8"
        <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
   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. 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 in a previous
   message).

   Note that some Content-Privacy-Domains, notably likely future revi-
   sions of MOSS and PKCS-7 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.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



Rescorla, Schiffman                                             [Page 11]Internet-Draft                Secure HTTP


   content should simply be the PKCS-7 message itself.

   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, then the ContentType of the outer content should be
   set appropriately; else, the ContentType should be represented as
   'Data'.

   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 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 7.2.1.

2.5.  Encapsulation Format Options

2.5.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



Rescorla, Schiffman                                             [Page 12]Internet-Draft                Secure HTTP


   2.3.6 since PKCS-7 does not support a 'KeyDigestedData' type,
   although it does support a 'DigestedData' type.

2.5.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 cer-
   tificate is a purely local matter.  In either case, a purely signed
   message is precisely PKCS-7 compliant.

2.5.1.2.  Encryption

2.5.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.

2.5.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 -- see
   Appendix A for a description of PKCS-7 operational modes.).

2.5.2.  Content-Privacy-Domain: MOSS

   The body of the message should be a MIME compliant message with con-
   tent type that matches the Content-Type line in the S-HTTP headers.
   Encrypted messages should use multipart/encrypted. Signed messages
   should use multipart/signed. However, since multipart/signed does not
   convey keying material, is is acceptable to use multipart/mixed where
   the first part is application/mosskey-data and the second part is
   multipart/mixed in order to convey certificates for use in verifying
   the signature.



Rescorla, Schiffman                                             [Page 13]Internet-Draft                Secure HTTP


   Implementation Note: When both encryption and signature are applied
   by the same agent, signature should in general be applied before
   encryption.

2.5.3.  Imported HTTP headers

2.5.3.1.  Overview

   Some HTTP facilities, particularly those involved with caching and
   proxies, require special consideration when S-HTTP processing has
   been applied. Secure HTTP makes special accomodation for these
   features by copying the relevant HTTP header lines into Secure HTTP
   header syntax as well.

   The behavior of these headers is intended to be in line with HTTP
   practice.  This text is largely paraphrased from HTTP/1.0. [BERN95b].
   Note that since the semantics of some of these headers may vary
   across HTTP versions, this document is the definitive reference for
   the meaning of these headers when present in S-HTTP headers.

2.5.3.2.  Connection: Keep-Alive

   The 'Connection: Keep-Alive' header is designed to permit persistent
   connections between client/proxy and proxy/server pairs.  A client or
   proxy which desires persistent connections should send the header
   'Connection: Keep-Alive'. A server which agrees should respond with
   'Connection: Keep-Alive'.

   The persistent connection ends when either side closes the connection
   or after the receipt of a response which lacks the "keep-alive" key-
   word. The server may close the connection immediately after respond-
   ing to a request without a "keep-alive" keyword. A client can tell if
   the connection will be closed by looking for a "keep-alive" in the
   response.

   Proxies and gateways should remove the Keep-Alive header, though, of
   course, they may optionally regenerate it if they desire a persistent
   connection with the next hop. HTTP clients not using gateways and
   desiring a persistent connection with the server should not use this
   mechanism, but rather should use whatever mechanisms HTTP provides.

2.5.3.3.  If-Modified-Since

   This may be used by the proxy to indicate that the document may be in
   its cache and that it is prepared to serve the document to the
   current requestor. Servers receiving this header and deciding not to
   resend the document should respond using the 320 response code as
   described in Section 5.2.5.



Rescorla, Schiffman                                             [Page 14]Internet-Draft                Secure HTTP


   This header should only be placed in S-HTTP headers by proxies.
   Clients wanting to use If-Modified-Since should place it in the HTTP
   headers of the inner content.

2.5.3.4.  Content-MD5

   Servers may generate a Content-MD5 header to enable proxies to detect
   when valid cache hits have occurred. Note that the Content-MD5 header
   provides the possibility of traffic analysis. Servers using this
   should bear that risk in mind.

   The Content-MD5 is exactly as described in [RFC-1864] except that it
   is computed on the inner content rather than on the ciphertext.

3.  Cryptographic Parameters

3.1.  Options Headers

   As described in Section 1.3.2, every S-HTTP request is (at least con-
   ceptually) preconditioned by the negotiation options provided by the
   potential receiver. The two primary locations for these options are

           1. In the headers of an HTTP Request/Response.
           2. In the HTML which contains the anchor being dereferenced.


   There are two kinds of cryptographic options which may be provided:
   Negotiation options, as discussed in Section 3.2 convey a potential
   message recipient's cryptographic preferences. Keying options, as
   discussed in Section 3.3 provide keying material (or pointers to key-
   ing material) which may be of use to the sender when enhancing a mes-
   sage.

   Binding cryptographic options to anchors using HTML extensions is the
   topic of the companion document draft-ietf-wts-shtml-01.txt and will
   not be treated here.


   3.2.  Negotiation Options

   3.2.1.  Negotiation Overview

   Both parties are able to express their requirements and preferences
   regarding what cryptographic enhancements they will permit/require
   the other party to provide. The appropriate option choices depend on
   implementation capabilities and the requirements of particular appli-
   cations.




Rescorla, Schiffman                                             [Page 15]Internet-Draft                Secure HTTP


   A negotiation header is a sequence of specifications each conforming
   to a four-part schema detailing:

        Property -- the option being negotiated, such as bulk
        encryption algorithm.

        Value -- the value being discussed for the property, such
        as DES-CBC

        Direction -- the direction which is to be affected, namely:
        during reception or origination (from the perspective of
        the originator).

        Strength -- strength of preference, namely: required,
        optional, refused

   As an example, the header line:

           SHTTP-Symmetric-Content-Algorithms: recv-optional=DES-CBC,RC2

   could be thought to say: ``You are free to use DES-CBC or RC2 for
   bulk encryption for encrypting messages to me.''

   We define new headers (to be used in the encapsulated HTTP header,
   not in the S-HTTP header) to permit negotiation of these matters.

3.2.2.  Negotiation Option Format

   The general format for negotiation options is:

           <Option> := <Field> ':' <Key-val>(';'<Key-val>)*
           <Key-val> := <Key> '=' <Value>(','<Value>)*
           <Key> := <Mode>'-'<Action>
           <Mode> := 'orig'|'recv'
           <Action> := 'optional'|'required'|'refused'

   The <Mode> value indicates whether this <Key-val> refers to what the
   agent's actions are upon sending privacy enhanced messages as opposed
   to upon receiving them. For any given mode-action pair, the interpre-
   tation to be placed on the enhancements (<Value>s) listed is:

         'recv-optional:' The agent will process the enhancement if
        the other party uses it, but will also gladly process mes-
        sages without the enhancement.

         'recv-required:' The agent will not process messages
        without this enhancement.




Rescorla, Schiffman                                             [Page 16]Internet-Draft                Secure HTTP


         'recv-refused:' The agent will not process messages with
        this enhancement.

         'orig-optional:' When encountering an agent which refuses
        this enhancement, the agent will not provide it, and when
        encountering an agent which requires it, this agent will
        provide it.

         'orig-required:' The agent will always generate the
        enhancement.

         'orig-refused:' The agent will never generate the enhance-
        ment.

   The behavior of agents which discover that they are communicating
   with an incompatible agent is at the discretion of the agents. It is
   inappropriate to blindly persist in a behavior that is known to be
   unacceptable to the other party. Plausible responses include simply
   terminating the connection, or, in the case of a server response,
   returning 'Not implemented 501'.

   Optional values are considered to be listed in decreasing order of
   preference. Agents are free to choose any member of the intersection
   of the optional lists (or none) however.

   If any <Key-Val> is left undefined, it should be assumed to be set to
   the default. Any key which is specified by an agent shall override
   any appearance of that key in any <Key-Val> in the default for that
   field.

3.2.3.  Parametrization for Variable-length Key Ciphers

   For ciphers with variable key lengths, values may be parametrized
   using the syntax <cipher>'['<length>']'

   For example, 'RSA[1024]' represents a 1024 bit key for RSA. Ranges
   may be represented as

           <cipher>'['<bound1>'-'<bound2>']'


   For purposes of preferences, this notation should be treated as if it
   read (assuming x and y are integers)

           <cipher>[x], <cipher>[x+1],...<cipher>[y] (if x<y)

   and




Rescorla, Schiffman                                             [Page 17]Internet-Draft                Secure HTTP



           <cipher>[x], <cipher>[x-1],...<cipher>[y] (if x>y)

   The special value 'inf' may be used to denote infinite length.

   Using simply <cipher> for such a cipher shall be read as the maximum
   range possible with the given cipher.

3.2.4.  Negotiation Syntax

3.2.4.1.  SHTTP-Privacy-Domains

   This header refers to the Content-Privacy-Domain type of section
   2.3.1. Acceptable values are as listed there. For instance,

           SHTTP-Privacy-Domains: orig-required=pkcs-7;
                                  recv-optional=pkcs-7,MOSS

   would indicate that the agent always generates PKCS-7 compliant mes-
   sages, but can read PKCS-7 or MOSS (or, unenhanced messages).

3.2.4.2.  SHTTP-Certificate-Types

   This indicates what sort of Public Key certificates the agent will
   accept. Currently defined values are 'X.509' and 'X.509v3'.

3.2.4.3.  SHTTP-Key-Exchange-Algorithms

   This header indicates which algorithms may be used for key exchange.
   Defined values are 'RSA', 'Outband', 'Inband', and 'Krb-'<kv>.  RSA
   refers to RSA enveloping. Outband refers to some sort of external key
   agreement. Inband and Kerberos refer to the protocols of sections
   3.3.3.1 and 3.3.3.2 respectively.

   The expected common configuration of clients having no certificates
   and servers having certificates would look like this (in a message
   sent by the server):

           SHTTP-Key-Exchange-Algorithms: orig-optional=Inband, RSA;
                                          recv-required=RSA


3.2.4.4.  SHTTP-Signature-Algorithms

   This header indicates what Digital Signature algorithms may be used.
   Defined values are 'RSA' [PKCS-1] and 'NIST-DSS' [FIPS-186] Since
   NIST-DSS and RSA use variable length moduli the parametrization syn-
   tax of section 3.2.3 should be used.  Note that a key length



Rescorla, Schiffman                                             [Page 18]Internet-Draft                Secure HTTP


   specification may interact with the acceptability of a given certifi-
   cate, since keys (and their lengths) are specified in public-key cer-
   tificates.

3.2.4.5.  SHTTP-Message-Digest-Algorithms

   This indicates what message digest algorithms may be used.  Previ-
   ously defined values are 'RSA-MD2' [RFC-1319], 'RSA-MD5' [RFC-1321],

3.2.4.6.  SHTTP-Symmetric-Content-Algorithms

   This header specifies the symmetric-key bulk cipher used to encrypt
   message content.  Defined values are:

        DES-CBC -- DES in Cipher Block Chaining (CBC) mode [FIPS-81]
        DES-EDE-CBC -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in outer CBC mode
        DES-EDE3-CBC -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in outer CBC mode
        DESX-CBC -- RSA's DESX in CBC mode
        IDEA-CBC -- IDEA in CBC mode [XXXX]
        RC2-CBC -- RSA's RC2 in CBC mode
        CDMF-CBC -- IBM's CDMF (weakened key DES) [JOHN93] in CBC mode

   Since RC2 keys are variable length, the syntax of section 3.2.3
   should be used.

3.2.4.7.  SHTTP-Symmetric-Header-Algorithms

   This header specifies the symmetric-key cipher used to encrypt mes-
   sage headers.

        DES-ECB -- DES in Electronic Codebook (ECB) mode [FIPS-81]
        DES-EDE-ECB -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode
        DES-EDE3-ECB -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode
        DESX-ECB -- RSA's DESX in ECB mode
        IDEA-ECB -- IDEA
        RC2-ECB -- RSA's RC2 in ECB mode
        CDMF-ECB -- IBM's CDMF in ECB mode


   Since RC2 is variable length, the syntax of section 3.2.3 should be
   used.

3.2.4.8.  SHTTP-MAC-Algorithms

   This header indicates what algorithms are acceptable for use in pro-
   viding a symmetric key MAC. 'RSA-MD2', 'RSA-MD5' and 'NIST-SHS' per-
   sist from S-HTTP/1.1 using the old MAC construction. The tokens
   'RSA-MD2-HMAC', 'RSA-MD5-HMAC' and 'NIST-SHS-HMAC' indicate the new



Rescorla, Schiffman                                             [Page 19]Internet-Draft                Secure HTTP


   HMAC construction of 2.3.6 with the MD2, MD5, and SHA-1 algorithms
   respectively.

   3.2.4.9.  SHTTP-Privacy-Enhancements

   This header indicates security enhancements to apply.  Possible
   values are 'sign', 'encrypt' and 'auth' indicating whether messages
   are signed, encrypted, or authenticated (i.e., provided with a MAC),
   respectively.

3.2.4.10.  Your-Key-Pattern

   This is a generalized pattern match syntax to describe identifiers
   for a large number of types of keying material. The general syntax
   is:

        Your-Key-Pattern : <key-use>','<pattern-info>
        <key-use> := 'cover-key' | 'auth-key' | 'signing-key' | 'krbID-'<kv>


3.2.4.10.1.  Cover Key Patterns

   This header specifies desired values for key names used for encryp-
   tion of transaction keys using the Prearranged-Key-Info syntax of
   section 2.3.5.  The pattern-info syntax consists of a series of comma
   separated regular expressions. Commas should be escaped with
   backslashes if they appear in the regexps. The first pattern should
   be assumed to be the most preferred.

3.2.4.10.2.  Auth key patterns

   Auth-key patterns specify name forms desired for use for MAC authen-
   ticators.  The pattern-info syntax consists of a series of comma
   separated regular expressions. Commas should be escaped with
   backslashes if they appear in the regexps. The first pattern should
   be assumed to be the most preferred.

3.2.4.10.3.  Signing Key Pattern

   This parameter describes a pattern or patterns for what keys are
   acceptable for signing for the digital signature enhancement.  The
   pattern-info syntax for signing-key is:

           <pattern-info> := <name-domain>','<pattern-data>


   The only currently defined name-domain is 'DN-1485'.  This parameter
   specifies desired values for fields of Distinguished Names.  DNs are



Rescorla, Schiffman                                             [Page 20]Internet-Draft                Secure HTTP


   considered to be represented as specified in RFC1485, the order of
   fields and whitespace between fields is not significant.

   All RFC1485 values should use ',' as a separator rather than ';',
   since ';' is used as a statement separator in S-HTTP.

   Pattern-data is a modified RFC1485 string, with regular expressions
   permitted as field values.  Pattern match is performed field-wise,
   unspecified fields match any value (and therefore leaving the DN-
   Pattern entirely unspecified allows for any DN). Certificate chains
   may be matched as well (to allow for certificates without name subor-
   dination). DN chains are considered to be ordered left-to-right with
   the issuer of a given certificate on its immediate right, although
   issuers need not be specified. A trailing '.' indicates that the
   sequence of DNs is absolute. I.e. that the one furthest to the right
   is a root.

   The syntax for the pattern values is,

        <Value> := <DN-spec> (','<Dn-spec>)*[.]
        <Dn-spec> := '/'<Field-spec>*'/'
        <Field-spec> := <Attr>'='<Pattern>
        <Attr> := 'CN' | 'L' | 'ST' | 'O' |
                   'OU' | 'C' | "or as appropriate"
        <Pattern> := "POSIX 1003.2 regular expressions"


   For example, to request that the other agent sign with a key certi-
   fied by the RSA Persona CA (which uses name subordination) one could
   use the expression below.  Note the use of RFC1485 quoting to protect
   the comma (an RFC1485 field separator) and the POSIX 1003.2 quoting
   to protect the dot (a regular expression metacharacter).
      Your-Key-Pattern: signing-key, DN-1485,
                  /OU=Persona Certificate, O="RSA Data Security, Inc\."/

3.2.4.11.  Example

   A representative header block for a server follows.

        SHTTP-Privacy-Domains: recv-optional=MOSS, PKCS-7;
              orig-required=PKCS-7
        SHTTP-Certificate-Types: recv-optional=X.509;
              orig-required=X.509
        SHTTP-Key-Exchange-Algorithms: recv-required=RSA;
              orig-optional=Inband,RSA
        SHTTP-Signature-Algorithms: orig-required=RSA; recv-required=RSA
        SHTTP-Privacy-Enhancements: orig-required=sign;
              orig-optional=encrypt



Rescorla, Schiffman                                             [Page 21]Internet-Draft                Secure HTTP


3.2.4.12.  Defaults

   Explicit negotiation parameters take precedence over default values.
   For a given negotiation option type, defaults for a given mode-action
   pair (such as 'orig-required') are implicitly merged unless expli-
   citly overridden.

   The default values (these may be negotiated downward or upward) are:

        SHTTP-Privacy-Domains: orig-optional=PKCS-7, MOSS;
                               recv-optional=PKCS-7, MOSS
        SHTTP-Certificate-Types: orig-optional=X.509;
                                 recv-optional=X.509
        SHTTP-Key-Exchange-Algorithms: orig-optional=RSA,Inband,Outband;
                                       recv-optional=RSA,Inband,Outband
        SHTTP-Signature-Algorithms: orig-optional=RSA; recv-optional=RSA
        SHTTP-Message-Digest-Algorithms: orig-optional=RSA-MD5;
                                         recv-optional=RSA-MD5
        SHTTP-Symmetric-Content-Algorithms: orig-optional=DES-CBC;
                                            recv-optional=DES-CBC
        SHTTP-Symmetric-Header-Algorithms: orig-optional=DES-ECB;
                                           recv-optional=DES-ECB
        SHTTP-Privacy-Enhancements: orig-optional=sign,encrypt, auth;
                                            recv-required=encrypt;
                                            recv-optional=sign, auth


3.3.  Non-Negotiation Headers

   There are a number of options that are used to communicate or iden-
   tify the potential recipient's keying material.

3.3.1.  Encryption-Identity

   This header identifies a potential principal for whom the message
   described by these options could be encrypted; Note that this expli-
   citly permits return encryption under (say) public key without the
   other agent signing first (or under a different key than that of the
   signature). Or, in the Kerberos case, provides information as the
   agent's Kerberos identity.  The syntax of the Encryption-Identity
   line is:

           Encryption-Identity: <name-class>,<key-sel>,<name-arg>
           <name-class> := 'DN-1485' | MOSS name forms

   The name-class is an ASCII string representing the domain within
   which the name is to be interpreted, in the spirit of the new MOSS
   drafts. In addition to the MOSS name forms of RFC1848, we add the



Rescorla, Schiffman                                             [Page 22]Internet-Draft                Secure HTTP


   DN-1485 name form to represent a more convenient form of dis-
   tinguished name.

   Note: The Kerberos name forms of previous drafts are subsumed by the
   MOSS email string form.

3.3.1.1.  DN-1485 Name Class

   The argument is an RFC-1485 encoded DN.

3.3.2.  Certificate-Info

   In order to permit public key operations on DNs specified by
   Encryption-Identity headers without explicit certificate fetches by
   the receiver, the sender may include certification information in the
   Certificate-Info option. The format of this option is:

           Certificate-Info: <Cert-Fmt>','<Cert-Group>

   <Cert-Fmt> should be the type of <Cert-Group> being presented.
   Defined values are 'PEM' and 'PKCS-7'. PKCS-7 certificate groups are
   provided as a base-64 encoded PKCS-7 SignedData message containing
   sequences of certificates with or without the SignerInfo field. A PEM
   format certificate group is a list of comma-separated base64-encoded
   PEM certificates.

   Multiple Certificate-Info lines may be defined.

3.3.3.  Key-Assign

   This option serves to indicate that the agent wishes to bind a key to
   a symbolic name for (presumably) later reference.

   The general syntax of the key-assign header is:

        Key-Assign: <Method>,<Key-Name>,<Lifetime>,<Ciphers>;<Method-args>

        <Key-name> := <string>
        <Lifetime> := 'this' | 'reply' | ''
        <Method> :='inband' | 'krb-'<kv>
        <Ciphers> := 'null' | <Cipher>+
        <Cipher> := "Header cipher from section 3.2.4.7"
        <kv> := '4' | '5'


   Key-Name is the symbolic name to which this key is to be bound.
   Ciphers is a list of ciphers for which this key is potentially appli-
   cable (see the list of header ciphers in section 3.2.4.7).  The



Rescorla, Schiffman                                             [Page 23]Internet-Draft                Secure HTTP


   keyword 'null' should be used to indicate that it is inappropriate
   for use with ANY cipher. This is potentially useful for exchanging
   keys for MAC computation.

   Lifetime is a representation of the longest period of time during
   which the recipient of this message can expect the sender to accept
   that key. 'this' indicates that it is likely to be valid only for
   reading this transmission. 'reply' indicates that it is useful for a
   reply to this message.  If a Key-Assign with the reply lifetime
   appears in a CRYPTOPTS block, it indicates that it is good for at
   least one (but perhaps only one) dereference of this anchor.  An
   unspecified lifetime implies that this key may be reused for an inde-
   finite number of transactions.

   Method should be one of a number of key exchange methods.  The
   currently defined values are 'inband', 'krb-4' and 'krb-5', referring
   respectively to Inband keys (i.e., direct assignment) and Kerberos
   versions 4 and 5 respectively. Method-args will depend on methods.

   This header line may appear either in an unencapsulated header or in
   an encapsulated message, though when an uncovered key is being
   directly assigned, it may only appear in an encrypted encapsulated
   content. Assigning to a key that already exists causes that key to be
   overwritten.

   Keys defined by this header are referred to elsewhere in this specif-
   ication as Key-IDs, which have the syntax:

           <Key-ID> := <method>':'<key-name>


   Key-Assign may also be used as a header line in the S-HTTP headers if
   the data it is carrying does not need to be secured itself, e.g. with
   Kerberos.

3.3.3.1.  Inband Key Assignment

   This refers to the direct assignment of an uncovered key to a sym-
   bolic name. Method-args should be just the desired session key
   encoded in hexidecimal as in:

        Key-Assign: inband,akey,reply,DES-ECB;0123456789abcdef


   Short keys should be derived from long keys by reading bits from left
   to right.

   Note that inband key assignment is especially important in order to



Rescorla, Schiffman                                             [Page 24]Internet-Draft                Secure HTTP


   permit confidential spontaneous communication between agents where
   one (but not both) of the agents have key pairs.  However, this
   mechanism is also useful to permit key changes without public key
   computations. The key information is carried in this header line must
   be in the inner secured HTTP request, therefore use in unencrypted
   messages is not permitted.

3.3.3.2.  Kerberos Key Assignment

   This permits the binding of the shared secret derived from a Kerberos
   ticket/authenticator pair to a symbolic keyname.  In this case,
   method-args should be the ticket/authenticator pair (each base64-
   encoded), comma separated. For example:

        Key-Assign: krb-4,akerbkey,reply,DES-ECB;<krb-ticket>,<krb-auth>


3.3.4.  Nonces

   Nonces are opaque, transient, session-oriented identifiers which may
   be used to provide demonstrations of freshness. Nonce values are a
   local matter, although they are might well be simply random numbers
   generated by the originator. The value is supplied simply to be
   returned by the recipient.

3.3.4.1.  Nonce

   This header is used by an originator to specify what value is to be
   returned in the reply. The field may be any value. Multiple nonces
   may be supplied, each to be echoed independently.

   The Nonce should be returned in a Nonce-Echo header line. See section
   4.1.1.

3.4.  Grouping Headers With SHTTP-Cryptopts

   In order for servers to bind a group of headers to an HTML anchor, it
   is possible to combine a number of headers on a single S-HTTP Cryp-
   topts header line. The names of the anchors to which these headers
   apply is indicated with a 'scope' parameter.

3.4.1.  SHTTP-Cryptopts

   This option provides a set of cryptopts and a list of references to
   which it applies. (For HTML, these references would be named using
   the NAME tag). The names are provided in the scope attribute as a
   comma separated list and separated from the next header line by a
   semicolon. The format for the SHTTP-Cryptopts line is:



Rescorla, Schiffman                                             [Page 25]Internet-Draft                Secure HTTP



           SHTTP-Cryptopts: <scope>';'<cryptopt-list>
           <scope> := 'scope='<tag-spec>
           <tag-spec> := <tag>(','<tag>)* | <null>
           <cryptopt-list> := <cryptopt>(';'<cryptopt>)*
           <cryptopt> := "S-HTTP cryptopt lines described below"
           <tag> := "value used in HTML anchor NAME attribute"


   For example:

           SHTTP-Cryptopts: scope=tag1,tag2;
                   SHTTP-Privacy-Domains:
                   orig-required=pkcs-7; recv-optional=pkcs-7,MOSS


   If a message contains both S-HTTP negotiation headers and headers
   grouped on SHTTP-Cryptopts line(s), the other headers shall be taken
   to apply to all anchors not bound on the SHTTP-Cryptopts line(s).
   Note that this is an all-or-nothing proposition. That is, if a
   SHTTP-Cryptopts header binds options to a reference, then none of
   these global options apply, even if some of the options headers do
   not appear in the bound options. Rather, the S-HTTP defaults found in
   Section 3.2.4.11 apply.

4.  New Header Lines for HTTP

   Two non-negotiation header lines for HTTP are defined here.

4.1.  Security-Scheme

   All S-HTTP compliant agents must generate the Security-Scheme header
   in the headers of all HTTP messages they generate. This header per-
   mits other agents to detect that they are communicating with an S-
   HTTP compliant agent and generate the appropriate cryptographic
   options headers.

   For implementations compliant with this specification, the value must
   be 'S-HTTP/1.2'.

4.1.1.  Nonce-Echo

   The header is used to return the value provided in a previously
   received Nonce: field. This has to go in the encapsulated headers so
   that it an be cryptographically protected.






Rescorla, Schiffman                                             [Page 26]Internet-Draft                Secure HTTP


5.  (Retriable) Server Status Error Reports

   We describe here the special processing appropriate for client
   retries in the face of servers returning an error status.

5.1.  Retry for Option (Re)Negotiation

   A server may respond to a client request with an error code that
   indicates that the request has not completely failed but rather that
   the client may possibly achieve satisfaction through another request.
   HTTP already has this concept with the 3XX redirection codes.

   In the case of S-HTTP, it is conceivable (and indeed likely) that the
   server expects the client to retry his request using another set of
   cryptographic options. E.g., the document which contains the anchor
   that the client is dereferencing is old and did not require digital
   signature for the request in question, but the server now has a pol-
   icy requiring signature for dereferencing this URL. These options
   should be carried in the header of the encapsulated HTTP message,
   precisely as client options are carried.

   The general idea is that the client will perform the retry in the
   manner indicated by the combination of the original request and the
   precise nature of the error and the cryptographic enhancements
   depending on the options carried in the server response.

   The guiding principle in client response to these errors should be to
   provide the user with the same sort of informed choice with regard to
   dereference of these anchors as with normal anchor dereference. For
   instance, in the case above, it would be inappropriate for the client
   to sign the request without requesting permission for the action.

5.2.  Specific Retry Behavior

5.2.1.  Unauthorized 401, PaymentRequired 402

   The HTTP errors 'Unauthorized 401', 'PaymentRequired 402' represent
   failures of HTTP style authentication and payment schemes. While S-
   HTTP has no explicit support for these mechanisms, they can be per-
   formed under S-HTTP while taking advantage of the privacy services
   offered by S-HTTP. (There are other errors for S-HTTP specific
   authentication errors.)

5.2.2.  420 SecurityRetry

   This server status reply is provided so that the server may inform
   the client that although the current request is rejected, a retried
   request with different cryptographic enhancements is worth



Rescorla, Schiffman                                             [Page 27]Internet-Draft                Secure HTTP


   attempting. This header shall also be used in the case where an HTTP
   request has been made but an S-HTTP request should have been made.
   Obviously, this serves no useful purpose other than signalling an
   error if the original request should have been encrypted, but in
   other situations (e.g. access control) may be useful.

5.2.2.1.  SecurityRetries for S-HTTP Requests

   In the case of a request that was made as an SHTTP request, it indi-
   cates that for some reason the cryptographic enhancements applied to
   the request were unsatisfactory and that the request should be
   repeated with the options found in the response header.  Note that
   this can be used as a way to force a new public key negotiation if
   the session key in use has expired or to supply a unique nonce for
   the purposes of ensuring request freshness.

5.2.2.2.  SecurityRetries for HTTP Requests

   If the 420 code is returned in response to an HTTP request, it indi-
   cates that the request should be retried using S-HTTP and the crypto-
   graphic options indicated in the response header.

5.2.3.  421 BogusHeader

   This error code indicates that something about the S-HTTP request was
   bad. The error code is to be followed by an appropriate explanation,
   e.g.:

           421 BogusHeader Content-Privacy-Domain must be specified


5.2.4.  422 SHTTP Proxy Authentication Required

   This response is analagous to the 420 response except that the
   options in the message refer to enhancements that the client must
   perform in order to satisfy the proxy.

5.2.5.  320 SHTTP Not Modifed

   This response code is specifically for use with proxy-server interac-
   tion where the proxy has placed the If-Modified-Since header in the
   S-HTTP headers of its request. This response indicates that the fol-
   lowing S-HTTP message contains sufficient keying material for the
   proxy to forward the cached document for the new requestor.

   In general, this takes the form of an S-HTTP message where the actual
   enhanced content is missing, but all the headers and keying material
   are retained. (I.e. the optional content section of the PKCS7 message



Rescorla, Schiffman                                             [Page 28]Internet-Draft                Secure HTTP


   has been removed.) So, if the original response was encrypted, the
   response contains the original DEK re-covered for the new recipient.
   (Notice that the server performs the same processing as it would have
   in the server side caching case of 7.1 except that the message body
   is elided.)

5.2.6.  Redirection 3XX

   These headers are again internal to HTTP, but may contain S-HTTP
   negotiation options of significance to S-HTTP. The request should be
   redirected in the sense of HTTP, with appropriate cryptographic pre-
   cautions being observed.

5.3.  Limitations On Automatic Retries

   Permitting automatic client retry in response to this sort of server
   response permits several forms of attack.  Consider for the moment
   the simple credit card case:

        The user views a document which requires his credit card.
        The user verifies that the DN of the intended recipient is
        acceptable and that the request will be encrypted and
        dereferences the anchor.  The attacker intercepts the
        server's reply and responds with a message encrypted under
        the client's public key containing the Moved 301 header. If
        the client were to automatically perform this redirect it
        would allow compromise of the user's credit card.

5.3.1.  Automatic Encryption Retry

   This shows one possible danger of automatic retries -- potential
   compromise of encrypted information. While it is impossible to con-
   sider all possible cases, clients should never automatically reen-
   crypt data unless the server requesting the retry proves that he
   already has the data. So, situations in which it would be acceptable
   to reencrypt would be if:

        1. The retry response was returned encrypted under an inband key
        freshly generated for the original request.
        2. The retry response was signed by the intended recipient of the
        original request.
        3. The original request used an outband key and the response is
        encrypted under that key.


   This is not an exhaustive list, however the browser author would be
   well advised to consider carefully before implementing automatic
   reencryption in other cases. Note that an appropriate behavior in



Rescorla, Schiffman                                             [Page 29]Internet-Draft                Secure HTTP


   cases where automatic reencryption is not appropriate is to query the
   user for permission.

5.3.2.  Automatic Signature Retry

   Since we discourage automatic (without user confirmation) signing in
   even the usual case, and given the dangers described above, it is
   prohibited to automatically retry signature enchancement.

5.3.3.  Automatic MAC Authentication Retry

   Assuming that all the other conditions are followed, it is permissi-
   ble to automatically retry MAC authentication.

6.  Other Issues

6.1.  Compatibility of Servers with Old Clients

   Servers which receive requests in the clear which should be secured
   should return 'SecurityRetry 420' with header lines set to indicate
   the required privacy enhancements.

6.2.  URL Protocol Type

   We define a new URL protocol designator, 'shttp'. Use of this desig-
   nator as part of an anchor URL implies that the target server is S-
   HTTP capable, and that a dereference of this URL should undergo S-
   HTTP processing.

   Note that S-HTTP oblivious agents should not be willing to derefer-
   ence a URL with an unknown protocol specifier, and hence sensitive
   data will not be accidentally sent in the clear by users of non-
   secure clients.

6.3.  Server Conventions

6.3.1.  Certificate Requests

   We define the convention that issuing a normal HTTP request:

           GET /SERVER-CERTIFICATE[<B64-DN>] <http-version>

   shall cause the server to return the corresponding certificate.
   <B64-DN> is the base-64 encoding (to protect whitespace) of the
   fully-specified canonical ASCII form for the DN of the requested cer-
   tificate (as in RFC 1485). If no DN is specified, then the server
   shall choose whatever certificate it deems most appropriate. The
   server should sign the response with the key corresponding to the DN



Rescorla, Schiffman                                             [Page 30]Internet-Draft                Secure HTTP


   supplied.

6.3.2.  Policy Requests

   Servers should (but not must) store the policies of the Policy Cer-
   tification Authorities, if available, corresponding to their various
   certificates. The convention for retrieving such policies via HTTP is
   the request:

           GET /POLICY-<B64-DN> <http-version>

   Again, <B64-DN> is the DN (encoded as per section 6.3.1) of the cer-
   tificate corresponding to the requested policy. It is recommended
   that this document be (pre-) signed by the PCA.

6.3.3.  CRL Requests

   Servers should (but not must) store the CRLs of the PCAs correspond-
   ing to their various certificates. The convention for retrieving such
   CRLs is:

           GET /CRL-<B64-DN> <http-version>

   Again, <B64-DN> is the DN (encoded as per section 6.3.1) of the cer-
   tificate corresponding to the requested CRL.

6.4.  Browser Presentation

6.4.1.  Transaction Security Status

   While preparing a secure message, the browser should provide a visual
   indication of the security of the transaction, as well as an indica-
   tion of the party who will be able to read the message. While reading
   a signed and/or enveloped message, the browser should indicate this
   and (if applicable) the identity of the signer. Self-signed certifi-
   cates should be clearly differentiated from those validated by a cer-
   tification hierarchy.

6.4.2.  Failure Reporting

   Failure to authenticate or decrypt an S-HTTP message should be
   presented differently from a failure to retrieve the document. Com-
   pliant clients may at their option display unverifiable documents but
   must clearly indicate that they were unverifiable in a way clearly
   distinct from the manner in which they display documents which pos-
   sessed no digital signatures or documents with verifiable signatures.





Rescorla, Schiffman                                             [Page 31]Internet-Draft                Secure HTTP


6.4.3.  Certificate Management

   Clients shall provide a method for determining that HTTP requests are
   to be signed and for determining which (assuming there are many) cer-
   tificate is to be used for signature. It is suggested that users be
   presented with some sort of selection list from which they may choose
   a default. No signing should be performed without some sort of expli-
   cit user interface action, though such action may take the form of a
   persistent setting via a user preferences mechanism (although this is
   discouraged.)

6.4.4.  Anchor Dereference

   Clients shall provide a method to display the DN and certificate
   chain associated with a given anchor to be dereferenced so that users
   may determine for whom their data is being encrypted.  This should be
   distinct from the method for displaying who has signed the document
   containing the anchor since these are orthogonal pieces of encryption
   information.

7.  Implementation Notes

7.1.  Preenhanced Data

   While S-HTTP has always supported preenhanced documents, in previous
   versions it was never made clear how to actually implement them.
   This section describes two methods for doing so: preenhancing the
   HTTP request/response and preenhancing the underlying data.

7.1.1.  Motivation

   The two primary motivations for preenhanced documents are security
   and performance. These advantages primarily accrue to signing but may
   also under special circumstances apply to confidentiality or repudi-
   able (MAC-based) authentication.

   Consider the case of a server which repeatedly serves the same con-
   tent to multiple clients. One such example would be a server which
   serves catalogs or price lists. Clearly, customers would like to be
   able to verify that these are actual prices. However, since the
   prices are typically the same to all comers, confidentiality is not
   an issue. (Note: see Section 7.1.5 below for how to deal with this
   case as well).

   Consequently, the server might wish to sign the document once and
   simply send the cached signed document out when a client makes a new
   request, avoiding the overhead of a private key operation each time.
   Note that conceivably, the signed document might have been generated



Rescorla, Schiffman                                             [Page 32]Internet-Draft                Secure HTTP


   by a third party and placed in the server's cache. The server might
   not even have the signing key! This illustrates the security benefit
   of presigning: Untrusted servers can serve authenticated data without
   risk even if the server is compromised.

7.1.2.  Presigned Requests/Responses

   The obvious implementation is simply to take a single
   request/response, cache it, and send it out in situations where a new
   message would otherwise be generated.

7.1.3.  Presigned Documents

   It is also possible using S-HTTP to sign the underlying data and send
   it as an S-HTTP messsage. In order to do this, one would take the
   signed document (a PKCS-7 or MOSS message) and attach both S-HTTP
   headers (e.g. the S-HTTP request/response line, the Content-Privacy-
   Domain)  and  the necessary HTTP headers (including a Content-Type
   that reflects the inner content).

           SECURE * Secure-HTTP/1.2
           Content-Type: text/html
           Content-Privacy-Domain: PKCS-7
           Content-Transfer-Encoding: base64

           -----BEGIN PRIVACY-ENHANCED MESSAGE-----
           Random signed message here...
           -----END PRIVACY-ENHANCED MESSAGE-----


   This message itself cannot be sent, but needs to be recursively
   encapsulated, as described in the next section.

7.1.4.  Recursive Encapsulation

   As required by Section 7.3, the result above needs to be itself
   encapsulated to protect the HTTP headers. the obvious case [and the
   one illustrated here] is when confidentiality is required, but the
   auth enhancement or even the null transform might be applied instead.
   That is, the message shown above can be used as the inner content of
   a new S-HTTP message, like so:










Rescorla, Schiffman                                             [Page 33]Internet-Draft                Secure HTTP



        SECURE * Secure-HTTP/1.2
        Content-Type: application/s-http
        Content-Privacy-Domain: PKCS-7
        Content-Transfer-Encoding: base64

        -----BEGIN PRIVACY-ENHANCED MESSAGE-----
        Encrypted version of the message above...
        -----END PRIVACY-ENHANCED MESSAGE-----


   To unfold this, the receiver would decode the outer S-HTTP message,
   reenter the (S-)HTTP parsing loop to process the new message, see
   that that too was S-HTTP, decode that, and recover the inner content.

   Note that this approach can also be used to provide freshness of
   server activity (though not of the document itself) while still pro-
   viding nonrepudiation of the document data if a NONCE is included in
   the request.

7.1.5.  Preencrypted Messages

   Although preenhancement works best with signature, it can also be
   used with encryption under certain conditions. Consider the situation
   where the same confidential document is to be sent out repeatedly.
   The time spent to encrypt can be saved by caching the ciphertext and
   simply generating a new key exchange block for each recipient. [Note
   that this is logically equivalent to a multi- recipient message as
   defined in both MOSS and PKCS-7 and so care must be taken to use
   proper PKCS-1 padding if RSA is being used since otherwise, one may
   be open to a low encryption exponent attack.[HAST96]

7.2.  Proxy Interaction

   The use of S-HTTP presents implementation issues to the use of HTTP
   proxies. While simply having the proxy blindly forward responses is
   straightforward, it would be preferable if S-HTTP aware proxies were
   still able to cache responses in at least some circumstances. In
   addition, S-HTTP services should be usable to protect client-proxy
   authentication. This section describes how to achieve those goals
   using the mechanisms described above.

7.2.1.  Client-Proxy Authentication

   When an S-HTTP aware proxy receives a request (HTTP or S-HTTP) that
   (by whatever access control rules it uses) it requires to be S-HTTP
   authenticated (and if it isn't already so), it should return the 422
   response code (5.7.4).



Rescorla, Schiffman                                             [Page 34]Internet-Draft                Secure HTTP


   When the client receives the 422 response code, it should read the
   cryptographic options that the proxy sent and determine whether or
   not it is willing to apply that enhancement to the message. If the
   client is willing to meet these requirements, it should recursively
   encapsulate the request it previously sent using the appropriate
   options.  (Note that since the enhancement is recursively applied,
   even clients which are unwilling to send requests to servers in the
   clear may be willing to send the already encrypted message to the
   proxy without further encryption.) (See Section 7.1 for another exam-
   ple of a recursively encapsulated message)

   When the proxy receives such a message, it should strip the outer
   encapsulation to recover the message which should be sent to the
   server.

7.2.2.  Proxy Caching of S-HTTP Messages

   Although it is often considered that security in general and confi-
   dentiality in specific obviate caching, this is only true under cer-
   tain circumstances. For example, when confidentiality is being used
   to restrict access to some class of documents to a broad class of
   users, and those users are behind a single proxy, it is obviously
   advantageous if that proxy can cache such documents. S-HTTP's message
   orientation makes this a fairly straightforward proposition, provided
   that the parties cooperate.

7.2.2.1.  Client Behavior

   All the client needs to do is to provide enough URL information to
   the proxy to enable the proxy to detect when potentially cached data
   is being requested. In order to do this, the client simply provides
   the whole URL HTTP style instead of the URI-less URL described in
   Section 2.1. Note that this provides the proxy with the URI. Conse-
   quently, clients which don't trust their proxy to receive that infor-
   mation or are worried about traffic analysis by the proxy should not
   enable caching in this way. (An insecure channel to the proxy can be
   defended against using a recursive encapsulation.)

7.2.2.2.  Proxy Behavior

   When forwarding requests, the proxy merely needs to recognize URLs
   that are in it's cache and add the If-Modified-Since header as it
   does for HTTP.

   When forwarding responses, the proxy needs to detect the 320 response
   and reassemble a valid S-HTTP response from the cached data and the
   new keying material provided by the server. The proxy should check
   the Content-MD5 header if supplied to ensure that a valid cache hit



Rescorla, Schiffman                                             [Page 35]Internet-Draft                Secure HTTP


   has occurred and retry the request minus the If-Modified-Since header
   if the Content-MD5s do not match.

7.2.2.3.  Server Behavior

   The server needs to detect the If-Modified-Since header provided by
   the proxy and generate the content-less message described in 5.2.5,
   if the document has not been modified since the time the header.

8.  Implementation Recommendations and Requirements

   All S-HTTP agents must support the MD5 message digest and MAC authen-
   tication. As of S-HTTP/1.2, all agents must also support the RSA-
   MD5-HMAC construction.

   All S-HTTP agents must support Outband key exchange.

   Support for encryption is recommended; agents which implement encryp-
   tion must support the in-band key exchange method and one of the fol-
   lowing three cryptosystems (in ECB and CBC modes): DES, RC2[40] and
   CDMF.

   Agents are recommended to support signature verification; server sup-
   port of signature generation is additionally recommended.  Agents
   which implement either signing or verification should support the RSA
   algorithm.

   Note that conformant implementations of the protocol (although not
   recommended ones) can avoid the use of public key cryptography
   entirely.

9.  Protocol Syntax Summary

   We present below a summary of the main syntactic features of S-
   HTTP/1.2, excluding message encapsulation proper.

9.1.  S-HTTP (Unencapsulated) Headers

   Content-Privacy-Domain: ('PKCS-7' | 'MOSS')
   Content-Transfer-Encoding: ('8BIT' | '7BIT' | 'BASE64')
   Prearranged-Key-Info: <Hdr-Cipher>,<Key>,<Key-ID>
   Content-Type: 'application/http'
   MAC-Info: [hex(timeofday)',']<hash-alg>','hex(<hash-data>)','
           <key-spec>

9.2.  HTTP (Encapsulated) Non-negotiation Options

   Key-Assign: <Method>','<Key-Name>','<Lifetime>','



Rescorla, Schiffman                                             [Page 36]Internet-Draft                Secure HTTP


           <Ciphers>';'<Method-args>
   Encryption-Identity: <name-class>','<key-sel>','<name-args>
   Certificate-Info: <Cert-Fmt>','<Cert-Group>
   Nonce: <string>
   Nonce-Echo: <string>

9.3.  Encapsulated Negotiation Options

   SHTTP-Cryptopts: <scope>';'<string>(,<string>)*
   SHTTP-Privacy-Domains: ('PKCS-7' | 'MOSS')
   SHTTP-Certificate-Types: ('X.509')
   SHTTP-Key-Exchange-Algorithms: ('RSA' | 'KRB-'<kv>)
   SHTTP-Signature-Algorithms: ('RSA' | 'NIST-DSS')
   SHTTP-Message-Digest-Algorithms: ('RSA-MD2' | 'RSA-MD5' | 'NIST-SHS'
           'RSA-MD2-HMAC', 'RSA-MD5-HMAC', 'NIST-SHS-HMAC')
   SHTTP-Symmetric-Content-Algorithms: ('DES-CBC' | 'DES-EDE-CBC' |
           'DES-EDE3-CBC' | 'DESX-CBC' | 'CDMF-CBC' | 'IDEA-CBC' |
           'RC2-CBC' )
   SHTTP-Symmetric-Header-Algorithms: ('DES-ECB' | 'DES-EDE-ECB' |
           'DES-EDE3-EBC' | 'DESX-ECB' | 'CDMF-ECB' |
           'IDEA-ECB' | 'RC2-ECB')
   SHTTP-Privacy-Enhancements: ('sign' | 'encrypt' | 'auth')
   Your-Key-Pattern: <key-use>','<pattern-info>

9.4.  HTTP Methods

   Secure * Secure-HTTP/1.2

9.5.  Server Status Reports

   Secure-HTTP/1.2 200 OK
   SecurityRetry 420
   BogusHeader 421 <reason>

9.6.  Server Conventions

   GET SERVER-CERTIFICATE-<B64-DN> <http-version>
   GET POLICY-<B64-DN> <http-version>
   GET CRL-<B64-DN> <http-version>

10.  An Extended Example

   We provide here a contrived example of a series of S-HTTP requests
   and replies. Rows of equal signs are used to set off the narrative
   from sample message traces. Note that, since we use base-64 encoding
   here for expository purposes, the example messages have the otherwise
   unnecessary MOSS-style "BEGIN/END PRIVACY-ENHANCED MESSAGE" delim-
   iters.



Rescorla, Schiffman                                             [Page 37]Internet-Draft                Secure HTTP


10.1.  A request using RSA key exchange with Inband key reply

   Alice, using an S-HTTP-capable client, begins by making an HTTP
   request which yields the following response page:
   ============================================================
   200 OK HTTP/1.0
   Server-Name: Navaho-0.1.2.3alpha
   Certificate-Info: PKCS7,MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqh
           kiG9w0BBwEAAKCAM
           IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH
           gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc
           29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N
           TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e
           SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA
           xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q
           cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDElX/qw9mIQu4xNj1FfepfJNx
           zPvA0OtMKhy6+bkrlyMEU8CAwEAATANBgkqhkiG9w0BAQIFAANPAAYn7jDgi
           rhiIL4wnP8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN78vAMGP8d8
           2H5+Ndfhi2mRp4YHiGHz0HlK6VbPfnyvS2wdjCCAccwggFRAgUCQAAAFDANB
           gkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhd
           GEgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd
           GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwMTA3MDAwMDAwWhcNOTYwMTA3M
           jM1OTU5WjBNMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2Vjd
           XJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydGlmaWNhdGUwaTANB
           gkqhkiG9w0BAQEFAANYADBVAk4GqghQDa9Xi/2zAdYEqJVIcYhlLN1FpI9tX
           Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBi+A
           QvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc
           PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM
           Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA
           AAAAA==
   Encryption-Identity: DN-1485, null, CN=Setec Astronomy, OU=Persona
           Certificate,O="RSA Data Security, Inc.", C=US;
   SHTTP-Privacy-Enhancements: recv-required=encrypt

   <A name=tag1 HREF="shttp://www.setec.com/secret">
   Don't read this. </A>
   ============================================================

   An appropriate HTTP request to dereference this URL would be:
   ============================================================
   GET /secret HTTP/1.0
   Security-Scheme: S-HTTP/1.2
   User-Agent: Web-O-Vision 1.2beta
   Accept: *.*
   Key-Assign: Inband,1,reply,des-ecb;7878787878787878

   ============================================================




Rescorla, Schiffman                                             [Page 38]Internet-Draft                Secure HTTP


   The added Key-Assign line that would not have been in an ordinary
   HTTP request permits Bob (the server) to encrypt his reply to Alice,
   even though Alice does not have a public key, since they would share
   a key after the request is received by Bob.  This request has the
   following S-HTTP encapsulation:
   ============================================================
   Secure * Secure-HTTP/1.2
   Content-Transfer-Encoding: base64
   Content-Type: application/http
   Content-Privacy-Domain: PKCS-7

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBqQIBADBTME0xCzAJBgNVBAYTAlVTMSAw
   HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29u
   YSBDZXJ0aWZpY2F0ZQICALYwDQYJKoZIhvcNAQEBBQAEQCU/R+YCJSUsV6XLilHG
   cNVzwqKcWzmT/rZ+duOv8Ggb7oO/d8H3xUVGQ2LsX4kYGq2szwj8Q6eWhsmhf4oz
   lvMAADCABgkqhkiG9w0BBwEwEQYFKw4DAgcECFif7BadXlw3oIAEgZBNcMexKe16
   +mNxx8YQPukBCL0bWqS86lvws/AgRkKPELmysBi5lco8MBCsWK/fCyrnxIRHs1oK
   BXBVlsAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW
   Op2gcgUtMJq6k2LFrs4L7HHqRPPlqNJ6j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k
   1JLSAAAAAAAAAAAAAA==
   -----END PRIVACY-ENHANCED MESSAGE-----
   ============================================================

   The data between the delimiters is a PKCS-7 message, RSA enveloped
   for Setec Astronomy.

   Bob decrypts the request, finds the document in question, and is
   ready to serve it back to Alice.

   An appropriate HTTP server response would be:
   ============================================================
   HTTP/1.0 200 OK
   Security-Scheme: S-HTTP/1.2
   Content-Type: text/html

   Congratulations, you've won.
   <A href="/prize.html"
    CRYPTOPTS="Key-Assign: Inband,alice1,reply,des-ecb;020406080a0c0e0f;
    SHTTP-Privacy-Enhancements: recv-required=auth">Click here to
   claim your prize</A>
   ============================================================

   This HTTP response, encapsulated as an S-HTTP message becomes:







Rescorla, Schiffman                                             [Page 39]Internet-Draft                Secure HTTP


   ============================================================
   Secure * Secure-HTTP/1.2
   Content-Transfer-Encoding: base64
   Content-Type: application/http
   Prearranged-Key-Info: des-ecb,697fa820df8a6e53,inband:1
   Content-Privacy-Domain: PKCS-7

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   MIAGCSqGSIb3DQEHBqCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsOAwIHBAifqtdy
   x6uIMYCCARgvFzJtOZBn773DtmXlx037ck3giqnV0WC0QAx5f+fesAiGaxMqWcir
   r9XvT0nT0LgSQ/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTT0TyL9uydG3w55vTnW
   aPbCPCWLudArI1UHDZbnoJICrVehxG/sYX069M8v6VO8PsJS7//hh1yM+0nekzQ5
   l1p0j7uWKu4W0csrlGqhLvEJanj6dQAGSTNCOoH3jzEXGQXntgesk8poFPfHdtj0
   5RH4MuJRajDmoEjlrNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5nlCK87tXl
   nL7DJwaPRYwxb3mnPKNq7ATiJPf5u162MbwxrddmiE7e3sST7naSN+GS0ateY5X7
   AAAAAAAAAAA=
   -----END PRIVACY-ENHANCED MESSAGE-----
   ============================================================

   The data between the delimiters is a PKCS7 message encrypted under a
   randomly-chosen DEK which can be recovered by computing:

           DES-DECRYPT(inband:1,697fa820df8a6e53)

   where 'inband:1' is the key exchanged in the Key-Assign line in the
   original request.

10.2.  A request using the auth enhancement

   There is a link on the HTML page that was just returned, which Alice
   dereferences, creating the HTTP message:
   ============================================================
   GET /prize.html HTTP/1.0
   Security-Scheme: S-HTTP/1.2
   User-Agent: Web-O-Vision 1.1beta
   Accept: *.*

   ============================================================

   Which, when encapsulated as an S-HTTP message, becomes:











Rescorla, Schiffman                                             [Page 40]Internet-Draft                Secure HTTP


   ============================================================
   Secure * Secure-HTTP/1.2
   Content-Transfer-Encoding: base64
   Content-Type: application/http
   MAC-Info:31ff8122,rsa-md5,b3ca4575b841b5fc7553e69b0896c416,inband:alice1
   Content-Privacy-Domain: PKCS-7

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   MIAGCSqGSIb3DQEHAaCABGNHRVQgL3ByaXplLmh0bWwgSFRUUC8xLjAKU2VjdXJp
   dHktU2NoZW1lOiBTLUhUVFAvMS4xClVzZXItQWdlbnQ6IFdlYi1PLVZpc2lvbiAx
   LjFiZXRhCkFjY2VwdDogKi4qCgoAAAAA
   -----END PRIVACY-ENHANCED MESSAGE-----
   ============================================================

   The data between the delimiters is a PKCS-7 'Data' representation of
   the request.



































Rescorla, Schiffman                                             [Page 41]Internet-Draft                Secure HTTP


Appendix: A Review of PKCS-7

   PKCS-7 ("Cryptographic Message Syntax Standard") is a cryptographic
   message encapsulation format, similar to PEM, which was defined by
   RSA Laboratories as part of a family of related standards. They
   state: "The PKCS standards are offered by RSA Laboratories to
   developers of computer systems employing public key cryptography.  It
   is RSA Laboratories' intention to improve and refine the standards in
   conjunction with computer system developers, with the goal of produc-
   ing standards that most if not all developers adopt."

   PKCS-7 is only one of two encapsulation formats supported by S-HTTP,
   but it is to be preferred since it permits the least restricted set
   of negotiable options, and permits binary encoding.  In the interest
   of making this specification more self-contained, we summarize PKCS-7
   here.

   PKCS-7 is a superset of PEM, in that PEM messages can be converted to
   PKCS-7 messages without any cryptographic operations, and vice-versa
   (given PKCS-7 messages which are restricted to PEM facilities).
   Additionally, PEM key management materials such as certificates and
   certificate revocation lists are compatible with PKCS-7's.

   PKCS-7 is defined in terms of OSI's Abstract Syntax Notation (ASN.1,
   defined in X.208), and is concretely represented using ASN.1's Basic
   Encoding Rules (BER, defined in X.209).  A PKCS-7 message is a
   sequence of typed content parts. There are six content types, recur-
   sively composable:

        Data -- Some bytes, with no enhancement.

        SignedData -- A content part, with zero or more signature
        blocks, and associated keying materials. Keying materials
        can be transported via the degenerate case of no signature
        blocks and no data.

        EnvelopedData -- One or more (per recipient) key exchange
        blocks and an encrypted content part.

        SignedAndEnvelopedData -- The obvious combination of
        SignedData and EnvelopedData for a single content part.

        DigestedData -- A content part with a single digest block.

        EncryptedData -- An encrypted content part, with key
        materials externally provided.

   Here we will dispense with convention for the sake of ASN.1-impaired



Rescorla, Schiffman                                             [Page 42]Internet-Draft                Secure HTTP


   readers, and present a syntax for PKCS-7 in informal BNF (with much
   gloss).  In the actual encoding, most productions have explicit tag
   and length fields.

   <Message> := (<Content>)+
   <Content> := <Data> | <SignedData> | <EnvelopedData> |
                   <SignedAndEnvelopedData> |
                   <DigestedData> | <EncryptedData>
   <Data> := <Bytes>
   <SignedData> := <DigestAlg>* <Content> <Certificates>*
                    <CRLs>* <SignerInfo>*
   <EnvelopedData> := <RecipientInfo>+ <BulkCryptAlg>
                   Encrypted(<Content>)
   <SignedAndEnvelopedData> := <RecipientInfo>* <DigestAlg>*
                   <EncryptedData> <Certificates>*
                   <CRLs>* <SignerInfos>*
   <DigestedData> := <DigestAlg> <Content> <DigestBytes>
   <EncryptedData> := <BulkCryptAlg> Encrypted(<Bytes>)
   <SignerInfo> := <CertID> ... Encrypted(<DigestBytes>) ...
   <RecipientInfo> := <CertID> <KeyCryptAlg> Encrypted(<DEK>)































Rescorla, Schiffman                                             [Page 43]Internet-Draft                Secure HTTP


Bibliography and References
   [BELL96] Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash Functions for
        Message Authentication", Preprint.

   [BERN95a] Berners-Lee, T., Connolly, D., "Hypertext Markup Language - 2.0",
        draft-ietf-html-spec-04, June 1995 (working draft)

   [BERN95b] Berners-Lee, T., Fielding, R. T., Nielsen, H., "Hypertext
        Transfer Protocol -- HTTP/1.0", draft-ietf-http-v10-spec-00,
        March 1995. (working draft)

   [FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB)
        46-1, Data Encryption Standard, Reaffirmed 1988 January 22
        (supersedes FIPS PUB 46, 1977 January 15).

   [FIPS-81] Federal Information Processing Standards Publication (FIPS PUB)
        81, DES Modes of Operation, 1980 December 2.

   [FIPS-180] Federal Information Processing Standards Publication (FIPS PUB)
       180-1, "Secure Hash Standard", 1995 April 17.

   [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB)
        186, Digital Signature Standard, 1994 May 19.

   [HAST86] Hastad, J., "On Using RSA With Low Exponents in a Public Key
        Network," Advances in Cryptology-CRYPTO 95 Proceedings,
        Springer-Verlag, 1986.

   [JOHN93] Johnson, D.B., Matyas, S.M., Le, A.V., Wilkins, J.D., "Design of the
        Commercial Data Masking Facility Data Privacy Algorithm," Proceedings
        1st ACM Conference on Computer & Communications Security,
        November 1993, Fairfax, VA., pp. 93-96.

   [KRAW96a] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: Keyed-MD5 for
        Message Authentication", draft-ietf-ipsec-hmac-md5-00.txt, March 1996.

   [KRAW96b] Krawczyk, H. personal communication.

   [LAI92] Lai, X. "On the Design and Security of Block Ciphers," ETH Series in
        Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.

   [PKCS-6] RSA Data Security, Inc. "Extended Certificate Syntax Standard",
       PKCS-6, Nov 1, 1993.

   [PKCS-7] RSA Data Security, Inc. "Cryptographic Message Syntax Standard",
       PKCS-7, Nov 1, 1993.

   [RFC-822] Crocker, D. "Standard For The Format Of ARPA Internet Text Messages",



Rescorla, Schiffman                                             [Page 44]Internet-Draft                Secure HTTP


        RFC822, August 1982.

   [RFC-1319] Kaliski, B. "The MD2 Message-Digest Algorithm", RFC1319, April 1992

   [RFC-1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC1321, April 1992

   [RFC-1421] Linn J. "Privacy Enhancement for Internet Electronic Mail:
       Part I: Message Encryption and Authentication Procedures",
       RFC1421, Feb 1993.

   [RFC-1422] Kent, S. "Privacy Enhancement for Internet Electronic Mail:
       Part II: Certificate-Based Key Management", RFC1422, Feb 1993.

   [RFC-1485] Hardcastle-Kille, S. "A String Representation of Distinguished
       Names", RFC1485, July 1993.

   [RFC-1510] Kohl, J., and Neuman, C., "The Kerberos Authentication Service
        (V5)", RFC1510, September 1993.

   [RFC-1521] Borenstein, N., Freed, N., "MIME (Multipurpose Internet
        Mail Extensions) Part One: Mechanisms for Specifying and Describing
        the Format of Internet Message Bodies", RFC-1521, September 1993.

   [RFC-1738] Berners-Lee, T. "Uniform Resource Locators (URLs)", RFC1738,
        Dec 1994

   [RFC-1847] Galvin, J., Murphy, S., Crocker, S., Freed, N.,
        "Security Muliparts for MIME: Multipart/Signed and Multipart/Encrypted",
         RFC-1847, October 1995.

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

   [RFC-1864] Myers, J.  Rose, M. "The Content-MD5 Header Field", 10/24/1995.
        RFC1864, October 1995.

   [SHTML] Rescorla, E., Schiffman, A., "Security Extensions For HTML",
        draft-ietf-wts-shtml-02.txt.

   [VANO95] B. Prennel and P. van Oorschot, "On the security of two MAC
        algorithms", to appear Eurocrypt'96.

   [X509] CCITT Recommendation X.509 (1988), "The Directory -
       Authentication Framework".



Security Considerations



Rescorla, Schiffman                                             [Page 45]Internet-Draft                Secure HTTP


   This entire document is about security.

Acknowledgements

   The authors wish to thank our colleagues at Terisa Systems, Enter-
   prise Integration, Technologies, RSA Data Security, TIS, MCI, BBN, HP
   Labs Bristol, NCSA, Spyglass, MIT, CERN, Open Market, Spry, Digital,
   W3C and elsewhere for their review of earlier drafts. We also wish to
   thank the many users who shared their experience with the S-HTTP
   reference implementation distributed by the CommerceNet Consortium.

   This work was initiated at Enterprise Integration Technologies Cor-
   poration and funded in part by the ARPA MADE (Manufacturing Automa-
   tion and Design Engineering) program, under contract management by
   the USAF Wright Laboratory.  In addition to the funding support, we
   appreciate the administrative and intellectual resources of the spon-
   sors and the research community they maintain.

Authors' Address

Eric Rescorla <[e-mail]>
Terisa Systems, Inc.
4984 El Camino Real
Los Altos, CA 94022
Phone: [phone]

Allan M. Schiffman <[e-mail]>
Terisa Systems, Inc.
4984 El Camino Real
Los Altos, CA 94022
Phone: [phone]




















Rescorla, Schiffman                                             [Page 46]Internet-Draft                Secure HTTP





                           Table of Contents




1. Introduction ...................................................    2

1.1. Summary of Features ..........................................    2

1.2. Changes ......................................................    3

1.3. Processing Model .............................................    3

1.4. Modes of Operation ...........................................    5

1.5. Implementation Options .......................................    6

2. Message Format .................................................    6

2.1. The Request Line .............................................    7

2.2. The Status Line ..............................................    7

2.3. Secure HTTP Header Lines .....................................    7

2.3.2. Content-Transfer-Encoding ..................................    8

2.4. Content ......................................................   11

2.5. Encapsulation Format Options .................................   12

2.5.1. Content-Privacy-Domain: PKCS-7 .............................   12

2.5.2. Content-Privacy-Domain: MOSS ...............................   13

2.5.3. Imported HTTP headers ......................................   14

2.5.3.2. Connection: Keep-Alive ...................................   14

2.5.3.3. If-Modified-Since ........................................   14

2.5.3.4. Content-MD5 ..............................................   15

3. Cryptographic Parameters .......................................   15




Rescorla, Schiffman                                             [Page 47]Internet-Draft                Secure HTTP


3.1. Options Headers ..............................................   15

   3.2. Negotiation Options .......................................   15

   3.2.1. Negotiation Overview ....................................   15

3.2.2. Negotiation Option Format ..................................   16

3.2.3. Parametrization for Variable-length Key Ciphers ............   17

3.2.4. Negotiation Syntax .........................................   18

3.3. Non-Negotiation Headers ......................................   22

3.3.1. Encryption-Identity ........................................   22

3.3.2. Certificate-Info ...........................................   23

3.3.4. Nonces .....................................................   25

3.4. Grouping Headers With SHTTP-Cryptopts ........................   25

3.4.1. SHTTP-Cryptopts ............................................   25

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 ......................................   27

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. Server Conventions ...........................................   30

6.4. Browser Presentation .........................................   31

7. Implementation Notes ...........................................   32




Rescorla, Schiffman                                             [Page 48]Internet-Draft                Secure HTTP


7.1. Preenhanced Data .............................................   32

7.2. Note:Proxy Interaction .......................................   34

7.2.1. Client-Proxy Authentication ................................   34

7.2.2. Proxy Caching of S-HTTP Message ............................   35

8. Implementation Recommendations and Requirements ................   36

9. Protocol Syntax Summary ........................................   36

10. An Extended Example ...........................................   37

Appendix: A Review of PKCS-7 ......................................   42

Bibliography and References .......................................   44

Security Considerations ...........................................   45

Acknowledgements ..................................................   46

Authors' Address ..................................................   46