As per Relevance of the word component, we have this rfc below:
Network Working Group S.
Request for Comments: 1422
Obsoletes: 1114 IAB IRTF PSRG, IETF
February 1993
Privacy Enhancement for Internet Electronic Mail
Part II: Certificate-Based Key
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This memo is the outgrowth of a series of meetings of the Privacy
Security Research Group of the Internet Research Task Force (IRTF
and the Privacy-Enhanced Electronic Mail Working Group of
Internet Engineering Task Force (IETF). I would like to thank
members of the PSRG and the PEM WG for their comments
contributions at the meetings which led to the preparation of
document. I also would like to thank contributors to the PEM-
mailing list who have provided valuable input which is reflected
this memo
1. Executive
This is one of a series of documents defining privacy
mechanisms for electronic mail transferred using Internet
protocols. RFC 1421 [6] prescribes protocol extensions
processing procedures for RFC-822 mail messages, given that
cryptographic keys are held by originators and recipients as
necessary precondition. RFC 1423 [7] specifies algorithms, modes
associated identifiers for use in processing privacy-
messages, as called for in RFC 1421 and this document. This
defines a supporting key management architecture and infrastructure
based on public-key certificate techniques, to provide
information to message originators and recipients. RFC 1424 [8]
provides additional specifications for services in conjunction
the key management infrastructure described herein
The key management architecture described in this document
compatible with the authentication framework described in CCITT 1988
X.509 [2]. This document goes beyond X.509 by
Kent [Page 1]
RFC 1422 Certificate-Based Key Management February 1993
procedures and conventions for a key management infrastructure
use with Privacy Enhanced Mail (PEM) and with other protocols,
both the TCP/IP and OSI suites, in the future. There are
motivations for establishing these procedures and conventions (
opposed to relying only on the very general framework outlined
X.509):
-It is important that a certificate management
for use in the Internet community accommodate a range
clearly-articulated certification policies for both
and organizations in a well-architected fashion
Mechanisms must be provided to enable each user to
aware of the policies governing any certificate which
user may encounter. This requires the
and standardization of procedures and conventions that
outside the scope of X.509.
-The procedures for authenticating originators and recipient
the course of message submission and delivery should
simple, automated and uniform despite the existence
differing certificate management policies. For example
users should not have to engage in careful examination of
complex set of certification relationships in order
evaluate the credibility of a claimed identity
-The authentication framework defined by X.509 is designed
operate in the X.500 directory server environment.
X.500 directory servers are not expected to be
in the Internet in the near future, so some
are adopted to facilitate operation of the key
infrastructure in the near term
-Public key cryptosystems are central to the
technology of X.509 and those which enjoy the
widespread use are patented in the U.S. Although
certification management scheme is compatible
the use of different digital signature algorithms, it
anticipated that the RSA cryptosystem will be used
the primary signature algorithm in establishing
Internet certification hierarchy. Special
arrangements have been made to facilitate
use of this algorithm in the U.S. portion of
environment
The infrastructure specified in this document establishes a
root for all certification within the Internet, the Internet
Registration Authority (IPRA). The IPRA establishes global policies
described in this document, which apply to all certification
Kent [Page 2]
RFC 1422 Certificate-Based Key Management February 1993
under this hierarchy. Beneath IPRA root are Policy
Authorities (PCAs), each of which establishes and publishes (in
form of an informational RFC) its policies for registration of
or organizations. Each PCA is certified by the IPRA. (It
desirable that there be a relatively small number of PCAs, each
a substantively different policy, to facilitate user familiarity
the set of PCA policies. However there is no explicit
that the set of PCAs be limited in this fashion.) Below PCAs
Certification Authorities (CAs) will be established to certify
and subordinate organizational entities (e.g., departments, offices
subsidiaries, etc.). Initially, we expect the majority of users
be registered via organizational affiliation, consistent with
practices for how most user mailboxes are provided. In this
the registration is analogous to the issuance of a university
company ID card
Some CAs are expected to provide certification for residential
in support of users who wish to register independent of
organizational affiliation. Over time, we anticipate that
government entities which already provide analogous
services in other contexts, e.g., driver's licenses, may
this service. For users who wish anonymity while taking advantage
PEM privacy facilities, one or more PCAs will be established
policies that allow for registration of users, under subordinate CAs
who do not wish to disclose their identities
2. Overview of
This document defines a key management architecture based on the
of public-key certificates, primarily in support of the
encipherment and authentication procedures defined in RFC 1421.
concept of public-key certificates is defined in X.509 and
architecture is a compliant subset of that envisioned in X.509.
Briefly, a (public-key) certificate is a data structure
contains the name of a user (the "subject"), the public
(This document adopts the terms "private component" and "
component" to refer to the quantities which are, respectively,
secret and made publicly available in asymmetric cryptosystems.
convention is adopted to avoid possible confusion arising from use
the term "secret key" to refer to either the former quantity or to
key in a symmetric cryptosystem.) of that user, and the name of
entity (the "issuer") which vouches that the public component
bound to the named user. This data, along with a time interval
which the binding is claimed to be valid, is cryptographically
by the issuer using the issuer's private component. The subject
issuer names in certificates are Distinguished Names (DNs) as
in the directory system (X.500).
Kent [Page 3]
RFC 1422 Certificate-Based Key Management February 1993
Once signed, certificates can be stored in directory servers
transmitted via non-secure message exchanges, or distributed via
other means that make certificates easily accessible to
system users, without regard for the security of the
medium. Certificates are used in PEM to provide the originator of
message with the (authenticated) public component of each
and to provide each recipient with the (authenticated)
component of the originator. The following brief
illustrates the procedures for both originator and recipients
Prior to sending an encrypted message (using PEM), an originator
acquire a certificate for each recipient and must validate
certificates. Briefly, validation is performed by checking
digital signature in the certificate, using the public component
the issuer whose private component was used to sign the certificate
The issuer's public component is made available via some out of
means (for the IPRA) or is itself distributed in a certificate
which this validation procedure is applied recursively. In
latter case, the issuer of a user's certificate becomes the
in a certificate issued by another certifying authority (or a PCA),
thus giving rise to a certification hierarchy. The validity
for each certificate is checked and Certificate Revocation
(CRLs) are checked to ensure that none of the certificates
in the validation process has been revoked by an issuer
Once a certificate for a recipient is validated, the public
contained in the certificate is extracted and used to encrypt
data encryption key (DEK), which, in turn, is used to encrypt
message itself. The resulting encrypted DEK is incorporated into
Key-Info field of the message header. Upon receipt of an
message, a recipient employs his private component to decrypt
field, extracting the DEK, and then uses this DEK to decrypt
message
In order to provide message integrity and data origin authentication
the originator generates a message integrity code (MIC),
(encrypts) the MIC using the private component of his public-
pair, and includes the resulting value in the message header in
MIC-Info field. The certificate of the originator is (optionally
included in the header in the Certificate field as described in
1421. This is done in order to facilitate validation in the
of ubiquitous directory services. Upon receipt of a privacy
message, a recipient validates the originator's certificate (
the IPRA public component as the root of a certification path),
checks to ensure that it has not been revoked, extracts the
component from the certificate, and uses that value to
(decrypt) the MIC. The recovered MIC is compared against the
calculated MIC to verify the integrity and data origin
Kent [Page 4]
RFC 1422 Certificate-Based Key Management February 1993
of the 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 in the Internet environment.
architecture describes procedures for registering
authorities and users, for generating and distributing certificates
and for generating and distributing CRLs. RFC 1421 describes
syntax and semantics of header fields used to transfer
and to represent the DEK and MIC in this public-key context
Definitions of the algorithms, modes of use and
identifiers are separated in RFC 1423 to facilitate the adoption
additional algorithms in the future. This document focuses on
management aspects of certificate-based, public-key cryptography
privacy enhanced mail
The proposed architecture imposes conventions for the
hierarchy which are not strictly required by the X.509
nor by the technology itself. These conventions are motivated
several factors, primarily the need for authentication
compatible with automated validation and the automated
of the policies under which certificates are issued
Specifically, the architecture proposes a system in which user (
mailing list) certificates represent the leaves in a
hierarchy. This certification hierarchy is largely isomorphic to
X.500 directory naming hierarchy, with two exceptions: the IPRA
the root of the tree (the root of the X.500 DIT is not
as a node), and a number of Policy Certification Authorities (PCAs
form the "roots" of subtrees, each of which represents a
certification policy
Not every level in the directory hierarchy need correspond to
certification authority. For example, the appearance of
entities in a distinguished name (e.g., countries, states, provinces
localities) does not require that various governments
certifying authorities in order to instantiate this architecture
However, it is anticipated that, over time, a number of such
in the hierarchy will be instantiated as CAs in order to
later transition of management to appropriate
authorities
These conventions minimize the complexity of validating
certificates, e.g., by making explicit the relationship between
Kent [Page 5]
RFC 1422 Certificate-Based Key Management February 1993
certificate issuer and the user (via the naming hierarchy). Note
in this architecture, only PCAs may be certified by the IPRA,
every CA's certification path can be traced to a PCA, through zero
more CAs. If a CA is certified by more than one PCA,
certificate issued by a PCA for the CA must contain a distinct
component. These conventions result in a certification
which is a compatible subset of that permitted under X.509,
respect to both syntax and semantics
Although the key management architecture described in this
has been designed primarily to support privacy enhanced mail,
infrastructure also may, in principle, be used to support X.400
security facilities (as per 1988 X.411) and X.500
authentication facilities. Thus, establishment of
infrastructure paves the way for use of these and other OSI
in the Internet in the future. In the future, these
also may be employed in the provision of security services in
protocols in the TCP/IP and OSI suites as well
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
This document interprets the X.509 certificate mechanism to serve
needs of PEM in the Internet environment. The
hierarchy proposed in this document in support of privacy
mail is intentionally a subset of that allowed under X.509.
certification hierarchy also embodies semantics which are
explicitly addressed by X.509, but which are consistent with X.509
precepts. An overview of the rationale for these semantics
provided in Section 1.
3.3 Certificate
Certificates are central to the key management architecture for X.509
and PEM. This section provides an overview of the syntax and
description of the semantics of certificates. Appendix A
the ASN.1 syntax for certificates. A certificate includes
following contents
Kent [Page 6]
RFC 1422 Certificate-Based Key Management February 1993
1.
2. serial
3. signature (algorithm ID and parameters
4. issuer
5. validity
6. subject
7. subject public key (and associated algorithm ID
3.3.1 Version
The version number field is intended to facilitate orderly changes
certificate formats over time. The initial version number
certificates used in PEM is the X.509 default which has a value
zero (0), indicating the 1988 version. PEM implementations
encouraged to accept later versions as they are endorsed
CCITT/ISO
3.3.2 Serial
The serial number field provides a short form, unique identifier
each certificate generated by an issuer. An issuer must ensure
no two distinct certificates with the same issuer DN contain the
serial number. (This requirement must be met even when
certification function is effected on a distributed basis and/or
the same issuer DN is certified under two different PCAs. This
especially critical for residential CAs certified under
PCAs.) The serial number is used in CRLs to identify
certificates, as described in Section 3.4.3.4. Although
attribute is an integer, PEM UA processing of this attribute need
involve any arithmetic operations. All PEM UA implementations
be capable of processing serial numbers at least 128 bits in length
and size-independent support serial numbers is encouraged
3.3.3
This field specifies the algorithm used by the issuer to sign
certificate, and any parameters associated with the algorithm. (
certificate signature is appended to the data structure, as
by the signature macro in X.509. This algorithm
information is replicated with the signature.) The signature
validated by the UA processing a certificate, in order to
that the integrity of its contents have not been modified
Kent [Page 7]
RFC 1422 Certificate-Based Key Management February 1993
to signing by a CA (IPRA, or PCA). In this context, a signature
effected through the use of a Certificate Integrity Check (CIC
algorithm and a public-key encryption algorithm. RFC 1423
the definitions and algorithm IDs for signature algorithms
in this architecture
3.3.4 Subject
A certificate provides a representation of its subject's identity
the form of a Distinguished Name (DN). The fundamental
ensured by the key management architecture is that between the
component and the user's identity in this form. A distinguished
is an X.500 directory system concept and if a user is
registered in an X.500 directory, his distinguished name is
via that registration. Users who are not registered in a
should keep in mind likely directory naming structure (schema)
selecting a distinguished name for inclusion in a certificate
3.3.5 Issuer
A certificate provides a representation of its issuer's identity,
the form of a Distinguished Name. The issuer identification is
to select the appropriate issuer public component to employ
performing certificate validation. (If an issuer (CA) is
by multiple PCAs, then the issuer DN does not uniquely identify
public component used to sign the certificate. In such
it may be necessary to attempt certificate validation using
public components, from certificates held by the issuer
different PCAs. If the 1992 version of a certificate is employed
the issuer may employ distinct issuer UIDs in the certificates
issues, to further facilitate selection of the right issuer
component.) The issuer is the certifying authority (IPRA, PCA or CA
who vouches for the binding between the subject identity and
public key contained in the certificate
3.3.6 Validity
A certificate carries a pair of date and time indications,
the start and end of the time period over which a certificate
intended to be used. The duration of the interval may be
for all user certificates issued by a given CA or it might
based on the nature of the user's affiliation. For example,
organization might issue certificates with shorter intervals
temporary employees versus permanent employees. It is
that the UTCT (Coordinated Universal Time) values recorded
specify granularity to no more than the minute, even though
granularity can be expressed in the format. (Implementors are
that no DER is defined for UTCT in X.509, thus transformation
Kent [Page 8]
RFC 1422 Certificate-Based Key Management February 1993
local and transfer syntax must be performed carefully, e.g.,
computing the hash value for a certificate. For example, a
value which includes explict, zero values for seconds would
produce the same hash value as one in which the seconds
omitted.) It also recommended that all times be expressed
Greenwich Mean Time (Zulu), to simplify comparisons and
confusion relating to daylight savings time. Note that
expresses the value of a year modulo 100 (with no indication
century), hence comparisons involving dates in different
must be performed with care
The longer the interval, the greater the likelihood that
of a private component or name change will render it invalid and
require that the certificate be revoked. Once revoked,
certificate must remain on the issuer's CRL (see Section 3.4.3.4)
until the validity interval expires. PCAs may impose restrictions
the maximum validity interval that may be elected by CAs operating
their certification domain (see Appendix B).
3.3.7 Subject Public
A certificate carries the public component of its associated subject
as well as an indication of the algorithm, and any
parameters, with which the public component is to be used.
algorithm identifier is independent of that which is specified in
signature field described above. RFC 1423 specifies the
identifiers which may be used in this context
3.4 Roles and
One way to explain the architecture proposed by this document is
examine the roles which are defined for various entities in
architecture and to describe what is required of each entity in
for the proposed system to work properly. The following
identify four types of entities within this architecture: users
user agents, the Internet Policy Registration Authority,
Certification Authorities, and other Certification Authorities.
each type of entity, this document specifies the procedures which
entity must execute as part of the architecture and
responsibilities the entity assumes as a function of its role in
architecture
3.4.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
Kent [Page 9]
RFC 1422 Certificate-Based Key Management February 1993
handling." In the Internet environment, programs such as rand
and Gnu emacs rmail are UAs. UAs exchange messages by calling on
supporting Message Transfer Service (MTS), e.g., the SMTP mail
used in the Internet
3.4.1.1 Generating and Protecting Component
A UA process supporting PEM must protect the private component of
associated entity (e.g., a human user or a mailing list)
disclosure, though the means by which this is effected is a
matter. It is essential that the user take all available
to protect his private component as the secrecy of this value
central to the security offered by PEM to that user. For example
the private component might be stored in encrypted form,
with a locally managed symmetric encryption key (e.g., using DES).
The user would supply a password or passphrase which would
employed as a symmetric key to decrypt the private component
required for PEM processing (either on a per message or per
basis). Alternatively, the private component might be stored on
diskette which would be inserted by the user whenever he
or received PEM messages. Explicit zeroing of memory locations
this component transiently resides could provide further protection
Other precautions, based on local operating system
facilities, also should be employed
It is recommended that each user employ ancillary software (
otherwise associated with normal UA operation) or hardware
generate his personal public-key component pair. Software
generating user component pairs will be available as part of
reference implementation of PEM distributed freely in the U.S
portion of the Internet. It is critically important that
component pair generation procedure be effected in as secure
fashion as possible, to ensure that the resulting private
is unpredictable. Introduction of adequate randomness into
component pair generation procedure is potentially the most
aspect of this process and the user is advised to pay
attention to this aspect. (Component pairs employed in public-
cryptosystems tend to be large integers which must be "randomly
selected subject to mathematical constraints imposed by
cryptosystem. Input(s) used to seed the component pair
process must be as unpredictable as possible. An example of a
random number selection technique is one in which a pseudo-
number generator is seeded solely with the current date and time.
attacker who could determine approximately when a component pair
generated could easily regenerate candidate component pairs
compare the public component to the user's public component to
when the corresponding private component had been found.)
Kent [Page 10]
RFC 1422 Certificate-Based Key Management February 1993
There is no requirement imposed by this architecture that
other than the user, including any certification authority,
access to the user's private component. Thus a user may retain
component pair even if his certificate changes, e.g., due to
in the validity interval or because of a change of
authority. Even if a user is issued a certificate in the context
his employment, there is generally no requirement that the
have access to the user's private component. The rationale is
any messages signed by the user are verifiable using his
component. In the event that the corresponding private
becomes unavailable, any ENCRYPTED messages directed to the
would be indecipherable and would require retransmission
Note that if the user stores messages in ENCRYPTED form,
messages also would become indecipherable in the event that
private component is lost or changed. To minimize the potential
loss of data in such circumstances messages can be transformed
MIC-ONLY or MIC-CLEAR form if cryptographically-
confidentiality is not required for the messages stored within
user's computer. Alternatively, these transformed messages might
forwarded in ENCRYPTED form to a (trivial) distribution list
serves in a backup capacity and for which the user's employer
the private component
A user may possess multiple certificates which may embody the same
different public components. For example, these certificates
represent a current and a former organizational user identity and
residential user identity. It is recommended that a PEM UA
capable of supporting a user who possess multiple certificates
irrespective of whether the certificates associated with the
contain the same or different DNs or public components
3.4.1.2 User
Most details of user registration are a local matter, subject
policies established by the user's CA and the PCA under which that
has been certified. In general a user must provide, at a minimum
his public component and distinguished name to a CA, or
representative thereof, for inclusion in the user's certificate
(The user also might provide a complete certificate, minus
signature, as described in RFC 1424.) The CA will employ some means
specified by the CA in accordance with the policy of its PCA,
validate the user's claimed identity and to ensure that the
component provided is associated with the user whose
name is to be bound into the certificate. (In the case of
certificates, described below, the procedure is a bit different.)
certifying authority generates a certificate containing the user'
distinguished name and public component, the authority'
Kent [Page 11]
RFC 1422 Certificate-Based Key Management February 1993
distinguished name and other information (see Section 3.3) and
the result using the private component of the authority
3.4.1.3 CRL
Mechanisms for managing a UA certificate cache are, in
standards parlance, a local matter. However, proper maintenance
such a cache is critical to the correct, secure operation of a PEM
and provides a basis for improved performance. Moreover, use of
cache permits a PEM UA to operate in the absence of directories (
in circumstances where directories are inaccessible). The
discussion provides a paradigm for one aspect of cache management
namely the processing of CRLs, the functional equivalent of
must be embodied in any PEM UA implementation compliant with
document. The specifications for CRLs used with PEM are provided
Section 3.5.
X.500 makes provision for the storage of CRLs as directory
associated with CA entries. Thus, when X.500 directories
widely available, UAs can retrieve CRLs from directories as required
In the interim, the IPRA will coordinate with PCAs to provide
robust database facility which will contain CRLs issued by the IPRA
by PCAs, and by all CAs. Access to this database will be
through mailboxes maintained by each PCA. Every PEM UA must
a facility for requesting CRLs from this database using
mechanisms defined in RFC 1424. Thus the UA must include
configuration parameter which specifies one or more mailbox
from which CRLs may be retrieved. Access to the CRL database may
automated, e.g., as part of the certificate validation process (
Section 3.6) or may be user directed. Responses to CRL requests
employ the PEM header format specified in RFC 1421 for
propagation. As noted in RFC 1421, every PEM UA must be capable
processing CRLs distributed via such messages. This message
also may be employed to support a "push" (versus a "pull") model
CRL distribution, i.e., to support unsolicited distribution of CRLs
CRLs received by a PEM UA must be validated (A CRL is validated
much the same manner as a certificate, i.e., the CIC (see RFC 1113)
is calculated and compared against the decrypted signature
obtained from the CRL. See Section 3.6 for additional
related to validation of certificates.) prior to being
against any cached certificate information. Any cache entries
match CRL entries should be marked as revoked, but it is
necessary to delete cache entries marked as revoked nor to
subordinate entries. In processing a CRL against the cache it
important to recall that certificate serial numbers are unique
for each issuer and that multiple, distinct CRLs may be issued
the same CA DN (signed using different private components), so
Kent [Page 12]
RFC 1422 Certificate-Based Key Management February 1993
must be exercised in effecting this cache search. (This
may arise either because an organizational CA is certified
multiple PCAs, or because multiple residential CAs are
under different PCAs.)
This procedure applies to cache entries associated with PCAs and CAs
as well as user entries. The UA also must retain each CRL to
incoming messages to detect use of revoked certificates carried
PEM message headers. Thus a UA must be capable of processing
retaining CRLs issued by the IPRA (which will list revoked
certificates), by any PCA (which will list revoked CA
issued by that PCA), and by any CA (which will list revoked user
subordinate CA certificates issued by that CA).
3.4.1.4 Facilitating
In the absence of ubiquitous directory services or
(acquired through out-of-band means) that a recipient
possesses the necessary issuer certificates, it is recommended
an originating (PEM) UA include sufficient certificates to
validation of the user's public key. To this end every PEM UA
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 IPRA, in a PEM message. A PEM
may send less than a full certification path, e.g., based on
of a recipient list, but a UA which provides this sort
optimization must also provide the user with a capability to
transmission of a full certification path
Optimization for the transmitted originator certification path may
effected by a UA as a side effect of the processing performed
message submission. When an originator submits an ENCRYPTED
(as per RFC 1421, his UA must validate the certificates of
recipients (see Section 3.6). In the course of performing
validation the UA can determine the minimum set of certificates
must be included to ensure that all recipients can process
received message. Submission of a MIC-ONLY or MIC-CLEAR message (
per RFC 1421) does not entail validation of recipient
and thus it may not be possible for the originator's UA to
the minimum certificate set as above
3.4.2 The Internet Policy Registration Authority (IPRA
The IPRA acts as the root of the certification hierarchy for
Internet community. The public component of the IPRA forms
foundation for all certificate validation within this hierarchy.
IPRA will be operated under the auspices of the Internet Society,
Kent [Page 13]
RFC 1422 Certificate-Based Key Management February 1993
international, non-profit organization. The IPRA certifies all PCAs
ensuring that they agree to abide by the Internet-wide
established by the IPRA. This policy, and the services provided
the IPRA, are detailed below
3.4.2.1 PCA
The IPRA certifies only PCAs, not CAs or users. Each PCA must
with the IPRA a description of its proposed policy. This
will be published as an informational RFC. A copy of the document
signed by the IPRA (in the form of a PEM MIC-ONLY message) will
made available via electronic mail access by the IPRA.
convention is adopted so that every Internet user has a
point for determining the policies associated with the issuance
any certificate which he may encounter. The existence of a
signed copy of the document ensures the immutability of the document
Authorization of a PCA to operate in the Internet hierarchy
signified by the publication of the policy document, and the
of a certificate to the PCA, signed by the IPRA. An outline for
policy statements is contained in Section 3.4.3 of this document
As part of registration, each PCA will be required to execute a
agreement with the IPRA, and to pay a fee to defray the costs
operating the IPRA. Each a PCA must specify its distinguished name
The IPRA will take reasonable precautions to ensure that
distinguished name claimed by a PCA is legitimate, e.g.,
the PCA to provide documentation supporting its claim to a DN
However, the certification of a PCA by the IPRA does not constitute
endorsement of the PCA's claim to this DN outside of the context
this certification system
3.4.2.2 Ensuring the Uniqueness of Distinguished
A fundamental requirement of this certification scheme is
certificates are not issued to distinct entities under the
distinguished name. This requirement is important to the success
distributed management for the certification hierarchy. The
will not certify two PCAs with the same distinguished name and no
may certify two CAs with the same DN. However, since PCAs
expected to certify organizational CAs in widely disjoint portions
the directory namespace, and since X.500 directories are
ubiquitous, a facility is required for coordination among PCAs
ensure the uniqueness of CA DNs. (This architecture allows
PCAs to certify residential CAs and thus multiple,
residential CAs with identical DNs may come into existence, at
until such time as civil authorities assume responsibilities for
certification. Thus, on an interim basis, the
explicitly accommodates the potential for duplicate residential
Kent [Page 14]
RFC 1422 Certificate-Based Key Management February 1993
DNs.)
In support of the uniqueness requirement, the IPRA will establish
maintain a database to detect potential, unintended
certification of CA distinguished names. This database will be
accessible to all PCAs via an email interface. Each entry in
database will consist of a 4-tuple. The first element in each
is a hash value, computed on a canonical, ASN.1
representation of a CA distinguished name. The second
contains the subjectPublicKey that appears in the CA's certificate
The third element is the distinguished name of the PCA
registered the entry. The fourth element consists of the date
time at which the entry was made, as established by the IPRA.
database structure provides a degree of privacy for CAs registered
PCAs, while providing a facility for ensuring global uniqueness of
DNs certified in this scheme
In order to avoid conflicts, a PCA should query the database using
CA DN hash value as a search key, prior to certifying a CA.
database will return any entries which match the query, i.e.,
have the same CA DN. The PCA can use the information contained
any returned entries to determine if any PCAs should be contacted
resolve possible DN conflicts. If no potential conflicts appear,
PCA can then submit a candidate entry, consisting of the first
element values, plus any entries returned by the query. The
will register this entry, supplying the time and date stamp, only
two conditions are met: (1) the first two elements (the CA DN
and the CA subjectPublicKey) of the candidate entry together must
unique and, (2) any other entries included in the submission
match what the current database would return if the
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
possible conflicting entries is not current (failure of case 2),
submission is rejected and the database will return the
conflicting entry (entries). If the submission is successful,
database will return the timestamped new entry. The database
not, in itself, guarantee uniqueness of CA DNs as it allows for
DNs associated with different public components to be registered
Rather, it is the responsibility of PCAs to coordinate with
another whenever the database indicates a potential DN conflict
to resolve such conflicts prior to certification of CAs. Details
the protocol used to access the database will be provided in
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
Kent [Page 15]
RFC 1422 Certificate-Based Key Management February 1993
policies. If a CA is certified by multiple different PCAs, the
must employ a different public key pair for each PCA. In
circumstances the certificate issued to the CA by each PCA
contain a different subjectPublicKey and thus will represent
different entry in this database. The same situation may arise
multiple, equivalent residential CAs are certified by different PCAs
To complete the strategy for ensuring uniqueness of DNs, there is
DN subordination requirement levied on CAs. In general, CAs
expected to sign certificates only if the subject DN in
certificate is subordinate to the issuer (CA) DN. This ensures
certificates issued by a CA are syntactically constrained to refer
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
if the certificates are "cross-certificates" or "
certificates" (see X.509) used with applications other than PEM
The IPRA also will establish and maintain a separate database
detect potential duplicate certification of (residential)
distinguished names. Each entry in this database will consist of 4-
tuple as above, but the first components is the hash of a
user DN and the third component is the DN of the residential CA
which registered the user. This structure provides a degree
privacy for users registered by CAs which service residential
while providing a facility for ensuring global uniqueness of user
certified under this scheme. The same database access facilities
provided as described above for the CA database. Here it is
responsibility of the CAs to coordinate whenever the
indicates a potential conflict and to resolve the conflict prior
(residential) user certification
3.4.2.3 Accuracy of Distinguished
As noted above, the IPRA will make a reasonable effort to ensure
PCA DNs are accurate. The procedures employed to ensure the
of a CA distinguished name, i.e., the confidence attached to
DN/public component binding implied by a certificate, will
according to PCA policy. However, it is expected that every PCA
make a good faith effort to ensure the legitimacy of each CA
certified by the PCA. Part of this effort should include a
that the purported CA DN is consistent with any applicable
standards for DN assignment, e.g., NADF recommendations within
America [5,9].
Kent [Page 16]
RFC 1422 Certificate-Based Key Management February 1993
3.4.2.4 Distinguished Name
A few basic DN conventions are included in the IPRA policy. The
will certify PCAs, but not CAs nor users. PCAs will certify CAs,
not users. These conventions are required to allow
certificate validation within PEM, as described later.
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
list maintained by the IANA, to provide a coordinated basis
attribute identification for all applications employing DNs.
list will initially be populated with attributes taken from X.520.
This document does not impose detailed restrictions on the
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
which have printable representations, to facilitate display
entry
3.4.2.5 CRL
Among the procedures articulated by each PCA in its policy
are procedures for the maintenance and distribution of CRLs by
PCA itself and by its subordinate CAs. The frequency of issue
CRLs may vary according to PCA-specific policy, but every PCA and
must issue a CRL upon inception to provide a basis for
certificate validation procedures throughout the Internet hierarchy
The IPRA will maintain a CRL for all the PCAs it certifies and
CRL will be updated monthly. Each PCA will maintain a CRL for all
the CAs which it certifies and these CRLs will be updated
accordance with each PCA's policy. The format for these CRLs
that specified in Section 3.5.2 of the document
In the absence of ubiquitous X.500 directory services, the IPRA
require each PCA to provide, for its users, robust database access
CRLs for the Internet hierarchy, i.e., the IPRA CRL, PCA CRLs,
CRLs from all CAs. The means by which this database is
is to be coordinated between the IPRA and PCAs. This database
be accessible via email as specified in RFC 1424, both for
of (current) CRLs by any user, and for submission of new CRLs by CAs
PCAs and the IPRA. Individual PCAs also may elect to maintain
archives for their CAs, but this is not required by this policy
3.4.2.6 Public Key Algorithm Licensing
This certification hierarchy is architecturally independent of
specific digital signature (public key) algorithm. Some algorithms
Kent [Page 17]
RFC 1422 Certificate-Based Key Management February 1993
employed for signing certificates and validating
signatures, are patented in some countries. The IPRA will not
a license to any PCA for the use of any signature algorithm
conjunction with the management of this certification hierarchy.
IPRA will acquire, for itself, any licenses needed for it to
certificates and CRLs for PCAs, for all algorithms which the
supports. Every PCA will be required to represent to the IPRA
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
and thus any PCA operating in the U.S. and using RSA to
certificates and CRLs must represent that it has a valid license
employ the RSA algorithm in this fashion. In contrast, a
employing RSA and operating outside of the U.S. would represent
it is exempt from these licensing constraints
3.4.3 Policy Certification
The policy statement submitted by a prospective PCA must address
topics in the following outline. Additional policy information
be contained in the statement, but PCAs are requested not to
these statements as advertising vehicles
1. PCA Identity- The DN of the PCA must be specified. A
address, an Internet mail address, and telephone (and optional fax
numbers must be provided for (human) contact with the PCA. The
on which this statement is effective, and its scheduled duration
be specified
2. PCA Scope- Each PCA must describe the community which the
plans to serve. A PCA should indicate if it will
organizational, residential, and/or PERSONA CAs. There is not
requirement that a single PCA serve only one type of CA, but if a
serves multiple types of CAs, the policy statement must
clearly how a user can distinguish among these classes. If the
will operate CAs to directly serve residential or PERSONA users,
must so state
3. PCA Security & Privacy- Each PCA must specify the technical
procedural security measures it will employ in the generation
protection of its component pair. If any security requirements
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
privacy of any information collected in the course of certifying CAs
If the PCA operates one or more CAs directly, to serve residential
PERSONA users, then this statement on privacy measures applies
these CAs as well
Kent [Page 18]
RFC 1422 Certificate-Based Key Management February 1993
4. Certification Policy- Each PCA must specify the policy
procedures which govern its certification of CAs and how this
applies transitively to entities (users or subordinate CAs)
by these CAs. For example, a PCA must state what procedure
employed to verify the claimed identity of a CA, and the CA's
to use a DN. Similarly, if any requirements are imposed on CAs
validate the identity of users, these requirements must be specified
Since all PCAs are required to cooperate in the resolution
potential DN conflicts, each PCA is required to specify the
it will employ to resolve such conflicts. If the PCA imposes
maximum validity interval for the CA certificates it issues, and/
for user (or subordinate CA) certificates issued by the CAs
certifies, then these restrictions must be specified
5. CRL Management- Each PCA must specify the frequency with which
will issue scheduled CRLs. It also must specify any constraints
imposes on the frequency of scheduled issue of CRLs by the CAs
certifies, and by subordinate CAs. Both maximum and
constraints should be specified. Since the IPRA policy calls
each CRL issued by a CA to be forwarded to the cognizant PCA,
PCA must specify a mailbox address to which CRLs are to
transmitted. The PCA also must specify a mailbox address for
queries. If the PCA offers any additional CRL management services
e.g., archiving of old CRLs, then procedures for invoking
services must be specified. If the PCA requires CAs to provide
additional CRL management services, such services must be
here
6. Naming Conventions- If the PCA imposes any conventions on DNs
by the CAs it certifies, or by entities certified by these CAs,
conventions must be specified. If any semantics are associated
such conventions, these semantics must be specified
7. Business Issues- If a legal agreement must be executed between
PCA and the CAs it certifies, reference to that agreement must
noted, but the agreement itself ought not be a part of the
statement. Similarly, if any fees are charged by the PCA this
be noted, but the fee structure per se ought not be part of
policy statement
8. Other- Any other topics the PCA deems relevant to a statement
its policy can be included. However, the PCA should be aware that
policy statement is considered to be an immutable, long
document and thus considerable care should be exercised in
what material is to be included in the statement
Kent [Page 19]
RFC 1422 Certificate-Based Key Management February 1993
3.4.4 Certification
In X.509 the term "certification authority" is defined as "
authority trusted by one or more users to create and
certificates". X.509 imposes few constraints on CAs, but
implementation of a worldwide certification system
establishment of technical and procedural conventions by which
CAs are expected to abide. Such conventions are
throughout this document. All CAs are required to maintain
database of the DNs which they have certified and to take measures
ensure that they do not certify duplicate DNs, either for users
for subordinate CAs
It is critical that the private component of a CA be afforded a
level of security, otherwise the authenticity guarantee implied
certificates signed by the CA is voided. Some PCAs may
stringent requirements on CAs within their purview to ensure that
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
Many of the CAs certified by PCAs are expected to
organizations. A wide range of organizations are encompassed by
model: commercial, governmental, educational, non-profit
professional societies, etc. The common thread is that the
certified by these CAs have some form of affiliation with
organization. The object classes for organizations,
units, organizational persons, organizational roles, etc., as
in X.521, form the models for entities certified by such CAs.
affiliation implied by organizational certification motivates the
subordination requirement cited in Section 3.4.2.4.
As an example, an organizational user certificate might contain
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
form: C = "US" SP = "Massachusetts" L = "Cambridge" O= "Bolt
and Newman". Note that the organizational unit attribute is
from the issuer DN, implying that there is no CA dedicated to
"Communications Division".
3.4.4.2 Residential
Users may wish to obtain certificates which do not imply
organizational affiliation but which do purport to accurately
uniquely identify them. Such users can be registered as
persons and the DN of such a user should be consistent with
Kent [Page 20]
RFC 1422 Certificate-Based Key Management February 1993
attributes of the corresponding X.521 object class. Over time
anticipate that such users will be accommodated by civil
entities who will assume electronic certification responsibility
geographically designated points in the naming hierarchy.
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
multiple PCAs, there is a potential for the same residential CA DN
be assumed by several distinct entities. This represents the
exception to the rule articulated throughout this document that
two entities may have the same DN. This conflict is tolerated so
to allow residential CAs to be established offering
policies. Two requirements are levied upon residential CAs as
result: (1) residential CAs must employ the residential DN
detection database maintained by the IPRA, and (2) residential
must coordinate to ensure that they do not assign
certificate serial numbers
As an example, a residential user certificate might include a
name of the form: C = "US" SP = "Massachusetts" L = "Boston" PA = "19
North Square" CN = "Paul Revere." The issuer of that
might have a DN of the form: C = "US" SP = "Massachusetts" L =
"Boston". Note that the issuer DN is superior to the subject DN,
required by the IPRA policy described earlier
3.4.4.3 PERSONA
One or more CAs will be established to accommodate users w