As per Relevance of the word receiving, we have this rfc below:
Network Working Group B. Ramsdell,
Request for Comments: 2632
Category: Standards Track June 1999
S/MIME Version 3 Certificate
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
1.
S/MIME (Secure/Multipurpose Internet Mail Extensions), described
[SMIME-MSG], provides a method to send and receive secure
messages. Before using a public key to provide security services,
S/MIME agent MUST certify that the public key is valid. S/MIME
MUST use PKIX certificates to validate public keys as described
the Internet X.509 Public Key Infrastructure (PKIX) Certificate
CRL Profile [KEYM]. S/MIME agents MUST meet the
processing requirements documented in this document in addition
those stated in [KEYM].
This specification is compatible with the Cryptographic
Syntax [CMS] in that it uses the data types defined by CMS. It
inherits all the varieties of architectures for certificate-based
management supported by CMS
1.1
For the purposes of this memo, the following definitions apply
ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680-689.
Attribute Certificate (AC): An X.509 AC is a separate structure
a subject's public key X.509 Certificate. A subject may
multiple X.509 ACs associated with each of its public key X.509
Certificates. Each X.509 AC binds one or more Attributes with one
the subject's public key X.509 Certificates. The X.509 AC syntax
defined in [X.509]
Ramsdell Standards Track [Page 1]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
BER: Basic Encoding Rules for ASN.1, as defined in ITU-T X.690.
Certificate: A type that binds an entity's distinguished name to
public key with a digital signature. This type is defined in
Internet X.509 Public Key Infrastructure (PKIX) Certificate and
Profile [KEYM]. This type also contains the distinguished name of
certificate issuer (the signer), an issuer-specific serial number
the issuer's signature algorithm identifier, a validity period,
extensions also defined in that document
Certificate Revocation List (CRL): A type that contains
about certificates whose validity an issuer has prematurely revoked
The information consists of an issuer name, the time of issue,
next scheduled time of issue, a list of certificate serial
and their associated revocation times, and extensions as defined
[KEYM]. The CRL is signed by the issuer. The type intended by
specification is the one defined in [KEYM].
DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-
X.690.
Receiving agent: software that interprets and processes S/MIME
objects, MIME body parts that contain CMS objects, or both
Sending agent: software that creates S/MIME CMS objects, MIME
parts that contain CMS objects, or both
S/MIME agent: user software that is a receiving agent, a
agent, or both
1.2 Compatibility with Prior Practice of S/
S/MIME version 3 agents should attempt to have the
interoperability possible with S/MIME version 2 agents. S/
version 2 is described in RFC 2311 through RFC 2315, inclusive.
2311 also has historical information about the development of S/MIME
1.3
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [MUSTSHOULD].
Ramsdell Standards Track [Page 2]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
2. CMS
The CMS message format allows for a wide variety of options
content and algorithm support. This section puts forth a number
support requirements and recommendations in order to achieve a
level of interoperability among all S/MIME implementations. Most
the CMS format for S/MIME messages is defined in [SMIME-MSG].
2.1
Receiving agents MUST support the Certificate Revocation List (CRL
format defined in [KEYM]. If sending agents include CRLs in
messages, the CRL format defined in [KEYM] MUST be used
All agents MUST be capable of performing revocation checks using
as specified in [KEYM]. All agents MUST perform revocation
checking in accordance with [KEYM]. Receiving agents MUST
CRLs in received S/MIME messages
Agents SHOULD store CRLs received in messages for use in
later messages
Agents MUST handle multiple valid Certificate Authority (CA
certificates containing the same subject name and the same
keys but with overlapping validity intervals
2.2
Receiving agents MUST support PKIX v1 and PKIX v3 certificates.
[KEYM] for details about the profile for certificate formats.
entity certificates MAY include an Internet mail address,
described in section 3.1.
Receiving agents SHOULD support X.509 attribute certificates
2.2.1 Historical Note About CMS
The CMS message format supports a choice of certificate formats
public key content types: PKIX, PKCS #6 Extended Certificates
X.509 Attribute Certificates. The PKCS #6 format is not in
use. In addition, PKIX certificate extensions address much of
same functionality and flexibility as was intended in the PKCS #6.
Thus, sending and receiving agents MUST NOT use PKCS #6
certificates
Ramsdell Standards Track [Page 3]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
2.3
Receiving agents MUST be able to handle an arbitrary number
certificates of arbitrary relationship to the message sender and
each other in arbitrary order. In many cases, the
included in a signed message may represent a chain of
from the sender to a particular root. There may be, however
situations where the certificates in a signed message may
unrelated and included for convenience
Sending agents SHOULD include any certificates for the user's
key(s) and associated issuer certificates. This increases
likelihood that the intended recipient can establish trust in
originator's public key(s). This is especially important when
a message to recipients that may not have access to the sender'
public key through any other means or when sending a signed
to a new recipient. The inclusion of certificates in
messages can be omitted if S/MIME objects are sent within a group
correspondents that has established access to each other'
certificates by some other means such as a shared directory or
certificate distribution. Receiving S/MIME agents SHOULD be able
handle messages without certificates using a database or
lookup scheme
A sending agent SHOULD include at least one chain of certificates
to, but not including, a Certificate Authority (CA) that it
that the recipient may trust as authoritative. A receiving
SHOULD be able to handle an arbitrarily large number of
and chains
Agents MAY send CA certificates, that is, certificates that
self-signed and can be considered the "root" of other chains.
that receiving agents SHOULD NOT simply trust any self-
certificates as valid CAs, but SHOULD use some other mechanism
determine if this is a CA that should be trusted. Also note that
the case of DSA certificates the parameters may be located in
root certificate. This would require that the recipient possess
root certificate in order to perform a signature verification, and
a valid example of a case where transmitting the root certificate
be required
Receiving agents MUST support chaining based on the
name fields. Other methods of building certificate chains may
supported but are not currently recommended
Ramsdell Standards Track [Page 4]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
Receiving agents SHOULD support the decoding of X.509
certificates included in CMS objects. All other issues regarding
generation and use of X.509 attribute certificates are outside of
scope of this specification
3. Using Distinguished Names for Internet
End-entity certificates MAY contain an Internet mail address
described in [RFC-822]. The address must be an "addr-spec" as
in Section 6.1 of that specification. The email address SHOULD be
the subjectAltName extension, and SHOULD NOT be in the
distinguished name
Receiving agents MUST recognize email addresses in the
field. Receiving agents MUST recognize email addresses in
Distinguished Name field in the PKCS #9 emailAddress attribute
Sending agents SHOULD make the address in the From or Sender
in a mail message match an Internet mail address in the signer'
certificate. Receiving agents MUST check that the address in the
or Sender header of a mail message matches an Internet mail
in the signer's certificate, if mail addresses are present in
certificate. A receiving agent SHOULD provide some explicit
processing of the message if this comparison fails, which may be
display a message that shows the recipient the addresses in
certificate or other certificate details
All subject and issuer names MUST be populated (i.e. not an
SEQUENCE) in S/MIME-compliant PKIX certificates, except that
subject DN in a user's (i.e. end-entity) certificate MAY be an
SEQUENCE in which case the subjectAltName extension will include
subject's identifier and MUST be marked as critical
4. Certificate
A receiving agent needs to provide some certificate
mechanism in order to gain access to certificates for recipients
digital envelopes. There are many ways to implement
retrieval mechanisms. X.500 directory service is an excellent
of a certificate retrieval-only mechanism that is compatible
classic X.500 Distinguished Names. The PKIX Working Group
investigating other mechanisms such as directory servers.
method under consideration by the IETF is to provide
retrieval services as part of the existing Domain Name System (DNS).
Until such mechanisms are widely used, their utility may be
by the small number of correspondent's certificates that can
Ramsdell Standards Track [Page 5]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
retrieved. At a minimum, for initial S/MIME deployment, a user
could automatically generate a message to an intended
requesting that recipient's certificate in a signed return message
Receiving and sending agents SHOULD also provide a mechanism to
a user to "store and protect" certificates for correspondents in
a way so as to guarantee their later retrieval. In many environments
it may be desirable to link the certificate retrieval/
mechanisms together in some sort of certificate database. In
simplest form, a certificate database would be local to a
user and would function in a similar way as a "address book"
stores a user's frequent correspondents. In this way, the
retrieval mechanism would be limited to the certificates that a
has stored (presumably from incoming messages). A
certificate retrieval/storage solution may combine two or
mechanisms to allow the greatest flexibility and utility to the user
For instance, a secure Internet mail agent may resort to checking
centralized certificate retrieval mechanism for a certificate if
can not be found in a user's local certificate storage/
database
Receiving and sending agents SHOULD provide a mechanism for
import and export of certificates, using a CMS certs-only message
This allows for import and export of full certificate chains
opposed to just a single certificate. This is described in [SMIME
MSG].
4.1 Certificate Revocation
In general, it is always better to get the latest CRL
from a CA than to get information stored away from incoming messages
A receiving agent SHOULD have access to some certificate-
list (CRL) retrieval mechanism in order to gain access
certificate-revocation information when validating
chains. A receiving or sending agent SHOULD also provide a
to allow a user to store incoming certificate-revocation
for correspondents in such a way so as to guarantee its
retrieval
Receiving and sending agents SHOULD retrieve and utilize
information every time a certificate is verified as part of
certificate chain validation even if the certificate was
verified in the past. However, in many instances (such as off-
verification) access to the latest CRL information may be
or impossible. The use of CRL information, therefore, may be
by the value of the information that is protected. The value of
Ramsdell Standards Track [Page 6]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
CRL information in a particular context is beyond the scope of
memo but may be governed by the policies associated with
certificate hierarchies
All agents MUST be capable of performing revocation checks using
as specified in [KEYM]. All agents MUST perform revocation
checking in accordance with [KEYM]. Receiving agents MUST
CRLs in received S/MIME messages
4.2 Certificate Chain
In creating a user agent for secure messaging, certificate, CRL,
certificate chain validation SHOULD be highly automated while
acting in the best interests of the user. Certificate, CRL, and
validation MUST be performed as per [KEYM] when validating
correspondent's public key. This is necessary before using a
key to provide security services such as: verifying a signature
encrypting a content-encryption key (ex: RSA); or forming a
symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt
content-encryption key
Certificates and CRLs are made available to the chain
procedure in two ways: a) incoming messages, and b) certificate
CRL retrieval mechanisms. Certificates and CRLs in incoming
are not required to be in any particular order nor are they
to be in any way related to the sender or recipient of the
(although in most cases they will be related to the sender).
certificates and CRLs SHOULD be cached for use in chain
and optionally stored for later use. This temporary certificate
CRL cache SHOULD be used to augment any other certificate and
retrieval mechanisms for chain validation on incoming
messages
4.3 Certificate and CRL Signing
Certificates and Certificate-Revocation Lists (CRLs) are signed
the certificate issuer. A receiving agent MUST be capable
verifying the signatures on certificates and CRLs made with id-dsa
with-sha1 [DSS].
A receiving agent SHOULD be capable of verifying the signatures
certificates and CRLs made with md2WithRSAEncryption
md5WithRSAEncryption and sha-1WithRSAEncryption signature
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
PKIX describes an extensible framework in which the basic
information can be extended and how such extensions can be used
control the process of issuing and validating certificates. The
Working Group has ongoing efforts to identify and create
which have value in particular certification environments. Further
there are active efforts underway to issue PKIX certificates
business purposes. This document identifies the minumum required
of certificate extensions which have the greatest value in the S/
environment. The syntax and semantics of all the
extensions are defined in [KEYM].
Sending and receiving agents MUST correctly handle the
Constraints Certificate Extension, the Key Usage
Extension, authorityKeyID, subjectKeyID, and the subjectAltNames
they appear in end-user certificates. Some mechanism SHOULD exist
handle the defined certificate extensions when they appear
intermediate or CA certificates
Certificates issued for the S/MIME environment SHOULD NOT contain
critical extensions (extensions that have the critical field set
TRUE) other than those listed here. These extensions SHOULD be
as non-critical unless the proper handling of the extension is
critical to the correct interpretation of the associated certificate
Other extensions may be included, but those extensions SHOULD NOT
marked as critical
Interpretation and syntax for all extensions MUST follow [KEYM],
unless otherwise specified here
4.4.1 Basic Constraints Certificate
The basic constraints extension serves to delimit the role
position of an issuing authority or end-entity certificate plays in
chain of certificates
For example, certificates issued to CAs and subordinate CAs contain
basic constraint extension that identifies them as issuing
certificates. End-entity certificates contain an extension
constrains the certificate from being an issuing
certificate
Certificates SHOULD contain a basicConstraints extension in
certificates, and SHOULD NOT contain that extension in end
certificates
Ramsdell Standards Track [Page 8]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
4.4.2 Key Usage Certificate
The key usage extension serves to limit the technical purposes
which a public key listed in a valid certificate may be used.
authority certificates may contain a key usage extension
restricts the key to signing certificates, certificate
lists and other data
For example, a certification authority may create subordinate
certificates which contain a keyUsage extension which specifies
the corresponding public key can be used to sign end user certs
sign CRLs
If a key usage extension is included in a PKIX certificate, then
MUST be marked as critical
4.4.2.1 Key Usage in Diffie-Hellman Key Exchange
For Diffie-Hellman key exchange certificates (certificates in
the subject public key algorithm is dhpublicnumber), if the
keyAgreement bit is set to 1 AND if the public key is to be used
form a pairwise key to decrypt data, then the S/MIME agent MUST
use the public key if the keyUsage encipherOnly bit is set to 0.
the keyUsage keyAgreement bit is set to 1 AND if the key is to
used to form a pairwise key to encrypt data, then the S/MIME
MUST only use the public key if the keyUsage decipherOnly bit is
to 0.
4.4.3 Subject Alternative Name
The subject alternative name extension is used in S/MIME as
preferred means to convey the RFC-822 email address(es)
correspond to the entity for this certificate. Any RFC-822
addresses present MUST be encoded using the rfc822Name CHOICE of
GeneralName type. Since the SubjectAltName type is a SEQUENCE
GeneralName, multiple RFC-822 email addresses MAY be present
5. Security
All of the security issues faced by any cryptographic
must be faced by a S/MIME agent. Among these issues are
the user's private key, preventing various attacks, and helping
user avoid mistakes such as inadvertently encrypting a message
the wrong recipient. The entire list of security considerations
beyond the scope of this document, but some significant concerns
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
processing might fail. Because the processing may be done by a
agent, a security gateway, or other program, there is no single
to handle such failures. Just because the methods to handle
failures has not been listed, however, the reader should not
that they are not important. The opposite is true: if a
is not provably valid and associated with the message, the
software should take immediate and noticable steps to inform the
user about it
Some of the many places where signature and certificate
might fail include
- no Internet mail addresses in a certificate match the
of a
- no certificate chain leads to a trusted
- no ability to check the CRL for a
- an invalid CRL was
- the CRL being checked is
- the certificate is
- the certificate has been
There are certainly other instances where a certificate may
invalid, and it is the responsibility of the processing software
check them all thoroughly, and to decide what to do if the
fails
Ramsdell Standards Track [Page 10]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
A.
[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
1994.
[KEYM] Housley, R., Ford, W., Polk, W. and D. Solo, "
X.509 Public Key Infrastructure Certificate and
Profile", RFC 2459, January 1999.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PKCS#1V2] Kaliski, B., "PKCS #1: RSA Cryptography
Version 2.0", RFC 2437, October 1998.
[RFC-822] Crocker, D., "Standard For The Format Of ARPA
Text Messages", STD 11, RFC 822, August 1982.
[SMIME-MSG] Ramsdell, B., Editor, "S/MIME Version 3
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
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.
Many thanks go out to the other authors of the S/MIME v2 RFC:
Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn't
a v3.
A number of the members of the S/MIME Working Group have also
very hard and contributed to this document. Any list of people
doomed to omission and for that I apologize. In alphabetical order
the following people stand out in my mind due to the fact that
made direct contributions to this document
Bill Flanigan Elliott Ginsburg Paul Hoffman Russ Housley
Myers John Pawling Denis Pinkas Jim
Editor's
Blake
17720 NE 65th St Ste 201
Redmond, WA 98052
Phone: +1 425 376 0225
EMail: blaker@deming.
Ramsdell Standards Track [Page 12]
RFC 2632 S/MIME Version 3 Certificate Handling June 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Ramsdell Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
