[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FWD: Announcing the release of RIPEM version 1.2.

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: [email protected]
Recipient-Key-Asymmetric:
 MFkwCgYEVQgBAQICAgUDSwAwSAJBFc8Mu+7j0iRqZ7eY39hyLUVSKPIRB+oVaGOJ
 9ttcJrBDPaucqCcp50leLhh48n9eUbvkQW9L7Yu8RiaLjeaNlU0CAwEAAQ==
Key-Info: RSA,
 Ep8yateOeP3bCBZzh4JYs9ZhlsZJ9B1WSM64nFnV2Y5gCExnKwIT/lhZssZTN0as
 V/i1ysZIp5QUPsRz/mlF0Ck=

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: [email protected]
UserDistinguishedName: CN = [email protected], OU = Persona
Certificate, O = RSA Data Security, Inc., C = US
CertificateInfo:
 MIIB0zCCAX0CEHvlDG8l4VHdqec4RvFBuGIwDQYJKoZIhvcNAQECBQAwbzELMAkG
 A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
 VQQLExNQZXJzb25hIENlcnRpZmljYXRlMSAwHgYDVQQDFBdqZWZmdEBjaGlyYWxp
 dHkucnNhLmNvbTAeFw05MzExMzAxOTE1NTFaFw05NTExMzAxOTE1NTFaMG8xCzAJ
 BgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoG
 A1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEgMB4GA1UEAxQXamVmZnRAY2hpcmFs
 aXR5LnJzYS5jb20wWDAKBgRVCAEBAgIB/gNKADBHAkAtAto1Bdion6FnjY2qkliO
 7n6RxmL68IJ8r5XMMPX5IERpo4pSEiE/Fbrw2jVlFUTbdQ36Y65tezhS1E4oNsUX
 AgMBAAEwDQYJKoZIhvcNAQECBQADQQAK/hg100zdjSCapJusmVSzwDaj6YKAa0p3
 GJBYYMMIMZbGlE2gx1bnMiI+twftqA2nRj7v7zlaWv3WiP+pihyx

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
[email protected] 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, [email protected].  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
months.

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..
..<[email protected]>                         4104-24th Street #419..
..                                        San Francisco, CA 94114-3615..
..                                        o415/647-6383  f415/647-6384..
..Mosaic/World-Wide-Web Front Door:                                   ..
..ftp://netcom7.netcom.com/pub/consensus/www/ConsensusFrontDoor.html  ..