rfc2660.txt

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

   2.3.1. Acceptable values are as listed there. For instance,

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

   would indicate that the agent always generates CMS compliant
   messages, but can read CMS 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 'DH', 'RSA', 'Outband' and 'Inband'. DH refers to
   Diffie-Hellman X9.42 style enveloping. [DH] RSA refers to RSA
   enveloping. Outband refers to some sort of external key agreement.



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


   Inband refers to section 3.3.3.1.

   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, DH;
                                         recv-required=DH

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
   syntax of section 3.2.3 should be used.  Note that a key length
   specification may interact with the acceptability of a given
   certificate, since keys (and their lengths) are specified in public-
   key certificates.

3.2.4.5.  SHTTP-Message-Digest-Algorithms

   This indicates what message digest algorithms may be used.
   Previously defined values are 'RSA-MD2' [RFC-1319], 'RSA-MD5' [RFC-
   1321], 'NIST-SHS' [FIPS-180].

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









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


3.2.4.7.  SHTTP-Symmetric-Header-Algorithms

   This header specifies the symmetric-key cipher used to encrypt
   message 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
   providing a symmetric key MAC. 'RSA-MD2', 'RSA-MD5' and 'NIST-SHS'
   persist 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
   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 =
                "Your-Key-Pattern" ":" key-use "," pattern-info
        key-use = "cover-key" | "auth-key" | "signing-key"










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


3.2.4.10.1.  Cover Key Patterns

   This header specifies desired values for key names used for
   encryption 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
   authenticators.  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-1779'.  This parameter
   specifies desired values for fields of Distinguished Names.  DNs are
   considered to be represented as specified in RFC1779, the order of
   fields and whitespace between fields is not significant.

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

   Pattern-data is a modified RFC1779 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
   subordination). 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.








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


   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
   certified by the RSA Persona CA (which uses name subordination) one
   could use the expression below.  Note the use of RFC1779 quoting to
   protect the comma (an RFC1779 field separator) and the POSIX 1003.2
   quoting to protect the dot (a regular expression metacharacter).

      Your-Key-Pattern: signing-key, DN-1779,
                   /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, CMS;
              orig-required=CMS
        SHTTP-Certificate-Types: recv-optional=X.509;
              orig-required=X.509
        SHTTP-Key-Exchange-Algorithms: recv-required=DH;
              orig-optional=Inband,DH
        SHTTP-Signature-Algorithms: orig-required=NIST-DSS;
              recv-required=NIST-DSS
        SHTTP-Privacy-Enhancements: orig-required=sign;
              orig-optional=encrypt

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
   explicitly overridden.

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

        SHTTP-Privacy-Domains: orig-optional=CMS;
                               recv-optional=CMS
        SHTTP-Certificate-Types: orig-optional=X.509;
                                 recv-optional=X.509
        SHTTP-Key-Exchange-Algorithms: orig-optional=DH,Inband,Outband;



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


                                       recv-optional=DH,Inband,Outband
        SHTTP-Signature-Algorithms: orig-optional=NIST-DSS;
                                    recv-optional=NIST-DSS
        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
   identify 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
   explicitly permits return encryption under (say) public key without
   the other agent signing first (or under a different key than that of
   the signature). The syntax of the Encryption-Identity line is:

           Encryption-Identity =
                   "Encryption Identity" ":" name-class,key-sel,name-arg
           name-class = "DN-1779" | 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 MOSS. In
   addition to the MOSS name forms of RFC1848, we add the DN-1779 name
   form to represent a more convenient form of distinguished name.

3.3.1.1.  DN-1779 Name Class

   The argument is an RFC-1779 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.



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


   Defined values are 'PEM' and 'CMS'. CMS certificate groups are
   provided as a base-64 encoded CMS 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 =
                "Key-Assign" ":" Method "," Key-Name ","
                Lifetime "," Ciphers ";" Method-args

        Key-name = string
        Lifetime = "this" | "reply" | ""
        Method ="inband"