rfc2312.txt

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

   is not provably valid and associated with the message, the processing
   software should take immediate and noticable steps to inform the end
   user about it.

   Some of the many places where signature and certificate checking
   might fail include:

   - no Internet mail addresses in a certificate match the sender of a
     message
   - no certificate chain leads to a trusted CA
   - no ability to check the CRL for a certificate
   - an invalid CRL was received
   - the CRL being checked is expired
   - the certificate is expired
   - the certificate has been revoked

   There are certainly other instances where a certificate may be
   invalid, and it is the responsibility of the processing software to
   check them all thoroughly, and to decide what to do if the check
   fails.















Dusse, et. al.               Informational                     [Page 14]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


A. Object Identifiers and Syntax

   Sections A.1 through A.4 are adopted from [SMIME-MSG].

A.5 Name Attributes

emailAddress OBJECT IDENTIFIER ::=

     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1}

CountryName OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 6}

StateOrProvinceName OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 8}

locality OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 7}

CommonName OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 3}

Title OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 12}

Organization OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 10}

OrganizationalUnit OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 11}

StreetAddress OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 9}

Postal Code OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 17}

Phone Number OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 20}

A.6 Certification Request Attributes

postalAddress OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 16}

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




Dusse, et. al.               Informational                     [Page 15]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


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

A.7 X.509 V3 Certificate Extensions

basicConstraints OBJECT IDENTIFIER ::=

     {joint-iso-ccitt(2) ds(5) 29 19 }

The ASN.1 definition of basicConstraints certificate extension is:

basicConstraints basicConstraints EXTENSION ::= {
     SYNTAX  BasicConstraintsSyntax
     IDENTIFIED BY { id-ce 19 } }

BasicConstraintsSyntax ::= SEQUENCE {
     cA                 BOOLEAN DEFAULT FALSE,
     pathLenConstraint  INTEGER (0..MAX) OPTIONAL }

keyUsage OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) 29 15 }

The ASN.1 definition of keyUsage certificate extension is:

keyUsage EXTENSION ::= {
     SYNTAX  KeyUsage
     IDENTIFIED BY { id-ce 15 }}

KeyUsage ::= BIT STRING {
     digitalSignature      (0),
     nonRepudiation        (1),
     keyEncipherment       (2),
     dataEncipherment      (3),
     keyAgreement          (4),
     keyCertSign           (5),
     cRLSign               (6)}















Dusse, et. al.               Informational                     [Page 16]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


B. References

   [KEYM] PKIX Part 1. At the time of this writing, PKIX is a Work in
   Progress, but it is expected that there will be standards-track RFCs
   at some point in the future.

   [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 1l4, RFC 2119, March 1997.

   [PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
   2313, March 1998.

   [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
   1.5", RFC 2315, March 1998.

   [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax
   Version 1.5", RFC 2314, March 1998.

   [RFC-822] Crocker, D., "Standard For The Format Of ARPA Internet Text
   Messages", STD 11, RFC 822, August 1982.

   [SMIME-MSG] Dusse, S., Hoffman, P., Ramsdell, R., Lundblade, L., and
   L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March
   1998.

   [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
   Information technology - Open Systems Interconnection - The
   Directory: Overview of concepts, models and services

   [X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997,
   Information technology - Open Systems Interconnection - The
   Directory: Models

   [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
   Information technology - Open Systems Interconnection - The
   Directory: Authentication framework

   [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,
   Information technology - Open Systems Interconnection - The
   Directory: Selected attribute types.











Dusse, et. al.               Informational                     [Page 17]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


C. Compatibility with Prior Practice in S/MIME

   S/MIME was originally developed by RSA Data Security, Inc. Many
   developers implemented S/MIME agents before this document was
   published. All S/MIME receiving agents SHOULD make every attempt to
   interoperate with these earlier implementations of S/MIME.

D. Acknowledgements

   Significant contributions to the content of this memo were made by
   many people, including David Solo, Anil Gangolli, Jeff Thompson, and
   Lisa Repka.







































Dusse, et. al.               Informational                     [Page 18]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


E. Authors' Addresses

   Steve Dusse
   RSA Data Security, Inc.
   100 Marine Parkway, #500
   Redwood City, CA  94065  USA

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


   Paul Hoffman
   Internet Mail Consortium
   127 Segre Place
   Santa Cruz, CA  95060

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


   Blake Ramsdell
   Worldtalk
   13122 NE 20th St., Suite C
   Bellevue, WA 98005

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


   Jeff Weinstein
   Netscape Communications Corporation
   501 East Middlefield Road
   Mountain View, CA  94043

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















Dusse, et. al.               Informational                     [Page 19]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


F.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Dusse, et. al.               Informational                     [Page 20]