rfc2660.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,642 行 · 第 1/5 页

   Note that some Content-Privacy-Domains, notably likely future
   revisions of MOSS and CMS may have support for symmetric integrity
   protection The MAC-Info field need not be used in such circumstances.
   Rather, the native syntax is preferred. Keys exchanged with Key-
   Assign, however, may be used in this situation.

2.5.  Content

   The content of the message is largely dependent upon the values of
   the Content-Privacy-Domain and Content-Transfer-Encoding fields.




Rescorla & Schiffman          Experimental                     [Page 12]

RFC 2660         The Secure HyperText Transfer Protocol      August 1999


   For a CMS message, with '8BIT' Content-Transfer-Encoding, the content
   should simply be the CMS message itself.

   If the Content-Privacy-Domain is MOSS, the content should consist of
   a MOSS Security Multipart as described in RFC1847.

   It is expected that once the privacy enhancements have been removed,
   the resulting (possibly protected) contents will be a normal HTTP
   request. Alternately, the content may be another Secure-HTTP message,
   in which case privacy enhancements should be unwrapped until clear
   content is obtained or privacy enhancements can no longer be removed.
   (This permits embedding of enhancements, such as sequential Signed
   and Enveloped enhancements.) Provided that all enhancements can be
   removed, the final de-enhanced content should be a valid HTTP request
   (or response) unless otherwise specified by the Content-Type line.

   Note that this recursive encapsulation of messages potentially
   permits security enhancements to be applied (or removed) for the
   benefit of intermediaries who may be a party to the transaction
   between a client and server (e.g., a proxy requiring client
   authentication).  How such intermediaries should indicate such
   processing is described in Section 7.2.1.

2.6.  Encapsulation Format Options

2.6.1.  Content-Privacy-Domain: CMS

   Content-Privacy-Domain 'CMS' follows the form of the CMS standard
   (see Appendix).

   Message protection may proceed on two orthogonal axes: signature and
   encryption. Any message may be either signed, encrypted, both, or
   neither. Note that the 'auth' protection mode of S-HTTP is provided
   independently of CMS coding via the MAC-Info header of section 2.3.6
   since CMS does not support a 'KeyDigestedData' type, although it does
   support a 'DigestedData' type.

2.6.1.1.  Signature

   This enhancement uses the 'SignedData' type of CMS.  When digital
   signatures are used, an appropriate certificate may either be
   attached to the message (possibly along with a certificate chain) as
   specified in CMS or the sender may expect the recipient to obtain its
   certificate (and/or chain) independently.  Note that an explicitly
   allowed instance of this is a certificate signed with the private
   component corresponding to the public component being attested to.
   This shall be referred to as a self-signed certificate. What, if any,
   weight to give to such a certificate is a purely local matter.  In



Rescorla & Schiffman          Experimental                     [Page 13]

RFC 2660         The Secure HyperText Transfer Protocol      August 1999


   either case, a purely signed message is precisely CMS compliant.

2.6.1.2.  Encryption

2.6.1.2.1.  Encryption -- normal, public key

   This enhancement is performed precisely as enveloping (using either '
   EnvelopedData' types) under CMS. A message encrypted in this fashion,
   signed or otherwise, is CMS compliant. To have a message which is
   both signed and encrypted, one simply creates the CMS SignedData
   production and encapsulates it in EnvelopedData as described in CMS.

2.6.1.2.2.  Encryption -- prearranged key

   This uses the 'EncryptedData' type of CMS. In this mode, we encrypt
   the content using a DEK encrypted under cover of a prearranged
   session key (how this key may be exchanged is discussed later), with
   key identification information specified on one of the header lines.
   The IV is in the EncryptedContentInfo type of the EncryptedData
   element.  To have a message which is both signed and encrypted, one
   simply creates the CMS SignedData production and encapsulates it in
   EncryptedData as described in CMS.

2.6.2.  Content-Privacy-Domain: MOSS

   The body of the message should be a MIME compliant message with
   content 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.

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

2.6.3.  Permitted HTTP headers

2.6.3.1.  Overview

   In general, HTTP [RFC-2616] headers should appear in the inner
   content (i.e. the message/http) of an S-HTTP message but should not
   appear in the S-HTTP message wrapper for security reasons. However,
   certain headers need to be visible to agents which do not have access
   to the encapsulated data. These headers may appear in the S-HTTP
   headers as well.



Rescorla & Schiffman          Experimental                     [Page 14]

RFC 2660         The Secure HyperText Transfer Protocol      August 1999


   Please note that although brief descriptions of the general purposes
   of these headers are provided for clarity, the definitive reference
   is [RFC-2616].

2.6.3.2.  Host

   The host header specificies the internet host and port number of the
   resource being requested. This header should be used to disambiguate
   among multiple potential security contexts within which this message
   could be interpreted. Note that the unwrapped HTTP message will have
   it's own Host field (assuming it's an HTTP/1.1 message). If these
   fields do not match, the server should respond with a 400 status
   code.

2.6.3.3.  Connection

   The Connection field has precisely the same semantics in S-HTTP
   headers as it does in HTTP headers. This permits persistent
   connections to be used with S-HTTP.

3.  Cryptographic Parameters

3.1.  Options Headers

   As described in Section 1.3.2, every S-HTTP request is (at least
   conceptually) 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
   keying material) which may be of use to the sender when enhancing a
   message.

   Binding cryptographic options to anchors using HTML extensions is the
   topic of the companion document [SHTML] and will not be treated here.










Rescorla & Schiffman          Experimental                     [Page 15]

RFC 2660         The Secure HyperText Transfer Protocol      August 1999


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

   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             ; This is represented as one
                                           ; token without whitespace
           Mode = "orig" | "recv"
           Action = "optional" | "required" | "refused"





Rescorla & Schiffman          Experimental                     [Page 16]

RFC 2660         The Secure HyperText Transfer Protocol      August 1999


   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
   interpretation 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 messages
        without the enhancement.

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

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

   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.












Rescorla & Schiffman          Experimental                     [Page 17]

RFC 2660         The Secure HyperText Transfer Protocol      August 1999


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

           <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