The PEM WG met during the San Diego IETF meeting 3/16-20. The
written comments provided John Linn (and distributed to this mailing
list) were reviewed and adopted. Several other changes were made to
the specification based on additional written comments from Jeff
Schiller, plus the PEM-DEV messages regarding encoding of the
signature as described at the end of Appendix A. One significant
change deals with the CRL database which was to be maintained by the
ICA. Now, each PCA will be responsible for publishing a mail address
to which CRL queries can be sent, and another for CRL updates from
CAs. It is the responsibility of the PCAs, working with the ICA, to
provide access to the complete CRL database via these interfaces.
details of the managment of this database will not be part of the RFC,
as this is exclusively a PCA-ICA interface issue. The description of
the DN conflcit detection database has been revised and the
specification of the protocol for accessing this database will not
appear as Appendix B, but rather will become a separate document.
Generally the version of the document (1114E) distributed
prior to the meeting was well received and the concensus is that it is
almost ready for publication as an ID. New versions of 1113 and 1115
should be available very soon, and an updated version of FORMS
(removing all the text not generally relevant to UAs) should be
forthcoming as well. Then all 4 documents can move on to become RFCs.
Here for your review is 1114F, revised as noted above. Please get
written comments to me, and the community, via this list as soon as
possible, so that we may proceed quickly.
Steve
--------------------------------------------------------------------
23 March 1992
Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management
STATUS OF THIS MEMO
This draft document will be submitted to the RFC editor as a
standards document, and is submitted as a proposed successor to RFC
1114. References within the text of this Internet-Draft to this
document as an RFC, or to related Internet-Drafts cited as "RFC
[1113E]", "RFC [1115C]", and "RFC [FORMS-C]" are not intended to
carry any connotation about the progression of these Internet-Drafts
through the IAB standards-track review cycle. Distribution of this
memo is unlimited. This specification was developed by the PEM
Working Group of the IETF, based on work initiated in the Internet
Research Task Force's Privacy and Security Research Group. Comments
should be sent to <pem-dev(_at_)tis(_dot_)com>.
This RFC specifies a key management infrastructure for use by the
Internet community, and requests discussion and suggestions for
improvements.
ACKNOWLEDGMENT
This RFC is the outgrowth of a series of meetings of the Privacy and
Security Research Group of the IRTF and the PEM Work Group of the
IETF. I would like to thank the members of the PSRG and the PEM WG
for their comments and contributions at the meetings which led to the
preparation of this RFC. I also would like to thank contributors to
the PEM-DEV mailing list who have provided valuable input which is
reflected in this RFC.
1 Executive Summary
This is one of a series of RFCs defining privacy enhancement
mechanisms for electronic mail transferred using Internet mail
protocols. RFC [1113E] prescribes protocol extensions and processing
procedures for RFC-822 mail messages, given that suitable
cryptographic keys are held by originators and recipients as a
necessary precondition. RFC [1115C] specifies algorithms, modes and
associated identifiers for use in processing privacy-enhanced
Kent (BBN) [Page 1]
PEM-1114F Certificate-Based Key Management March 1992
messages, as called for in RFC [1113E] and this RFC. This RFC
defines a supporting key management architecture and infrastructure,
based on public-key certificate techniques, to provide keying
information to message originators and recipients. RFC [FORMS-C]
provides additional specifications for services in conjunction with
the key management infrastructure described herein.
The key management architecture described in this RFC is compatible
with the authentication framework described in CCITT 1988 X.509 [2].
This RFC goes beyond X.509 by establishing procedures and conventions
for a key management infrastructure for use with Privacy Enhanced
Mail (PEM) and with other protocols, from both the TCP/IP and OSI
suites, in the future. There are several motivations for
establishing these procedures and conventions (as opposed to relying
only on the very general framework outlined in X.509):
- It is important that a certificate management infrastructure
for use in the Internet community accommodate a range of
clearly-articulated certification policies for both users and
organizations in a well-architected fashion. Mechanisms
must be provided to enable each user to be aware of the
policies governing any certificate which the user may
encounter. This requires the introduction and
standardization of procedures and conventions that are
outside the scope of X.509.
-The procedures for authenticating originators and recipient in
the course of message submission and delivery should be
simple, automated and uniform despite the existence of
differing certificate management policies. For example,
users should not have to engage in careful examination of a
complex set of certification relationships in order to
evaluate the credibility of a claimed identity.
-The authentication framework defined by X.509 is designed to
operate in the X.500 directory server environment. However
X.500 directory servers are not expected to be ubiquitous in
the Internet in the near future, so some conventions are
adopted to facilitate operation of the key management
infrastructure in the near term.
-Public key cryptosystems are central to the authentication
technology of X.509 and those which enjoy the most widespread
use are patented in the U.S. Although this certification
Kent (BBN) [Page 2]
PEM-1114F Certificate-Based Key Management March 1992
management scheme is compatible with the use of different
digital signature algorithms, it is anticipated that the RSA
cryptosystem will be used as the primary signature algorithm
in establishing the Internet certification hierarchy.
Special license arrangements have been made to facilitate the
use of this algorithm in the U.S. portion of Internet
environment.
The infrastructure specified in this RFC establishes a single root
for all certification within the Internet, the Internet Certification
Authority (ICA). The ICA establishes global policies, described in
this RFC, which apply to all certification effected under this
hierarchy. Beneath ICA root are Policy Certification Authorities
(PCAs), each of which establishes and publishes (in the form of an
informational RFC) its policies for registration of users or
organizations. Each PCA is certified by the ICA. (1) Below PCAs,
Certification Authorities (CAs) will be established to certify users
and subordinate organizational entities (e.g., departments, offices,
subsidiaries, etc.). Initially, we expect the majority of users will
be registered via organizational affiliation, consistent with current
practices for how most user mailboxes are provided. In this sense
the registration is analogous to the issuance of a university or
company ID card.
Some CAs are expected to provide certification for residential users
in support of users who wish to register independent of any
organizational affiliation. Over time, we anticipate that civil
government entities which already provide analogous identification
services in other contexts, e.g., driver's licenses, may provide
this service. For users who wish anonymity while taking advantage of
PEM privacy facilities, one or more PCAs will be established with
policies that allow for registration of users, under subordinate CAs,
who do not wish to disclose their identities.
_______________
(1) It is desirable that there be a relatively small number of
PCAs, each with a substantively different policy, to facilitate
user familiarity with the set of PCA policies. However there is
no explicit requirement that the set of PCAs be limited in this
fashion.
Kent (BBN) [Page 3]
PEM-1114F Certificate-Based Key Management March 1992
2 Overview of Approach
This RFC defines a key management architecture based on the use of
public-key certificates, primarily in support of the message
encipherment and authentication procedures defined in RFC [1113E].
The concept of public-key certificates is defined in X.509 and this
architecture is a compliant subset of that envisioned in X.509.
Briefly, a (public-key) certificate is a data structure which
contains the name of a user (the "subject"), the public component (2)
of that user, and the name of an entity (the "issuer") which vouches
that the public component is bound to the named user. This data,
along with a time interval over which the binding is claimed to be
valid, is cryptographically signed by the issuer using the issuer's
private component. The subject and issuer names in certificates are
Distinguished Names (DNs) as defined in the directory system (X.500).
Once signed, certificates can be stored in directory servers,
transmitted via non-secure message exchanges, or distributed via any
other means that make certificates easily accessible to message
system users, without regard for the security of the transmission
medium. Certificates are used in PEM to provide the originator of a
message with the (authenticated) public component of each recipient
and to provide each recipient with the (authenticated) public
component of the originator. The following brief discussion
illustrates the procedures for both originator and recipients.
Prior to sending an encrypted message (using PEM), an originator must
acquire a certificate for each recipient and must validate these
certificates. Briefly, validation is performed by checking the
digital signature in the certificate, using the public component of
the issuer whose private component was used to sign the certificate.
The issuer's public component is made available via some out of band
means (for the ICA) or is itself distributed in a certificate to
which this validation procedure is applied recursively. In the
_______________
(2) This RFC adopts the terms "private component" and "public
component" to refer to the quantities which are, respectively,
kept secret and made publicly available in asymmetric
cryptosystems. This convention is adopted to avoid possible
confusion arising from use of the term "secret key" to refer to
either the former quantity or to a key in a symmetric
cryptosystem.
Kent (BBN) [Page 4]
PEM-1114F Certificate-Based Key Management March 1992
latter case, the issuer of a user's certificate becomes the subject
in a certificate issued by another certifying authority (or a PCA),
thus giving rise to a certification hierarchy. The validity interval
for each certificate is checked and Certificate Revocation Lists
(CRLs) are checked to ensure that none of the certificates employed
in the validation process has been revoked by an issuer.
Once a certificate for a recipient is validated, the public component
contained in the certificate is extracted and used to encrypt the
data encryption key (DEK), which, in turn, is used to encrypt the
message itself. The resulting encrypted DEK is incorporated into the
Key-Info field of the message header. Upon receipt of an encrypted
message, a recipient employs his private 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), signs
(encrypts) the MIC using the private component of his public-key
pair, and includes the resulting value in the message header in the
MIC-Info field. The certificate of the originator is (optionally)
included in the header in the Certificate field as described in RFC
[1113E]. This is done in order to facilitate validation in the
absence of ubiquitous directory services. Upon receipt of a privacy
enhanced message, a recipient validates the originator's certificate
(using the ICA public component as the root of a certification path),
checks to ensure that it has not been revoked, extracts the public
component from the certificate, and uses that value to recover
(decrypt) the MIC. The recovered MIC is compared against the locally
calculated MIC to verify the integrity and data origin authenticity
of the message.
3 Architecture
3.1 Scope and Restrictions
The architecture described below is intended to provide a basis for
managing public-key cryptosystem values in support of privacy
enhanced electronic mail in the Internet environment. The
architecture describes procedures for registering certification
authorities and users, for generating and distributing certificates,
and for generating and distributing CRLs. RFC [1113E] describes the
Kent (BBN) [Page 5]
PEM-1114F Certificate-Based Key Management March 1992
syntax and semantics of header fields used to transfer certificates
and to represent the DEK and MIC in this public-key context.
Definitions of the algorithms, modes of use and associated
identifiers are separated in RFC [1115C] to facilitate the adoption
of additional algorithms in the future. This RFC focuses on the
management aspects of certificate-based, public-key cryptography for
privacy enhanced mail.
The proposed architecture imposes conventions for the certification
hierarchy which are not strictly required by the X.509 recommendation
nor by the technology itself. These conventions are motivated by
several factors, primarily the need for authentication semantics
compatible with automated validation and the automated determination
of the policies under which certificates are issued.
Specifically, the architecture proposes a system in which user (or
mailing list) certificates represent the leaves in a certification
hierarchy. This certification hierarchy is largely isomorphic to the
X.500 directory naming hierarchy, with two exceptions: the ICA forms
the root of the tree (the root of the X.500 DIT is not instantiated
as a node), and a number of Policy Certification Authorities (PCAs)
form the "roots" of subtrees, each of which represents a different
certification policy.
Not every level in the directory hierarchy need correspond to a
certification authority. For example, the appearance of geographic
entities in a distinguished name (e.g., countries, states, provinces,
localities) does not require that various governments become
certifying authorities in order to instantiate this architecture.
However, it is anticipated that, over time, a number of such points
in the hierarchy will be instantiated as CAs in order to simplify
later transition of management to appropriate governmental
authorities.
These conventions minimize the complexity of validating user
certificates, e.g., by making explicit the relationship between a
certificate issuer and the user (via the naming hierarchy). Note that
in this architecture, only PCAs may be certified by the ICA, and
every CA's certification path can be traced to a PCA, through zero or
more CAs. If a CA is certified by more than one PCA, each
certificate issued by a PCA for the CA must contain a distinct public
component. These conventions result in a certification hierarchy
which is a compatible subset of that permitted under X.509, with
respect to both syntax and semantics.
Kent (BBN) [Page 6]
PEM-1114F Certificate-Based Key Management March 1992
Although the key management architecture described in this RFC has
been designed primarily to support privacy enhanced mail, this
infrastructure also may, in principle, be used to support X.400 mail
security facilities (as per 1988 X.411) and X.500 directory
authentication facilities. Thus establishment of this infrastructure
paves the way for use of these and other OSI protocols in the
Internet in the future. In the future, these certificates also may
be employed in the provision of security services in other protocols
in the TCP/IP and OSI suites as well.
3.2 Relation to X.509 Architecture
CCITT 1988 Recommendation X.509, "The Directory - Authentication
Framework", defines a framework for authentication of entities
involved in a distributed directory service. Strong authentication,
as defined in X.509, is accomplished with the use of public-key
cryptosystems. Unforgeable certificates are generated by
certification authorities; these authorities may be organized
hierarchically, though such organization is not required by X.509.
There is no implied mapping between a certification hierarchy and the
naming hierarchy imposed by directory system naming attributes.
This RFC interprets the X.509 certificate mechanism to serve the
needs of PEM in the Internet environment. The certification
hierarchy proposed in this RFC in support of privacy enhanced mail is
intentionally a subset of that allowed under X.509. This
certification hierarchy also embodies semantics which are not
explicitly addressed by X.509, but which are consistent with X.509
precepts. An overview of the rationale for these semantics is
provided in Section 1.
3.3 Certificate Definition
Certificates are central to the key management architecture for X.509
and PEM. This section provides an overview of the syntax and a
description of the semantics of certificates. Appendix A includes
the ASN.1 syntax for certificates. A certificate includes the
following contents:
1. version
Kent (BBN) [Page 7]
PEM-1114F Certificate-Based Key Management March 1992
2. serial number
3. signature (algorithm ID and parameters)
4. issuer name
5. validity period
6. subject name
7. subject public key (and associated algorithm ID)
3.3.1 Version Number
The version number field is intended to facilitate orderly changes in
certificate formats over time. The initial version number for
certificates used in PEM is the X.509 default which has a value of
zero (0), indicating the 1988 version. PEM implementations are
encouraged to accept later versions as they are endorsed by
CCITT/ISO.
3.3.2 Serial Number
The serial number field provides a short form, unique identifier for
each certificate generated by an issuer. An issuer must ensure that
no two distinct certificates with the same issuer DN contain the same
serial number. (3) The serial number is used in CRLs to identify
revoked certificates, as described in Section 3.4.3.4. Although this
attribute is an integer, PEM UA processing of this attribute need not
involve any arithmetic operations. All PEM UA implementations must
be capable of processing serial numbers at least 128 bits in length
and size-independent support serial numbers is encouraged.
_______________
(3) This requirement must be met even when the certification
function is effected on a distributed basis and/or when the same
issuer DN is certified under two different PCAs. This is
especially critical for residential CAs certified under different
PCAs.
Kent (BBN) [Page 8]
PEM-1114F Certificate-Based Key Management March 1992
3.3.3 Signature
This field specifies the algorithm used by the issuer to sign the
certificate, and any parameters associated with the algorithm. (4)
The signature is validated by the UA processing a certificate, in
order to determine that the integrity of its contents have not been
modified subsequent to signing by a CA (ICA, or PCA). In this
context, a signature is effected through the use of a Certificate
Integrity Check (CIC) algorithm and a public-key encryption
algorithm. RFC [1115C] contains the definitions and algorithm IDs
for signature algorithms employed in this architecture.
3.3.4 Subject Name
A certificate provides a representation of its subject's identity in
the form of a Distinguished Name (DN). The fundamental binding
ensured by the key management architecture is that between the public
component and the user's identity in this form. A distinguished name
is an X.500 directory system concept and if a user is already
registered in an X.500 directory, his distinguished name is defined
via that registration. Users who are not registered in a directory
should keep in mind likely directory naming structure (schema) when
selecting a distinguished name for inclusion in a certificate.
3.3.5 Issuer Name
A certificate provides a representation of its issuer's identity, in
the form of a Distinguished Name. The issuer identification is used
to select the appropriate issuer public component to employ in
performing certificate validation. (5) The issuer is the certifying
_______________
(4) The certificate signature is appended to the data structure,
as defined by the signature macro in X.509. This algorithm
identification information is replicated with the signature.
(5) If an issuer (CA) is certified by multiple PCAs, then the
issuer DN does not uniquely identify the public component used to
sign the certificate. In such circumstances it may be necessary
to attempt certificate validation using multiple public
components, from certificates held by the issuer under different
PCAs. If the 1992 version of a certificate is employed, the
Kent (BBN) [Page 9]
PEM-1114F Certificate-Based Key Management March 1992
authority (ICA, PCA or CA) who vouches for the binding between the
subject identity and the public key contained in the certificate.
3.3.6 Validity Period
A certificate carries a pair of date and time indications, indicating
the start and end of the time period over which a certificate is
intended to be used. The duration of the interval may be constant
for all user certificates issued by a given CA or it might differ
based on the nature of the user's affiliation. For example, an
organization might issue certificates with shorter intervals to
temporary employees versus permanent employees. It is recommended
that the UTCT values recorded here specify granularity to no more
than the minute, even though finer granularity can be expressed in
the format. It also recommended that all times be expressed as
Greenwich Mean Time (Zulu), to simplify comparisons and avoid
confusion relating to daylight savings time.
The longer the interval, the greater the likelihood that compromise
of a private component or name change will render it invalid and thus
require that the certificate be revoked. Once revoked, the
certificate must remain on the issuer's CRL (see Section 3.4.3.4)
until the validity interval expires. PCAs may impose restrictions on
the maximum validity interval that may be elected by CAs operating in
their certification domain (see Appendix B).
3.3.7 Subject Public Key
A certificate carries the public component of its associated subject,
as well as an indication of the algorithm, and any algorithm
parameters, with which the public component is to be used. This
algorithm identifier is independent of that which is specified in the
signature field described above. RFC [1115C] specifies the algorithm
identifiers which may be used in this context.
_______________
issuer may employ distinct issuer UIDs in the certificates it
issues, to further facilitate selection of the right issuer
public component.
Kent (BBN) [Page 10]
PEM-1114F Certificate-Based Key Management March 1992
3.4 Roles and Responsibilities
One way to explain the architecture proposed by this document is to
examine the roles which are defined for various entities in the
architecture and to describe what is required of each entity in order
for the proposed system to work properly. The following sections
identify four types of entities within this architecture: users and
user agents, the Internet Certification Authority, Policy
Certification Authorities, and other Certification Authorities. For
each type of entity, this document specifies the procedures which the
entity must execute as part of the architecture and what
responsibilities the entity assumes as a function of its role in the
architecture.
3.4.1 Users and User Agents
The term User Agent (UA) is taken from CCITT X.400 Message Handling
Systems (MHS) Recommendations, which define it as follows: "In the
context of message handling, the functional object, a component of
MHS, by means of which a single direct user engages in message
handling." In the Internet environment, programs such as rand mh
and Gnu emacs rmail are UAs. UAs exchange messages by calling on a
supporting Message Transfer Service (MTS), e.g., the SMTP mail relays
used in the Internet.
3.4.1.1 Generating and Protecting Component Pairs
A UA process supporting PEM must protect the private component of its
associated entity (e.g., a human user or a mailing list) from
disclosure, though the means by which this is effected is a local
matter. It is essential that the user take all available precautions
to protect his private component as the secrecy of this value is
central to the security offered by PEM to that user. For example,
the private component might be stored in encrypted form, protected
with a locally managed symmetric encryption key (e.g., using DES).
The user would supply a password or passphrase which would be
employed as a symmetric key to decrypt the private component when
required for PEM processing (either on a per message or per session
basis). Alternatively, the private component might be stored on a
diskette which would be inserted by the user whenever he originated
Kent (BBN) [Page 11]
PEM-1114F Certificate-Based Key Management March 1992
or received PEM messages. Explicit zeroing of memory locations where
this component transiently resides could provide further protection.
Other precautions, based on local operating system security
facilities, also should be employed.
It is recommended that each user employ ancillary software (not
otherwise associated with normal UA operation) or hardware to
generate his personal public-key component pair. Software for
generating user component pairs will be available as part of the
reference implementation of PEM distributed freely in the U.S.
portion of the Internet. It is critically important that the
component pair generation procedure be effected in as secure a
fashion as possible, to ensure that the resulting private component
is unpredictable. Introduction of adequate randomness into the
component pair generation procedure is potentially the most difficult
aspect of this process and the user is advised to pay particular
attention to this aspect. (6)
There is no requirement imposed by this architecture that anyone
other than the user, including any certification authority, have
access to the user's private component. Thus a user may retain his
component pair even if his certificate changes, e.g., due to rollover
in the validity interval or because of a change of certifying
authority. Even if a user is issued a certificate in the context of
his employment, there is generally no requirement that the employer
have access to the user's private component. The rationale is that
any messages signed by the user are verifiable using his public
component. In the event that the corresponding private component
becomes unavailable, any ENCRYPTED messages directed to the user
would be indecipherable and would require retransmission.
_______________
(6) Component pairs employed in public-key cryptosystems tend to
be large integers which must be "randomly" selected subject to
mathematical constraints imposed by the cryptosystem. Input(s)
used to seed the component pair generation process must be as
unpredictable as possible. An example of a poor random number
selection technique is one in which a pseudo-random number
generator is seeded solely with the current date and time. An
attacker who could determine approximately when a component pair
was generated could easily regenerate candidate component pairs
and compare the public component to the user's public component
to detect when the corresponding private component had been
found.
Kent (BBN) [Page 12]
PEM-1114F Certificate-Based Key Management March 1992
Note that if the user stores messages in ENCRYPTED form, these
messages also would become indecipherable in the event that the
private component is lost or changed. To minimize the potential for
loss of data in such circumstances messages can be transformed into
MIC-ONLY or MIC-CLEAR form if cryptographically-enforced
confidentiality is not required for the messages stored within the
user's computer. Alternatively, these transformed messages might be
forwarded in ENCRYPTED form to a (trivial) distribution list which
serves in a backup capacity and for which the user's employer holds
the private component.
A user may possess multiple certificates which may embody the same or
different public components. For example, these certificates might
represent a current and a former organizational user identity and a
residential user identity. It is recommended that a PEM UA be
capable of supporting a user who possess multiple certificates,
irrespective of whether the certificates associated with the user
contain the same or different DNs or public components.
3.4.1.2 User Registration
Most details of user registration are a local matter, subject to
policies established by the user's CA and the PCA under which that CA
has been certified. In general a user must provide, at a minimum,
his public component and distinguished name to a CA, or a
representative thereof, for inclusion in the user's certificate.
(The user also might provide a complete certificate, minus the
signature, as described in RFC [FORMS-C].) The CA will employ some
means, specified by the CA in accordance with the policy of its PCA,
to validate the user's claimed identity and to ensure that the
public component provided is associated with the user whose
distinguished name is to be bound into the certificate. (In the case
of PERSONA certificates, described below, the procedure is a bit
different.) The certifying authority generates a certificate
containing the user's distinguished name and public component, the
authority's distinguished name and other information (see Section
3.3) and signs the result using the private component of the
authority.
Kent (BBN) [Page 13]
PEM-1114F Certificate-Based Key Management March 1992
3.4.1.3 CRL Management
Mechanisms for managing a UA certificate cache are, in typical
standards parlance, a local matter. However, proper maintenance of
such a cache is critical to the correct, secure operation of a PEM UA
and provides a basis for improved performance. Moreover, use of a
cache permits a PEM UA to operate in the absence of directories (and
in circumstances where directories are inaccessible). The following
discussion provides a paradigm for one aspect of cache management,
namely the processing of CRLs, the functional equivalent of which
must be embodied in any PEM UA implementation compliant with this
RFC. The specifications for CRLs used with PEM are provided in
Section 3.5.
X.500 makes provision for the storage of CRLs as directory attributes
associated with CA entries. Thus, when X.500 directories become
widely available, UAs can retrieve CRLs from directories as required.
In the interim, the ICA will coordinate with PCAs to provide a robust
database facility which will contain CRLs issued by the ICA, by PCAs,
and by all CAs. Access to this database will be provided through
mailboxes maintained by each PCA. Every PEM UA must provide a
facility for requesting CRLs from this database using the mechanisms
defined in RFC [FORMS-C]. Thus the UA must include a configuration
parameter which specifies one or more mailbox addresses from which
CRLs may be retrieved. Access to the CRL database may be automated,
e.g., as part of the certificate validation process (see Section 3.6)
or may be user directed. Responses to CRL requests will employ the
PEM header format specified in RFC [1113E] for CRL propagation. As
noted in RFC [1113E], every PEM UA must be capable of processing CRLs
distributed via such messages. This message format also may be
employed to support a "push" (versus a "pull") model of CRL
distribution, i.e., to support unsolicited distribution of CRLs.
CRLs received by a PEM UA must be validated (7) prior to being
processed against any cached certificate information. Any cache
entries which match CRL entries should be marked as revoked, but it
is not necessary to delete cache entries marked as revoked nor to
delete subordinate entries. In processing a CRL against the cache it
_______________
(7) A CRL is validated in much the same manner as a certificate,
i.e., the CIC is calculated and compared against the decrypted
signature value obtained from the CRL. See Section 3.6 for
additional details related to validation of certificates.
Kent (BBN) [Page 14]
PEM-1114F Certificate-Based Key Management March 1992
is important to recall that certificate serial numbers are unique
only for each issuer and that multiple, distinct CRLs may be issued
under the same CA DN (signed using different private components), so
care must be exercised in effecting this cache search. (8)
This procedure applies to cache entries associated with PCAs and CAs,
as well as user entries. The UA also must retain each CRL to screen
incoming messages to detect use of revoked certificates carried in
PEM message headers. Thus a UA must be capable of processing and
retaining CRLs issued by the ICA (which will list revoked PCA
certificates), by any PCA (which will list revoked CA certificate
issued by that PCA), and by any CA (which will list revoked user or
subordinate CA certificates issued by that CA).
3.4.1.4 Facilitating Interoperation
In the absence of ubiquitous directory services or knowledge
(acquired through out-of-band means) that a recipient already
possesses the necessary issuer certificates, it is recommended that
an originating (PEM) UA include sufficient certificates to permit
validation of the user's public key. To this end every PEM UA must
be capable of including a full (originator) certification path, i.e.,
including the user's certificate (using the "Originator-Certificate"
field) and every superior (CA/PCA) certificate (using "Issuer-
Certificate" fields) back to the ICA, in a PEM message. A PEM UA may
send less than a full certification path, e.g., based on analysis of
a recipient list, but a UA which provides this sort of optimization
must also provide the user with a capability to force transmission of
a full certification path.
Optimization for the transmitted originator certification path may be
effected by a UA as a side effect of the processing performed during
message submission. When an originator submits an ENCRYPTED message
(as per RFC [1113E], his UA must validate the certificates of the
recipients (see Section 3.6). In the course of performing this
validation the UA can determine the minimum set of certificates which
must be included to ensure that all recipients can process the
_______________
(8) This situation may arise either because an organizational CA
is certified by multiple PCAs, or because multiple residential
CAs are certified under different PCAs.
Kent (BBN) [Page 15]
PEM-1114F Certificate-Based Key Management March 1992
received message. Submission of a MIC-ONLY or MIC-CLEAR message (as
per RFC [1113D) does not entail validation of recipient certificates
and thus it is may not be possible for the originator's UA to
determine the minimum certificate set as above.
3.4.2 The Internet Certification Authority (ICA)
The ICA acts as the root of the certification hierarchy for the
Internet community. The public component of the ICA forms the
foundation for all certificate validation within this hierarchy. The
ICA will be operated under the auspices of the Internet Society, an
international, non-profit organization [ISOC92]. The ICA certifies
all PCAs, ensuring that they agree to abide by the Internet-wide
policy established by the ICA. This policy, and the services
provided by the ICA, are detailed below.
3.4.2.1 PCA Registration
The ICA certifies only PCAs, not CAs or users. Each PCA must file
with the ICA a description of its proposed policy. This document
will be published as an informational RFC. A copy of the document,
signed by the ICA (in the form of a PEM MIC-ONLY message) will be
made available via electronic mail access by the ICA. This
convention is adopted so that every Internet user has a reference
point for determining the policies associated with the issuance of
any certificate which he may encounter. The existence of a digitally
signed copy of the document ensures the immutability of the document.
Authorization of a PCA to operate in the Internet hierarchy is
signified by the publication of the policy document, and the issuance
of a certificate to the PCA, signed by the ICA. An outline for PCA
policy statements is contained in Section 3.4.3 of this document.
As part of registration, each PCA will be required to execute a legal
agreement with the ICA, and to pay a fee to defray the costs of
operating the ICA. Each a PCA must specify its distinguished name.
The ICA will take reasonable precautions to ensure that the
distinguished name claimed by a PCA is legitimate, e.g., requiring
the PCA to provide documentation supporting its claim to a DN.
However, the certification of a PCA by the ICA does not constitute a
endorsement of the PCA's claim to this DN outside of the context of
Kent (BBN) [Page 16]
PEM-1114F Certificate-Based Key Management March 1992
this certification system.
3.4.2.2 Ensuring the Uniqueness of Distinguished Names
A fundamental requirement of this certification scheme is that
certificates are not issued to distinct entities under the same
distinguished name. This requirement is important to the success of
distributed management for the certification hierarchy. The ICA will
not certify two PCAs with the same distinguished name and no PCA may
certify two CAs with the same DN. However, since PCAs are expected
to certify organizational CAs in widely disjoint portions of the
directory namespace, and since X.500 directories are not ubiquitous,
a facility is required for coordination among PCAs to ensure the
uniqueness of CA DNs. (9)
In support of the uniqueness requirement, the ICA will establish and
maintain a database to detect potential, unintended duplicate
certification of CA distinguished names. This database will be made
accessible to all PCAs via an email interface. Each entry in this
database will consist of a 4-tuple. The first element in each entry
is a hash value, computed on a canonical, ASN.1 encoded
representation of a CA distinguished name. The second element
contains the subjectPublicKey that appears in the CA's certificate.
The third element is the distinguished name of the PCA which
registered the entry. The fourth element consists of the date and
time at which the entry was made, as established by the ICA. This
database structure provides a degree of privacy for CAs registered by
PCAs, while providing a facility for ensuring global uniqueness of CA
DNs certified in this scheme.
In order to avoid conflicts, a PCA should query the database using a
CA DN hash value as a search key, prior to certifying a CA. The
database will return any entries which match the query, i.e., which
have the same CA DN. The PCA can use the information contained in
_______________
(9) This architecture allows multiple PCAs to certify residential
CAs and thus multiple, distinct residential CAs with identical
DNs may come into existence, at least until such time as civil
authorities assume responsibilities for such certification.
Thus, on an interim basis, the architecture explicitly
accommodates the potential for duplicate residential CA DNs.
Kent (BBN) [Page 17]
PEM-1114F Certificate-Based Key Management March 1992
any returned entries to determine if any PCAs should be contacted to
resolve possible DN conflicts. If no potential conflicts appear, a
PCA can then submit a candidate entry, consisting of the first three
element values, plus any entries returned by the query. The database
will register this entry, supplying the time and date stamp, only if
two conditions are met: (1) the first two elements (the CA DN hash
and the CA subjectPublicKey) of the candidate entry together must be
unique and, (2) any other entries included in the submission must
match what the current database would return if the query
corresponding to the candidate entry were submitted.
If the database detects a conflicting entry (failure of case 1
above), or if the submission indicates that the PCA's perception of
possible conflicting entries is not current (failure of case 2), the
submission is rejected and the database will return the potential
conflicting entry (entries). If the submission is successful, the
database will return the timestamped new entry. The database does
not, in itself, guarantee uniqueness of CA DNs as it allows for two
DNs associated with different public components to be registered.
Rather, it is the responsibility of PCAs to coordinate with one
another whenever the database indicates a potential DN conflict and
to resolve such conflicts prior to certification of CAs. Details of
the protocol used to access the database will be provided in another
document.
As noted earlier, a CA may be certified under more than one PCA,
e.g., because the CA wants to issue certificates under two different
policies. If a CA is certified by multiple different PCAs, the CA
must employ a different public key pair for each PCA. In such
circumstances the certificate issued to the CA by each PCA will
contain a different subjectPublicKey and thus will represent a
different entry in this database. The same situation may arise if
multiple, equivalent residential CAs are certified by different PCAs.
To complete the strategy for ensuring uniqueness of DNs, there is a
DN subordination requirement levied on CAs. In general, CAs are
expected to sign certificates only if the subject DN in the
certificate is subordinate to the issuer (CA) DN. This ensures that
certificates issued by a CA are syntactically constrained to refer to
subordinate entities in the X.500 directory information tree (DIT),
and this further limits the possibility of duplicate DN registration.
CAs may sign certificates which do not comply with this requirement
if the certificates are "cross-certificates" or "reverse
certificates" (see X.509) used with applications other than PEM.
Kent (BBN) [Page 18]
PEM-1114F Certificate-Based Key Management March 1992
The ICA also will establish and maintain a separate database to
detect potential duplicate certification of (residential) user
distinguished names. Each entry in this database will consist of 4-
tuple as above, but the first components is the hash of a residential
user DN and the third component is the DN of the residential CA DN
which registered the user. This structure provides a degree of
privacy for users registered by CAs which service residential users
while providing a facility for ensuring global uniqueness of user DNs
certified under this scheme. The same database access facilities are
provided as described above for the CA database. Here it is the
responsibility of the CAs to coordinate whenever the database
indicates a potential conflict and to resolve the conflict prior to
(residential) user certification.
3.4.2.3 Accuracy of Distinguished Names
As noted above, the ICA will make a reasonable effort to ensure that
PCA DNs are accurate. The procedures employed to ensure the accuracy
of a CA distinguished name, i.e., the confidence attached to the
DN/public component binding implied by a certificate, will vary
according to PCA policy. However, it is expected that every PCA will
make a good faith effort to ensure the legitimacy of each CA DN
certified by the PCA. Part of this effort should include a check
that the purported CA DN is consistent with any applicable national
standards for DN assignment, e.g., NADF recommendations within North
America [RFC-NADF].
3.4.2.4 Distinguished Name Conventions
A few basic DN conventions are included in the ICA policy. The ICA
will certify PCAs, but not CAs nor users. PCAs will certify CAs, but
not users. These conventions are required to allow simple
certificate validation within PEM, as described later. Certificates
issued by CAs (for use with PEM) will be for users or for other CAs,
either of which must have DNs subordinate to that of the issuing CA.
The attributes employed in constructing DNs will be specified in a
list maintained by the IANA, to provide a coordinated basis for
attribute identification for all applications employing DNs. This
list will initially be populated with attributes taken from X.520.
Kent (BBN) [Page 19]
PEM-1114F Certificate-Based Key Management March 1992
This document does not impose detailed restrictions on the attributes
used to identify different entities to which certificates are issued,
but PCAs may impose such restrictions as part of their policies.
PCAs, CAs and users are urged to employ only those DN attributes
which have printable representations, to facilitate display and
entry.
3.4.2.5 CRL Management
Among the procedures articulated by each PCA in its policy statement
are procedures for the maintenance and distribution of CRLs by the
PCA itself and by its subordinate CAs. The frequency of issue of
CRLs may vary according to PCA-specific policy, but every PCA and CA
must issue a CRL upon inception to provide a basis for uniform
certificate validation procedures throughout the Internet hierarchy.
The ICA will maintain a CRL for all the PCAs it certifies and this
CRL will be updated monthly. Each PCA will maintain a CRL for all of
the CAs which it certifies and these CRLs will be updated in
accordance with each PCA's policy. The format for these CRLs is
that specified in Section 3.5.2 of the document.
In the absence of ubiquitous X.500 directory services, the ICA will
require each PCA to provide, for its users, robust database access to
CRLs for the Internet hierarchy, i.e., the ICA CRL, PCA CRLs, and
CRLs from all CAs. The means by which this database is implemented
is to be coordinated between the ICA and PCAs. This database will be
accessible via email as specified in RFC [FORMS-C], both for
retrieval of (current) CRLs by any user, and for submission of new
CRLs by CAs, PCAs and the ICA. Individual PCAs also may elect to
maintain CRL archives for their CAs, but this is not required by this
policy.
3.4.2.6 Public Key Algorithm Licensing Issues
This certification hierarchy is architecturally independent of any
specific digital signature (public key) algorithm. Some algorithms,
employed for signing certificates and validating certificate
signatures, are patented in some countries. The ICA will not grant a
license to any PCA for the use of any signature algorithm in
conjunction with the management of this certification hierarchy. The
Kent (BBN) [Page 20]
PEM-1114F Certificate-Based Key Management March 1992
ICA will acquire, for itself, any licenses needed for it to sign
certificates and CRLs for PCAs, for all algorithms which the ICA
supports. Every PCA will be required to represent to the ICA that
the PCA has obtained any licenses required to issue (sign)
certificates and CRLs in the environment(s) which the PCA will serve.
For example, the RSA cryptosystem is patented in the United States
and thus any PCA operating in the U.S. and using RSA to sign
certificates and CRLs must represent that it has a valid license to
employ the RSA algorithm in this fashion. In contrast, a PCA
employing RSA and operating outside of the U.S. would represent that
it is exempt from these licensing constraints.
3.4.3 Policy Certification Authorities
The policy statement submitted by a prospective PCA must address the
topics in the following outline. Additional policy information may
be contained in the statement, but PCAs are requested not to use
these statements as advertising vehicles.
1. PCA Identity- The DN of the PCA must be specified. A postal
address, an Internet mail address, and telephone (and optional fax)
numbers must be provided for (human) contact with the PCA. The date
on which this statement is effective, and its scheduled duration must
be specified.
2. PCA Scope- Each PCA must describe the community which the PCA
plans to serve. A PCA should indicate if it will certify
organizational, residential, and/or PERSONA CAs. There is not a
requirement that a single PCA serve only one type of CA, but if a PCA
serves multiple types of CAs, the policy statement must specify
clearly how a user can distinguish among these classes. If the PCA
will operate CAs to directly serve residential or PERSONA users, it
must so state.
3. PCA Security & Privacy- Each PCA must specify the technical and
procedural security measures it will employ in the generation and
protection of its component pair. If any security requirements are
imposed on CAs certified by the PCA these must be specified as well.
A PCA also must specify what measures it will take to protect the
privacy of any information collected in the course of certifying CAs.
If the PCA operates one or more CAs directly, to serve residential or
Kent (BBN) [Page 21]
PEM-1114F Certificate-Based Key Management March 1992
PERSONA users, then this statement on privacy measures applies to
these CAs as well.
4. Certification Policy- Each PCA must specify the policy and
procedures which govern its certification of CAs and how this policy
applies transitively to entities (users or subordinate CAs) certified
by these CAs. For example, a PCA must state what procedure is
employed to verify the claimed identity of a CA, and the CA's right
to use a DN. Similarly, if any requirements are imposed on CAs to
validate the identity of users, these requirements must be specified.
Since all PCAs are required to cooperate in the resolution of
potential DN conflicts, each PCA is required to specify the procedure
it will employ to resolve such conflicts. If the PCA imposes a
maximum validity interval for the CA certificates it issues, and/or
for user (or subordinate CA) certificates issued by the CAs it
certifies, then these restrictions must be specified.
5. CRL Management- Each PCA must specify the frequency with which it
will issue scheduled CRLs. It also must specify any constraints it
imposes on the frequency of scheduled issue of CRLs by the CAs it
certifies, and by subordinate CAs. Both maximum and minimum
constraints should be specified. Since the ICA policy calls for each
CRL issued by a CA to be forwarded to the cognizant PCA, each PCA
must specify a mailbox address to which CRLs are to be transmitted.
The PCA also must specify a mailbox address for CRL queries. If the
PCA offers any additional CRL management services, e.g., archiving of
old CRLs, then procedures for invoking these services must be
specified. If the PCA requires CAs to provide any additional CRL
management services, such services must be specified here.
6. Naming Conventions- If the PCA imposes any conventions on DNs used
by the CAs it certifies, or by entities certified by these CAs, these
conventions must be specified. If any semantics are associated with
such conventions, these semantics must be specified.
7. Business Issues- If a legal agreement must be executed between a
PCA and the CAs it certifies, reference to that agreement must be
noted, but the agreement itself ought not be a part of the policy
statement. Similarly, if any fees are charged by the PCA this should
be noted, but the fee structure per se ought not be part of this
policy statement.
Kent (BBN) [Page 22]
PEM-1114F Certificate-Based Key Management March 1992
8. Other- Any other topics the PCA deems relevant to a statement of
its policy can be included. However, the PCA should be aware that a
policy statement is considered to be an immutable, long lived
document and thus considerable care should be exercised in deciding
what material is to be included in the statement.
3.4.4 Certification Authorities
In X.509 the term "certification authority" is defined as "an
authority trusted by one or more users to create and assign
certificates". X.509 imposes few constraints on CAs, but practical
implementation of a worldwide certification system requires
establishment of technical and procedural conventions by which all
CAs are expected to abide. Such conventions are established
throughout this RFC. All CAs are required to maintain a database of
the DNs which they have certified and to take measures to ensure that
they do not certify duplicate DNs, either for users or for
subordinate CAs.
It is critical that the private component of a CA be afforded a high
level of security, otherwise the authenticity guarantee implied by
certificates signed by the CA is voided. Some PCAs may impose
stringent requirements on CAs within their purview to ensure that a
high level of security is afforded the certificate signing process,
but not all PCAs are expected to impose such constraints.
3.4.4.1 Organizational CAs
Many of the CAs certified by PCAs are expected to represent
organizations. A wide range of organizations are encompassed by this
model: commercial, governmental, educational, non-profit,
professional societies, etc. The common thread is that the entities
certified by these CAs have some form of affiliation with the
organization. The object classes for organizations, organizational
units, organizational persons, organizational roles, etc., as defined
in X.521, form the models for entities certified by such CAs. The
affiliation implied by organizational certification motivates the DN
subordination requirement cited in Section 3.4.2.4.
Kent (BBN) [Page 23]
PEM-1114F Certificate-Based Key Management March 1992
As an example, an organizational user certificate might contain a
subject DN of the form: C = "US" SP = "Massachusetts" L = "Cambridge"
O = "Bolt Beranek and Newman" OU = "Communications Division" CN =
"Steve Kent". The issuer of this certificate might have a DN of the
form: C = "US" SP = "Massachusetts" L = "Cambridge" O= "Bolt Beranek
and Newman". Note that the organizational unit attribute is omitted
from the issuer DN, implying that there is no CA dedicated to the
"Communications Division".
3.4.4.2 Residential CAs
Users may wish to obtain certificates which do not imply any
organizational affiliation but which do purport to accurately and
uniquely identify them. Such users can be registered as residential
persons and the DN of such a user should be consistent with the
attributes of the corresponding X.521 object class. Over time we
anticipate that such users will be accommodated by civil government
entities who will assume electronic certification responsibility at
geographically designated points in the naming hierarchy. Until
civil authorities are prepared to issue certificates of this form,
residential user CAs will accommodate such users.
Because residential CAs may be operated under the auspices of
multiple PCAs, there is a potential for the same residential CA DN to
be assumed by several distinct entities. This represents the one
exception to the rule articulated throughout this document that no
two entities may have the same DN. This conflict is tolerated so as
to allow residential CAs to be established offering different
policies. Two requirements are levied upon residential CAs as a
result: (1) residential CAs must employ the residential DN conflict
detection database maintained by the ICA, and (2) residential CAs
must coordinate to ensure that they do not assign duplicate
certificate serial numbers.
As an example, a residential user certificate might include a subject
name of the form: C = "US" SP = "Massachusetts" L = "Boston" PA = "19
North Square" CN = "Paul Revere." The issuer of that certificate
might have a DN of the form: C = "US" S = "Massachusetts" L =
"Boston". Note that the issuer DN is superior to the subject DN, as
required by the ICA policy described earlier.
Kent (BBN) [Page 24]
PEM-1114F Certificate-Based Key Management March 1992
3.4.4.3 PERSONA CAs
One or more CAs will be established to accommodate users who wish to
conceal their identities while making use of PEM security features,
e.g., to preserve the anonymity offered by "arbitrary" mailbox names
in the current mail environment. In this case the certifying
authority is explicitly NOT vouching for the identity of the user.
All such certificates are issued under a PERSONA CA, subordinate to a
PCA with a PERSONA policy, to warn users explicitly that the subject
DN is NOT a validated user identity. To minimize the possibility of
syntactic confusion with certificates which do purport to specify an
authenticated user identity, a PERSONA certificate is issued as a
form of organizational user certificate, not a residential user
certificate. There are no explicit, reserved words used to identify
PERSONA user certificates.
A CA issuing PERSONA certificates must institute procedures to ensure
that it does not issue the same subject DN to multiple users (a
constraint required for all certificates of any type issued by any
CA). There are no requirements on an issuer of PERSONA certificates
to maintain any other records that might bind the true identity of
the subject to his certificate. However, a CA issuing such
certificates must establish procedures (not specified in this RFC) in
order to allow the holder of a PERSONA certificate to request that
the certificate be revoked (i.e., listed on a CRL).
As an example, a PERSONA user certificate might include a subject DN
of the form: C = "US" SP = "Massachusetts" L = "Boston" O =
"Pseudonyms R US" CN = "Paul Revere." The issuer of this certificate
might have a DN of the form: C = "US" S = "Massachusetts" L =
"Boston" O = "Pseudonyms R US". Note the differences between this
PERSONA user certificate for "Paul Revere" and the corresponding
residential user certificate for the same common name.
3.4.4.4 CA Responsibilities for CRL Management
As X.500 directory servers become available, CRLs should be
maintained and accessed via these servers. However, prior to
widespread deployment of X.500 directories, this RFC adopts some
additional requirements for CRL management by CAs and PCAs. As per
X.509, each CA is required to maintain a CRL (in the format specified
by this RFC in Appendix A) which contains entries for all
Kent (BBN) [Page 25]
PEM-1114F Certificate-Based Key Management March 1992
certificates issued and later revoked by the CA. Once a certificate
is entered on a CRL it remains there until the validity interval
expires. Each PCA is required to maintain a CRL for revoked CA
certificates within its domain. The interval at which a CA issues a
CRL is not fixed by this RFC, but the PCAs may establish minimum and
maximum intervals for such issuance.
As noted earlier, each PCA will provide access to a database
containing CRLs issued by the ICA, PCAs, and all CAs. In support of
this requirement, each CA must supply its current CRL to its PCA in a
fashion consistent with CRL issuance rules imposed by the PCA and
with the next scheduled issue date specified by the CA (see Section
3.5.1). CAs may distribute CRLs to subordinate UAs using the CRL
processing type available in PEM messages (see RFC [1113E]). CAs
also may provide access to CRLs via the database mechanism described
in RFC [FORMS-C] and alluded to immediately above.
3.5 Certificate Revocation
3.5.1 X.509 CRLs
X.509 states that it is a CA's responsibility to maintain: "a time-
stamped list of the certificates it issued which have been revoked."
There are two primary reasons for a CA to revoke a certificate, i.e.,
suspected compromise of a private component (invalidating the
corresponding public component) or change of user affiliation
(invalidating the DN). The use of Certificate Revocation Lists
(CRLs) as defined in X.509 is one means of propagating information
relative to certificate revocation, though it is not a perfect
mechanism. In particular, an X.509 CRL indicates only the age of the
information contained in it; it does not provide any basis for
determining if the list is the most current CRL available from a
given CA.
The proposed architecture establishes a format for a CRL in which not
only the date of issue, but also the next scheduled date of issue is
specified. Adopting this convention, when the next scheduled issue
date arrives a CA (10) will issue a new CRL, even if there are no
_______________
(10) Throughout this section, when the term "CA" is employed, it
should be interpreted broadly, to include the ICA and PCAs as
well as organizational, residential, and PERSONA CAs.
Kent (BBN) [Page 26]
PEM-1114F Certificate-Based Key Management March 1992
changes in the list of entries. In this fashion each CA can
independently establish and advertise the frequency with which CRLs
are issued by that CA. Note that this does not preclude CRL issuance
on a more frequent basis, e.g., in case of some emergency, but no
system-wide mechanisms are architected for alerting users that such
an unscheduled issuance has taken place. This scheduled CRL issuance
convention allows users (UAs) to determine whether a given CRL is
"out of date," a facility not available from the (1988) X.509 CRL
format.
The description of CRL management in the text and the format for CRLs
specified in X.509 (1988) are inconsistent. For example, the latter
associates an issuer distinguished name with each revoked certificate
even though the text states that a CRL contains entries for only a
single issuer (which is separately specified in the CRL format). The
CRL format adopted for PEM is a (simplified) format consistent with
the text of X.509, but not identical to the accompanying format. The
ASN.1 format for CRLs used with PEM is provided in Appendix A.
X.509 also defines a syntax for the "time-stamped list of revoked
certificates representing other CAs." This syntax, the
"AuthorityRevocationList" (ARL) allows the list to include references
to certificates issued by CAs other than the list maintainer. There
is no syntactic difference between these two lists except as they are
stored in directories. Since PEM is expected to be used prior to
widespread directory deployment, this distinction between ARLs and
CRLs is not syntactically significant. As a simplification, this RFC
specifies the use the CRL format defined below for revocation both of
user and of CA certificates.
3.5.2 PEM CRL Format
Appendix A contains the ASN.1 description of CRLs specified by this
RFC. This section provides an informal description of CRL components
analogous to that provided for certificates in Section 3.3.
1. signature (signature algorithm ID and parameters)
2. issuer
3. last update
Kent (BBN) [Page 27]
PEM-1114F Certificate-Based Key Management March 1992
4. next update
5. revoked certificates
The "signature" is a data item completely analogous to the signature
data item in a certificate. Similarly, the "issuer" is the DN of the
CA which signed the CRL. The "last update" and "next update" fields
contain time and date values (UTCT format) which specify,
respectively, when this CRL was issued and when the next CRL is
scheduled to be issued. Finally, "revoked certificates" is a
sequence of ordered pairs, in which the first element is the serial
number of the revoked certificate and the second element is the time
and date of the revocation for that certificate.
The semantics for this second element are not made clear in X.509.
For example, the time and date specified might indicate when a
private component was thought to have been compromised or it may
reflect when the report of such compromise was reported to the CA.
For uniformity, this RFC adopts the latter convention, i.e., the
revocation date specifies the time and date at which a CA formally
acknowledges a report of a compromise or a change or DN attributes.
As with certificates, it is recommended that the UTCT values be of no
finer granularity than minutes and that all values be stated in terms
of Zulu.
3.6 Certificate Validation
3.6.1 Validation Basics
Every UA must contain the public component of the ICA as the root for
its certificate validation database. Public components associated
with PCAs must be identified as such, so that the certificate
validation process described below can operate correctly. Whenever a
certificate for a PCA is entered into a UA cache, e.g., if
encountered in a PEM message encapsulated header, the certificate
must NOT be entered into the cache automatically. Rather, the user
must be notified and must explicitly direct the UA to enter any PCA
certificate data into the cache. This precaution is essential
because introduction of a PCA certificate into the cache implies user
recognition of the policy associated with the PCA.
Kent (BBN) [Page 28]
PEM-1114F Certificate-Based Key Management March 1992
Validating a certificate begins with verifying that the signature
affixed to the certificate is valid, i.e., that the hash value
computed on the certificate contents matches the value that results
from decrypting the signature field using the public component of the
issuer. In order to perform this operation the user must possess the
public component of the issuer, either via some integrity-assured
channel, or by extracting it from another (validated) certificate.
In order to rapidly terminate this recursive validation process, we
recommend each PCA sign certificates for all CAs within its domain,
even CAs which are certified by other, superior CAs in the
certification hierarchy.
The public component needed to validate certificates signed by the
ICA is made available to each user as part of the registration or via
the PEM installation process. Thus a user will be able to validate
any PCA certificate immediately. CAs are certified by PCAs, so
validation of a CA certificate requires processing a validation path
of length two. User certificates are issued by CAs (either
immediately subordinate to PCAs or subordinate to other CAs), thus
validation of a user certificate may require three or more steps.
Local caching of validated certificates by a UA can be used to speed
up this process significantly.
Consider the situation in which a user receives a privacy enhanced
message from an originator with whom the recipient has never
previously corresponded, and assume that the message originator
includes a full certification path in the PEM message header. First
the recipient can use the ICA's public component to validate a PCA
certificate contained in an Issuer-Certificate field. Using the
PCA's public component extracted from this certificate, the CA
certificate in an Issuer-Certificate field also can be validated.
This process cam be repeated until the certificate for the
originator, from the Originator-Certificate field, is validated.
Having performed this certificate validation process, the recipient
can extract the originator's public component and use it to decrypt
the content of the MIC-Info field. By comparing the decrypted
contents of this field against the MIC computed locally on the
message the user verifies the data origin authenticity and integrity
of the message. It is recommended that implementations of privacy
enhanced mail cache validated public components (acquired from
incoming mail) to speed up this process. If a message arrives from
an originator whose public component is held in the recipient's cache
(and if the cache is maintained in a fashion that ensures timely
Kent (BBN) [Page 29]
PEM-1114F Certificate-Based Key Management March 1992
incorporation of received CRLs), the recipient can immediately employ
that public component without the need for the certificate validation
process described here. (11)
3.6.2 Display of Certificate Validation Data
PEM provides authenticated identities for message recipients and
originators expressed in the form of distinguished names. Mail
systems in which PEM is employed may employ identifiers other than
DNs as the primary means of identifying recipients or originators.
Thus, in order to benefit from these authentication facilities, each
PEM implementation must employ some means of binding native mail
system identifiers to distinguished names in a fashion which does not
undermine this basic PEM functionality.
For example, if a human user interacts directly with PEM, then the
full DN of the originator of any message received using PEM should be
displayed for the user. Merely displaying the PEM-protected message
content, containing an originator name from the native mail system,
does not provide equivalent security functionality and could allow
spoofing. If the recipient of a message is a forwarding agent such
as a list exploder or mail relay, display of the originator's DN is
not a relevant requirement. In all cases the essential requirement
is that the ultimate recipient of a PEM message be able to ascertain
the identity of the originator based on the PEM certification system,
not on unauthenticated identification information, e.g., extracted
from the native message system.
Conversely, for the originator of an ENCRYPTED message, it is
important that recipient identities be linked to the DNs as expressed
in PEM certificates. This can be effected in a variety of ways by
the PEM implementation, e.g., by display of recipient DNs upon
message submission or by a tightly controlled binding between local
aliases and the DNs. Here too, if the originator is a forwarding
process this linkage might be effected via various mechanisms not
applicable to direct human interaction. Again, the essential
_______________
(11) For some digital signature algorithms, the processing
required for certificate validation is considerably faster than
that involved in signing a certificate. Use of such algorithms
serves to minimize the computational burden on UAs.
Kent (BBN) [Page 30]
PEM-1114F Certificate-Based Key Management March 1992
requirement is to avoid procedures which might undermine the
authentication services provided by PEM.
As described above, it is a local matter how and what certification
information is displayed for a human user in the course of submission
or delivery of a PEM message. Nonetheless all PEM implementations
must provide a user with the ability to display a full certification
path for any certificate employed in PEM upon demand. Implementors
are urged to not overwhelm the user with certification path
information which might confuse him or distract him from the critical
information cited above.
3.6.3 Validation Procedure Details
Every PEM implementation is required to perform the following
validation steps for every public component employed in the
submission of an ENCRYPTED PEM message or the delivery of an
ENCRYPTED, MIC-ONLY, or MIC-CLEAR PEM message. Each public component
may be acquired from an internal source, e.g., from a (secure) cache
at the originator/recipient or it may be obtained from an external
source, e.g., the PEM header of an incoming message or a directory.
The following procedures applies to the validation of certificates
from either type of source.
Validation of a public component involves constructing a
certification path between the component and the public component of
the ICA. The validity interval for every certificate in this path
must be checked. PEM software must, at a minimum, warn the user if
any certificate in the path fails the validity interval check, though
the form of this warning is a local matter. For example, the warning
might indicate which certificate in the path was expired. Local
security policy may prohibit use of expired certificates.
Each certificate also must be checked against the current CRL from
the certificate's issuer to ensure that revoked certificates are not
employed. If the UA does not have access to the current CRL for any
certificate in the path, the user must be warned. Again, the form of
the warning is a local matter. For example, the warning might
indicate whether the CRL is unavailable or, if available but not
current, the CRL issue date should be displayed. Local policy may
prohibit use of a public component which cannot be checked against a
current CRL, and in such cases the user should receive the same
Kent (BBN) [Page 31]
PEM-1114F Certificate-Based Key Management March 1992
information provided by the warning indications described above.
If any revoked certificates are encountered in the construction of a
certification path, the user must be warned. The form of the warning
is a local matter, but it is recommended that this warning be more
stringent than those previously alluded to above. For example, this
warning might display the issuer and subject DNs from the revoked
certificate and the date of revocation and require the user to
provide a positive response before the submission or delivery process
may proceed. In the case of message submission, the warning might
display the identity of the recipient affected by this validation
failure and the user might be provided with the option to specify
that this recipient be dropped from recipient list processing without
affecting PEM processing for the remaining recipients. Local policy
may prohibit PEM processing if a revoked certificate is encountered
in the course of constructing a certification path.
Note that in order to comply with these validation procedures, a
certificate cache must maintain all of the information contained in a
certificate, not just the DNs and the public component. For example
the serial number and validity interval must be associated with the
cache entry to comply with the checks described above. Also note
that these procedures apply to human interaction in message
submission and delivery and are not directly applicable to forwarding
processes. When non human interaction is involved, a compliant PEM
implementation must provide parameters to enable a process to specify
whether certificate validation will succeed or fail if any of the
conditions arise which would result in warnings to a human user.
Finally, in the course of validating certificates as described above,
one additional check must be performed; the subject DN of every
certificate must be subordinate to the certificate issuer DN, except
if the issuer is the ICA or a PCA (hence another reason to
distinguish the ICA and PCA entries in a certificate cache). This
requirement is levied upon all PEM implementations as part of
maintaining the certification hierarchy constraints defined in this
document. Any certificate which does not comply with these
requirements is considered invalid and must be rejected in PEM
submission or delivery processing. The user must be notified of the
nature of this fatal error.
Kent (BBN) [Page 32]
PEM-1114F Certificate-Based Key Management March 1992
A Appendix A: ASN.1 Syntax for Certificates and CRLs
A.1 Certificate Syntax
The X.509 certificate format is defined by the following ASN.1
syntax:
Certificate ::= SIGNED SEQUENCE{
version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo}
Version ::= INTEGER {v1988(0)}
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE{
notBefore UTCTime,
notAfter UTCTime}
SubjectPublicKeyInfo ::= SEQUENCE{
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING}
AlgorithmIdentifier ::= SEQUENCE{
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL}
The components of this structure are defined by ASN.1 syntax defined
in the X.500 Series Recommendations. RFC [1115C] provides references
for and the values of AlgorithmIdentifiers used by PEM in the
subjectPublicKeyInfo and the signature data items. It also describes
how a signature is generated and the results represented. Because
the certificate is a signed data object, the distinguished encoding
rules (see X.509, section 8.7) must be applied prior to signing.
Kent (BBN) [Page 33]
PEM-1114F Certificate-Based Key Management March 1992
A.2 Certificate Revocation List Syntax
The following ASN.1 syntax, derived from X.509 and aligned with the
suggested format in recently submitted defect reports, defines the
format of CRLs for use in the PEM environment.
CertificateRevocationList ::= SIGNED SEQUENCE{
signature AlgorithmIdentifier,
issuer Name,
lastUpdate UTCTime,
nextUpdate UTCTime,
revokedCertificates
SEQUENCE OF CRLEntry OPTIONAL}
CRLEntry ::= SEQUENCE{
userCertificate SerialNumber,
revocationDate UTCTime}
B References
[1] CCITT Recommendation X.411 (1988), "Message Handling Systems:
Message Transfer System: Abstract Service Definition and Procedures".
[2] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[3] CCITT Recommendation X.520 (1988), "The Directory - Selected
Attribute Types". CCITT
[4] NIST Special Publication 500-183, "Stable Agreements for Open
Systems Interconnection Protocols," Version 4, Edition 1, December
1990.
[5] North American Directory Forum, ...
[6] RFC 1113E, Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures, J. Linn, ?,
1992.
[7] RFC 1115C, Privacy Enhancement for Internet Electronic Mail: Part
III: Algorithms, Modes, and Identifiers, D. Balenson, ?, 1992.
Kent (BBN) [Page 34]
PEM-1114F Certificate-Based Key Management March 1992
[8] RFC FORMS-C, Privacy Enhancement for Internet Electronic Mail:
Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving Services,
B. Kalaski, ?, 1992.
Kent (BBN) [Page 35]