As per Relevance of the word organization, we have this rfc below:
Network Working Group S.
Request for Comments: 1114
J.
IAB Privacy Task
August 1989
Privacy Enhancement for Internet Electronic Mail
Part II -- Certificate-Based Key
STATUS OF THIS
This RFC suggests a draft standard elective protocol for the
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
This RFC is the outgrowth of a series of IAB Privacy Task
meetings and of internal working papers distributed for
meetings. We would like to thank the members of the Privacy
Force for their comments and contributions at the meetings which
to the preparation of this RFC: David Balenson, Curt Barker,
Bishop, Morrie Gasser, Russ Housley, Dan Nessett, Mike Padlipsky,
Shirey, and Steve Wilbur
Table of
1. Executive Summary 2
2. Overview of Approach 3
3. Architecture 4
3.1 Scope and Restrictions 4
3.2 Relation to X.509 Architecture 7
3.3 Entities' Roles and Responsibilities 7
3.3.1 Users and User Agents 8
3.3.2 Organizational Notaries 9
3.3.3 Certification Authorities 11
3.3.3.1 Interoperation Across Certification Hierarchy Boundaries 14
3.3.3.2 Certificate Revocation 15
3.4 Certificate Definition and Usage 17
3.4.1 Contents and Use 17
3.4.1.1 Version Number 18
3.4.1.2 Serial Number 18
3.4.1.3 Subject Name 18
3.4.1.4 Issuer Name 19
3.4.1.5 Validity Period 19
3.4.1.6 Subject Public Component 20
Kent & Linn [Page 1]
RFC 1114 Mail Privacy: Key Management August 1989
3.4.1.7 Certificate Signature 20
3.4.2 Validation Conventions 20
3.4.3 Relation with X.509 Certificate Specification 22
NOTES 24
1. Executive
This is one of a series of RFCs defining privacy
mechanisms for electronic mail transferred using Internet
protocols. RFC-1113 (the successor to RFC 1040) prescribes
extensions and processing procedures for RFC-822 mail messages,
that suitable cryptographic keys are held by originators
recipients as a necessary precondition. RFC-1115
algorithms for use in processing privacy-enhanced messages, as
for in RFC-1113. This RFC defines a supporting key
architecture and infrastructure, based on public-key
techniques, to provide keying information to message originators
recipients. A subsequent RFC, the fourth in this series,
provide detailed specifications, paper and electronic
forms, etc. for the key management infrastructure described herein
The key management architecture described in this RFC is
with the authentication framework described in X.509. The
contributions of this RFC lie not in the specification of
communication protocols or algorithms but rather in procedures
conventions for the key management infrastructure. This
incorporates numerous conventions to facilitate near
implementation. Some of these conventions may be superceded in
as the motivations for them no longer apply, e.g., when X.500
similar directory servers become well established
The RSA cryptographic algorithm, covered in the U.S. by
administered through RSA Data Security, Inc. (hereafter
RSADSI) has been selected for use in this key management system
This algorithm has been selected because it provides all
necessary algorithmic facilities, is "time tested" and is
efficient to implement in either software or hardware. It is
the primary algorithm identified (at this time) for use
international standards where an asymmetric encryption algorithm
required. Protocol facilities (e.g., algorithm identifiers) exist
permit use of other asymmetric algorithms if, in the future,
becomes appropriate to employ a different algorithm for
management. However, the infrastructure described herein is
to use of the RSA algorithm in many respects and thus might
different if the underlying algorithm were to change
Current plans call for RSADSI to act in concert with
organizations as a "certifying authority" in a fashion
Kent & Linn [Page 2]
RFC 1114 Mail Privacy: Key Management August 1989
later in this RFC. RSADSI will offer a service in which it will
a certificate which has been generated by a user and vouched
either by an organization or by a Notary Public. This service
carry a $25 biennial fee which includes an associated license to
the RSA algorithm in conjunction with privacy protection
electronic mail. Users who do not come under the purview of the
patent, e.g., users affiliated with the U.S. government or
outside of the U.S., may make use of different certifying
and will not require a license from RSADSI. Procedures
interacting with these other certification authorities,
and distribution of revoked certificate lists from such authorities
etc. are outside the scope of this RFC. However, techniques
validating certificates issued by other authorities are
within the RFC to ensure interoperability across the
jurisdictional boundaries
2. Overview of
This RFC defines a key management architecture based on the use
public-key certificates, in support of the message encipherment
authentication procedures defined in RFC-1113. In the
architecture, a "certification authority" representing
organization applies a digital signature to a collection of
consisting of a user's public component, various information
serves to identify the user, and the identity of the
whose signature is affixed. (Throughout this RFC we have adopted
terms "private component" and "public component" to refer to
quantities which are, respectively, kept secret and made
available in asymmetric cryptosystems. This convention is adopted
avoid possible confusion arising from use of the term "secret key"
refer to either the former quantity or to a key in a
cryptosystem.) This establishes a binding between these
credentials, the user's public component and the organization
vouches for this binding. The resulting signed, data item is
a certificate. The organization identified as the
authority for the certificate is the "issuer" of that certificate
In signing the certificate, the certification authority vouches
the user's identification, especially as it relates to the user'
affiliation with the organization. The digital signature is
on behalf of that organization and is in a form which can
recognized by all members of the privacy-enhanced electronic
community. Once generated, certificates can be stored in
servers, transmitted via unsecure message exchanges, or
via any other means that make certificates easily accessible
message originators, without regard for the security of
transmission medium
Kent & Linn [Page 3]
RFC 1114 Mail Privacy: Key Management August 1989
Prior to sending an encrypted message, an originator must acquire
certificate for each recipient and must validate these certificates
Briefly, validation is performed by checking the digital signature
the certificate, using the public component of the issuer
private component was used to sign the certificate. The issuer'
public component is made available via some out of band
(described later) or is itself distributed in a certificate to
this validation procedure is applied recursively
Once a certificate for a recipient is validated, the public
contained in the certificate is extracted and used to encrypt
data encryption key (DEK) that is used to encrypt the message itself
The resulting encrypted DEK is incorporated into the X-Key-Info
of the message header. Upon receipt of an encrypted message,
recipient employs his secret component to decrypt this field
extracting the DEK, and then uses this DEK to decrypt the message
In order to provide message integrity and data origin authentication
the originator generates a message integrity code (MIC),
(encrypts) the MIC using the secret component of his public-key pair
and includes the resulting value in the message header in the X-MIC
Info field. The certificate of the originator is also included
the header in the X-Certificate field as described in RFC-1113,
order to facilitate validation in the absence of ubiquitous
services. Upon receipt of a privacy enhanced message, a
validates the originator's certificate, extracts the public
from the certificate, and uses that value to recover (decrypt)
MIC. The recovered MIC is compared against the locally
MIC to verify the integrity and data origin authenticity of
message
3.
3.1 Scope and
The architecture described below is intended to provide a basis
managing public-key cryptosystem values in support of
enhanced electronic mail (see RFC-1113) in the Internet environment
The architecture describes procedures for ordering certificates
issuers, for generating and distributing certificates, and for "
listing" of revoked certificates. Concurrent with the issuance
this RFC, RFC 1040 has been updated and reissued as RFC-1113
describe the syntax and semantics of new or revised header
used to transfer certificates, represent the DEK and MIC in
public-key context, and to segregate algorithm definitions into
separate RFC to facilitate the addition of other algorithms in
future. This RFC focuses on the management aspects of certificate
Kent & Linn [Page 4]
RFC 1114 Mail Privacy: Key Management August 1989
based, public-key cryptography for privacy enhanced mail while RFC
1113 addresses representation and processing aspects of such mail
including changes required by this key management technology
The proposed architecture imposes conventions for certification
which are not strictly required by the X.509 recommendation nor
the technology itself. The decision to impose these conventions
based in part on constraints imposed by the status of the
cryptosystem within the U.S. as a patented algorithm, and in part
the need for an organization to assume operational responsibility
certificate management in the current (minimal) directory
infrastructure for electronic mail. Over time, we anticipate
some of these constraints, e.g., directory service availability,
change and the procedures specified in the RFC will be reviewed
modified as appropriate
At this time, we propose a system in which user
represent the leaves in a shallow (usually two tier)
hierarchy (tree). Organizations which act as issuers are
by certificates higher in the tree. This convention minimizes
complexity of validating user certificates by limiting the length
"certification paths" and by making very explicit the
between a certificate issuer and a user. Note that
organizations may act as issuers in the proposed architecture; a
certificate may not appear in a certification path, except as
terminal node in the path. These conventions result in
certification hierarchy which is a compatible subset of
permitted under X.509, with respect to both syntax and semantics
The RFC proposes that RSADSI act as a "co-issuer" of certificates
behalf of most organizations. This can be effected in a
which is "transparent" so that the organizations appear to be
issuers with regard to certificate formats and validation procedures
This is effected by having RSADSI generate and hold the
components used to sign certificates on behalf of organizations.
motivation for RSADSI's role in certificate signing is twofold
First, it simplifies accounting controls in support of licensing
ensuring that RSADSI is paid for each certificate. Second,
contributes to the overall integrity of the system by establishing
uniform, high level of protection for the private-components used
sign certificates. If an organization were to sign
directly on behalf of its affiliated users, the organization
have to establish very stringent security and accounting
and enter into (elaborate) legal agreements with RSADSI in order
provide a comparable level of assurance. Requests by
to perform direct certificate signing will be considered on a case
by-case basis, but organizations are strongly urged to make use
the facilities proposed by this RFC
Kent & Linn [Page 5]
RFC 1114 Mail Privacy: Key Management August 1989
Note that the risks associated with disclosure of an organization'
secret component are different from those associated with
of a user's secret component. The former component is used only
sign certificates, never to encrypt message traffic. Thus
exposure of an organization's secret component could result in
generation of forged certificates for users affiliated with
organization, but it would not affect privacy-enhanced messages
are protected using legitimate certificates. Also note that
certificates generated as a result of such a disclosure are
traceable to the issuing authority which holds this component, e.g.,
RSADSI, due to the non-repudiation feature of the digital signature
The certificate registration and signing procedures established
this RFC would provide non-repudiable evidence of disclosure of
organization's secret component by RSADSI. Thus this RFC
use of RSADSI as a co-issuer for certificates until such time
technical security mechanisms are available to provide a similar
system-wide level of assurance for (distributed) certificate
by organizations
We identify two classes of exceptions to this certificate
paradigm. First, the RSA algorithm is patented only within the U.S.,
and thus it is very likely that certificate signing by issuers
arise outside of the U.S., independent of RSADSI. Second,
research that led to the RSA algorithm was sponsored by the
Science Foundation, and thus the U.S. government retains royalty-
license rights to the algorithm. Thus the U.S. government
establish a certificate generation facilities for its
users. A number of the procedures described in this document
only to the use of RSADSI as a certificate co-issuer; all
certificate generation practices lie outside the scope of this RFC
This RFC specifies procedures by which users order
either directly from RSADSI or via a representative in
organization with which the user holds some affiliation (e.g.,
user's employer or educational institution). Syntactic
are made which allow a recipient to determine, to some granularity
which identifying information contained in the certificate is
for by the certificate issuer. In particular, organizations
usually be vouching for the affiliation of a user with
organization and perhaps a user's role within the organization,
addition to the user's name. In other circumstances, as discussed
section 3.3.3, a certificate may indicate that an issuer vouches
for the user's name, implying that any other identifying
contained in the certificate may not have been validated by
issuer. These semantics are beyond the scope of X.509, but are
incompatible with that recommendation
The key management architecture described in this RFC has
Kent & Linn [Page 6]
RFC 1114 Mail Privacy: Key Management August 1989
designed to support privacy enhanced mail as defined in this RFC
RFC-1113, and their successors. Note that this infrastructure
supports X.400 mail security facilities (as per X.411) and thus
the way for transition to the OSI/CCITT Message Handling
paradigm in the Internet in the future. The certificate issued to
user for the $25 biennial fee will grant to the user identified
that certificate a license from RSADSI to employ the RSA
for certificate validation and for encryption and
operations in this electronic mail context. No use of the
outside the scope defined in this RFC is authorized by this
as of this time. Expansion of the license to other Internet
applications is possible but not yet authorized. The license
by this fee does not authorize the sale of software or
incorporating the RSA algorithm; it is an end-user license, not
developer's license
3.2 Relation to X.509
CCITT 1988 Recommendation X.509, "The Directory -
Framework", defines a framework for authentication of
involved in a distributed directory service. Strong authentication
as defined in X.509, is accomplished with the use of public-
cryptosystems. Unforgeable certificates are generated
certification authorities; these authorities may be
hierarchically, though such organization is not required by X.509.
There is no implied mapping between a certification hierarchy and
naming hierarchy imposed by directory system naming attributes.
public-key certificate approach defined in X.509 has also
adopted in CCITT 1988 X.411 in support of the message
application
This RFC interprets the X.509 certificate mechanism to serve
needs of privacy-enhanced mail in the Internet environment.
certification hierarchy proposed in this RFC in support of
enhanced mail is intentionally a subset of that allowed under X.509.
In large part constraints have been levied in order to
certificate validation in the absence of a widely available, user
level directory service. The certification hierarchy proposed
also embodies semantics which are not explicitly addressed by X.509,
but which are consistent with X.509 precepts. The
semantic constraints have been adopted to explicitly
questions of issuer "authority" which we feel are not well defined
X.509.
3.3 Entities' Roles and
One way to explain the architecture proposed by this RFC is
examine the various roles which are defined for various entities
Kent & Linn [Page 7]
RFC 1114 Mail Privacy: Key Management August 1989
the architecture and to describe what is required of each entity
order for the proposed system to work properly. The
sections identify three different types of entities within
architecture: users and user agents, organizational notaries,
certification authorities. For each class of entity we describe
(electronic and paper) procedures which the entity must execute
part of the architecture and what responsibilities the entity
as a function of its role in the architecture. Note that
infrastructure described here applies to the situation wherein
acts as a co-issuer of certificates, sharing the role
certification authority as described later. Other
authority arrangements may employ different procedures and are
addressed by this RFC
3.3.1 Users and User
The term User Agent (UA) is taken from CCITT X.400 Message
Systems (MHS) Recommendations, which define it as follows: "In
context of message handling, the functional object, a component
MHS, by means of which a single direct user engages in
handling." UAs exchange messages by calling on a supporting
Transfer Service (MTS).
A UA process supporting privacy-enhanced mail processing must
the private component of its associated entity (ordinarily, a
user) from disclosure. We anticipate that a user will
ancillary software (not otherwise associated with the UA) to
his public/private component pair and to compute the (one-way
message hash required by the registration procedure. The
component, along with information that identifies the user, will
transferred to an organizational notary (see below) for inclusion
an order to an issuer. The process of generating public and
components is a local matter, but we anticipate Internet-
distribution of software suitable for component-pair generation
facilitate the process. The mechanisms used to transfer the
component and the user identification information must preserve
integrity of both quantities and bind the two during this transfer
This proposal establishes two ways in which a user may order
certificate, i.e., through the user's affiliation with
organization or directly through RSADSI. In either case, a user
be required to send a paper order to RSADSI on a form described in
subsequent RFC and containing the following information
1. Distinguished Name elements (e.g., full legal name
organization name, etc.)
2. Postal
Kent & Linn [Page 8]
RFC 1114 Mail Privacy: Key Management August 1989
3. Internet electronic mail
4. A message hash function, binding the above information to
user's public
Note that the user's public component is NOT transmitted via
paper path. In part the rationale here is that the public
consists of many (>100) digits and thus is prone to error if it
copied to and from a piece of paper. Instead, a message hash
computed on the identifying information and the public component
this (smaller) message hash value is transmitted along with
identifying information. Thus the public component is
only via an electronic path, as described below
If the user is not affiliated with an organization which
established its own "electronic notary" capability (an
notary or "ON" as discussed in the next section), then this
registration form must be notarized by a Notary Public. If the
is affiliated with an organization which has established one or
ONs, the paper registration form need not carry the endorsement of
Notary Public. Concurrent with the paper registration, the user
send the information outlined above, plus his public component
either to his ON, or directly to RSADSI if no appropriate ON
available to the user. Direct transmission to RSADSI of
information will be via electronic mail, using a
described in a subsequent RFC. The paper registration must
accompanied by a check or money order for $25 or an organization
establish some other billing arrangement with RSADSI. The
(and default) lifetime of a certificate ordered through this
is two years
The transmission of ID information and public component from a
to his ON is a local matter, but we expect electronic mail will
be the preferred approach in many circumstances and we
general distribution of software to support this process. Note
it is the responsibility of the user and his organization to
the integrity of this transfer by some means deemed adequately
for the local computing and communication environment. There is
requirement for secrecy in conjunction with this
transfer, but the integrity of the information must be ensured
3.3.2 Organizational
An organizational notary is an individual who acts as a
for certificate orders originating within an administrative
such as a corporation or a university. An ON represents
organization or organizational unit (in X.500 naming terms), and
assumed to have some independence from the users on whose
Kent & Linn [Page 9]
RFC 1114 Mail Privacy: Key Management August 1989
certificates are ordered. An ON will be restricted
mechanisms implemented by the issuing authority, e.g., RSADSI,
ordering certificates properly associated with the domain of that ON
For example, an ON for BBN should not be able to order
for users affiliated with MIT or MITRE, nor vice versa. Similarly
if a corporation such as BBN were to establish ONs on a per
subsidiary basis (corresponding to organization units in X.500
parlance), then an ON for the BBN Communications subsidiary
not be allowed to order a certificate for a user who
affiliation with the BBN Software Products subsidiary
It can be assumed that the set of ONs changes relatively slowly
that the number of ONs is relatively small in comparison with
number of users. Thus a more extensive, higher assurance process
reasonably be associated with ON accreditation than with per-
certificate ordering. Restrictions on the range of information
an ON is authorized to certify are established as part of this
elaborate registration process. The procedures by
organizations and organizational units are established in the
database, and by which ONs are registered, will be described in
subsequent RFC
An ON is responsible for establishing the correctness and
of information incorporated in an order, and will generally vouch
(certify) the accuracy of identity information at a granularity
than that provided by a Notary Public. We do not believe that it
feasible to enforce uniform standards for the user
process across all ONs, but we anticipate that organizations
endeavor to maintain high standards in this process in recognition
the "visibility" associated with the identification data contained
certificates. An ON also may constrain the validity period of
ordered certificate, restricting it to less than the default two
interval imposed by the RSADSI license agreement
An ON participates in the certificate ordering process by
and validating identification information from a user and
this information to RSADSI. The ON accepts the electronic
information described above (Distinguished Name elements,
address, public component, and message hash computed on all of
data) from a user. (The representation for user-to-ON
of this data is a local matter, but we anticipate that the
specified for ON-to-RSADSI representation of this data will often
employed.) The ON sends an integrity-protected (as described
RFC-1113) electronic message to RSADSI, vouching for the
of the binding between the public component and the
data. Thus, to support this function, each ON will hold
certificate as an individual user within the organization which
represents. RSADSI will maintain a database which identifies
Kent & Linn [Page 10]
RFC 1114 Mail Privacy: Key Management August 1989
users who also act as ONs and the database will specify
on credentials which each ON is authorized to certify.
electronic mail representation for a user's certificate data in an
message to RSADSI will be specified in a subsequent RFC
3.3.3 Certification
In X.509 the term "certification authority" is defined as "
authority trusted by one or more users to create and
certificates". This alternate expansion for the acronym "CA"
roughly equivalent to that contemplated as a "central authority"
RFC-1040 and RFC-1113. The only difference is that in X.509 there
no requirement that a CA be a distinguished entity or that a CA
a large number of users, as envisioned in these RFCs. Rather,
user who holds a certificate can, in the X.509 context, act as a
for any other user. As noted above, we have chosen to restrict
role of CA in this electronic mail environment to
entities, to simplify the certificate validation process, to
semantics which support organizational affiliation as a basis
certification, and to facilitate license accountability
In the proposed architecture, individuals who are affiliated
(registered) organizations will go through the process
above, in which they forward their certificate information to
ON for certification. The ON will, based on local procedures,
the accuracy of the user's credentials and forward this
to RSADSI using privacy-enhanced mail to ensure the integrity
authenticity of the information. RSADSI will carry out the
certificate generation process on behalf of the
represented by the ON. Recall that it is the identity of
organization which the ON represents, not the ON's identity,
appears in the issuer field of the user certificate. Therefore it
the private component of the organization, not the ON, which is
to sign the user certificate
In order to carry out this procedure RSADSI will serve as
repository for the private components associated with
representing organizations or organizational units (but
individuals). In effect the role of CA will be shared between
organizational notaries and RSADSI. This shared role will not
visible in the syntax of the certificates issued under
arrangement nor is it apparent from the validation procedure
applies to these certificates. In this sense, the role of RSADSI
the actual signer of certificates on behalf of organizations
transparent to this aspect of system operation
If an organization were to carry out the certificate signing
locally, and thus hold the private component associated with
Kent & Linn [Page 11]
RFC 1114 Mail Privacy: Key Management August 1989
organization certificate, it would need to contact RSADSI to
security safeguards, special legal agreements, etc. A number
requirements would be imposed on an organization if such an
were persued. The organization would be required to
additional legal instruments with RSADSI, e.g., to ensure
accounting for certificates generated by the organization.
software will be required to support the certificate signing process
distinct from the software required for an ON. Stringent procedural
physical, personnel and computer security safeguards would
required to support this process, to maintain a relatively high
of security for the system as a whole. Thus, at this time, it is
recommended that organizations pursue this approach although
certificate generation is not expressly precluded by the
architecture
RSADSI has offered to operate a service in which it serves as a
for users who are not affiliated with any organization or who
affiliated with an organization which has not opted to establish
organizational notary. To distinguish certificates issued to
"non-affiliated" users the distinguished string "Notary" will
as the organizational unit name of the issuer of the certificate
This convention will be employed throughout the system. Thus
only RSADSI but any other organization which elects to provide
type of service to non-affiliated users may do so in a
fashion. Hence a corporation might issue a certificate with
"Notary" designation to students hired for the summer,
differentiate them from full-time employees. At least in the case
RSADSI, the standards for verifying user credentials that carry
designation will be well known and widely recognized (e.g.,
Public endorsement).
To illustrate this convention, consider the following examples
Employees of RSADSI will hold certificates which indicate "RSADSI"
the organization in both the issuer field and the subject field
perhaps with no organizational unit specified. Certificates
directly from RSADSI, by user's who are not affiliated with any ON
will also indicate "RSADSI" as the organization and will
"Notary" as an organizational unit in the issuer field. However
these latter certificates will carry some other designation
organization (and, optionally, organizational unit) in the
field. Moreover, an organization designated in the subject field
such a certificate will not match any for which RSADSI has an
registered (to avoid possible confusion).
In all cases described above, when a certificate is generated
will send a paper reply to the ordering user, including two
hash functions
Kent & Linn [Page 12]
RFC 1114 Mail Privacy: Key Management August 1989
1. a message hash computed on the user's identifying
and public component (and sent to RSADSI in the
process), to guarantee its integrity across the
process,
2. a message hash computed on the public component of RSADSI,
provide independent authentication for this public
which is transmitted to the user via email (see below).
RSADSI will send to the user via electronic mail (not
enhanced) a copy of his certificate, a copy of the
certificate identified in the issuer field of the user's certificate
and the public component used to validate certificates signed
RSADSI. The "issuer" certificate is included to simplify
validation process in the absence of a user-level directory system
its distribution via this procedure will probably be phased out
the future. Thus, as described in RFC-1113, the originator of
message is encouraged, though not required, to include
certificate, and that of its issuer, in the privacy enhanced
header (X-Issuer-Certificate) to ensure that each recipient
process the message using only the information contained in
header. The organization (organizational unit) identified in
subject field of the issuer certificate should correspond to
which the user claims affiliation (as declared in the subject
of his certificate). If there is no appropriate
between these fields, recipients ought to be suspicious of
implied certification path. This relationship should hold except
the case of "non-affiliated" users for whom the "Notary"
is employed
In contrast, the issuer field of the issuer's certificate
specify "RSADSI" as the organization, i.e., RSADSI will certify
organizational certificates. This convention allows a recipient
validate any originator's certificate (within the
certification hierarchy) in just two steps. Even if an
establishes a certification hierarchy involving organizational units
certificates corresponding to each unit can be certified both
RSADSI and by the organizational entity immediately superior to
unit in the hierarchy, so as to preserve this short
path feature. First, the public component of RSADSI is employed
validate the issuer's certificate. Then the issuer's
component is extracted from that certificate and is used to
the originator's certificate. The recipient then extracts
originator's public component for use in processing the X-Mic-
field of the message (see and RFC-1113).
The electronic representation used for transmission of the data
described above (between an ON and RSADSI) will be contained in
Kent & Linn [Page 13]
RFC 1114 Mail Privacy: Key Management August 1989
subsequent RFC. To verify that the registration process has
successfully completed and to prepare for exchange of privacy
enhanced electronic mail, the user should perform the
steps
1. extract the RSADSI public component, the issuer's
and the user's certificate from the
2. compute the message hash on the RSADSI public component
compare the result to the corresponding message hash that
included in the paper
3. use the RSADSI public component to validate the signature
the issuer's certificate (RSADSI will be the issuer of
certificate
4. extract the organization public component from the
issuer's certificate and use this public component
validate the user
5. extract the identification information and public
from the user's certificate, compute the message hash on
and compare the result to the corresponding message
value transmitted via the paper
For a user whose order was processed via an ON, successful
of these steps demonstrates that the certificate issued to
matches that which he requested and which was certified by his ON
It also demonstrates that he possesses the (correct) public
for RSADSI and for the issuer of his certificate. For a user
order was placed directly with RSADSI, this process demonstrates
his certificate order was properly processed by RSADSI and that
possesses the valid issuer certificate for the RSADSI Notary.
user can use the RSADSI public component to validate
certificates for organizations other than his own. He can employ
public component associated with his own organization to
certificates issued to other users in his organization
3.3.3.1 Interoperation Across Certification Hierarchy
In order to accommodate interoperation with other
authorities, e.g., foreign or U.S. government CAs, two
will be adopted. First, all certifying authorities must agree
"cross-certify" one another, i.e., each must be willing to sign
certificate in which the issuer is that certifying authority and
subject is another certifying authority. Thus, RSADSI might
a certificate in which it is identified as the issuer and
certifying authority for the U.S. government is indentified as
Kent & Linn [Page 14]
RFC 1114 Mail Privacy: Key Management August 1989
subject. Conversely, that U.S. government certifying authority
generate a certificate in which it is the issuer and RSADSI is
subject. This cross-certification of certificates for "top-level
CAs establishes a basis for "lower level" (e.g., organization
user) certificate validation across the hierarchy boundaries.
avoids the need for users in one certification hierarchy to engage
some "out-of-band" procedure to acquire a public-key for use
validating certificates from a different certification hierarchy
The second convention is that more than one X-Issuer-
field may appear in a privacy-enhanced mail header. Multiple
certificates can be included so that a recipient can more
validate an originator's certificate when originator and
are not part of a common CA hierarchy. Thus, for example, if
originator served by the RSADSI certification hierarchy sends
message to a recipient served by a U.S. government hierarchy,
originator could (optionally) include an X-Issuer-Certificate
containing a certificate issued by the U.S. government CA for RSADSI
In this fashion the recipient could employ his public component
the U.S. government CA to validate this certificate for RSADSI,
which he would extract the RSADSI public component to validate
certificate for the originator's organization, from which he
extract the public component required to validate the originator'
certificate. Thus, more steps can be required to
certificates when certification hierarchy boundaries are crossed,
the same basic procedure is employed. Remember that caching
certificates by UAs can significantly reduce the effort required
process messages and so these examples should be viewed as "
case" scenarios
3.3.3.2 Certificate
X.509 states that it is a CA's responsibility to maintain
1. a time-stamped list of the certificates it issued which
been
2. a time-stamped list of revoked certificates
other
There are two primary reasons for a CA to revoke a certificate, i.e.,
suspected compromise of a secret component (invalidating
corresponding public component) or change of user
(invalidating the Distinguished Name). As described in X.509, "
listing" is one means of propagating information relative
certificate revocation, though it is not a perfect mechanism.
particular, an X.509 Revoked Certificate List (RCL) indicates
the age of the information contained in it; it does not provide
Kent & Linn [Page 15]
RFC 1114 Mail Privacy: Key Management August 1989
basis for determining if the list is the most current RCL
from a given CA. To help address this concern, the
architecture establishes a format for an RCL in which not only
date of issue, but also the next scheduled date of issue
specified. This is a deviation from the format specified in X.509.
Adopting this convention, when the next scheduled issue date
a CA must issue a new RCL, even if there are no changes in the
of entries. In this fashion each CA can independently establish
advertise the frequency with which RCLs are issued by that CA.
that this does not preclude RCL issuance on a more frequent basis
e.g., in case of some emergency, but no Internet-wide mechanisms
architected for alerting users that such an unscheduled issuance
taken place. This scheduled RCL issuance convention allows
(UAs) to determine whether a given RCL is "out of date," a
not available from the standard RCL format
A recent (draft) version of the X.509 recommendation calls for
RCL to contain the serial numbers of certificates which have
revoked by the CA administering that list, i.e., the CA that
identified as the issuer for the corresponding revoked certificates
Upon receipt of a RCL, a UA should compare the entries against
cached certificate information, deleting cache entries which
RCL entries. (Recall that the certificate serial numbers are
only for each issuer, so care must be exercised in effecting
cache search.) The UA should also retain the RCL to screen
messages to detect use of revoked certificates carried in
message headers. More specific details for processing RCL are
the scope of this RFC as they are a function of local
management techniques
In the architecture defined by this RFC, a RCL will be maintained
each CA (organization or organizational unit), signed using
private component of that organization (and thus verifiable using
public component of that organization as extracted from
certificate). The RSADSI Notary organizational unit is included
this collection of RCLs. CAs operated under the auspices of the U.S
government or foreign CAs are requested to provide RCLs conforming
these conventions, at least until such time as X.509 RCLs
equivalent functionality, in support of interoperability with
Internet community. An additional, "top level" RCL, will
maintained by RSAD-SI, and should be maintained by other "top level
CAs, for revoked organizational certificates
The hot listing procedure (expect for this top level RCL) will
effected by having an ON from each organization transmit to RSADSI
list of the serial numbers of users within his organization, to
hot listed. This list will be transmitted using privacy-
Kent & Linn [Page 16]
RFC 1114 Mail Privacy: Key Management August 1989
mail to ensure authenticity and integrity and will
representation conventions to be provided in a subsequent RFC
RSADSI will format the RCL, sign it using the private component
the organization, and transmit it to the ON for dissemination,
a representation defined in a subsequent RFC. Means
dissemination of RCLs, both within the administrative domain of a
and across domain boundaries, are not specified by this proposal
However, it is anticipated that each hot list will also be
via network information center databases, directory servers, etc
The following ASN.1 syntax, derived from X.509, defines the format
RCLs for use in the Internet privacy enhanced email environment.
the ASN.1 definition of certificates (later in this RFC or in X.509,
Annex G) for comparison
revokedCertificateList ::= SIGNED SEQUENCE {
signature AlgorithmIdentifier
issuer Name
list SEQUENCE RCLEntry
lastUpdate UTCTime
nextUpdate UTCTime
RCLEntry ::= SEQUENCE {
subject CertificateSerialNumber
revocationDate UTCTime
3.4 Certificate Definition and
3.4.1 Contents and
A certificate contains the following contents
1.
2. serial
3. certificate signature (and associated algorithm identifier
4. issuer
5. validity
6. subject
7. subject public component (and associated algorithm identifier
This section discusses the interpretation and use of each of
certificate elements
Kent & Linn [Page 17]
RFC 1114 Mail Privacy: Key Management August 1989
3.4.1.1 Version
The version number field is intended to facilitate orderly changes
certificate formats over time. The initial version number
certificates is zero (0).
3.4.1.2 Serial
The serial number field provides a short form, unique identifier
each certificate generated by an issuer. The serial number is
in RCLs to identify revoked certificates instead of including
certificates. Thus each certificate generated by an issuer
contain a unique serial number. It is suggested that these
be issued as a compact, monotonic increasing sequence
3.4.1.3 Subject
A certificate provides a representation of its subject's identity
organizational affiliation in the form of a Distinguished Name.
fundamental binding ensured by the privacy enhancement mechanisms
that between public-key and the user identity. CCITT
X.500 defines the concept of Distinguished Name
Version 2 of the U.S. Government Open Systems Interconnection
(GOSIP) specifies maximum sizes for O/R Name attributes. Since
of these attributes also appear in Distinguished Names, we
adopted the O/R Name attribute size constraints specified in
and noted below. Using these size constraints yields a
Distinguished Name length (exclusive of ASN encoding) of two-
fifty-nine (259) characters, based on the required and
attributes described below for subject names. The
attributes are required in subject Distinguished Names for
of this RFC
1. Country Name in standard encoding (e.g., the two-
Printable String "US" assigned by ISO 3166 as the
for the United States of America, the string "GB" assigned
the identifier for the United Kingdom, or the string "NQ
assigned as the identifier for Dronning Maud Land).
ASCII character length of three (3).
2. Organizational Name (e.g., the Printable String "Bolt
and Newman, Inc."). Maximum ASCII character length
sixty-four (64).
3. Personal Name (e.g., the X.402/X.411 structured
String encoding for the name John Linn). Maximum
character length of sixty-four (64).
Kent & Linn [Page 18]
RFC 1114 Mail Privacy: Key Management August 1989
The following attributes are optional in subject Distinguished
for purposes of this RFC
1. Organizational Unit Name(s) (e.g., the Printable String "
Communications Corporation") A hierarchy of up to
organizational unit names may be provided; the
significant member of the hierarchy is represented first
Each of these attributes has a maximum ASCII character length
thirty-two (32), for a total of one-hundred and twenty-
(128) characters if all four are present
3.4.1.4 Issuer
A certificate provides a representation of its issuer's identity,
the form of a Distinguished Name. The issuer identification
needed in order to determine the appropriate issuer public
to use in performing certificate validation. The
attributes are required in issuer Distinguished Names for purposes
this RFC
1. Country Name (e.g., encoding for "US")
2. Organizational
The following attributes are optional in issuer Distinguished
for purposes of this RFC
1. Organizational Unit Name(s). (A hierarchy of up to
organizational unit names may be provided; the least
member of the hierarchy is represented first.) If
issuer is vouching for the user identity in the Notary
described above, then exactly one instance of this
must be present and it must consist of the string "Notary".
As noted earlier, only organizations are allowed as issuers in
proposed authentication hierarchy. Hence the Distinguished Name
an issuer should always be that of an organization, not a user,
thus no Personal Name field may be included in the Distinguished
of an issuer
3.4.1.5 Validity
A certificate carries a pair of time specifiers, indicating the
and end of the time period over which a certificate is intended to
used. No message should ever be prepared for transmission with
non-current certificate, but recipients should be prepared to
messages processed using recently-expired certificates. This
results from the unpredictable (and sometimes substantial
Kent & Linn [Page 19]
RFC 1114 Mail Privacy: Key Management August 1989
transmission delay of the staged-delivery electronic
environment. The default and maximum validity period
certificates issued in this system will be two years
3.4.1.6 Subject Public
A certificate carries the public component of its associated entity
as well as an indication of the algorithm with which the
component is to be used. For purposes of this RFC, the
identifier will indicate use of the RSA algorithm, as specified
RFC-1115. Note that in this context, a user's public component
actually the modulus employed in RSA algorithm calculations.
"universal" (public) exponent is employed in conjunction with
modulus to complete the system. Two choices of exponents
recommended for use in this context and are described in
3.4.3. Modulus size will be permitted to vary between 320 and 632
bits
3.4.1.7 Certificate
A certificate carries a signature algorithm identifier and
signature, applied to the certificate by its issuer. The
is validated by the user of a certificate, in order to determine
the integrity of its contents have not been compromised subsequent
generation by a CA. An encrypted, one-way hash will be employed
the signature algorithm. Hash functions suitable for use in
context are notoriously difficult to design and tend to
computationally intensive. Initially we have adopted a hash
developed by RSADSI and which exhibits performance roughly
to the DES (in software). This same function has been selected
use in other contexts in this system where a hash function (
hash algorithm) is required, e.g., MIC for multicast messages.
the future we expect other one-way hash functions will be added
the list of algorithms designated for this purpose
3.4.2 Validation
Validating a certificate involves verifying that the
affixed to the certificate is valid, i.e., that the hash
computed on the certificate contents matches the value that
from decrypting the signature field using the public component of
issuer. In order to perform this operation the user must possess
public component of the issuer, either via some integrity-
channel, or by extracting it from another (validated) certificate
In the proposed architecture this recursive operation is
quickly by adopting the convention that RSADSI will certify
certificates of all organizations or organizational units which
as issuers for end users. (Additional validation steps may
Kent & Linn [Page 20]
RFC 1114 Mail Privacy: Key Management August 1989
required for certificates issued by other CAs as described in
3.3.3.1.)
Certification means that RSADSI will sign certificates in which
subject is the organization or organizational unit and for
RSADSI is the issuer, thus implying that RSADSI vouches for
credentials of the subject. This is an appropriate construct
each ON representing an organization or organizational unit must
registered with RSADSI via a procedure more rigorous than
user registration. This does not preclude an organizational
from also holding a certificate in which the "parent"
(or organizational unit) is the issuer. Both certificates
appropriate and permitted in the X.509 framework. However, in
to facilitate the validation process in an environment where user
level directory services are generally not available, we will (
this time) adopt this certification convention
The public component needed to validate certificates signed by
(in its role as a CA for issuers) is transmitted to each user as
of the registration process (using electronic mail with independent
postal confirmation via a message hash). Thus a user will be able
validate any user certificate (from the RSADSI hierarchy) in at
two steps. Consider the situation in which a user receives a
enhanced message from an originator with whom the recipient has
previously corresponded. Based on the certification
described above, the recipient can use the RSADSI public component
validate the issuer's certificate contained in the X-Issuer
Certificate field. (We recommend that, initially, the
include his organization's certificate in this optional field so
the recipient need not access a server or cache fo