rfc1424.txt

<VC++网络游戏建摸与实现>源代码

   Since the reply is an ordinary privacy-enhanced message, the new
   certificate can be inserted into the requestor's database during
   normal privacy-enhanced mail processing. The requestor can forward
   the reply to other requestors to disseminate the certificate.

   Example:

   To: [e-mail]
   From: [e-mail]

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,MIC-ONLY
   Content-Domain: RFC822
   Originator-Certificate: <requestor's new certificate>
   Issuer-Certificate: <issuer's certificate>
   MIC-Info: RSA,RSA-MD2,<requestor's signature on text>

   <text>
   -----END PRIVACY-ENHANCED MESSAGE-----








Kaliski                                                         [Page 5]

RFC 1424        Key Certification and Related Services     February 1993


3.3 CRL-storage request

   A CRL-storage request is an RFC 1421 CRL-type privacy-enhanced
   message containing the CRLs to be stored and optionally their
   certification paths to the RFC 1422 Internet certification authority.

   Example:

   To: [e-mail]
   From: [e-mail]

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,CRL
   CRL: <CRL to be stored>
   Originator-Certificate: <CRL issuer's certificate>
   CRL: <another CRL to be stored>
   Originator-Certificate: <other CRL issuer's certificate>
   -----END PRIVACY-ENHANCED MESSAGE-----

3.4 CRL-storage reply

   A CRL-storage reply is an ordinary message acknowledging the storage
   of CRLs. No particular syntax is specified.

3.5 CRL-retrieval request

   A CRL-retrieval request is a new type of privacy-enhanced message,
   distinguished from RFC 1421 privacy-enhanced messages by the process
   type CRL-RETRIEVAL-REQUEST.

   The request has two or more encapsulated header fields: the required
   "Proc-Type:" field and one or more "Issuer:" fields. The fields must
   appear in the order just described. There is no encapsulated text, so
   there is no blank line separating the fields from encapsulated text.

   Each "Issuer:" field specifies an issuer whose latest CRL is to be
   retrieved. The field contains a value of type Name specifying the
   issuer's distinguished name. The value is encoded as in an RFC 1421
   "Originator-ID-Asymmetric:" field (i.e., according to the Basic
   Encoding Rules, then in ASCII).











Kaliski                                                         [Page 6]

RFC 1424        Key Certification and Related Services     February 1993


   Example:

   To: [e-mail]
   From: [e-mail]

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,CRL-RETRIEVAL-REQUEST
   Issuer: <issuer whose latest CRL is to be retrieved>
   Issuer: <another issuer whose latest CRL is to be retrieved>
   -----END PRIVACY-ENHANCED MESSAGE-----

3.6 CRL-retrieval reply

   A CRL-retrieval reply is an RFC 1421 CRL-type privacy-enhanced
   message containing retrieved CRLs, their certification paths to the
   RFC 1422 Internet certification authority, and possibly other
   certificates.

   Since the reply is an ordinary privacy-enhanced message, the
   retrieved CRLs can be inserted into the requestor's database during
   normal privacy-enhanced mail processing. The requestor can forward
   the reply to other requestors to disseminate the CRLs.

   Example:

   To: [e-mail]
   From: [e-mail]

   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,CRL
   CRL: <issuer's latest CRL>
   Originator-Certificate: <issuer's certificate>
   CRL: <other issuer's latest CRL>
   Originator-Certificate: <other issuer's certificate>
   -----END PRIVACY-ENHANCED MESSAGE-----


Patent Statement

   This version of Privacy Enhanced Mail (PEM) relies on the use of
   patented public key encryption technology for authentication and
   encryption.  The Internet Standards Process as defined in RFC 1310
   requires a written statement from the Patent holder that a license
   will be made available to applicants under reasonable terms and
   conditions prior to approving a specification as a Proposed, Draft or
   Internet Standard.





Kaliski                                                         [Page 7]

RFC 1424        Key Certification and Related Services     February 1993


   The Massachusetts Institute of Technology and the Board of Trustees
   of the Leland Stanford Junior University have granted Public Key
   Partners (PKP) exclusive sub-licensing rights to the following
   patents issued in the United States, and all of their corresponding
   foreign patents:

      Cryptographic Apparatus and Method
      ("Diffie-Hellman")............................... No. 4,200,770

      Public Key Cryptographic Apparatus
      and Method ("Hellman-Merkle").................... No. 4,218,582

      Cryptographic Communications System and
      Method ("RSA")................................... No. 4,405,829

      Exponential Cryptographic Apparatus
      and Method ("Hellman-Pohlig").................... No. 4,424,414

   These patents are stated by PKP to cover all known methods of
   practicing the art of Public Key encryption, including the variations
   collectively known as El Gamal.

   Public Key Partners has provided written assurance to the Internet
   Society that parties will be able to obtain, under reasonable,
   nondiscriminatory terms, the right to use the technology covered by
   these patents.  This assurance is documented in RFC 1170 titled
   "Public Key Standards and Licenses".  A copy of the written assurance
   dated April 20, 1990, may be obtained from the Internet Assigned
   Number Authority (IANA).

   The Internet Society, Internet Architecture Board, Internet
   Engineering Steering Group and the Corporation for National Research
   Initiatives take no position on the validity or scope of the patents
   and patent applications, nor on the appropriateness of the terms of
   the assurance.  The Internet Society and other groups mentioned above
   have not made any determination as to any other intellectual property
   rights which may apply to the practice of this standard. Any further
   consideration of these matters is the user's own responsibility.

Security Considerations

   The self-signed certificate (Section 3.1) prevents a requestor from
   requesting a certificate with another party's public key. Such an
   attack would give the requestor the minor ability to pretend to be
   the originator of any message signed by the other party. This attack
   is significant only if the requestor does not know the message being
   signed, and the signed part of the message does not identify the
   signer. The requestor would still not be able to decrypt messages



Kaliski                                                         [Page 8]

RFC 1424        Key Certification and Related Services     February 1993


   intended for the other party, of course.

References

   [1] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
       I: Message Encryption and Authentication Procedures", RFC 1421,
       DEC, February 1993.

   [2] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
       II: Certificate-Based Key Management", RFC 1422, BBN, February
       1993.

   [3] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
       Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS,
       February 1993.

Author's Address

       Burton S. Kaliski, Jr.
       RSA Laboratories (a division of RSA Data Security, Inc.)
       10 Twin Dolphin Drive
       Redwood City, CA  94065

       Phone: [phone]
       FAX: [phone]
       EMail: [e-mail]

























Kaliski                                                         [Page 9]