rfc1898.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   which is then encrypted, electronically signed by the merchant, and
   sent to the CyberCash Server.  (See CM1 & CM2 messages.)  The
   CyberCash Server can authenticate all the signatures and be sure that
   the customer and merchant agree on the invoice and charge amount.
   The CyberCash Server then forwards the relevant information to the



Eastlake, et al              Informational                      [Page 6]

RFC 1898                 CyberCash Version 0.8             February 1996


   acquiring bank along with a request on behalf of the merchant for a
   specific banking operation such as charge authorization.  The bank
   decrypts and then processes the received data as it would normally
   process a credit card transaction.  The bank's response is returned
   to the CyberCash Server which returns an electronic receipt to the
   merchant (see CM6 message) part of which the merchant is expected to
   forward to the customer (see CH2 message).  The transaction is
   complete.

2. General Message Wrapper Format

   Version 0.8 of the external format for the encoding of CyberCash
   messages is described below.  CyberCash messages are stylized
   documents for the transmission of financial data over the Internet.

   While there are numerous schemes for sending information over the
   Internet (HTTP, SMTP, and others), each is attached to a specific
   transmission mechanism.  Because CyberCash messages will need to
   travel over each of these media (as well as others) a transmission
   independent mechanism is needed.

2.1 Message Format

   CyberCash messages consist of the following components:

   1. Header - defines the start of the CyberCash message and includes
      version information.

   2. Transparent Part - contains information that is not private.

   3. Opaque Part(s) - contains the financial information in the
      message and is both privacy protected as well as tamper protected.
      An opaque part is not present in some messages. When present, the
      opaque part usually provides tamper protection for the transparent
      part.

   4. Trailer - defines the end of the CyberCash message and includes a
      check value to enable the receiver to determine that the message
      has arrived undamaged. Note: this check value is intended only to
      detect accidental damage to the message, not deliberate tampering.

      No null characters (zero value) or characters with the eighth bit
      on are permitted inside a CyberCash message.  "Binary" quantities
      that might have such byte values in them are encoded in base64 as
      described in RFC 1521.






Eastlake, et al              Informational                      [Page 7]

RFC 1898                 CyberCash Version 0.8             February 1996


2.2 Details of Format

   The header consists of a single line which looks approximately like
   this

        $$-CyberCash-0.8-$$

   or like this

        $$-CyberCash-1.2.3-Extra-$$

   It includes a number of fields separated with the minus character "-"

   1. "$$" - the literal string with the initial $ in column 1.

   2. "CyberCash" - the literal string (case insensitive)

   3. x.y or x.y.z - the version number of the message format.  x is the
   primary version number.  y is a subversion number.  z, if present, is
   a subsubversion number.

   4. "Extra" - an optional additional alphanumeric string.

   5.  "$$" - the literal string

   Version numbers start at 0.7 and count up.  The ".z" is omitted when
   z is zero.  0.7 and 0.8 are the test and initial shipped version of
   the credit card system. 0.9 and 1.0 are expected to also incorporate
   the test and initial shipped versions of the cash facilities as well
   as improvements to the credit card system.

   The "Extra" string is used within secure environments so that one
   subcomponent can scribble a note to another with minimum overhead.
   For example, a server firewall could put "HTTP" or "SMTP" here before
   forwarding the message to the core server within the firewall
   perimeter.

2.3 Body Parts

   The body parts of the message (both transparent and opaque) consist
   of attribute value pairs in formats that are reminiscent of the
   standard electronic mail header (RFC822) format. However, there are
   some differences.

   Attribute names start with and are composed predominantly of letters
   and internal hyphens except that they sometimes end with a hyphen
   followed by a number.  Such a trailing number is used when there is
   logically an indexed vector of values.  Attribute names are



Eastlake, et al              Informational                      [Page 8]

RFC 1898                 CyberCash Version 0.8             February 1996


   frequently referred to as labels.

   If the label ends with a ":", then RFC822 processing is done.  While
   the existence of trailing white space is significant, all leading
   white space on continuation lines is stripped.  Such lines are
   wrapped at 64 characters in length, excluding any line termination
   character(s).

   However, if the label is terminated with a ";", this indicates a
   free-form field where new-line characters and any leading white
   space, after the initial space that indicates a continuation line, is
   significant.  Such lines should not be wrapped except that, to avoid
   other processing problems, they are forcibly wrapped at 200
   characters.

   Blank lines are ignored and do not signify a change  to  a  different
   mode of line handling.

   Another way of looking at the above is as follows: after having found
   an initial $$ start line, you can treat any following lines according
   to the first character.  If it is alphanumeric, it is a new label
   which should be terminated with a ":" or ";" and indicates a new
   label-value pair.  If it is a white space character, it indicates the
   continuation of the value for the preceding new label line.  (Exactly
   how the continuation is processed depends on the label termination
   character.)  If it is "$", it should be the end line for the message.
   If it is #, it is a comment line and should be ignored.  Other
   initial characters are undefined.  (As of this date, no software
   sends CyberCash messages with # lines but they are convenient for
   commenting messages stored in files.)

2.4 Transparent Part

   The transparent part includes any clear-text data associated with the
   financial transaction as well as information needed by CyberCash and
   others to decrypt the opaque part(s).  It always includes a
   transaction field which is the transaction number generated by the
   requester and which is repeated in the response.  It always includes
   a date field that is the local date and time at the requester and is
   repeated in the response.  In all cases other than an initial
   registration to establish a persona ID, it includes the requester's
   persona ID.

   On messages bound for the server, there is a "cyberkey:" field that
   identifies which server public key was used to encrypt the session
   key.





Eastlake, et al              Informational                      [Page 9]

RFC 1898                 CyberCash Version 0.8             February 1996


2.5 Opaque Part

   The opaque part consists of a single block of characters encoded
   using base64 encoding (see RFC 1521). The data in the opaque section
   is always encrypted before encoding.

   The label "opaque" or "merchant-opaque" precedes the opaque part
   depending on whether the data was encrypted by the client or merchant
   software.

   On messages inbound to the server, the data to be opaqued is DES CBC
   encrypted under a random transacton key and then that DES key is RSA
   encrypted under one of the server's public keys.  The RSA encrypted
   DES key appears as the first part of the base64 encoded field and is
   not broken out as a separate value in the message.  The corresponding
   outbound reply from the server can simply be DES encrypted under this
   transaction key as there is enough plain text information to identify
   the transaction and the customer or merchant will have remembered the
   transaction key from the inbound message.

   A signature is not generally necessary in the opaque part of a reply
   message.  Knowledge of the transaction key is adequate
   authentication.  In order for someone to forge the response, they
   would have to know the server's private key to be able to get at the
   transaction key.  It is assumed that if anyone tampered with the
   response opaque part, the probability that it would decrypt to
   something that would parse is insignificant.  (Just the fact that the
   8th bit has to be off means a chance of 1 in 2**n where there are n
   characters and that's ignoring the rest of the formatting.)  While
   someone can tamper with the transparent part, this usually either has
   no effect or means that the client won't find the transaction key, in
   which case it's just a particular example of denial of service by
   damaging a message.

2.6 Trailer

   The trailer is intended to close the message and provide a definitive
   and parseable end of the message.

   The trailer consists of several fields separated by "-" as in header.

   1. "$$" - literal string.

   2. "CyberCash" - literal string (case insensitive).

   3. "End" - literal string (case insensitive).

   4. transmission checksum.



Eastlake, et al              Informational                     [Page 10]

RFC 1898                 CyberCash Version 0.8             February 1996


   5.  "$$" - literal string.

   The transmission checksum is the MD5 has of all printable characters
   in the version number in the start line and those appearing after the
   second $$ of the start line and before the first $$ of the trailer
   line as transmitted.  Note that all white space is left out of this
   hash, including any new-lines, spaces, tabs, carriage returns, etc.
   The exact label terminators actually used (: or ;) are included as
   would any # comment line.  Note that the optional "Extra" string in
   the $ start line is not included.  The idea is to check correct
   transmission while avoiding sensitivity to gateways or processing
   that might change the line terminator sequence, convert tabs to
   spaces, or the like.

2.7 Example Messages

   Simple message from a client:

   $$-CyberCash-0.8-$$
   id: DONALD-69
   transaction: 918273645
   date: 199512250102
   cyberkey:CC1001
   opaque:
    GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG
    aXmoxyUlwVnFkYcOyTbSOidqrwOjnAwLEVGJ/wa4ciKKI2PsNPA4sThpV2leFp2Vmkm4
    elmZdS0Qe350g6OPrkC7TKpqQKHjzczRRytWbFvE+zSi44wMF/ngzmiVsUCW01FXc8T9
    EB8KjHEzVSRfZDn+lP/c1nTLTwPrQ0DYiN1lGy9nwM1ImXifijHR19LZIHlRXy8=
   $$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$


   Message from a merchant:

   $$-CyberCash-a.b.c-extra-$$
   merchant-ccid: acme-69
   merchant-date: 19951231115959
   merchant-transaction: 987654321
   label: value

   labelx: multiple line
      value...
   # comment
   # another comment line
   label; text with a real
     multi-line
        format !
   merchant-cyberkey: CC1001
   merchant-opaque:



Eastlake, et al              Informational                     [Page 11]

RFC 1898                 CyberCash Version 0.8             February 1996


    C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y
    /iomz6/+LgX+Dn0smoAge7W+ESJ6d6Ge3kRAQKVCSpbOVLXF6E7mshlyXgQYmtwIVN2J
    66fJMQpo31ErrdPVdtq6MufynN8rJyJtu8xSNolXlqIYNQy5G2I3XCc6D3UnSErPx1VJ
    6cbwjLuIHHv58Nk+xxt/FyW7yAMwUb9YNcmOj//6Ru0NiOA9P/IiWczDe2mJRK1uqVpC
    sDrWehG/UbFTPD26trlYRnnY
   $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

3. Signatures and Hashes

   Inbound CyberCash request messages normally have a signature, as
   described below, of all of the messages fields outside of the
   signature.  This signature is transmitted inside the opaque part of
   the message.  It enables the server to authenticate the source of the
   message.

   Messages from a merchant to a client initiating a purchase sequence
   have fields signed by the merchant.  These fields and this signature
   are included by the client in the opaque part of their card purchase
   message to the merchant so that, when all is passed on to the server,
   it can verify that the client saw the information the merchant
   intended.

   More information on CyberCash signatures and the hash codes they are
   based on, is given below.

3.1 Digital Signatures

   Digital signatures are a means of authenticating information.  In
   CyberCash messages, they are calculated by first taking the hash of
   the data to be authenticated, as described below, and then encoding
   the hash using an RSA private key.

   Anyone possessing the corresponding public key can then decrypt the
   hash and compare it with the message hash.  If they match, then you
   can be sure that the signature was generated by someone possessing
   the private key which corresponded with the public key you used and