rfc1423.txt

RFC 的详细文档！

     AlgorithmIdentifier ::= SEQUENCE {
         algorithm         OBJECT IDENTIFIER,
         parameters        ANY DEFINED BY algorithm OPTIONAL
     }

   An RSA input block is encrypted using the RSA algorithm with the
   first (or left-most) octet taken as the most significant octet, and
   the last (or right-most) octet taken as the least significant octet.
   The resulting RSA output block is interpreted in a similar manner.

   When RSAEncryption is used to encrypt a DEK, the second argument in a
   "MIC-Info:" header field, an asymmetrically encrypted DEK, is
   represented using the printable encoding technique defined in Section
   4.3.2.4 of RFC 1421 [12].

   When RSAEncryption is used to sign a MIC, the third argument in a
   "MIC-Info:" header field, an asymmetrically signed MIC, is
   represented using the printable encoding technique defined in Section
   4.3.2.4 of RFC 1421.

4.3  Asymmetric Signature Algorithms

   This section identifies the alternative algorithms which shall be
   used to asymmetrically sign certificates and certificate revocation
   lists (CRLs) in accordance with the SIGNED macro defined in Annex G
   of X.509.  ASN.1 object identifiers are identified for incorporation
   in certificates and CRLs to indicate the choice of algorithm
   employed.

   Only one alternative is presently defined in this category.





Balenson                                                       [Page 10]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993


4.3.1  md2WithRSAEncryption

   The md2WithRSAEncryption signature algorithm is used to sign
   certificates and CRLs.  The algorithm is defined in PKCS #1 [11].  It
   combines the RSA-MD2 message digest algorithm described here in
   Section 2.2 with the RSAEncryption asymmetric encryption algorithm
   described here in Section 4.2.1.  As defined in PKCS #1, the ASN.1
   object identifier

     md2WithRSAEncryption OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
         pkcs-1(1) 2
     }

   identifies this algorithm.  When this object identifier is used with
   the ASN.1 type AlgorithmIdentifier, the parameters component of that
   type is the ASN.1 type NULL.

   There is some ambiguity in X.509 regarding the definition of the
   SIGNED macro and, in particular, the representation of a signature in
   a certificate or a CRL.  The interpretation selected for PEM requires
   that the data to be signed (in our case, an MD2 message digest) is
   first ASN.1 encoded as an OCTET STRING and the result is encrypted
   (in our case, using RSAEncryption) to form the signed quantity, which
   is then ASN.1 encoded as a BIT STRING.

5.  Descriptive Grammar

   ; Addendum to PEM BNF representation, using RFC 822 notation
   ; Provides specification for official PEM cryptographic algorithms,
   ; modes, identifiers and formats.

   ; Imports <hexchar> and <encbin> from RFC [1421]

       <dekalgid> ::= "DES-CBC"
       <ikalgid>  ::= "DES-EDE" / "DES-ECB" / "RSA"
       <sigalgid> ::= "RSA"
       <micalgid> ::= "RSA-MD2" / "RSA-MD5"

       <dekparameters> ::= <DESCBCparameters>
       <DESCBCparameters> ::= <IV>
       <IV> ::= <hexchar16>

       <symencdek> ::= <DESECBencDESCBC> / <DESEDEencDESCBC>
       <DESECBencDESCBC> ::= <hexchar16>
       <DESEDEencDESCBC> ::= <hexchar16>

       <symencmic> ::= <DESECBencRSAMD2> / <DESECBencRSAMD5>



Balenson                                                       [Page 11]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993


       <DESECBencRSAMD2> ::= 2*2<hexchar16>
       <DESECBencRSAMD5> ::= 2*2<hexchar16>

       <asymsignmic> ::= <RSAsignmic>
       <RSAsignmic> ::= <encbin>

       <asymencdek> ::= <RSAencdek>
       <RSAencdek> ::= <encbin>

       <hexchar16> ::= 16*16<hexchar>

References

   [1] Federal Information Processing Standards Publication (FIPS PUB)
       46-1, Data Encryption Standard, Reaffirmed 1988 January 22
       (supersedes FIPS PUB 46, 1977 January 15).

   [2] ANSI X3.92-1981, American National Standard Data Encryption
       Algorithm, American National Standards Institute, Approved 30
       December 1980.

   [3] Federal Information Processing Standards Publication (FIPS PUB)
       81, DES Modes of Operation, 1980 December 2.

   [4] ANSI X3.106-1983, American National Standard for Information
       Systems - Data Encryption Algorithm - Modes of Operation,
       American National Standards Institute, Approved 16 May 1983.

   [5] ISO 8372, Information Processing Systems: Data Encipherment:
       Modes of Operation of a 64-bit Block Cipher.

   [6] ANSI X9.17-1985, American National Standard, Financial
       Institution Key Management (Wholesale), American Bankers
       Association, April 4, 1985, Section 7.2.

   [7] Voydock, V. L. and Kent, S. T., "Security Mechanisms in High-
       Level Network Protocols", ACM Computing Surveys, Vol. 15, No. 2,
       June 1983, pp. 135-171.

   [8] CCITT Recommendation X.509, "The Directory - Authentication
       Framework", November 1988, (Developed in collaboration, and
       technically aligned, with ISO 9594-8).

   [9] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, RSA
       Laboratories, April 1992.

  [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
       Laboratory for Computer Science and RSA Data Security, Inc.,



Balenson                                                       [Page 12]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993


       April 1992.

  [11] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data Security,
       Inc., June 3, 1991.

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

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

  [14] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
       Part IV: Key Certification and Related Services", RFC 1424, RSA
       Laboratories, February 1993.

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.

   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.



Balenson                                                       [Page 13]

RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993


   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

   This entire document is about security.

Author's Address

   David Balenson
   Trusted Information Systems
   3060 Washington Road
   Glenwood, Maryland 21738

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





















Balenson                                                       [Page 14]