this RFC:
1. Country Name (e.g., encoding for "US")
2. Organizational Name
The following attributes are optional in issuer Distinguished Names
for purposes of this RFC:
1. Organizational Unit Name(s). (A hierarchy of up to four
organizational unit names may be provided; the least significant
member of the hierarchy is represented first.) If the
issuer is vouching for the user identity in the Notary capacity
described above, then exactly one instance of this field
must be present and it must consist of the string "Notary".
As noted earlier, only organizations are allowed as issuers in the
proposed authentication hierarchy. Hence the Distinguished Name for
an issuer should always be that of an organization, not a user, and
thus no Personal Name field may be included in the Distinguished Name
of an issuer.
3.4.1.5 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. No message should ever be prepared for transmission with a
non-current certificate, but recipients should be prepared to receive
messages processed using recently-expired certificates. This fact
results from the unpredictable (and sometimes substantial)
transmission delay of the staged-delivery electronic mail
environment. The default and maximum validity period for
certificates issued in this system will be two years.
3.4.1.6 Subject Public Component
A certificate carries the public component of its associated entity,
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-1115. Note that in this context, a user's public component is
actually the modulus employed in RSA algorithm calculations. A
"universal" (public) exponent is employed in conjunction with the
modulus to complete the system. Two choices of exponents are
recommended for use in this context and are described in section
3.4.3. Modulus size will be permitted to vary between 320 and 632
bits.
3.4.1.7 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 user of a certificate, in order to determine that
the integrity of its contents have not been compromised subsequent to
generation by a CA. An encrypted, one-way hash will be employed as
the signature algorithm. Hash functions suitable for use in this
context are notoriously difficult to design and tend to be
computationally intensive. Initially we have adopted a hash function
developed by RSADSI and which exhibits performance roughly equivalent
to the DES (in software). This same function has been selected for
use in other contexts in this system where a hash function (message
hash algorithm) is required, e.g., MIC for multicast messages. In
the future we expect other one-way hash functions will be added to
the list of algorithms designated for this purpose.
3.4.2 Validation Conventions
Validating a certificate involves 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 the proposed architecture this recursive operation is terminated
quickly by adopting the convention that RSADSI will certify the
certificates of all organizations or organizational units which act
as issuers for end users. (Additional validation steps may be
required for certificates issued by other CAs as described in section
3.3.3.1.)
Certification means that RSADSI will sign certificates in which the
subject is the organization or organizational unit and for which
RSADSI is the issuer, thus implying that RSADSI vouches for the
credentials of the subject. This is an appropriate construct since
each ON representing an organization or organizational unit must have
registered with RSADSI via a procedure more rigorous than individual
user registration. This does not preclude an organizational unit
from also holding a certificate in which the "parent" organization
(or organizational unit) is the issuer. Both certificates are
appropriate and permitted in the X.509 framework. However, in order
to facilitate the validation process in an environment where user-
level directory services are generally not available, we will (at
this time) adopt this certification convention.
The public component needed to validate certificates signed by RSADSI
(in its role as a CA for issuers) is transmitted to each user as part
of the registration process (using electronic mail with independent,
postal confirmation via a message hash). Thus a user will be able to
validate any user certificate (from the RSADSI hierarchy) in at most
two 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 the RSADSI public component to
validate the issuer's certificate contained in the X-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 X-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 X-MIC-Info field and thus verify the data origin
authenticity and integrity of the message. Of course,
implementations of privacy enhanced mail should cache validated
public components (acquired from incoming mail or via the message
from a user registration process) 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 users.
A separate issue associated with validation of certificates is a
semantic one, i.e., is the entity identified in the issuer field
appropriate to vouch for the identifying information in the subject
field. This is a topic outside the scope of X.509, but one which
must be addressed in any viable system. The hierarchy proposed in
this RFCis designed to address this issue. In most cases a user
will claim, as part of his identifying information, affiliation with
some organization and that organization will have the means and
responsibility for verifying this identifying information. In such
circumstances one should expect an obvious relationship between the
Distinguished Name components in the issuer and subject fields.
For example, if the subject field of a certificate identified an
individual as affiliated with the "Widget Systems Division"
(Organizational Unit Name) of "Compudigicorp" (Organizational Name),
one would expect the issuer field to specify "Compudigicorp" as the
Organizational Name and, if an Organizational Unit Name were present,
it should be "Widget Systems Division." If the issuer's certificate
indicated "Compudigicorp" as the subject (with no Organizational Unit
specified), then the issuer should be "RSADSI." If the issuer's
certificate indicated "Widget Systems Division" as Organizational
Unit and "Compudigicorp" as Organization in the subject field, then
the issuer could be either "RSADSI" (due to the direct certification
convention described earlier) or "Compudigicorp" (if the organization
elected to distribute this intermediate level certificate). In the
later case, the certificate path would involve an additional step
using the certificate in which "Compudigicorp" is the subject and
"RSADSI" is the issuer. One should be suspicious if the validation
path does not indicate a subset relationship for the subject and
issuer Distinguished Names in the certification path, expect where
cross-certification is employed to cross CA boundaries.
It is a local matter whether the message system presents a human user
with the certification path used to validate a certificate associated
with incoming, privacy-enhanced mail. We note that a visual display
of the Distinguished Names involved in that path is one means of
providing the user with the necessary information. We recommend,
however, that certificate validation software incorporate checks and
alert the user whenever the expected certification path relationships
are not present. The rationale here is that regular display of
certification path data will likely be ignored by users, whereas
automated checking with a warning provision is a more effective means
of alerting users to possible certification path anomalies. We urge
developers to provide facilities of this sort.
3.4.3 Relation with X.509 Certificate Specification
An X.509 certificate can be viewed as two components: contents and an
encrypted hash. The encrypted hash is formed and processed as
follows:
1. X, the hash, is computed as a function of the certificate
contents
2. the hash is signed by raising X to the power e (modulo n)
3. the hash's signature is validated by raising the result of
step 2 to the power d (modulo n), yielding X, which is
compared with the result computed as a function of certificate
contents.
Annex C to X.509 suggests the use of Fermat number F4 (65537 decimal,
1 + 2 **16 ) as a fixed value for e which allows relatively efficient
authentication processing, i.e., at most seventeen (17)
multiplications are required to effect exponentiation). As an
alternative one can employ three (3) as the value for e, yielding
even faster exponentiation, but some precautions must be observed
(see RFC-1115). Users of the algorithm select values for d (a secret
quantity) and n (a non-secret quantity) given this fixed value for e.
As noted earlier, this RFCproposes that either three (3) or F4 be
employed as universal encryption exponents, with the choice specified
in the algorithm identifier. In particular, use of an exponent value
of three (3) for certificate validation is encouraged, to permit
rapid certificate validation. Given these conventions, a user's
public component, and thus the quantity represented in his
certificate, is actually the modulus (n) employed in this computation
(and in the computations used to protect the DEK and MSGHASH, as
described in RFC-1113). A user's private component is the exponent
(d) cited above.
The X.509 certificate format is defined (in X.509, Annex G) 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}
All components of this structure are well defined by ASN.1 syntax
defined in the 1988 X.400 and X.500 Series Recommendations, except
for the AlgorithmIdentifier. An algorithm identifier for RSA is
contained in Annex H of X.509 but is unofficial. RFC-1115 will
provide detailed syntax and values for this field.
NOTES:
[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".
Authors' Addresses
Steve Kent
BBN Communications
50 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3988
EMail: kent@BBN.COM
John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA 01719-1326
Phone: 508-264-5491
EMail: Linn@ultra.enet.dec.com