rfc2632.txt

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

   are not required to be in any particular order nor are they required
   to be in any way related to the sender or recipient of the message
   (although in most cases they will be related to the sender). Incoming
   certificates and CRLs SHOULD be cached for use in chain validation
   and optionally stored for later use. This temporary certificate and
   CRL cache SHOULD be used to augment any other certificate and CRL
   retrieval mechanisms for chain validation on incoming signed
   messages.

4.3 Certificate and CRL Signing Algorithms

   Certificates and Certificate-Revocation Lists (CRLs) are signed by
   the certificate issuer. A receiving agent MUST be capable of
   verifying the signatures on certificates and CRLs made with id-dsa-
   with-sha1 [DSS].

   A receiving agent SHOULD be capable of verifying the signatures on
   certificates and CRLs made with md2WithRSAEncryption,
   md5WithRSAEncryption and sha-1WithRSAEncryption signature algorithms
   with key sizes from 512 bits to 2048 bits described in [PKCS#1V2].







Ramsdell                    Standards Track                     [Page 7]

RFC 2632         S/MIME Version 3 Certificate Handling         June 1999


4.4 PKIX Certificate Extensions

   PKIX describes an extensible framework in which the basic certificate
   information can be extended and how such extensions can be used to
   control the process of issuing and validating certificates. The PKIX
   Working Group has ongoing efforts to identify and create extensions
   which have value in particular certification environments. Further,
   there are active efforts underway to issue PKIX certificates for
   business purposes. This document identifies the minumum required set
   of certificate extensions which have the greatest value in the S/MIME
   environment. The syntax and semantics of all the identified
   extensions are defined in [KEYM].

   Sending and receiving agents MUST correctly handle the Basic
   Constraints Certificate Extension, the Key Usage Certificate
   Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when
   they appear in end-user certificates. Some mechanism SHOULD exist to
   handle the defined certificate extensions when they appear in
   intermediate or CA certificates.

   Certificates issued for the S/MIME environment SHOULD NOT contain any
   critical extensions (extensions that have the critical field set to
   TRUE) other than those listed here. These extensions SHOULD be marked
   as non-critical unless the proper handling of the extension is deemed
   critical to the correct interpretation of the associated certificate.
   Other extensions may be included, but those extensions SHOULD NOT be
   marked as critical.

   Interpretation and syntax for all extensions MUST follow [KEYM],
   unless otherwise specified here.

4.4.1 Basic Constraints Certificate Extension

   The basic constraints extension serves to delimit the role and
   position of an issuing authority or end-entity certificate plays in a
   chain of certificates.

   For example, certificates issued to CAs and subordinate CAs contain a
   basic constraint extension that identifies them as issuing authority
   certificates. End-entity certificates contain an extension that
   constrains the certificate from being an issuing authority
   certificate.

   Certificates SHOULD contain a basicConstraints extension in CA
   certificates, and SHOULD NOT contain that extension in end entity
   certificates.





Ramsdell                    Standards Track                     [Page 8]

RFC 2632         S/MIME Version 3 Certificate Handling         June 1999


4.4.2 Key Usage Certificate Extension

   The key usage extension serves to limit the technical purposes for
   which a public key listed in a valid certificate may be used. Issuing
   authority certificates may contain a key usage extension that
   restricts the key to signing certificates, certificate revocation
   lists and other data.

   For example, a certification authority may create subordinate issuer
   certificates which contain a keyUsage extension which specifies that
   the corresponding public key can be used to sign end user certs and
   sign CRLs.

   If a key usage extension is included in a PKIX certificate, then it
   MUST be marked as critical.

4.4.2.1 Key Usage in Diffie-Hellman Key Exchange Certificates

   For Diffie-Hellman key exchange certificates (certificates in which
   the subject public key algorithm is dhpublicnumber), if the keyUsage
   keyAgreement bit is set to 1 AND if the public key is to be used to
   form a pairwise key to decrypt data, then the S/MIME agent MUST only
   use the public key if the keyUsage encipherOnly bit is set to 0. If
   the keyUsage keyAgreement bit is set to 1 AND if the key is to be
   used to form a pairwise key to encrypt data, then the S/MIME agent
   MUST only use the public key if the keyUsage decipherOnly bit is set
   to 0.

4.4.3 Subject Alternative Name Extension

   The subject alternative name extension is used in S/MIME as the
   preferred means to convey the RFC-822 email address(es) that
   correspond to the entity for this certificate. Any RFC-822 email
   addresses present MUST be encoded using the rfc822Name CHOICE of the
   GeneralName type. Since the SubjectAltName type is a SEQUENCE OF
   GeneralName, multiple RFC-822 email addresses MAY be present.

5. Security Considerations

   All of the security issues faced by any cryptographic application
   must be faced by a S/MIME agent. Among these issues are protecting
   the user's private key, preventing various attacks, and helping the
   user avoid mistakes such as inadvertently encrypting a message for
   the wrong recipient. The entire list of security considerations is
   beyond the scope of this document, but some significant concerns are
   listed here.





Ramsdell                    Standards Track                     [Page 9]

RFC 2632         S/MIME Version 3 Certificate Handling         June 1999


   When processing certificates, there are many situations where the
   processing might fail. Because the processing may be done by a user
   agent, a security gateway, or other program, there is no single way
   to handle such failures. Just because the methods to handle the
   failures has not been listed, however, the reader should not assume
   that they are not important. The opposite is true: if a certificate
   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.

























Ramsdell                    Standards Track                    [Page 10]

RFC 2632         S/MIME Version 3 Certificate Handling         June 1999


A. References

   [CERTV2]     Dusse, S., Hoffman, P. and B. Ramsdell,"S/MIME Version 2
                Certificate Handling", RFC 2312, March 1998.

   [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
                June 1999.

   [DSS]        NIST FIPS PUB 186, "Digital Signature Standard", 18 May
                1994.

   [KEYM]       Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
                X.509 Public Key Infrastructure Certificate and CRL
                Profile", RFC 2459, January 1999.

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

   [PKCS#1V2]   Kaliski, B., "PKCS #1: RSA Cryptography Specifications
                Version 2.0", RFC 2437, October 1998.

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

   [SMIME-MSG]  Ramsdell, B., Editor, "S/MIME Version 3 Message
                Specification", RFC 2633, June 1999.

   [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.








Ramsdell                    Standards Track                    [Page 11]

RFC 2632         S/MIME Version 3 Certificate Handling         June 1999


B. Acknowledgements

   Many thanks go out to the other authors of the S/MIME v2 RFC:  Steve
   Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn't be
   a v3.

   A number of the members of the S/MIME Working Group have also worked
   very hard and contributed to this document. Any list of people is
   doomed to omission and for that I apologize. In alphabetical order,
   the following people stand out in my mind due to the fact that they
   made direct contributions to this document.

   Bill Flanigan Elliott Ginsburg Paul Hoffman Russ Housley Michael
   Myers John Pawling Denis Pinkas Jim Schaad

Editor's Address

   Blake Ramsdell
   Worldtalk
   17720 NE 65th St Ste 201
   Redmond, WA 98052

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



























Ramsdell                    Standards Track                    [Page 12]

RFC 2632         S/MIME Version 3 Certificate Handling         June 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ramsdell                    Standards Track                    [Page 13]