rfc1898.txt

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

   that the message was not tampered with.

   In the CyberCash system, clients, merchants, and the server have
   public-private key pairs.  By keeping the private key secret and
   registering their public key with the server (for a merchant or
   client) or publishing their public key or keys (for the server), they
   can provide high quality authentication by signing parts of messages.

   An RSA digital signature is approximately the size of the modulus
   used.  For example, if that is 768 bits long, then the binary digital
   signature would be 768 bits or 96 bytes long and its base 64 encoding
   would be 128 bytes.



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


3.2 Hash Codes

   The hashes used in CyberCash messages are message digests.  That is,
   a non-invertable fingerprint of a message such that it is
   computationally infeasible to find an alternate message with the same
   hash.  Thus the relatively small hash can be used to secure a larger
   message.  If you are confident in the authenticity of the hash and
   are presented with a message which matches the hash, you can be sure
   it is the original message, at least as regards all aspects that have
   been included in the hash.

   The hash is calculated using the MD5 algorithm (see RFC 1321) on a
   synthetic message.  The synthetic message is composed of the labels
   and values specified in a list for the particular hash.  Since the
   hash is input order dependent, it is essential that the label-value
   pairs be assembled in the order specified.  In some cases, a range of
   matching labels is specified.  For example, "card*" to match card-
   number, card-expiration-date, and all other labels starting with
   "card".  In such cases, all existing matching labels are used in
   ascending alphabetic order by ASCII character code.

   If a label is specified in a signature list but is not present in the
   label-value data on which the hash is being calculated, it is not
   included in the hash at all.  That is, even the label and label
   terminator are omitted from the synthetic message.

   Before being hashed, the text of the synthetic message is processed
   to remove all "white space" characters.  White space characters are
   defined as any with an ASCII value of 32 (space) or less or 127
   (rubout) or greater.  Thus all forms of new-line/carriage-return and
   distinctions such as blank lines, trailing spaces, replacement of a
   horizontal tab character by multiple spaces, etc., are ignored for
   hash purposes.

   MD5 hashes are 16 bytes long.  This means that the base 64 encoding
   of such a hash will be 24 characters (of which the last two will
   always be padding equal signs).

4. Specific Message Formats

   This section describes the formats of the Verison 0.8 CyberCash
   messages by example with comments.  The reader in assumed to be
   familiar with terms such as "acquirer", "PAN" (primary account
   number), etc., defined in ISO 8583, and currency designations as
   defined in ISO 4217. A few fields not relevant to current operations
   have been removed to simplify this exposition.





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


   In the following example messages, signatures, hashes, and encrypted
   sections are fake nonsense text and ids are fictitious.

4.1 Persona Registration and Application Retrieval

   The first step in customer use of CyberCash is registering a persona
   using the customer application.  This is done with the R1 message
   defined below.  The CyberCash server responds with the R2 message.

   When the customer application learns that it is out of date, it can
   use the GA1 request message to the server and its GA2 response to
   download a new signed version of itself.

4.1.1 R1 - registration

   Description: This is the initial message sent to create a new
       CyberCash persona.

   #####################################################################
   Sender: CyberApp
   Receiver: CyberServer
   #####################################################################
   Sample Message:

   $$-CyberCash-0.8-$$
   transaction: 123123213
   date: 19950121100505.nnn
   cyberkey: CC1001
   opaque:
    FrYOQrD16lEfrvkrqGWkajM1IZOsLbcouB43A4HzIpV3/EBQM5WzkRJGzYPM1r3noBUc
    MJ4zvpG0xlroY1de6DccwO9j/0aAZgDi9bcQWV4PFLjsN604j3qxWdYn9evIGQGbqGjF
    vn1qI1Ckrz/4/eT1oRkBBILbrWsuwTltFd84plvTy+bo5WE3WnhVKsCUJAlkKpXMaX73
    JRPoOEVQ3YEmhmD8itutafqvC90atX7ErkfUGDNqcB9iViRQ7HSvGDnKwaihRyfirkgN
    +lhOg6xSEw2AmYlNiFL5d/Us9eNG8cZM5peTow==
   $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

   #####################################################################

   Opaque Key: Generated using CyberCash encrypting public key
       identified in CyberKey.

   #####################################################################
   Opaque Section Contents:

   type: registration
   swversion: 0.8win
   content-language: en-us
   requested-id: MyRequestedCCID



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


   email: [e-mail]
   pubkey:
    0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
    E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
   signature:
    v6JGmxIwRiB6iXUK7XAIiHZRQsZwkbLV0L0OpVEvan9l59hVJ3nia/cZc/r5arkLIYEU
    dw6Uj/R4Z7ZdqO/fZZHldpd9+XPaqNHw/y8Arih6VbwrO5pKerLQfuuPbIom

   #####################################################################
   signature is of the following fields: transaction, date, cyberkey,
       type, swversion, content-language, requested-id, email, pubkey

   #####################################################################
   Explanation:
   content-language is taken from the MIME header field (see RFC1766)
       and is the language text messages should be generated in.  (only
       en-us implemented at this time.
   swversion used to check if client application is old.


4.1.2 R2 - registration-response

   Description: This message gives the success/failure response to R1.

   #####################################################################
   Sender: CyberServer
   Receiver: CyberApp
   #####################################################################
   Sample Message:

   $$-CyberCash-0.8-$$
   transaction: 12312313
   date: 19950121100505.nnn
   opaque:
    r1XfjSQt+KJYUVOGU60r7voFrm55A8fP5DjJZuPzWdPQjGBIu3B6Geya8AlJfHsW11u8
    dIv1yQeeYj/+l9TD1dXW21/1cUDFFK++J2gUMVv8mX1Z6Mi4OU8AfsgoCliwSkWmjSOb
    kE62sAlZTnw998cKzMFp70TSlI3PEBtvIfpLq5lDCNbWidX8vFZV0ENUmMQ9DTP3du9w
    fsFGvz1mvtHLT/Gj8GNQRYKF4xiyx4HYzTkSMhgU5B/QDLPS/SawIJuR86b9X0mwsr0a
    gbGTzECPJTiKkrhxxMG/eymptsVQSLqNaTCx6w==
   $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$

   #####################################################################
   Opaque Key: Same as session key for R1 for same Transaction and
       connection (there may be no ID!).

   #####################################################################
   Opaque Section Contents:




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


   type: registration-response
   server-date: 19950121100506.nnn
   requested-id: MyRequestedCCID
   response-id: CyberCashHandle
   email: [e-mail]
   response-code: success/failure/etc.
   pubkey:
    0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
    E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
   swseverity: fatal/warning  [absent if ok]
   swmessage; Tells CyberApp that it is obsolete.  Display this
    text to the user.  [only present if SWSeverity present]
   message;
          Free text of the error/success condition.
          This text is to be displayed to the person
          by the CyberCash application...

          In general this includes: duplicate-id, bad-signature,
          or ill-formed-registration

   #####################################################################
   Signature is of the following fields: no-signature

   #####################################################################
   Explanation:
   responseid is used to suggest a unique ID if the failure was due
       to the requested ID being already in use... If the reason for
       failure was not due to duplicate ID then this field may be
       omitted.
   responseid gives the actual ID with check characters appended if
       success.
   swseverity can warn user of old client application or indicate
       failure due to old or known buggy version.


4.1.3 GA1 - get-application

   Description: Used by CyberApp to get an updated version.

   #####################################################################
   Sender: CyberApp
   Receiver: CyberServer
   #####################################################################
   Sample Message:

   $$-CyberCash-0.8-$$
   transaction: 123123213
   date: 19950121100505.nnn



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


   cyberkey: CC1001
   opaque:
    VHMS611wGkUmR6bKoI+ODoSbl7L5PKtEo6aM88LCidqN+H/8B4xM3LxdwUiLn7rMPkZi
    xOGb+5d1lRV7WeTp21QYlqJr8emc6FAnGd5c0csPmcnEpTFh9xZDJaStarxxmSEwm2mw
    l2VjEUODH6321vjoMAOFQWn7ER0o
   $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$

   #####################################################################
   Opaque Key: Generated using CyberCash encrypting public key identified
      in CyberKey.

   #####################################################################
   Opaque Section Contents:

   type: get-application
   swversion: 0.8win

   #####################################################################
   Signature is of the following fields: no signature

   #####################################################################
   Explanation:
   There may not be a customer persona so there is no ID.  There
       may not be a customer public/private key pair so there is
       no signature.  The swversion is mandatory so the server can
       tell what to return.


4.1.4 GA2 - get-application-response

   Description: Return success and URL of up to date copy of CyberApp
       or failure.

   #####################################################################
   Sender: CyberServer
   Receiver: CyberApp
   #####################################################################
   Sample Message:

   $$-CyberCash-0.8-$$
   transaction: 12312313
   date: 19950110102333.nnn
   opaque:
    EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
    nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
    4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
    rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
    QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==



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


   $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$


   #####################################################################
   Opaque Key: session key from GA1

   #####################################################################
   Opaque Section Contents:

   type: get-application-response
   server-date: 19950110102334.nnn
   response-code: success/failure/etc.
   message; Text message to be displayed to the user providing more
       information on the success/failure.
   swversion: 0.8win
   application-url: http://foo.cybercash.com/server/0.8WIN.EXE
   application-hash: lSLzs/vFQ0BXfU98LZNWhQ==

   #####################################################################
   Signature: none.

   #####################################################################
   Explanation:
   application-hash is the MD5 of the binary of the application.
   application-url & application-hash omitted on failure.
   swversion is the version being transmitted to the customer.


4.2 Binding Credit Cards