applies transitively to entities (users or subordinate CAs) certified
by these CAs. For example, a PCA must state what procedure is
employed to verify the claimed identity of a CA, and the CA's right
to use a DN. Similarly, if any requirements are imposed on CAs to
validate the identity of users, these requirements must be specified.
Since all PCAs are required to cooperate in the resolution of
potential DN conflicts, each PCA is required to specify the procedure
it will employ to resolve such conflicts. If the PCA imposes a
maximum validity interval for the CA certificates it issues, and/or
for user (or subordinate CA) certificates issued by the CAs it
certifies, then these restrictions must be specified.
5. CRL Management- Each PCA must specify the frequency with which it
will issue scheduled CRLs. It also must specify any constraints it
imposes on the frequency of scheduled issue of CRLs by the CAs it
certifies, and by subordinate CAs. Both maximum and minimum
constraints should be specified. Since the IPRA policy calls for
each CRL issued by a CA to be forwarded to the cognizant PCA, each
PCA must specify a mailbox address to which CRLs are to be
transmitted. The PCA also must specify a mailbox address for CRL
queries. If the PCA offers any additional CRL management services,
e.g., archiving of old CRLs, then procedures for invoking these
services must be specified. If the PCA requires CAs to provide any
additional CRL management services, such services must be specified
here.
6. Naming Conventions- If the PCA imposes any conventions on DNs used
by the CAs it certifies, or by entities certified by these CAs, these
conventions must be specified. If any semantics are associated with
such conventions, these semantics must be specified.
7. Business Issues- If a legal agreement must be executed between a
PCA and the CAs it certifies, reference to that agreement must be
noted, but the agreement itself ought not be a part of the policy
statement. Similarly, if any fees are charged by the PCA this should
be noted, but the fee structure per se ought not be part of this
policy statement.
8. Other- Any other topics the PCA deems relevant to a statement of
its policy can be included. However, the PCA should be aware that a
policy statement is considered to be an immutable, long lived
document and thus considerable care should be exercised in deciding
what material is to be included in the statement.
3.4.4 Certification Authorities
In X.509 the term "certification authority" is defined as "an
authority trusted by one or more users to create and assign
certificates". X.509 imposes few constraints on CAs, but practical
implementation of a worldwide certification system requires
establishment of technical and procedural conventions by which all
CAs are expected to abide. Such conventions are established
throughout this document. All CAs are required to maintain a
database of the DNs which they have certified and to take measures to
ensure that they do not certify duplicate DNs, either for users or
for subordinate CAs.
It is critical that the private component of a CA be afforded a high
level of security, otherwise the authenticity guarantee implied by
certificates signed by the CA is voided. Some PCAs may impose
stringent requirements on CAs within their purview to ensure that a
high level of security is afforded the certificate signing process,
but not all PCAs are expected to impose such constraints.
3.4.4.1 Organizational CAs
Many of the CAs certified by PCAs are expected to represent
organizations. A wide range of organizations are encompassed by this
model: commercial, governmental, educational, non-profit,
professional societies, etc. The common thread is that the entities
certified by these CAs have some form of affiliation with the
organization. The object classes for organizations, organizational
units, organizational persons, organizational roles, etc., as defined
in X.521, form the models for entities certified by such CAs. The
affiliation implied by organizational certification motivates the DN
subordination requirement cited in Section 3.4.2.4.
As an example, an organizational user certificate might contain a
subject DN of the form: C = "US" SP = "Massachusetts" L = "Cambridge"
O = "Bolt Beranek and Newman" OU = "Communications Division" CN =
"Steve Kent". The issuer of this certificate might have a DN of the
form: C = "US" SP = "Massachusetts" L = "Cambridge" O= "Bolt Beranek
and Newman". Note that the organizational unit attribute is omitted
from the issuer DN, implying that there is no CA dedicated to the
"Communications Division".
3.4.4.2 Residential CAs
Users may wish to obtain certificates which do not imply any
organizational affiliation but which do purport to accurately and
uniquely identify them. Such users can be registered as residential
persons and the DN of such a user should be consistent with the
attributes of the corresponding X.521 object class. Over time we
anticipate that such users will be accommodated by civil government
entities who will assume electronic certification responsibility at
geographically designated points in the naming hierarchy. Until
civil authorities are prepared to issue certificates of this form,
residential user CAs will accommodate such users.
Because residential CAs may be operated under the auspices of
multiple PCAs, there is a potential for the same residential CA DN to
be assumed by several distinct entities. This represents the one
exception to the rule articulated throughout this document that no
two entities may have the same DN. This conflict is tolerated so as
to allow residential CAs to be established offering different
policies. Two requirements are levied upon residential CAs as a
result: (1) residential CAs must employ the residential DN conflict
detection database maintained by the IPRA, and (2) residential CAs
must coordinate to ensure that they do not assign duplicate
certificate serial numbers.
As an example, a residential user certificate might include a subject
name of the form: C = "US" SP = "Massachusetts" L = "Boston" PA = "19
North Square" CN = "Paul Revere." The issuer of that certificate
might have a DN of the form: C = "US" SP = "Massachusetts" L =
"Boston". Note that the issuer DN is superior to the subject DN, as
required by the IPRA policy described earlier.
3.4.4.3 PERSONA CAs
One or more CAs will be established to accommodate users who wish to
conceal their identities while making use of PEM security features,
e.g., to preserve the anonymity offered by "arbitrary" mailbox names
in the current mail environment. In this case the certifying
authority is explicitly NOT vouching for the identity of the user.
All such certificates are issued under a PERSONA CA, subordinate to a
PCA with a PERSONA policy, to warn users explicitly that the subject
DN is NOT a validated user identity. To minimize the possibility of
syntactic confusion with certificates which do purport to specify an
authenticated user identity, a PERSONA certificate is issued as a
form of organizational user certificate, not a residential user
certificate. There are no explicit, reserved words used to identify
PERSONA user certificates.
A CA issuing PERSONA certificates must institute procedures to ensure
that it does not issue the same subject DN to multiple users (a
constraint required for all certificates of any type issued by any
CA). There are no requirements on an issuer of PERSONA certificates
to maintain any other records that might bind the true identity of
the subject to his certificate. However, a CA issuing such
certificates must establish procedures (not specified in this
document) in order to allow the holder of a PERSONA certificate to
request that his certificate be revoked (i.e., listed on a CRL).
As an example, a PERSONA user certificate might include a subject DN
of the form: C = "US" SP = "Massachusetts" L = "Boston" O =
"Pseudonyms R US" CN = "Paul Revere." The issuer of this certificate
might have a DN of the form: C = "US" SP = "Massachusetts" L =
"Boston" O = "Pseudonyms R US". Note the differences between this
PERSONA user certificate for "Paul Revere" and the corresponding
residential user certificate for the same common name.
3.4.4.4 CA Responsibilities for CRL Management
As X.500 directory servers become available, CRLs should be
maintained and accessed via these servers. However, prior to
widespread deployment of X.500 directories, this document adopts some
additional requirements for CRL management by CAs and PCAs. As per
X.509, each CA is required to maintain a CRL (in the format specified
by this document 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 PCA is required to maintain a CRL for revoked CA
certificates within its domain. The interval at which a CA issues a
CRL is not fixed by this document, but the PCAs may establish minimum
and maximum intervals for such issuance.
As noted earlier, each PCA will provide access to a database
containing CRLs issued by the IPRA, PCAs, and all CAs. In support of
this requirement, each CA must supply its current CRL to its PCA in a
fashion consistent with CRL issuance rules imposed by the PCA and
with the next scheduled issue date specified by the CA (see Section
3.5.1). CAs may distribute CRLs to subordinate UAs using the CRL
processing type available in PEM messages (see RFC1421). CAs also
may provide access to CRLs via the database mechanism described in
RFC1424 and alluded to immediately above.
3.5 Certificate Revocation
3.5.1 X.509 CRLs
X.509 states that it is a CA's responsibility to maintain: "a time-
stamped list of the certificates it issued which have been revoked."
There are two primary reasons for a CA to revoke a certificate, i.e.,
suspected compromise of a private component (invalidating the
corresponding public component) or change of user affiliation
(invalidating the DN). The use of Certificate Revocation Lists
(CRLs) as defined in X.509 is one means of propagating information
relative to certificate revocation, though it is not a perfect
mechanism. In particular, an X.509 CRL indicates only the age of the
information contained in it; it does not provide any basis for
determining if the list is the most current CRL available from a
given CA.
The proposed architecture establishes a format for a CRL in which not
only the date of issue, but also the next scheduled date of issue is
specified. Adopting this convention, when the next scheduled issue
date arrives a CA (Throughout this section, when the term "CA" is
employed, it should be interpreted broadly, to include the IPRA and
PCAs as well as organizational, residential, and PERSONA CAs.) 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 that CA. Note that this does
not preclude CRL issuance on a more frequent basis, e.g., in case of
some emergency, but no system-wide mechanisms are architected for
alerting users that such an unscheduled issuance has taken place.
This scheduled CRL issuance convention allows users (UAs) to
determine whether a given CRL is "out of date," a facility not
available from the (1988) X.509 CRL format.
The description of CRL management in the text and the format for CRLs
specified in X.509 (1988) are inconsistent. For example, the latter
associates an issuer distinguished name with each revoked certificate
even though the text states that a CRL contains entries for only a
single issuer (which is separately specified in the CRL format). The
CRL format adopted for PEM is a (simplified) format consistent with
the text of X.509, but not identical to the accompanying format. The
ASN.1 format for CRLs used with PEM is provided in Appendix A.
X.509 also defines a syntax for the "time-stamped list of revoked
certificates representing other CAs." This syntax, the
"AuthorityRevocationList" (ARL) allows the list to include references
to certificates issued by CAs other than the list maintainer. There
is no syntactic difference between these two lists except as they are
stored in directories. Since PEM is expected to be used prior to
widespread directory deployment, this distinction between ARLs and
CRLs is not syntactically significant. As a simplification, this
document specifies the use the CRL format defined below for
revocation both of user and of CA certificates.
3.5.2 PEM CRL Format
Appendix A contains the ASN.1 description of CRLs specified by this
document. This section provides an informal description of CRL
components analogous to that provided for certificates in Section
3.3.
1. signature (signature algorithm ID and parameters)
2. issuer
3. last update
4. next update
5. revoked certificates
The "signature" is a data item completely analogous to the signature
data item in a certificate. Similarly, the "issuer" is the DN of the
CA which signed the CRL. The "last update" and "next update" fields
contain time and date values (UTCT format) which specify,
respectively, when this CRL was issued and when the next CRL is
scheduled to be issued. Finally, "revoked certificates" is a
sequence of ordered pairs, in which the first element is the serial
number of the revoked certificate and the second element is the time
and date of the revocation for that certificate.
The semantics for this second element are not made clear in X.509.
For example, the time and date specified might indicate when a
private component was thought to have been compromised or it may
reflect when the report of such compromise was reported to the CA.
For uniformity, this document adopts the latter convention, i.e., the
revocation date specifies the time and date at which a CA formally
acknowledges a report of a compromise or a change or DN attributes.
As with certificates, it is recommended that the UTCT values be of no
finer granularity than minutes and that all values be stated in terms
of Zulu.
3.6 Certificate Validation
3.6.1 Validation Basics
Every UA must contain the public component of the IPRA as the root
for its certificate validation database. Public components
associated with PCAs must be identified as such, so that the
certificate validation process described below can operate correctly.
Whenever a certificate for a PCA is entered into a UA cache, e.g., if
encountered in a PEM message encapsulated header, the certificate
must NOT be entered into the cache automatically. Rather, the user
must be notified and must explicitly direct the UA to enter any PCA
certificate data into the cache. This precaution is essential
because introduction of a PCA certificate into the cache implies user
recognition of the policy associated with the PCA.
Validating a certificate begins with verifying that the signature
affixed to the certificate is valid, i.e., that the hash value
computed on the certificate contents matches the value that results
from decrypting the signature field using the public component of the
issuer. In order to perform this operation the user must possess the
public component of the issuer, either via some integrity-assured
channel, or by extracting it from another (validated) certificate.
In order to rapidly terminate this recursive validation process, we
recommend each PCA sign certificates for all CAs within its domain,
even CAs which are certified by other, superior CAs in the
certification hierarchy.
The public component needed to validate certificates signed by the
IPRA is made available to each user as part of the registration or
via the PEM installation process. Thus a user will be able to
validate any PCA certificate immediately. CAs are certified by PCAs,
so validation of a CA certificate requires processing a validation
path of length two. User certificates are issued by CAs (either
immediately subordinate to PCAs or subordinate to other CAs), thus
validation of a user certificate may require three or more steps.
Local caching of validated certificates by a UA can be used to speed
up this process significantly.
Consider the situation in which a user receives a privacy enhanced
message from an originator with whom the recipient has never
previously corresponded, and assume that the message originator
includes a full certification path in the PEM message header. First
the recipient can use the IPRA's public component to validate a PCA
certificate contained in an Issuer-Certificate field. Using the
PCA's public component extracted from this certificate, the CA
certificate in an Issuer-Certificate field also can be validated.
This process cam be repeated until the certificate for the
originator, from the Originator-Certificate field, is validated.
Having performed this certificate validation process, the recipient
can extract the originator's public component and use it to decrypt
the content of the MIC-Info field. By comparing the decrypted
contents of this field against the MIC computed locally on the
message the user verifies the data origin authenticity and integrity
of the message. It is recommended that implementations of privacy
enhanced mail cache validated public components (acquired from
incoming mail) to speed up this process. If a message arrives from
an originator whose public component is held in the recipient's cache
(and if the cache is maintained in a fashion that ensures timely
incorporation of received CRLs), the recipient can immediately employ
that public component without the need for the certificate validation
process described here. (For some digital signature algorithms, the
processing required for certificate validation is considerably faster
than that involved in signing a certificate. Use of such algorithms
serves to minimize the computational burden on UAs.)
3.6.2 Display of Certificate Validation Data
PEM provides authenticated identities for message recipients and
originators expressed in the form of distinguished names. Mail
systems in which PEM is employed may employ identifiers other than
DNs as the primary means of identifying recipients or originators.
Thus, in order to benefit from these authentication facilities, each
PEM implementation must employ some means of binding native mail
system identifiers to distinguished names in a fashion which does not
undermine this basic PEM functionality.
For example, if a human user interacts directly with PEM, then the
full DN of the originator of any message received using PEM should be
displayed for the user. Merely displaying the PEM-protected message
content, containing an originator name from the native mail system,
does not provide equivalent security functionality and could allow
spoofing. If the recipient of a message is a forwarding agent such
as a list exploder or mail relay, display of the originator's DN is
not a relevant requirement. In all cases the essential requirement
is that the ultimate recipient of a PEM message be able to ascertain
the identity of the originator based on the PEM certification system,
not on unauthenticated identification information, e.g., extracted
from the native message system.
Conversely, for the originator of an ENCRYPTED message, it is
important that recipient identities be linked to the DNs as expressed
in PEM certificates. This can be effected in a variety of ways by
the PEM implementation, e.g., by display of recipient DNs upon
message submission or by a tightly controlled binding between local
aliases and the DNs. Here too, if the originator is a forwarding
process this linkage might be effected via various mechanisms not
applicable to direct human interaction. Again, the essential
requirement is to avoid procedures which might undermine the
authentication services provided by PEM.
As described above, it is a local matter how and what certification
information is displayed for a human user in the course of submission
or delivery of a PEM message. Nonetheless all PEM implementations
must provide a user with the ability to display a full certification
path for any certificate employed in PEM upon demand. Implementors
are urged to not overwhelm the user with certification path
information which might confuse him or distract him from the critical
information cited above.
3.6.3 Validation Procedure Details
Every PEM implementation is required to perform the following
validation steps for every public component employed in the
submission of an ENCRYPTED PEM message or the delivery of an
ENCRYPTED, MIC-ONLY, or MIC-CLEAR PEM message. Each public component
may be acquired from an internal source, e.g., from a (secure) cache
at the originator/recipient or it may be obtained from an external
source, e.g., the PEM header of an incoming message or a directory.
The following procedures applies to the validation of certificates
from either type of source.
Validation of a public component involves constructing a
certification path between the component and the public component of
the IPRA. The validity interval for every certificate in this path
must be checked. PEM software must, at a minimum, warn the user if
any certificate in the path fails the validity interval check, though
the form of this warning is a local matter. For example, the warning
might indicate which certificate in the path had expired. Local
security policy may prohibit use of expired certificates.
Each certificate also must be checked against the current CRL from
the certificate's issuer to ensure that revoked certificates are not
employed. If the UA does not have access to the current CRL for any
certificate in the path, the user must be warned. Again, the form of
the warning is a local matter. For example, the warning might
indicate whether the CRL is unavailable or, if available but not
current, the CRL issue date should be displayed. Local policy may
prohibit use of a public component which cannot be checked against a
current CRL, and in such cases the user should receive the same
information provided by the warning indications described above.
If any revoked certificates are encountered in the construction of a
certification path, the user must be warned. The form of the warning
is a local matter, but it is recommended that this warning be more
stringent than those previously alluded to above. For example, this
warning might display the issuer and subject DNs from the revoked
certificate and the date of revocation, and then require the user to
provide a positive response before the submission or delivery process
may proceed. In the case of message submission, the warning might
display the identity of the recipient affected by this validation
failure and the user might be provided with the option to specify
that this recipient be dropped from recipient list processing without
affecting PEM processing for the remaining recipients. Local policy
may prohibit PEM processing if a revoked certificate is encountered
in the course of constructing a certification path.
Note that in order to comply with these validation procedures, a
certificate cache must maintain all of the information contained in a
certificate, not just the DNs and the public component. For example
the serial number and validity interval must be associated with the
cache entry to comply with the checks described above. Also note
that these procedures apply to human interaction in message
submission and delivery and are not directly applicable to forwarding
processes. When non human interaction is involved, a compliant PEM
implementation must provide parameters to enable a process to specify
whether certificate validation will succeed or fail if any of the
conditions arise which would result in warnings to a human user.
Finally, in the course of validating certificates as described above,
one additional check must be performed: the subject DN of every
certificate must be subordinate to the certificate issuer DN, except
if the issuer is the IPRA or a PCA (hence another reason to
distinguish the IPRA and PCA entries in a certificate cache). This
requirement is levied upon all PEM implementations as part of
maintaining the certification hierarchy constraints defined in this
document. Any certificate which does not comply with these
requirements is considered invalid and must be rejected in PEM
submission or delivery processing. The user must be notified of the
nature of this fatal error.
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. RFC1423 provides references
for and the values of AlgorithmIdentifiers used by PEM in the
subjectPublicKeyInfo and the signature data items. It also describes
how a signature is generated and the results represented. Because
the certificate is a signed data object, the distinguished encoding
rules (see X.509, section 8.7) must be applied prior to signing.
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}
References
[1] CCITT Recommendation X.411 (1988), "Message Handling Systems:
Message Transfer System: Abstract Service Definition and
Procedures".
[2] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[3] CCITT Recommendation X.520 (1988), "The Directory - Selected
Attribute Types".
[4] NIST Special Publication 500-183, "Stable Agreements for Open
Systems Interconnection Protocols," Version 4, Edition 1,
December 1990.
[5] North American Directory Forum, "A Naming Scheme for c=US", RFC
1255, NADF, September 1991.
[6] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures", RFC1421,
DEC, February 1993.
[7] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC1423, TIS,
February 1993.
[8] Balaski, B., "Privacy Enhancement for Internet Electronic Mail:
Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving
Services", RFC1424, RSA Laboratories, February 1993.
[9] North American Directory Forum, "NADF Standing Documents: A Brief
Overview", RFC1417, NADF, February 1993.
Patent Statement
This version of Privacy Enhanced Mail (PEM) relies on the use of
patented public key encryption technology for authentication and
encryption. The Internet Standards Process as defined in RFC1310
requires a written statement from the Patent holder that a license
will be made available to applicants under reasonable terms and
conditions prior to approving a specification as a Proposed, Draft or
Internet Standard.
The Massachusetts Institute of Technology and the Board of Trustees
of the Leland Stanford Junior University have granted Public Key
Partners (PKP) exclusive sub-licensing rights to the following
patents issued in the United States, and all of their corresponding
foreign patents:
Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770
Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582
Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829
Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414
These patents are stated by PKP to cover all known methods of
practicing the art of Public Key encryption, including the variations
collectively known as El Gamal.
Public Key Partners has provided written assurance to the Internet
Society that parties will be able to obtain, under reasonable,
nondiscriminatory terms, the right to use the technology covered by
these patents. This assurance is documented in RFC1170 titled
"Public Key Standards and Licenses". A copy of the written assurance
dated April 20, 1990, may be obtained from the Internet Assigned
Number Authority (IANA).
The Internet Society, Internet Architecture Board, Internet
Engineering Steering Group and the Corporation for National Research
Initiatives take no position on the validity or scope of the patents
and patent applications, nor on the appropriateness of the terms of
the assurance. The Internet Society and other groups mentioned above
have not made any determination as to any other intellectual property
rights which may apply to the practice of this standard. Any further
consideration of these matters is the user's own responsibility.
Security Considerations
This entire document is about security.
Author's Address
Steve Kent
BBN Communications
50 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3988
EMail: kent@BBN.COM