Paul_Lambert-P15452(_at_)email(_dot_)mot(_dot_)com writes:
Suggestions:
- Reduce the number of MIME-PEM options (remove most of the identifier forms)
I couldn't agree more. RIPEM already uses only the recipient's public
key to identify the recipient of an encrypted message. I don't think
RIPEM will add support for any other identifier forms.
When finding a certificate chain for the originator of a message,
RIPEM 2.0 uses the public key as a starting off point if it is
available in the Originator-Certificate field. When a certified key
is found and it verifies the message signature, the name that it is
bound to, as found by the chaining algorithm, is presented as the
*last* step.
If RIPEM gets any name information along with a public key in an
originator identifier, it ignores it. And I don't see why RIPEM
should output anything but the public key for the originator when it
composes a signed message.
- Document a suggested trust model (maybe several if necessary).
Perhaps the RIPEM trust model can be one such example. I have
included an extended excerpt from the RIPEM 2.0 user manual below.
- Jeff
Certificates
A potential problem with public key cryptography is this: If
you get a public key for some user, such as Alice, in order
to encrypt a message for her or to verify a signature from
her, how do you know that public key you have really belongs
to her? If someone else could substitute their own public
key, the message you encrypt could be read by them and they
could send signed messages to you, impersonating Alice. This
problem is solved by certificates.
A certificate itself is a short message containing, among
other things, the name and public key of a user (called the
subject) as well as the name of a user (called the issuer)
which is vouching that the subject really owns that public
key. The certificate itself is signed by the issuer using
their own private key. Note that if you have the public key
of the issuer, and you trust that one public key, then you
can use it to check the signature on any certificate that
the issuer creates for other users, giving you trustworthy
access to all those other public keys.
You can also make use of certificates which you yourself
issue for other users. When you develop trust in the public
key of another user, you can make a certificate with
yourself as the issuer and the other user as the subject.
When you place certificates like this in your public key
file, it is a safe way to store the public keys that you
trust. Since the certificates are signed, no one can alter
the public key or the name of the subject without breaking
the signature on the certificate. This is the method RIPEM
uses. It is called "direct trust" since you create
certificates directly for users which you trust, and is
discussed more in the next section. Certificate chains,
which allow you to use a certificate with someone besides
yourself as the issuer, are discussed later.
Besides a subject's name and public key and the issuer's
name, a certificate has a validity period which tells when
the issuer created the certificate and how long the issuer
believes the subject's public key can be trusted. Validity
periods are usually one or two years. A certificate also has
a serial number which the issuer generates when the
certificate is created. The combination of issuer name and
serial number always uniquely identifies any certificate.
(RIPEM actually uses the MD5 digest of the information in
the certificate as the serial number since this digest will
always be unique.)
CRLs
A certificate can be revoked by the issuer for various
reasons, such as if the subject's private key is
compromised. The issuer revokes the certificate by placing
RIPEM User's Guide Page 13
the certificate's serial number on a certificate revocation
list (CRL) which is signed document that the issuer
periodically publishes. This is similar to the "hot list"
that a credit card company distributes. To revoke a credit
card, the company does not recall the credit card. Rather it
places the number of the credit card on a hot list which any
merchant must check before trusting a credit card. A CRL,
like a certificate, is signed with the issuer's private key
and has a validity period. Usually, the validity period is
only a few months and the issuer publishes a fresh CRL near
the end of the period. Once a certificate is placed on a CRL
it is not removed until the certificate's validity period
expires.
Since you create certificates in the course of using RIPEM,
you maintain your own CRL. Before trusting a certificate you
have made for another user, RIPEM checks your CRL to see if
you have revoked that user.
Maintaining CRLs is easy using RCERTS. When the validity
period on the CRL issued by you expires, use N to renew it.
Any revocation entries in the CRL will be kept and you can
choose the duration of the validity period of the new CRL.
Also, if you don't have any CRLs, this will create a new
one. To revoke a user, use S to select the user and R to
revoke them. Remember, once a user's certificate is listed
in you CRL, you cannot remove it.
Certificate statuses
Given all these factors, the certificate status for a
certificate can be any of the following values. Note that if
the signature on the certificate is corrupt, or the public
key of the issuer cannot be found, the certificate is
discarded altogether and none of the following certificate
statuses apply.
. VALID: The certificate's validity period is current and a
current CRL from the issuer is found and the certificate
is not in the revocation list.
. REVOCATION UNKNOWN: The certificate's validity period is
current but a CRL from the issuer could not be found (or
the signature on the CRL is corrupt). You may want to
request a CRL from the issuer. (See Sending and Receiving
CRLs below.) Note that REVOCATION UNKNOWN is the normal
status from issuers which choose not to publish CRLs.
. PENDING: The certificate's validity period has not yet
started.
. EXPIRED: The certificate's validity period has passed. If
a CRL from the issuer can be found which was active when
the certificate expired, RIPEM checks the revocation
list. If it is in the list, then the REVOKED certificate
status overrides EXPIRED.
RIPEM User's Guide Page 14
. CRL EXPIRED: The certificate's validity period is current
and the certificate is not in the revocation list of the
most recent CRL which could be found. However, this CRL's
validity period has passed. You should get a current CRL
from the issuer and check the certificate status again
because the certificate may have been revoked in the mean
time. (See Sending and Receiving CRLs below.)
. CRL OUT OF SEQUENCE: The certificate's validity period is
current and the certificate is not in the revocation list
of the most recent CRL which could be found. However, the
issue date of the CRL does not match the expected value.
An important recent CRL may be missing. See explanation
below.
. REVOKED: The certificate is listed in the CRL from the
issuer. The CRL may be expired, or may be a CRL from the
time at which the certificate expired (see EXPIRED
above). This means the public key in the certificate
should not be trusted.
You may also get a status of UNVALIDATED when you encipher
or decipher a message. This means no certificate could be
found, but an old-style RIPEM 1.1 public key was found. This
public key is "stand alone" and not protected by a signature
as public keys in certificates are. If you get this status,
you should use caution in trusting it and ask the owner of
the key to upgrade to using certificates.
CRL OUT OF SEQUENCE status
The CRL OUT OF SEQUENCE status requires extra explanation.
Suppose you revoke Alice by listing her certificate in the
next CRL that you issue. If Alice somehow has delete access
to your CRL database, she might delete that CRL, effectively
unrevoking herself. When you check the status on the
certificate you made for her, you will find only the
previous CRL. The certificate status will be CRL EXPIRED, or
if the two CRL validity periods overlap, you might even get
a VALID status!
RIPEM solves this by keeping track of the date of the most
recent CRL you issue. When RIPEM selects your current CRL
from the database, it checks this date, and if it doesn't
match, the certificate status is CRL OUT OF SEQUENCE. In the
future, the standards for CRLs in general may be improved so
that every CRL will include a sequence number. This would
allow you to make sure there are no gaps in the sequence of
other issuer's CRLs as well as your own.
Note that the CRL last issue date is kept in the RIPEM
preferences and is protected in the same manner as the other
preferences. See RIPEM Preferences below for more details.
Self-Signed Certificates
RIPEM User's Guide Page 15
A self-signed certificate is like a normal certificate,
except that it is issued by you for your own public key and
name and signed with your own private key. This has two
purposes: first, it is a convenient format for transmitting
your name and public key; and second, when someone uses the
public key in the certificate to verify the certificate's
signature, it proves that you actually had possession of
your private key when you made the signature. This prevents
some crypto attacks. A self-signed certificate is included
in every RIPEM message so that the recipient has the name
and public key of the sender. (For the PEM message format, a
self-signed certificate is not included if the sender is
certified under exactly one certificate chain. See
Specifying Message Format under Advanced Usage for more
details.)
Self-signed certificates are used to establish "direct
trust" with another user. (The difference between direct and
extended trust is explained in the next section.) To
establish direct trust for another user, you need a signed
RIPEM message from that user. The first time you try to
receive their message, RIPEM will tell you that you have not
yet validated that user, and RIPEM will show you the digest
on the sender's self-signed certificate. You may now call
the sender on the phone and ask them to read the digest of
their self-signed certificate. (Or you may get their digest
through some other trustworthy channel.) If the digests
match, then you have good reason to trust that the self-
signed certificate is actually theirs. Now you can receive
their signed message again in validation mode (see Receiving
in Validation Mode below). RIPEM creates a certificate
signed by you containing the other person's name and public
key and adds it to pubkeys in your RIPEM home directory. Now
you are ready to send that user encrypted mail and to trust
further signed messages from them.
The reverse is also true: For another user to establish
direct trust in your public key, you can send them a signed
RIPEM message. Expect the other user to contact you and ask
you to state the digest of your self-signed certificate. (If
you forget your self-signed certificate digest, run RCERTS
and use V to view detail for the selected user (which is you
when RCERTS starts up). This will display your digest.) The
other user then receives your signed message in validation
mode, and now the two of you have a trusted channel.
Certificate Chains
The previous section described direct trust, where you only
trust a user if there is a certificate for that user issued
directly by you. In this model, you must issue a certificate
for every one of your correspondents. But suppose another
user, Bob, has already issued certificates for some users
such as Alice and Carlos. If you trust Bob's certification
RIPEM User's Guide Page 16
procedures, then you can issue just one certificate for Bob
and tell RIPEM that you allow certificates issued directly
by Bob. In the terminology used here, you set "chain length
allowed" for Bob to one. In other words, you trust Bob as a
certification authority. Now you can trust Alice, Carlos,
and any other users Bob certifies. This is called a
certificate chain because there is a chain of trust from you
to Bob to the users Bob certifies. This is also sometimes
called "extended trust" in contrast to "direct trust."
Furthermore, if you trust that Bob only certifies users
which themselves can be trusted as certification
authorities, then you might set the chain length allowed for
Bob to two. In this case, you would trust a user who has a
certificate from Alice, who in turn has a certificate from
Bob. This is how a typical certificate hierarchy works on
the Internet.
To "hook into" the Low Assurance Certification Authority's
hierarchy, you make a certificate for that certification
authority and set the chain length allowed to two. (This is
done automatically in RCERTS when you use E to enable
standard issuers and select L for Low Assurance.) Doing this
means you allow the Low Assurance Certification Authority to
certify other certification authorities like the Persona
certification authority, which can in turn certify ordinary
users. Now for example, if a user posts a message to a
newsgroup and includes a certificate issued for them by the
Persona certification authority, and also a certificate for
Persona from the Low Assurance Certification Authority, then
you will be able to trust their public key and check the
signature on their message. You never even had to interact
with that user!
Finding the "best" chain
Note that if you trust multiple certification authorities,
then it is possible that a single user could have more than
one chain which you might trust. As well as these extended
certificate chains, you may also have made a direct
certificate for this user. Which one should you use? RIPEM
solves this by looking at the chain status for each of the
possible chains.
The chain status is computed by looking at the certificate
status of each of the certificates in the chain. The status
of an entire chain is the worst of all the individual
certificate statuses. Therefor, if all the certificates in
the chain are VALID, except one which is EXPIRED, the chain
status is EXPIRED. (Certificate statuses were explained
above in the section on Certificates.) The "best to worse"
certificate statuses go in the order listed above, starting
from VALID and ending with REVOKED.
RIPEM User's Guide Page 17
When choosing among many possible certificate chains, RIPEM
chooses the "best" one by comparing each chain status. (If
two chain statuses are the same, the shorter chain is
considered better.) In this way, RIPEM will find valid
certificates if possible and avoid expired certificates or
certificates from issuers which have not published a current
CRL.
Setting chain length allowed
RIPEM will allow you to set the chain length allowed for a
user as high as you want (up to the maximum chain length
that RIPEM can handle). Typically, though, you will set it
to one or two. Note that if you set chain length allowed to
zero, then you revert to direct trust for that user. You
still trust that user directly because you trust your own
certificate that you issue for them, but you don't trust
that user to certify others.
To set the chain length allowed for a user, run RCERTS and
use S to select that user as the current user. (This assumes
you have already validated that user as described in
Receiving in Validation Mode.) Then use M to modify the
chain length allowed. When you are selecting the user,
RCERTS asks if you want to allow any certificate chain for
the user or to select only a direct certificate. Enter D for
a direct certificate because you cannot set the chain length
allowed on a user which is certified by someone else. This
is necessary since RCERTS will select the "best" chain for a
user as described above. If you allow any certificate chain
and the certificate issued directly by you is expired, then
a longer chain may have a valid status and RCERTS will
select it instead, which is not what you want.
You can also use E to enable a standard issuer such as the
Low Assurance Certification Authority or the Commercial
Certification Authority. In this case, since RCERTS already
knows the name and public key, you do not need a self-signed
certificate from that user, nor to validate the user ahead
of time. You also do not need to use S to select them as the
current user. RCERTS will automatically create a certificate
issued by you and set the chain length allowed.
RIPEM Preferences
As discussed above, the RIPEM preferences store the chain
length allowed you set for users and the date of the most
recent CRL you issue. This information is kept in the file
preferen in the RIPEM home directory. (See the document
RIPEM Message and File Formats for details on the
preferences file format.)
RIPEM User's Guide Page 18
The RIPEM preferences are signed to make them tamperproof.
When RIPEM starts, if the preferences can't be found, or the
preferences are corrupt, RIPEM warns you, disregards the
preferences, and uses defaults. The defaults are that no
user has chain length allowed of one or more. This means you
do not trust any extended certificate chains. You must use
RCERTS to set the chain length allowed as you did the first
time for the users you trust as certification authorities.
The default is also that there is no date for the most
recent CRL. This means that RIPEM does not check for CRL OUT
OF SEQUENCE. This preference will be set again the next time
you issue a CRL in RCERTS by revoking a user or by using N
to renew the CRL issued by you.
The preferences signature method
The RIPEM preferences are not signed with your RSA private
key like other signed messages. Instead, the signature is
computed by digesting your password and appending this to
your preferences. Then all of this is digested and the
result is the signature. When the signature is checked by
computing the same digest, if the preferences are different,
or you don't supply the same password, then the signature
doesn't verify. Note that only a single user can create and
verify the signature, since the password is secret. This is
fine since you don't use someone else's preferences.
The RIPEM preferences is synchronized with your current
password. When you use the -c option to change your
password, RIPEM not only encrypts your private key under the
new password, but also recomputes the signature on your
preferences using the new password.
Preventing the replay attack
The technique of using the password to make the preferences
signature has the advantage that it makes the signature
time-dependent. You can use this advantage to prevent the
following security risk. Suppose you were trusting a user as
a certification authority by setting their chain length
allowed greater than one. If you no longer want to trust
them as a certification authority, you use RCERTS to set the
chain length allowed to zero, which creates new a
preferences file. Now suppose someone replaces the new
preferences file with the old one. If the signature were not
time-dependent you would have no way of noticing the swap
and you would suddenly be trusting the user as a
certification authority again! This is called the "replay
attack".
Now suppose that you set the chain length allowed as before,
but you also immediately change your password. If someone
replaces the new preferences file with the old one, the
signature will not verify since it is signed under a
RIPEM User's Guide Page 19
different password, and you will notice the swap instead of
trusting the old information. RIPEM will detect a corrupt
signature and reset the preferences to the defaults as
described above. Note that the same method of changing your
password can prevent replay attacks on other preferences
information like the date of your most recent CRL.
In summary, if you are concerned that someone can replace
your current preferences information with older, inaccurate
information, then every time you change your preferences,
also change your password. This includes every time you
modify the chain length allowed for a user and every time
you revoke a user (which modifies the date of the most
recent CRL you issue).