|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T d
Length: 117626 (0x1cb7a)
Types: TextFile
Names: »draft-ietf-pem-keymgmt-00.txt«
└─⟦4f9d7c866⟧ Bits:30007245 EUUGD6: Sikkerheds distributionen
└─⟦this⟧ »./papers/IETF-drafts/draft-ietf-pem-keymgmt-00.txt«
Network Working Group Kent (BBN)
Internet Draft IAB IRTF PSRG
28 June 1991
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
current RFC-1114. References within the text of this Internet-Draft
to this document as an RFC, or to related Internet-Drafts cited as
"RFC [1113D]", "RFC [1115B]", and "RFC [FORMS-A]" 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 Internet
Research Task Force's Privacy and Security Research Group. Comments
should be sent to <pem-dev@tis.com>.
ACKNOWLEDGMENT
This RFC is the outgrowth of a series of IAB Privacy And Security
Research Group meetings and of internal working papers distributed
for those meetings. In particular, John Linn contributed
significantly to the predecessor to this document (RFC 1114). I
would like to thank the members of the PSRG 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 [1113D] 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 [1115B] specifies algorithms, modes and
associated identifiers for use in processing privacy-enhanced
messages, as called for in RFC [1113D] and this RFC. This RFC
defines a supporting key management architecture and infrastructure,
Kent (BBN) [Page 1]
Internet Draft Certificate-Based Key Management June 28, 1991
based on public-key certificate techniques, to provide keying
information to message originators and recipients. RFC [FORMS-A]
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 [1].
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, TCP/IP and OSI, 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):
-The quality of user authentication offered by the key management
infrastructure should be as uniform as possible throughout
the Internet community to help instill user confidence in the
overall system. 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
automated. Users should not have to engage in careful
examination of a complex set of assertions 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 for some time and so some conventions are
adopted to facilitate operation of the key management
infrastructure in the near term.
-Organizations which can most appropriately vouch for the
identity of users may not possess specialized technology
required to manage cryptographic keys in a secure fashion.
Thus provisions must be made to provide such technology to
support uniformly high quality authentication.
-Public key cryptosystems, which are central to the
authentication technology of X.509, are patented in the U.S.
In particular, PEM makes use of the RSA cryptosystem and
Kent (BBN) [Page 2]
Internet Draft Certificate-Based Key Management June 28, 1991
special license arrangements (1) have been made so that this
algorithm may be used with freely distributed software in the
Internet environment. Appendix B provides additional details
on user and organization registration within the purview of
the RSA patent.
The infrastructure specified in this RFC specifies procedures for the
registration of PEM users. The registration procedures apply not
only to individuals but also to mailing lists and organizational
roles (see Section 3.6). 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. Nonetheless, the RFC establishes procedures for
users to be registered 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. Also, in support of
personal privacy, special provisions have been made for registration
of users who do not wish to disclose their identity. Naming
conventions are established to ensure that users registered under
these provisions will not be be confused with other users who are
asserting validated identities.
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 [1113D].
The concept of public-key certificates is defined in X.509 and this
architecture is compliant with X.509.
_______________
(1) No use of the RSA public-key cryptosystem outside the scope
defined in this RFC is authorized by this license as of this
time, although expansion of the license to other Internet
security applications is anticipated. The license alluded to
here does not authorize the sale of software or hardware
incorporating the RSA algorithm; it is an end-user license, not a
developer's license.
Kent (BBN) [Page 3]
Internet Draft Certificate-Based Key Management June 28, 1991
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 key of each recipient and to
provide each recipient with the (authenticated) public key of the
originator. The following brief discussion illustrates the
procedures for both originator and recipients.
Prior to sending an encrypted message, 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
(described later) or is itself distributed in a certificate to which
this validation procedure is applied recursively. In the latter
case, the issuer of a user's certificate becomes the subject in a
certificate issued by another certifying authority, 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.
_______________
(2) Throughout this RFC we have adopted 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]
Internet Draft Certificate-Based Key Management June 28, 1991
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) that 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
[1113D]. 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,
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 [1113D] describes the
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 [1115B] to facilitate the addition
of other algorithms in the future. This RFC focuses on the
management aspects of certificate-based, public-key cryptography for
privacy enhanced mail.
Kent (BBN) [Page 5]
Internet Draft Certificate-Based Key Management June 28, 1991
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, including the need for authentication semantics
compatible with automated validation, a near-term dearth of
electronic mail directory services, and some implications of the
patent status of public-key cryptosystems in the U.S. Over time we
anticipate that some of these constraints, e.g., directory service
availability, will change and the procedures specified in the RFC
will be reviewed and modified as appropriate.
Specifically, the architecture proposes a system in which user
certificates represent the leaves in a shallow certification
hierarchy. This certification hierarchy is largely isomorphic to the
X.500 directory naming hierarchy, with two exceptions: a small
number of "top level" certification authorities (TLCAs) which form
the "roots" of the certification tree, and an interim convention
which allows users unaffiliated with an organization in the
certification hierarchy to obtain public-key certificates
nonetheless.
Not every level in the directory hierarchy need correspond to a
certification authority. For example, the appearance of geographic
entities in a name (e.g., states, provinces, cities) does not require
that various local governments become certifying authorities in order
to instantiate this architecture.
These conventions minimize the complexity of validating user
certificates by limiting the length of "certification paths" and by
making explicit the relationship between a certificate issuer and the
user (via the naming hierarchy). Note that in this architecture,
only organizations may act as issuers; a user certificate may appear
in a certification path only as the terminal node in the path. 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.
Although the key management architecture described in this RFC has
been designed primarily to support privacy enhanced mail, this
infrastructure also supports 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
Kent (BBN) [Page 6]
Internet Draft Certificate-Based Key Management June 28, 1991
security services in other protocols in the TCP/IP suite 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 privacy-enhanced mail 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 a brief description of the syntax and
semantics of certificates. Appendix A includes the ASN.1 syntax for
certificates. A certificate includes the following contents:
1. version
2. serial number
3. certificate signature (and associated algorithm ID)
4. issuer name
5. validity period
Kent (BBN) [Page 7]
Internet Draft Certificate-Based Key Management June 28, 1991
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).
3.3.2 Serial Number
The serial number field provides a short form, unique identifier for
each certificate generated by an issuer. 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 processing of
this attribute need not involve any arithmetic operations. All PEM
implementations must be capable of processing serial numbers up to 48
bits in length and support for larger serial numbers is encouraged.
3.3.3 Certificate Signature
A certificate carries a signature algorithm identifier and a
signature, applied to the certificate by its issuer. The signature
is validated by the UA processing a certificate, in order to
determine that the integrity of its contents have not been
compromised subsequent to generation by a CA. In this context, a
signature is effected through the use of a Certificate Integrity
Check (CIC) algorithm and a public-key encryption algorithm. RFC
[1115B] contains the definitions and algorithm IDs for signature
algorithms employed in this architecture.
Kent (BBN) [Page 8]
Internet Draft Certificate-Based Key Management June 28, 1991
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.
Section 3.6 describes constraints imposed on the form of
distinguished names for use in this architecture.
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. The issuer is the Certifying
Authority (CA) who vouches for the subject identity contained in the
certificate.
3.3.6 Validity Period
A certificate carries a pair of time specifiers, 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.
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. TLCAs may impose restrictions
Kent (BBN) [Page 9]
Internet Draft Certificate-Based Key Management June 28, 1991
on the maximum 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 with which the public
component is to be used. For purposes of this RFC, the algorithm
identifier will indicate use of the RSA algorithm, as specified in
RFC [1115B]. If other public key algorithms are supported in the
future, additional algorithm identifiers will be specified.
3.4 Entities' Roles and Responsibilities
One way to explain the architecture proposed by this RFC 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 three types of entities within this architecture: users and
user agents, organizational notaries and certification authorities
(including "top level" certification authorities). For each class of
entity we describe 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." UAs exchange messages by calling on a supporting Message
Transfer Service (MTS).
Kent (BBN) [Page 10]
Internet Draft Certificate-Based Key Management June 28, 1991
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). Other precautions, based on local operating system security
facilities, also should be employed.
We recommend that each user employ ancillary software or hardware
(not otherwise associated with normal UA operation) to generate his
personal public/private 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.) 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 component pair is unpredictable.
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.
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
Kent (BBN) [Page 11]
Internet Draft Certificate-Based Key Management June 28, 1991
user's computer. Alternatively, these messages can 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.
Many details of user registration are a local matter, but in general
a user must provide his public component and distinguished name to a
representative of a certification authority for inclusion in the
user's certificate. The representative will employ some (locally
defined) means 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. 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.
For users affiliated with organizations which register as CAs, there
will be one or more individuals identified as Organizational Notaries
(ONs) (see below) within each organization who will act as CA
representatives. In such cases the distinguished name of the user
(subject) will be subordinate to the distinguished name of the
issuer, emphasizing the relationship between the issuer and the
subject.
A user who does not wish to claim affiliation with an organization
can register as a "residential user" (see Section 3.6). Over time
such registration is expected to be provided by state and municipal
government, but in the near term such users will be able to register
with one or more organizations which will provide some degree of
public registration services as described in RFC [FORMS-A]. In the
latter case the resulting certificate will indicate that the CA is
not vouching for the user's identity via an organizational
affiliation. Such certificates are designated "NOTARY" certificates
and are unambiguously identified via a naming convention employed by
the issuer and described in Section 3.4.3.1.
An additional provision is made to accommodate any user who wishes to
engage in secure communication without revealing his true identity
(as would otherwise occur in the course of certificate management).
Such users can be issued "PERSONA" certificates which are
unambiguously identified via a naming convention employed by the
issuer and described in Section 3.4.3.2. Such certificates
explicitly DO NOT represent a validated identity attested to by the
Kent (BBN) [Page 12]
Internet Draft Certificate-Based Key Management June 28, 1991
issuer. The issuer of a PERSONA certificate represents only that he
maintains records sufficient to prevent issuance of the same
distinguished name to different users.
The transmission of a user's identifying information and public
component to an organizational (or "public") notary is a local
matter, but we expect electronic mail will be the preferred approach
in many circumstances. RFC [FORMS-A] describes electronic mail
formats and procedures in support of user registration. Software
compliant with RFC [FORMS-A] will be included in the PEM reference
implementation in support of this procedure.
3.4.2 Organizational Notaries
An organizational notary (ON) is an individual who acts as a
representative of a CA to register users within an organization such
as a corporation or a university. A CA may be represented by one or
more ONs. Each ON represents an organization or some division
thereof, e.g., an organizational unit in X.500 naming terms. An ON
is required to have some independence from the users on whose behalf
certificates are ordered, so as not be to subject to influence by the
user who he is registering. Each ON should be a "trustworthy"
individual (as determined by the organization) and the role of an ON
should be viewed as a position of trust within the organization. An
ON must be in a position to verify the identity of each individual to
whom he issues a certificate, otherwise he is not properly executing
his responsibility. ("PERSONA" certificates represent an exception to
this latter requirement, as discussed later.)
In order to maintain the structure of the certification hierarchy, an
ON must issue certificates only for users whose DN is subordinate to
that of the CA in the directory hierarchy. ("NOTARY" certificates,
defined in Section 3.4.3.1, represent an exception to this general
rule). Procedural, legal and/or technical means may be employed by
TLCAs to enforce this requirement. In addition, PEM software must
reject any certificate which does not comply with this convention,
i.e., a certificate in which the subject DN is not subordinate to the
issuer DN, except as provided elsewhere in this RFC. For example, an
ON at BBN must not issue certificates for users who are affiliated
with MIT or MITRE (as indicated by their DNs).
Kent (BBN) [Page 13]
Internet Draft Certificate-Based Key Management June 28, 1991
It can be assumed that the set of organizations and ONs changes
relatively slowly and that that set is relatively small in comparison
with the number of users. Thus a more extensive, higher assurance
process may reasonably be associated with the registration of
organizations and ONs than with per-user registration. Restrictions
on the range of information which an ON is authorized to certify are
established as part of this more elaborate registration process. The
procedures for registering certifying authorities with top-level CAs
vary both internationally and within the U.S. Appendix B describes
procedures for registration of non-government certifying authorities
in the U.S. (where patent licensing issues impose a specific
structure). Registration with TLCAs in other countries, and within
the U.S. government, are outside the scope of this RFC, but are
expected to be comparable in terms of security procedures, in order
to maintain uniform assurance across TLCA domains.
An ON is responsible for establishing the correctness and integrity
of information incorporated in an order, and will generally vouch for
(certify) the accuracy of identity information at a granularity finer
than that provided by certifying authorities offering a "public
service." Although it is probably infeasible to enforce absolutely
uniform standards for the user certification process across all ONs,
we anticipate that organizations will endeavor to maintain high
standards in this process in recognition of the "visibility"
associated with the identification data contained in certificates.
Moreover, minimum requirements for ON registration and user
registration may be specified by a TLCA in the course of registering
CAs within its purview. For example, RSADSI, the TLCA for the (non-
governmental) U.S. community has established such requirements as
part of the legal agreement it executes with prospective CAs (see RFC
[OrgAgreement]).
An ON must supply or may constrain the validity period of a
certificate prior to signing it (to comply with the policy of the CA
which the ON represents or with a policy imposed by the cognizant
TLCA). If distributed CA functionality is offered through multiple
ONs, provisions must be made to ensure that the serial number and the
subject DN contained in each certificate is unique among all issued
under the auspices of the CA.
Kent (BBN) [Page 14]
Internet Draft Certificate-Based Key Management June 28, 1991
3.4.3 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.
Note that the signature applied to each certificate is that of the
issuer (CA), not that of the ON. Thus, if multiple ONs implement a
distributed CA function, provisions must be made so that all of the
ONs can cause certificates which they have approved to be signed
using the same issuer private component. The means by which this can
be accomplished is a local matter, but Appendix B describes two
mechanisms which may be employed to effect this distributed issuer
function in a secure fashion.
It is critical that the private component of a CA be afforded a very
high level of security, otherwise the authenticity guarantee implied
by certificates signed by the CA is voided. TLCAs may impose
stringent requirements on CAs within their purview to ensure that a
high level of security is afforded the certificate signing process.
These requirements are expected to address both technical and
procedural security concerns. Specific requirements for CAs under
the certification hierarchy established by RSADSI are described in
Appendix B.
3.4.3.1 The NOTARY Convention
Some 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" under the DN conventions described in Section 3.6. Such a
DN consists entirely of geographic and postal attributes, i.e., no
organizational attributes are allowed. 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, the NOTARY
convention is established to accommodate such users. Under this
Kent (BBN) [Page 15]
Internet Draft Certificate-Based Key Management June 28, 1991
convention, certificates issued to residential users are identified
by requiring the last attribute of the issuer name to be an
organizationalUnit with the value "NOTARY". In this case the subject
DN is explicitly NOT subordinate to the issuer DN. Thus this is one
of the two exceptions to the general rule of issuer and subject DN
relationship (see also Section 3.4.3.3).
Every TLCA must establish at least one CA which will issue NOTARY
certificates to users within its purview. This CA may be affiliated
with the TLCA, but this is not required. We expect that each TLCA
will have responsibility for a (non-overlapping) portion of the
naming hierarchy and thus if only one CA provides this service under
the auspices of each TLCA, it should be possible to avoid issuance of
NOTARY certificates with conflicting subject DNs. However, if
multiple CAs issue NOTARY certificates under the auspices of a single
TLCA, there is a potential naming conflict problem. In such
circumstances the TLCA must institute some co-ordination mechanisms
to ensure that duplicate subject DNs are not certified by different
CAs. Also note that CAs issuing NOTARY certificates are expected to
implement procedures that provide a reasonable degree of confidence
in the user's claimed identity. Such procedures might include
written confirmation of the user's identity, including claimed postal
address, by a Notary Public or equivalent. (3)
To illustrate the NOTARY certificate convention, consider the
following example in which RSADSI acts as an issuer in this capacity.
A user certified by RSADSI under this convention may hold a
certificate in which the issuer DN might consist of the following
sequence of attributes: C = "US" S = "CA" O = "RSA Data Security
Inc." OU = "Notary." The subject of such a certificate might contain
the following DN: C = "US" S = "Massachusetts" L = "Boston" PA = "19
North Square" CN = "Paul Revere."
_______________
(3) Users should be aware that the subject DN in a NOTARY
certificate may fail to match the naming schema adopted by
directory authorities for residential users in the future. Thus
the certificate may have to be reissued to comply with the naming
schema at some future date. This situation may arise whenever a
user is issued a certificate prior to being registered in a
directory. It is even more likely to be a problem for
residential users since provisions for registration of such users
by appropriate (e.g., civil) authorities may take some time to
implement.
Kent (BBN) [Page 16]
Internet Draft Certificate-Based Key Management June 28, 1991
One final note about NOTARY certificates. There is no provision made
to issue certificates to individuals who claim organizational
affiliation to an organization which is not registered as a CA. Thus
no NOTARY certificates will be issued by a TLCA for organizational
persons (vs. residential persons, see Section 3.6). The motivation
underlying this constraint is that only an organization should be
able to authorize individuals to be certified as being affiliated
with that organization. Thus no CA, not even a TLCA, is empowered to
certify a user as being affiliated with another organization.
3.4.3.2 The PERSONA Convention
A second convention is adopted 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.
Such certificates are identified by the presence, in the subject DN,
of an organizationalUnit attribute with the value "PERSONA". This
convention is established to warn other users that the subject DN is
NOT a validated user identity. Note that a PERSONA certificate
differs from a NOTARY certificate in that the distinguished attribute
appears not in the issuer's DN but in the subject's DN. Note also
that, unlike a NOTARY certificate, the subject DN must be subordinate
to the issuer in the naming hierarchy, and thus the subject's DN will
include the issuer's DN (as a prefix).
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 PERSONA certificate. However, a CA issuing
PERSONA certificates must establish procedures (not specified in this
RFC) in order to allow the holder of a PESRONA certificate to request
that the certificte be revoked (i.e., list on a CRL).
Kent (BBN) [Page 17]
Internet Draft Certificate-Based Key Management June 28, 1991
3.4.3.3 The GUEST Convention
As noted earlier, an organization acting as a CA may issue
certificates to users who may not be "closely affiliated" with the
organization. For example, a user whose access to Internet mail
facilities is the result of his guest affiliation with a company or
university may be an inappropriate candidate for the strong
association typically implied by that organization's granting of his
certificate. In such a case, the organization acting as a CA should
be able to issue a certificate which does not imply that the user is
closely affiliated with the organization.
This situation is addressed by adopting a third convention by which
organizations wishing to certify these less closely affiliated users
do so by including an organizationalUnit attribute with the value
"GUEST" in the subject DN of the user certificate. The subject name
in such a certificate is still constrained by the general requirement
set forth in this RFC that the subject DN be subordinate to the
issuer DN in the naming hierarchy and thus uniqueness of subject DNs
in GUEST certificates is readily ensured by CAs. A CA issuing a
GUEST certificate may employ less stringent standards of identity
validation than are applied to users closely affiliated with the CA's
organization. However, GUEST certificates are intended to accurately
convey a user's identity and thus a GUEST certificate must not be
issued as an alternative to a PERSONA certificate (see above).
3.4.3.4 Interoperation Across Certification Domains
Interoperation across the certification domains implied by the
purviews of distinct TLCAs is a goal of PEM. In support of that
goal, all TLCAs which impose comparable security requirements for
user certification are expected to "cross certify" one another. For
example, RSADSI would generate a certificate in which it is
identified as the issuer and a certifying authority for the U.S.
government is identified as the subject. Conversely, the U.S.
government certifying authority would generate a certificate in which
it is the issuer and RSADSI is the subject.
Cross certification is always symmetric, i.e., no TLCA shall issue a
certificate with another TLCA as subject unless the latter TLCA also
issues a certificate with the former TLCA as subject. This
requirement is intended to preclude circumstances where users in
Kent (BBN) [Page 18]
Internet Draft Certificate-Based Key Management June 28, 1991
different certification domains are unable to exchange PEM message
because of asymmetries in certification paths. Note that "cross
certificates", because they involve TLCAs as both issuer and subject,
also violate the general rule about the required relationship between
issuer and subject DNs.
This cross certification of TLCAs establishes a basis for "lower
level" (e.g., organization and user) certificate validation across
the domain boundaries. Starting with the public component for one's
"native" TLCA, (4) one can validate a certificate in another
certification domain through the use of a cross certificate. This
avoids the need for users in one certification domain to engage in
some "out-of-band" procedure to acquire a public-key for use in
validating certificates from a different certification domain.
Because the trust implied by cross certification between TLCAs will
likely be based on bilateral agreements between the TLCAs, cross
certification is NOT transitive. Thus, in the course of validating a
certificate, at most one cross certificate may be encountered. This
convention prevents cross certification by TLCAs from extending the
certification hierarchy without the explicit consent of the involved
TLCAs. Mechanistically, this constraint can be enforced because of
the convention which requires a TLCA to be identified as such via
inclusion of an organizationalUnit attribute with value "TLCA" in its
distinguished name. Thus a cross certificate is one in which both
issuer and subject DNs contain this reserved organizationalUnit
attribute.
In the absence of ubiquitous directory services or knowledge that a
recipient already possesses the necessary cross certificates, it is
recommended that an originator include the appropriate cross
certificate(s) (using the "Issuer-Certificate" field) when
communicating with a recipient outside the originator's certification
domain. When an originator submits an ENCRYPTED message (as per RFC
[1113D], his UA must validate the certificates of the recipients. In
the course of performing this validation it will be apparent if any
of the recipients are registered under a TLCA other than the user's
native TLCA. It is recommended that PEM software include a provision
for the user to specify the automatic inclusion of all appropriate
_______________
(4) Each PEM implementation must include facilities to identify a
native TLCA, specified either by the user or as a configuration
paramater.
Kent (BBN) [Page 19]
Internet Draft Certificate-Based Key Management June 28, 1991
cross certificates when sending ENCRYPTED message.
Submission of a MIC-ONLY or MIC-CLEAR message (as per RFC [1113D)
does not entail validation of recipient certificates and thus is may
not be possible for the UA to automatically determine when cross
certificates are required for the validation of the message
signature. In such cases it may be necessary for the user to
explicitly specify which cross certificates are required. It is
recommended that PEM software provide an interface to allow the user
to explicitly specify the inclusion of cross certificates when
submitting MIC-CLEAR or MIC-ONLY messages.
Thus, additional steps may be required to validate certificates when
certification domain boundaries are crossed, but the same basic
procedure (described in Section 3.5) is employed. Caching of
certificates by UAs can significantly reduce the effort required to
process messages and so these examples should be viewed as "worst
case" scenarios.
3.4.3.5 Certificate Revocation
3.4.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 will issue a new CRL, even if there are no changes
in the list of entries. In this fashion each CA can independently
establish and advertise the frequency with which CRLs are issued by
Kent (BBN) [Page 20]
Internet Draft Certificate-Based Key Management June 28, 1991
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.
These deficiencies are the subject of two recently submitted defect
reports (in process at the time of RFC publication). These reports
suggest addressing the defects with exactly the CRL format outlined
in this architecture. Thus, although the format of a PEM CRL is a
deviation from the format specified in X.509 (1988), it is hoped that
it will be consistent with the next version of the X.509 standard (in
1992), and with implementations of X.509 whose CRL format is
consistent with the solutions in an updated "CCITT Directory
Implementor's Guide."
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.
The requirement for this syntax may be occasioned because, in its
most general form, X.509 allows all certification paths within the
transitive closure of cross-certifications by CAs. For example, a CA
may wish to include in its ARL the revocation of the certificate for
a CA which would otherwise be recognized as a valid issuer through an
implied path of cross certifications. The requirement for ARLs of
this sort is considerably weakened in the PEM environment where the
cross certification of hierarchies is considerably limited (e.g.,
Kent (BBN) [Page 21]
Internet Draft Certificate-Based Key Management June 28, 1991
cross certification takes place only between TLCAs and is not
transitive). As a simplification, this RFC proposes to use CRLs for
revocation both of user and of authority certificates.
3.4.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. CRL signature (and associated algorithm ID)
2. issuer
3. last update
4. next update
5. revoked certificates
The "CRL signature" is a data item completely analogous to a
certificate signature and 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.
Kent (BBN) [Page 22]
Internet Draft Certificate-Based Key Management June 28, 1991
3.4.3.5.3 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 TLCAs. 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
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 TLCA 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 TLCAs are expected to establish
minimum and maximum intervals for such issuance (e.g., see Appendix
B).
Each TLCA is required to establish a database which maintains CRLs
for all of the CAs within its domain. At a minimum, access to the
database must be provided via electronic mail as described in RFC
[FORMS-A]. Other access means also may be provided, e.g., file
transfer, as appropriate to the network environment. In support of
this requirement, each CA must supply its current CRL to its TLCA in
a timely fashion, consistent with CRL issuance rules imposed by the
TLCA. CAs may transfer CRLs to subordinate UAs using the CRL
processing type available in PEM messages (see RFC [1113D]). CAs
also may provide access to CRLs via the database mechanism described
in RFC [FORMS-A] and alluded to immediately above.
3.4.3.5.4 UA Responsibilities for CRL Management
The X.509 recommendation calls for each CRL to contain the serial
numbers of certificates which have been revoked by the CA
administering that list, i.e., the CA that is identified as the
issuer for the corresponding revoked certificates. Mechanisms for
managing a certificate cache are, in typical standards parlance, a
local matter. However the following discussion provides a paradigm,
the functional equivalent of which must be embodied in any PEM
implementation compliant with this RFC.
As noted above, 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 could retrieve CRLs from
Kent (BBN) [Page 23]
Internet Draft Certificate-Based Key Management June 28, 1991
directories as required. In the interim, and to support a "push"
(vs. "pull") model of CRL distribution, a PEM header format has been
defined specifically for CRL propagation (see RFC [1113D]). As noted
in RFC [1113D], every PEM UA must be capable of processing CRLs
distributed via such messages.
Upon receipt and validation of a CRL, (5) a PEM UA must compare the
CRL entries against any cached certificate information, and must mark
as revoked any cache entries which match CRL entries. (Recall that
the certificate serial numbers are unique only for each issuer, so
care must be exercised in effecting this cache search.) This
procedure applies to cache entries associated with CAs as well as
user entries. The UA also must retain the CRL to screen incoming
messages to detect use of revoked certificates carried in PEM message
headers. A UA must be capable of processing CRLs issued by various
CAs, i.e., any CA which issues certificates which the UA employs in
the submission or delivery of PEM messages. Thus a UA must, in
general, be capable of storing a number of CRLs from different CAs.
3.5 Certificate Validation
3.5.1 Validation Basics
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 TLCA sign certificates for all CAs within its domain,
even CAs which are certified by other, superior CAs in the
certification hierarchy. One additional validation step is required
for certificates issued by a TLCA other that the one which certified
the user's CA, as described in section 3.4.3.3.
_______________
(5) 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.5 for
additional details related to validation of certificates.
Kent (BBN) [Page 24]
Internet Draft Certificate-Based Key Management June 28, 1991
The public component needed to validate certificates signed by the
TLCA (in its role as a CA for subordinate CAs) 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 user certificate
in at most two or three steps. Consider the situation in which a
user receives a privacy enhanced message from an originator with whom
the recipient has never previously corresponded. Based on the
certification convention described above, the recipient can use his
TLCA's public component to validate the issuer's certificate
contained in the Issuer-Certificate field. (We recommend that,
initially, the originator include his organization's certificate in
this optional field so that the recipient need not access a server or
cache for this public component.) Using the issuer's public
component (extracted from this certificate), the recipient can
validate the originator's certificate contained in the Certificate
field of the header.
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, the recipient can immediately employ that public component
without the need for the certificate validation process described
here. Also note that the arithmetic required for certificate
validation is considerably faster than that involved in digitally
signing a certificate, so as to minimize the computational burden on
UAs.
3.5.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 not employ 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
Kent (BBN) [Page 25]
Internet Draft Certificate-Based Key Management June 28, 1991
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. However, 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 recipeint 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
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.5.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
Kent (BBN) [Page 26]
Internet Draft Certificate-Based Key Management June 28, 1991
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 user's (native) TLCA. 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, identifying the certificate in question.
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. The warning must
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
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 warning must
display the issuer and subject DNs from the revoked certificate and
the date of revocation. The user must provide a positive response to
the warning before the submission or delivery process may proceed.
In the case of message submission, it is recommended that the
identity of the recipient affected by this validation failure also be
displayed and that the user 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
Kent (BBN) [Page 27]
Internet Draft Certificate-Based Key Management June 28, 1991
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,
an additional set of checks must be performed. These checks ensure
that the certificates comply with the fundamental DN conventions
described throughout this RFC. UA software is not required to check
all of the DN conventions specified in Section 3.6, just those
specified here. Any certificate which does not comply with these
constraints is considered invalid and must not be employed in PEM
submission or delivery processing. The user must be notified of the
nature of this fatal error and encouraged to report it to his ON.
First, the subject DN of every certificate must be subordinate to the
certificate issuer DN, except when a TLCA is the issuer or in the
case of the NOTARY convention. Second, no issuer DN may terminate
with a commonName attribute. Third, no certificate may contain any
DN attribute other than those defined in Section 3.6 (or authorized
in a subsequent PEM RFC). Fourth, no more that one cross-certificate
may be employed in the process of validation. These stringent
requirements are levied upon all PEM implementations as part
maintaining the certification hierarchy constraints defined in this
RFC. By requiring checks for compliance with the certification
hierarchy by the users of the system as well as the issuers, the
potential for abuse through the use of non-compliant certificates is
minimized.
3.6 Distinguished Name Conventions
In the PEM environment, X.500 distinguished names (DNs) are employed
within certificates to uniquely identify issuers and subjects. The
issuers are always certifying authorities (organizations) while the
subjects are either certifying authorities, end users or distribution
(mailing) lists. Software used in the PEM environment must be able
to unambiguously display the attributes of any DN that might be
encountered in a certificate, not only in the course of constructing
and signing certificates (e.g., in conjunction with user and
certifying authority registration), but also during normal message
processing (e.g., in conjunction with submission and delivery of a
PEM-protected message). Thus PEM software must incorporate a
facility for mapping DN attribute identifiers to printable strings so
that these attributes can be meaningfully displayed for users.
Kent (BBN) [Page 28]
Internet Draft Certificate-Based Key Management June 28, 1991
The X.500 series of recommendations places no strict constraints on
the form DNs may take, i.e., neither the attributes which may be used
to form a DN nor the order in which they may appear in a DN are
specified. X.521 does specify a set of object classes for directory
entries and each of the attributes identified therein is also
specified individually with regard to data type and maximum size.
However, the recommendation specifically accommodates the creation of
new object classes and most of the existing object class definitions
are not proscriptive with regard to attributes which might be
included in an entry, perhaps as DN components.
Although Annex B to X.521 includes a "recommended" structure for the
directory and from this one could infer a set of constraints on the
composition of DNs, this Annex is explicitly NOT part of the standard
and thus is not binding on implementors. The December 1990 version
of the OIW Stable Implementor Agreements imposes few constraints on
naming schema beyond X.521. There is work underway now to
standardize the top level structure of DNs of the directory for the
U.S., but this work is not yet complete and does not address complete
DN structure.
Thus, in support of the requirement cited earlier for PEM
implementations, i.e., the need to be able to unambiguously identify
and display for a human user all of the attributes of any DN
encountered in a certificate, this RFC identifies the set of
attributes which constitute the universe from which DN components may
be selected for PEM environments. The definition of such attributes
in this RFC is viewed as an interim measure until such time as
suitable profiles are established by directory standards groups. At
that time the requirements will be changed to cite such standards.
For now, each PEM implementation is required to incorporate a
database which maps DN attribute identifiers to attribute names. The
contents of the database are specified in this section. Over time,
additional attributes may be added to the database via standards
processes and thus it is important that this database be easily
modifiable in support of these changes. However it also is important
that this database grow only as a result of changes promulgated
through standards processes, since local or bilateral changes would
tend to introduce interoperability barriers within the PEM community.
The attributes defined for use in distinguished names in the PEM
environment (and corresponding abbreviations) are taken from X.520.
Only the attribute name and abbreviation are reproduced here. The
Kent (BBN) [Page 29]
Internet Draft Certificate-Based Key Management June 28, 1991
reader is referred to X.520 for a complete description of each
attribute, including upper bounds on size. The permitted attributes
and their abbreviations are: countryName (C), stateOrProvinceName
(S), localityName (L), organizationName (O), organizationalUnitName
(OU), commonName (CN), and streetAddress (SA).
This RFC also imposes some minimal constraints on the structure of
DNs consistent with the certification hierarchy constraints discussed
earlier. The resulting naming schema is consistent with X.521 Annex
B. These constraints are imposed to attach semantics to DNs in an
effort to avoid possible confusion for PEM users. For example, we
feel that it is important that a user be able to differentiate
between a certificate associated with a specific individual vs. a
mailing list. These constraints are embodied in the definition of
five types of DNs described below. All CAs are expected to issue
certificates in which the issuer and subject DNs comply with the
syntax and semantics described below.
These DN types are designed to accommodate a wide range of PEM users
as both subjects and issuers in certificates. For each DN type, a
set of (required) attributes is specified which must be present in
the name and a set of optional attributes are specified. The
attributes are drawn from the list above and, in most cases, the
object classes which "inspire" most of these DN types are defined in
X.521. Note that these DN types are not object classes per se; thus
these DN type constraints do not preclude the inclusion of additional
attributes in a directory entry which contains a certificate
specified by these rules. These constraints apply only to directory
entries in so far as DN attributes are concerned. A table at the end
of this sections provides a concise summary of these DN types.
1. Certifying Authority- All certificates must contain an issuer DN
of this type. A subject DN may be of this type only if the
subject is itself an issuer of certificates. There is no single
attribute required in a DN of this type. This is because both
countries and international organizations are legitimate CAs and
neither has a common attribute. Thus a DN of this type must
contain either countryName or organizationName at a minimum.
Optional attributes are: countryName, stateOrProvinceName,
localityName, streetAddress and organizationalUnitName. The
attribute commonName must not appear in the DN of this class as
individuals, mailing lists and organizational roles are not
permitted to be issuers in this certification hierarchy. If and
only if the issuer is a top level certifying authority, the
Kent (BBN) [Page 30]
Internet Draft Certificate-Based Key Management June 28, 1991
terminal component of the DN must be an organizationalUnitName
with the value "TLCA". If the issuer is acting in the NOTARY
capacity as defined in Section 3.4.3.1 of this RFC, the terminal
component of the DN must consist solely of an
organizationalUnitName with the value "NOTARY".
2. Residential Person- A certificate containing this type of subject
DN is issued to an individual who does not wish to claim
affiliation with any organization via this certificate. The
required attributes are: countryName, stateOrProvinceName,
localityName, streetAddress, and commonName. The terminal
component of this DN must be a commonName. The are no optional
attributes. The attributes organizationName, and
organizationalUnitName must not appear in a DN of this type.
Initially, certificates of this type are expected to be available
only via NOTARY issuers.
3. Organizational Person- A certificate with a subject DN of this
type is issued to an individual to express some form of
affiliation between the individual and the named organization.
The required attributes are: organizationName and commonName.
CommonName must be the terminal component of the DN. Optional
attributes are: countryName, stateOrProvinceName, localityName,
streetAddress, and organizationalUnitName. GUEST and PERSONA
certificates fall into this category, and imply progerssively
less affiliation with the issuer.
4. Organizational Role- A certificate with a subject DN of this type
is issued to represent a position within an organization which
may be occupied by different individuals, e.g., serially over
time. The required attributes are: organizationName and
commonName. The commonName must be the terminal component and
must specify the name of the role represented by this DN (see
X.521, 6.9). The optional attributes are: countryName,
stateOrProvinceName, localityName, streetAddress, and
organizationalUnitName.
5. Distribution List- A certificate issued with a subject of this
type is intended to represent a collection of users (a mailing
list or distribution list) to which messages may be directed via
this DN. It is anticipated that a server process will be used to
accept mail directed at this DN using PEM and will forward
messages to the group members. The process by which PEM can be
utilized with a mail list exploder is described in RFC [1113D].
Kent (BBN) [Page 31]
Internet Draft Certificate-Based Key Management June 28, 1991
The commonName attribute is required and since this subject DN
must be subordinate to an issuer DN, either countryName or
organizationName must also appear in this DN. The DN must not be
structured so as to be confused with any of the human user DN
types noted above. We recommend that the string "Distribution
List" be incorporated in the DN as a second, terminal commonName
attribute to avoid any possible confusion. In any event, the
terminal component of a DN of this type must be a commonName.
The optional attributes are: countryName, organizationName,
organizationalUnitName, stateOrProvinceName, localityName and
streetAddress.
Distinguished Name Attribute Conventions
DISTINGUISHED NAME TYPE MANDATORY OPTIONAL PROHIBITED
Certification Authority C or O C,S,L,OU,SA,O CN
Residential Person C,S,L,SA,CN O,OU
Organizational Person O,CN C,S,L,SA,OU
Organizational Role O,CN C,S,L,OU,SA
Distribution List C or O, CN OU,S,L,SA
Kent (BBN) [Page 32]
Internet Draft Certificate-Based Key Management June 28, 1991
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 [1115B] provides references
for and the values of AlgortihmIdentifiers used by PEM in the
subjectPublicKeyInfo the signature data items. There is also some
ambiguity in X.509 with regard to the representation of a signed
value, e.g., a certificate signature. The interpretation selected in
PEM requires that the data to be signed is first ASN.1 encoded as an
OCTET STRING and the result is encrypted to form the signed quantity,
which is then ASN.1 encoded as an OCTET STRING. 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]
Internet Draft Certificate-Based Key Management June 28, 1991
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 Appendix B: RSA Data Security Inc. as a TLCA
THIS APPENDIX HAS NOT, IN ITS ENTIRETY, BEEN REVIEWED BY RASDSI AND
THUS SHOULD NOT BE CONSIDERED DEFINITIVE.
B.1 Overview
The RSA cryptographic algorithm, covered in the U.S. by patents
administered through RSA Data Security, Inc. (hereafter abbreviated
RSADSI) has been selected for use in this key management system.
This algorithm has been selected because it provides all the
necessary algorithmic facilities, is "time tested" and is relatively
efficient to implement in either software or hardware. It is also
the primary algorithm identified (at this time) for use in
international standards where an asymmetric encryption algorithm is
required. Protocol facilities (e.g., algorithm identifiers) exist to
permit use of other asymmetric algorithms if, in the future, it
becomes appropriate to employ a different algorithm for key
management. However, the infrastructure described herein is specific
to use of the RSA algorithm in many respects and thus might be
different if the underlying algorithm were to change.
Kent (BBN) [Page 34]
Internet Draft Certificate-Based Key Management June 28, 1991
Below we describe two scenarios under which the use of the RSA
algorithm to sign certificates will be administered by RSADSI. Both
support CAs which are represented by multiple ONs. Both also provide
a very high level of security for the certification procedure. Each
protects the private component of the CA, ensures unique certificate
serial numbering for the CA, enforces validity interval constraints,
and enforces the DN conventions specified in Section 3.6. Although
TLCAs other that RSADSI are not required to provide identical CA
support options, they should provide equivalently secure facilities
in order to warrant cross certification by RSADSI.
In the first scenario, an organization acquires a trusted Certificate
Signature Unit (CSU) which allows it to generate and retain its
private key, issue certificates to its users, and account for each
certificate it signs (to ensure serial number uniqueness). At least
one form of CSU will be made available and administered with the
cooperation of RSADSI as patent administrator for the public-key
technology. This method for issuing certificates will entail a fee
for the acquisition of a CSU as well as an incremental fee for each
certificate issued. RSADSI will make available functional and
security specifications for CSU vendors, but retains ultimate
authority for approval of CSUs for use with its certification
hierarchy.
The second scenario, better suited to subscriber organizations which
expect to be lower-volume issuers, calls for such organizations to
act in concert with a "Co-Issuer," a role which RSADSI will fill, at
least initially. In this context, the Co-Issuer essentially "time
shares" one or more CSUs among CAs to provide a certificate signing
service for CAs not wishing to purchase a CSU. This scenario also
involves a per-certificate fee to compensate the Co-Issuer not only
for the algorithm license but also to pay for the secure retention of
the organization's private component, accounting for certificates
issued, etc. The fees are for both the CSU and Co-Issuer cases will
be detailed in the legal agreement executed between RSADSI and an
organization wishing to act as a CA.
This certificate signing paradigm applies only in those circumstances
where the RSA patent applies. There are two broad environments where
the patent in not applicable. First, the RSA algorithm is patented
only within the U.S., thus CAs outside of the U.S. are not within the
certification domain of RSADSI. Second, the research that led to the
RSA algorithm was sponsored by the National Science Foundation.
Hence the U.S. government retains royalty-free license rights to the
Kent (BBN) [Page 35]
Internet Draft Certificate-Based Key Management June 28, 1991
algorithm and is expected to establish certificate generation
facilities for its affiliated users. Thus CAs (including TLCAs)
operating in these environments outside of the scope of the RSA
patent are not required to pay license fees.
In order to facilitate interoperability, RSADSI will cross certify
TLCAs outside its purview if these TLCAs (and their subordinate CAs)
conform to the CA requirements defined in this RFCand if they employ
security procedures and technology comparable to those employed by
RSADSI (as described below). This cross certification will be
performed on a non-discriminatory basis and will not entail onerous
fees.
B.2 The CSU Scenario
A CSU is a device approved by RSADSI for use in local generation of
an CA's component pair and the signing of certificates and CRLs on
behalf of the CA. It offers a CA greater autonomy and responsiveness
in the certification process by virtue of local control. A CA will
procure a CSU from an authorized vendor and install it in conjunction
with a workstation/PC used by one or more ONs. Before the CSU can be
used to generate certificates, the CA must be registered with RSADSI
and RDSDSI must provide the CA with a signed authorization message
which enables the CSU. Once this procedure has been effected,
certificates can be signed by the CSU on behalf of the CA in a
completely local procedure. RSADSI will provide additional
authorization messages to enable generation of certificates beyond an
initial authorized limit, or to add additional CAs to the CSU.
A CSU must embody a number of security and reliability features to
make local certificate and CRL signing as secure and relaible as the
functions offered by a Co-Issuer (see below). For example, the
generation of a CA's component pair is a critical operation which, if
performed without sufficient security, could undermine confidence in
the overall certification system.
To generate a CA component pair, a CSU should employ a hardware
random number generator to seed the generation of candidate primes
and employ high quality code to test for primality and other "good
RSA key" properties. Once generated, the private component of a CA
should be protected to very high standards, higher than those which
may be feasible to apply to individual user private components. This
Kent (BBN) [Page 36]
Internet Draft Certificate-Based Key Management June 28, 1991
motivates the use of physical tamper-protection measures and maybe
even means to protect against compromising electromagnetic radiation
by the CSU. (While TEMPEST certification may be overkill for CSUs in
most environments, existing and proposed standards for commercial
cryptographic modules (e.g., FIPS 140 and DRAFT FIPS 140-1) do
specify EMI/EMC requirements.) In part, the motivation here is that
compromise of a CA's private component would result in the revocation
of all subordinate certificates, significantly disrupting PEM usage
and calling into question the integrity of the certification system.
Not only must a CSU generate and keep CA private components secret,
it must provide mechanisms to assist in the procedural control of the
certification function. Thus the use of a crypto-ignition keys to
enable the CSU and provision for n-of-k user authorization facilities
are important features. A CSU should safeguard the CA's private
component in such a fashion so that no individual has knowledge of
this value, yet the CSU also must provide facilities to enable secure
recovery of the private component in the event that the CSU is stolen
or destroyed.
In allowing local issuance of certificates, RSADSI will require the
CSU to incorporate a facility to account for the number of
certificates issued, to ensure payment of certificate fees. There
also must be a provision for RSADSI to authorize the CSU to sign
messages for specified CAs. Authorization should encompass not only
the number of certificates that may be signed, but also specify if
the CA is allowed to generate NOTARY certificates or if it is a TLCA
and thus authorized to generate cross-certificates. These facilities
must be controllable via the use of signed "messages" to facillitate
remote administration of the CSU by RSADSI.
A CSU must check each certificate and CRL it signs against the
constraints imposed by this RFC, as would a Co-Issuer (see below).
Thus requirements for a subject DN to be subordinate to the issuer
DN, (except in the case of NOTARY certificates), use of authorized
attribute types, correct certificate and CRL syntax, etc. should be
checked by a CSU. These features must not be tamperable even by the
CA.
These requirements for CSU functionality and security motivate the
use of CSUs which are dedicated devices, realized in hardware, and
designed to meet high security, reliability and robustness standards.
The level 3 cryptographic module standards as specified in DRAFT FIPS
140-1 are suggestive of the security requirements. Detailed security
Kent (BBN) [Page 37]
Internet Draft Certificate-Based Key Management June 28, 1991
and functionality requirements, including support for good procedural
security and recovery procedures, will be specified by RSADSI in
separate documentation.
B.3 The Co-Issuer Scenario
When RSADSI (or an entity designated by RASDSI) acts as a Co-Issuer
of certificates on behalf of an organization which does not possess a
CSU, the Co-Issuer actually signs certificates for the organization
in a fashion which is "transparent" so that the organization appears
to be the issuer with regard to certificate formats and validation
procedures. This is effected by having the Co-Issuer use a CSU to
generate and hold the private component used to sign certificates on
behalf of the organization. The motivation for the Co-issuer's role
in certificate signing is twofold. First and foremost, it
contributes to the overall integrity of the system by establishing a
uniform, high level of protection for the private component used to
sign certificates. Second, it simplifies accounting controls in
support of licensing, ensuring that RSADSI is paid for each
certificate.
In the co-issuer case, after verifying the accuracy of the user's
credentials, the co-issuing ON will forward this information to the
Co-Issuer using privacy-enhanced mail to ensure the integrity and
authenticity of the information. The format for transmission of this
data is defined in RFC [FORMS-A]. The Co-Issuer will carry out the
actual certificate signing process on behalf of the organization
represented by the ON.
In order to carry out this procedure, the Co-Issuer will generate and
retain the private component associated with the public component in
the certificate which represents the organization, using a CSU
equivalent to that which could be purchased directly by a CA. In
effect the role of CA will be shared between the ONs for the
organization and the Co-Issuer. This shared role will not be visible
in the syntax of the certificates issued under this arrangement nor
is it apparent from the validation procedure one applies to these
certificates. In this sense, the role of the Co-Issuer as the actual
signer of certificates on behalf of organizations is transparent to
this aspect of system operation.
Kent (BBN) [Page 38]
Internet Draft Certificate-Based Key Management June 28, 1991
Note that the risks associated with disclosure of a CA's private
component are different from those associated with disclosure of a
user's private component. The former component is used only to sign
certificates, never to encrypt message traffic. Thus the exposure of
a CA's private component could result in the generation of forged
certificates for users affiliated with that organization, but it
would not affect privacy-enhanced messages which are protected using
legitimate certificates. Also note that any certificates generated
as a result of such a disclosure are readily traceable to the issuing
authority which holds this component, due to the non-repudiation
feature of the digital signature. Thus if the Co-Issuer were to
disclose the private component of an organization for which it acts
in this role, the mere existence of certificates signed with this
private component (and verifiable with the organization's public
component) would provide non-repudiable evidence of the compromise.
B.4 Organization Registration Procedures
Upon receipt of an Organizational Agreement together with a notarized
Organizational Notary information form, together with the appropriate
application fees, RSADSI will make such investigation of the
Organization as it deems necessary. Upon completion of such
investigation, RSADSI shall either: (i) issue to organization a
Certificate and grant Organization status as an Issuing Authority or
(ii) reject Organization's application from such a Certificate.
RSADSI shall approve or disapprove the Organization Agreement within
fifteen business days after its receipt by RSADSI. RSADSI shall have
final approval of the Organization Agreement, but shall not
unreasonably deny such approval. Failure to provide accurate and
complete information shall be grounds for RSADSI to deny or
subsequently rescind the Certificate. Should RSADSI disapprove the
Organization Agreement, RSADSI shall notify the Organization of the
reason(s) for such disapproval, and where appropriate, permit the
Organization to submit revised/accurate information
Upon receipt of the Organization's Certificate from RSADSI, the
Organization shall verify that the registration process has been
successfully completed. It is the Organiztion's responsibility to
verify the validity of the Certificate per this RFC. The
Organization shall promptly notify RSADSI if the Certificate does not
appear authentic. The Organization shall complete the validation
Kent (BBN) [Page 39]
Internet Draft Certificate-Based Key Management June 28, 1991
process before using PEM. The Organization shall not utilize an
expired, invalid or revoked Certificate.
The Organization shall promptly Notify RSADSI of any change in its
Issuing Authority's Distinguished Name or administrative information.
If the Distinguished name has changed, the Organization and its users
shall immediately cease originating PEM certified under the
Organization's Certificate. Before resuming use of PEM, the
Organization must submit a new Organization Agreement, including
payment of a new application fee, and RSADSI must duly accept such
new application. If only the administrative information has changed,
the Organization should notify RSADSI and the Organization may
continue communicating PEM.
B.5 Organizational Notary Requirements and Responsibilities
An Organizational Notary information form shall be filled out by
every ON and submitted to RSADSI. The Organizational Notary
information form shall list each Issuing Authority's distinguished
name that the ON is authorized to act on behalf of, the ON's
distinguished name, administrative information, a signature
authorizing the responsibilities of the ON and a notarized signature
attesting to the identity of the ON.
Each Certification Authority shall designate one or more
Organizational Notaries ("ONs") who, on behalf of the Organization,
shall provide ON services and shall verify User's identity and
Affiliation with the Organization. The Organizational Notary plays a
pivotal role in ensuring the day-to-day integrity of Certificate
Generation services, and is the primary "gate-keeper" and human
contact with its User Community. Consequently, ON requirements have
critical impact. This ON shall be registered with RSADSI as having
authorization to sign certificates for the Organization.
The Organization shall adopt reasonable procedures so that its ONs
accurately and properly perform all ON responsibilities. Each ON, at
a minimum: (i) is an employee (or general partner, proprietor, or
Organization official, if applicable) of the Organization; and (ii)
holds a position of trust in the Organization (such as a security
officer or a manager). The Organization may establish additional
criteria to further ensure the trustworthiness of ONs.
Kent (BBN) [Page 40]
Internet Draft Certificate-Based Key Management June 28, 1991
An Organization must report any ON changes or additions in writing to
RSADSI. All ONs should be registered with a notarized Organizational
Notary information form.
ONs shall verify and be responsible for User Certificate authenticity
and integrity. The ON shall also verify User Affiliation with the
Organization. ON responsibilities shall include:
i. verifying that all Certificate applicants submit a Certificate
application to the ON;
ii. taking reasonable steps to ensure the authenticity of
application information, e.g., by requiring the physical
presence of the applicant before the ON; or by the ON
initiating telephone contact with the applicant using a
telephone number listed in the application, after the ON
independently confirms the correspondence between the
applicant and the telephone number;
iii. maintaining a copy of all User Information submitted by each
applicant and a copy of each User Certificate issued by the
ON for at least three (3) years;
iv. acknowledging to the Organization that the ON has read and
understands the requirements and procedures referred to in
RFCs [1113-1115], [FORMS-A]; and
v. where the Organization does not undertake Certificate
Generation, submitting to the Co-Issuer a Certificate Request
as defined by RFC [FORMS-A].
Step ii is not applicable for PERSONA certificates and should be
interpreted appropriately for certificates issued to organizational
roles and for mailing lists. In the case of PERSONA certificates,
step iii need not imply retention of any information which directly
identifies a user, though provisions should be made to allow the
holder of a PERSONA certificate to unambiguously inform the ON of a
compromise of a private component.
No ON shall provide public key Certificate management services unless
its Organization holds a valid Organization License.
Kent (BBN) [Page 41]
Internet Draft Certificate-Based Key Management June 28, 1991
B.6 Certificate Revocation List Management
Certificate-based key distribution requires the use of Certificate
Revocation Lists ("CRLs") to provide timely information about, and to
ensure the integrity of, revoked Certificates due either to Private
Component compromise, or changes in User or Certification Authority
Identification Information.
The Organization shall verify CRL integrity, timeliness, and
reasonable security as follows:
B.6.1 Co-Issuer Scenario
a. Scheduled Prototype CRLs - The Organization shall Notify the Co-
Issuer Vendor of the serial numbers of User Certificates within its
User Community to be included in a new CRL one (1) business day prior
to the next regularly scheduled date for CRL issuance, even if there
are no changes in the CRL entries. The Prototype CRL must be
communicated to the Co-Issuer "one business day prior to the next
regularly scheduled date for CRL issuance" to provide the Co-Issuer
with adequate opportunity to process the serial numbers and include
them on a CRL issued by Co-Issuer (on behalf of the Organization). To
ensure that the Prototype CRL is as up-to-date as possible, the
Organization must not send the Prototype CRL to Co-Issuer more than
one business day prior to the next regularly scheduled date for CRL
issuance. The Organization shall issue a regularly scheduled
Prototype CRL no more frequently than weekly and no less frequently
than monthly.
b. Unscheduled Prototype CRLs - The Organization shall issue a
Prototype CRL more frequently, in case of an actual or perceived
security compromise, change(s) in User or Certification Authority
Distinguished Name, or upon discovering a material mistake in a
current CRL (collectively a "Change or Mistake"). However, the
Organization need not generally issue a Prototype CRL to initiate an
unscheduled CRL where the Organization learns of the Change or
Mistake within two (2) business days preceding the next regularly
scheduled CRL.
Kent (BBN) [Page 42]
Internet Draft Certificate-Based Key Management June 28, 1991
B.6.2 CSU Scenario
a. Scheduled CRLs - The Organization shall issue a new CRL one (1)
business day prior to the next regularly scheduled date for CRL
issuance, even if there are no changes in the CRL entries. The
Organization shall issue a regularly scheduled CRL no more frequently
than weekly and no less frequently than monthly.
b. Unscheduled CRLs - The Organization shall issue a CRL more
frequently, in case of an actual or perceived security compromise,
change(s) in User or Issuing Authority Distinguished Name, or upon
discovering a material mistake in a current CRL. However, the
Organization need not generally issue an unscheduled CRL where the
Organization learns of the Change or Mistake within two (2) business
days preceding the next regularly scheduled CRL.
If the Organization fails to issue a new CRL as required, then RSADSI
may thereafter issue a new CRL revoking the Organization's
Certificate (i) after Notice by RSADSI to the Organization
(communicating the Organization's failure to issue a timely CRL), and
(ii) where the Organization then fails to promptly issue the new CRL.
Where the Organization generates Certificates, it shall retain a copy
of all CRLs which it issues for at least three (3) years following
their issuance. Where the Organization does not generates
Certificates, it shall retain a copy of all Prototype CRLs which it
issues for at least three (3) years following their issuance. The
Co-Issuer vendor shall retain a copy of all CRLs which it issues, for
at least three (3) years following their issuance. CRLs may be
communicated and shared between the Co-Issuer vendor and any
Organization or User of PEM.
The requirement to maintain all Prototype CRLs and CRLs for a period
of at least three (3) years is intended to ensure available proof in
the event of a transactional dispute. The required information may be
maintained in paper or electronic form, or both. The default
retention period of "at least three (3) years" is consistent with
many government records retention requirements, and some commercial
practices. Notwithstanding, the actual retention period should
reflect the nature of the planned PEM transactions, available storage
media, storage costs, risk analysis, retention strategies and any
specific legal retention periods and statute of limitations for such
information.
Kent (BBN) [Page 43]
Internet Draft Certificate-Based Key Management June 28, 1991
B.7 Certificate Generation
B.7.1 CSU Scenario
The CSU vendor shall initialize the CSU prior to its installation in
the Organization. The Organization shall install and maintain the CSU
at a registered location listed with the CSU vendor, and in
accordance with CSU installation and operating instructions. The
Organization shall take reasonable efforts to ensure the security of
the CSU, and shall promptly notify the CSU vendor should the CSU
become misplaced, stolen, tampered with, damaged or destroyed. The
CSU vendor or RSADSI may inspect the CSU, upon giving reasonable
Notice to the Organization.
The CSU will generally be loaded with cryptosystem keys by the CSU
vendor prior to installation. The CSU vendor shall initialize the CSU
using the CSU Private Component, CSU Secret Key and RSADSI Public
Component. The CSU must be kept at the building and address listed
with the CSU vendor, but may be moved within such building without
notifying the vendor, except when the vendor or RSADSI notifies the
Organization of its intention to inspect the CSU. The CSU vendor's or
RSADSI's right to inspect the CSU is necessary to ensure the
integrity of the Certificate Generation process (confirmation of the
CSU's tamper resistance is undertaken by visual observation), to
periodically test or update its circuitry or software, and where the
CSU is leased, to verify compliance with the provisions of the
applicable lease.
Where multiple CSUs are used by the Organization, each CSU will be
uniquely identifiable by a device serial number. CSU installation and
operation are further specified in the CSU installation and operation
instructions, and should be thoroughly reviewed prior to commencing
operation.
B.7.2 Co-Issuer Scenario
Where the Organization does not undertake Certificate Generation, a
Co-Issuer vendor shall act as an agent on behalf of the Organization
so that the Organization substantially appears to be the issuer with
regard to Certificate formats and validation procedures. The
Organization shall not independently generate Certificates or CRLs.
The Co-Issuer vendor shall generate and retain exclusively the
Kent (BBN) [Page 44]
Internet Draft Certificate-Based Key Management June 28, 1991
Organization's Private Component to Sign Certificates on behalf of
the Organization.
A Co-Issuer vendor may generate a Certificate for a User where: Co-
Issuer vendor has received a PEM message from the Organization's ON
authorizing the issuance of a User Certificate. The Co-Issuer vendor
may rely exclusively upon the accuracy and propriety of the
Organization's PEM instructions to generate a User Certificate
without additional scrutiny.
This is the case where the Organization does not use a CSU. Instead,
the Organization submits authenticated Certificate authorizations on
behalf of its User Community to the Co-Issuer vendor. The Co-Issuer
vendor thereafter issues Certificates Signed by the Organization's
Private Key. The Organization should implement sufficient controls to
ensure that only intended Certificate authorizations are communicated
to the Co-Issuer vendor.
Additional issues may arise from the Co-Issuer vendor's retention of
the Organization's Private Component. The following section imposes
on the Co-Issuer vendor considerable obligations to Notify the
Organization in the unlikely event of a mistaken or wrongful
disclosure of such Private Component. These obligations are intended
to ensure (i) speedy, accurate and provable Notification to the
Organization of the disclosure, and (ii) facilitation of CRL issuance
to the Organization, and it's User Community.
The Co-Issuer vendor shall take reasonable efforts not to mistakenly
or wrongfully disclose the Organization's Private Component,
including to the Organization ("Compromise"). If the Private
Component of the Organization is Compromised by Co-Issuer vendor, or
if the Co-Issuer vendor has reason to believe that there may have
been a disclosure by the Co-Issuer vendor, the Co-Issuer vendor shall
use reasonable efforts to Notify promptly the Organization of the
relevant facts by:
a. sending PEM to the Organization;
b. telephoning at least one of its ONs;
c. sending the Organization via U.S.P.S. Certified Mail, return
receipt requested; and
d. distributing a corresponding CRL to the Organization, to its
Kent (BBN) [Page 45]
Internet Draft Certificate-Based Key Management June 28, 1991
User Community, and to a widely-accessible network information
center.
Upon the Organization's request following a Private Component Compromise
by the Co-Issuer vendor, the Co-Issuer vendor shall (i) within one (1)
business day, generate and communicate a new Certificate for the
Organization containing a new Public Component, (ii) promptly Sign and
reissue all current Certificates previously issued under the old
compromised Private Component, (iii) bear (with respect to the
Organization) all reasonable direct costs to reregister the User
Community with the Certification Authority, and (iv) Notify the
Organization of the cause of the Compromise, if known, and any remedial
actions intended to mitigate the possibility of a future Compromise,
provided such disclosure by the Co-Issuer vendor to the Organization
does not itself threaten or potentially threaten PEM security. The Co-
Issuer vendor shall not otherwise be liable for a Private Component
Compromise.
In the unlikely event that the Co-Issuer vendor mistakenly or wrongfully
discloses the Organization's Private Component, then upon request from
the Organization, the Co-Issuer vendor shall provide the Organization
with a new Organization Certificate, and/or reregister the
Organization's User Community without additional fee.
B.8 Security and Confidentiality
Security is an essential component of public key Certification
procedures. The Organization and vendors shall employ Reasonable
Security procedures to safeguard key generation, communication, and
storage. These procedures should include, at a minimum, safe storage of
the CSU when not in use and delegation of the cryptographic ignition
keys and fill device such that at least two individuals are needed to
issue certificates using an Organization's key. Additional procedures
could, for example, require the use of special access control devices,
supplemental hardware, additional use of codes or secrets, physical
procedures, and supplemental documentation.
All vendors and Organizations shall make reasonable efforts to ensure
the integrity and confidentiality of information it receives, holds or
transfers in conjunction with its responsibilities under this this RFC,
by means adequately reliable and secure in both its computing and
communications environments.
Kent (BBN) [Page 46]
Internet Draft Certificate-Based Key Management June 28, 1991
Information furnished by either party to the other to facilitate
performance that is labelled "COMPANY PRIVATE/CONFIDENTIAL" or other
agreed-upon indication of its confidential status, with the exception of
information previously disclosed to the public, shall be considered
confidential and shall neither be used for competitive purposes nor
disclosed to third parties by the recipient, except to the limited
extent that such information: (i) was in possession of or known to the
recipient prior to the disclosure thereof; (ii) is or becomes public
knowledge by means other than a breach of confidentiality by the
recipient; (iii) is thereafter received by the recipient from a third
party who did not require the recipient to keep it in confidence; (iv)
is developed by the recipient independently of any disclosure; (v) is
not identified as material considered "COMPANY PRIVATE/CONFIDENTIAL" at
the time it is provided; or (vi) is required by an appropriate
governmental, regulatory or judicial authority to be disclosed to such
authority. Such confidential information shall not be unnecessarily
communicated within the Organization's or vendor's respective
operations. Each party shall Notify each employee, agent or person to
whom any such disclosure is made in confidence, that such confidential
information shall be kept in confidence (by such employee, agent or
person).
B.9 Reporting Requirements
The Organization's responsibility to provide "bug" and flaw reports
("Reports") to vendors will help the vendors provide quality service and
information to the Organization and the Internet Community. Reports
generally will concern (i) the PEM and key management process; or (ii)
the CSU, where the Organization has purchased or leased a CSU. Reports
should generally include the following information:
a. Organization Name (Organization Submitting the Report);
b. Name, Street and Email Address, and Phone (of Person(s)
Submitting the Report);
c. Description of the Bug or Flaw; and
d. Other Information (Which the Organization Determines is Helpful
to Identify the Bug or Flaw, and its Resolution).
Kent (BBN) [Page 47]
Internet Draft Certificate-Based Key Management June 28, 1991
The Organization should encourage its staff to document PEM
certification problems and possible solutions, and to regularly
communicate them to the vendors. Reports can be communicated to the
vendors in any form in which Notice is permissible.
The vendors shall make reasonable efforts to communicate to the
Organization relevant and appropriate Report information received from
other organizations. However, the identity of an organization submitting
a Report will be kept confidential, whenever properly marked "COMPANY
PRIVATE/CONFIDENTIAL"
C References
CCITT Recommendation X.411 (1988), "Message Handling Systems: Message
Transfer System: Abstract Service Definition and Procedures".
[1] CCITT Recommendation X.509 (1988), "The Directory - Authentication
Framework".
[2] CCITT Recommendation X.520 (1988), "The Directory - Selected
Attribute Types". CCITT
[3] NIST Special Publication 500-183, "Stable Agreements for Open
Systems Interconnection Protocols," Version 4, Edition 1, December 1990.
Kent (BBN) [Page 48]