FWD: Announcing the release of RIPEM version 1.2.
consensus at netcom.com
Wed Mar 16 13:07:45 PST 1994
Announcing the release of RIPEM version 1.2.
RIPEM 1.2 contains extensive modifications by Jeff Thompson of RSA
Data Security to provide a measure of true Internet PEM interoperability,
and to implement a "direct-trust" model for public keys. This new
certificate-based trust model is more secure than RIPEM 1.1's but
less hierarchical than Internet PEM's.
RIPEM 1.2 can read all RIPEM 1.1-formatted messages, and can also
read genuine MIC-ONLY and MIC-CLEAR Internet PEM messages. RIPEM
1.2 cannot read or produce encrypted Internet PEM messages. RIPEM
1.2's outputed messages can be read by RIPEM 1.1.
Before using RIPEM 1.2 to produce messages, you must first generate
a "self-signed" certificate. This is done automatically during
key generation. For current RIPEM users, you can create a self-signed
certificate by simply invoking RIPEM in change-password mode:
ripem -c -S output-private-key-file -P output-public-key-file
The old field of Originator-Name is only supported for backward compatibility.
RIPEM 1.2 really uses the self-signed cert in the Originator-Certificate
field. When you receive a message from a sender for the first time,
RIPEM will tell you that you don't have a validated certificate for
the sender and will display the sender's self-signed certificate digest.
You can call the sender and verify that it's correct. Then, you
receive the message in -v validation mode which will create and store
a certificate from you to the sender. From now on, RIPEM uses it.
When you encrypt a message, the message includes something like
Recipient-Name: jefft at chirality.rsa.com
Recipient-Name is only included for backwards compatibility.
RIPEM 1.2 really uses Recipient-Key-Asymmetric, which is the DER
encoding of my public key. When jefft sees this while receiving the
message, he knows the associated Key-Info is for him. Using the public
key is nice because you don't have to know what your correspondant's
issuer and serial number are. It supports this direct trust model nicely.
RIPEM 1.2 uses a home directory which currently holds two files:
privkey and pubkeys. privkey is the same as the old RIPEM -s private
key file. The pubkeys file holds the user's self-signed certificate
and the direct-trust certificates they make for other users:
User: jefft at chirality.rsa.com
UserDistinguishedName: CN = jefft at chirality.rsa.com, OU = Persona
Certificate, O = RSA Data Security, Inc., C = US
Notice that there is no public key by itself, since it is now
validated inside the certificate. For RIPEM 1.2, a user's
distinguished name is formed with the old RIPEM username as the common
name in a Persona distinguished name.
Important: During ripem -e -m encrypted -u username, RIPEM looks up
the recipient's certificate by scanning pubkeys for a "User:" field as
specified by -u and uses the first one it finds. It is possible that
there are multiple users with the same common name, so RIPEM always
displays the full distinguished names of the recipients it finds when
encrypting. If one of these is the wrong DN, the user can abort
sending the message.
Notice that the Originator-Certificate field is a self-signed cert, a
RIPEM signed message conforms closely to RFC 1424. In fact, since the
names are already Persona names, you can send it to
persona-request at rsa.com and it will return a real Persona certificate.
(The RIPEM 1.2 documentation doesn't mention this because there's
really nothing a 1.2 user can do with a hierarchical cert right now,
but you can see what the future plans are.)
Lastly, RIPEM 1.2 doesn't make use of key servers except for backwards
compatibility. Quoting from the user manual:
Note: RIPEM 1.2 does not use key servers or finger to manage
certificates. RIPEM 1.2 only transmits a self-signed
certificate, and the only other certificates that are made are
direct peer-to-peer. As a RIPEM 1.2 user, you make a
certificate from yourself to, say, fred at snark.edu. No one other
than you and fred would be interested in this certificate.
Hence, RIPEM 1.2 makes no provision for these certificates to be
on key servers. A future version of RIPEM is planned which will
allow certificate chaining. This will allow you to indirectly
trust users directly certified by users of your choice. You
will be able to say "I trust all users certified by fred". When
this future version of RIPEM is available, it will become
meaningful to place certificates on key servers.
RIPEM 2.0, with certificate chaining ("web-of-trust") and full Internet
PEM interoperability, is expected to be available within a few
As usual, this distribution can be found on ripem.msu.edu.
Only US and Canadian citizens/permanent residents are allowed
access; see ripem.msu.edu:/pub/crypt/GETTING_ACCESS.
..Christopher Allen Consensus Development Corporation..
..<consensus at netcom.com> 4104-24th Street #419..
.. San Francisco, CA 94114-3615..
.. o415/647-6383 f415/647-6384..
..Mosaic/World-Wide-Web Front Door: ..
More information about the cypherpunks-legacy