rfc2660.txt

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

        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
   applicable (see the list of header ciphers in section 3.2.4.7). The
   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
   indefinite number of transactions.

   Method should be one of a number of key exchange methods.  The only
   currently defined value is 'inband' referring to Inband keys (i.e.,
   direct assignment).





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


   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
   specification as Key-IDs, which have the syntax:

        Key-ID = method ":" key-name

3.3.3.1.  Inband Key Assignment

   This refers to the direct assignment of an uncovered key to a
   symbolic 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
   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.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.




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


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
   Cryptopts 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:

SHTTP-Cryptopts =
                   "SHTTP-Cryptopts" ":" scope ";" cryptopt-list
scope = "scope="<tag-spec>    ; This is all one token without whitespace
tag-spec = tag *("," tag) | ""
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=cms; recv-optional=cms,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
   permits other agents to detect that they are communicating with an
   S-HTTP compliant agent and generate the appropriate cryptographic



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


   options headers.

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

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.

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









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


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
   performed 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
   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
   indicates 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
   indicates that the request should be retried using S-HTTP and the
   cryptographic 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






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


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
   interaction where the proxy has placed the If-Modified-Since header
   in the S-HTTP headers of its request. This response indicates that
   the following 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 CMS message
   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
   precautions 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.







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


5.3.1.  Automatic Encryption Retry

   This shows one possible danger of automatic retries -- potential
   compromise of encrypted information. While it is impossible to
   consider all possible cases, clients should never automatically
   reencrypt 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 reci