From jefft@RSA.COM Fri Feb  4 13:13:04 1994
Received: from RSA.COM by scss3.cl.msu.edu (4.1/4.7)  id AA03255; Fri, 4 Feb 94 13:13:02 EST
Received: by RSA.COM 
	id AA00462; Fri, 4 Feb 94 10:09:36 PST
Date: Fri, 4 Feb 94 10:09:36 PST
From: jefft@RSA.COM (Jeff Thompson)
Message-Id: <9402041809.AA00462@RSA.COM>
To: raylau@mit.edu
Cc: mrr@scss3.cl.msu.edu
Subject: RIPEM 1.2 changes
Status: ORS


-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 2001,MIC-CLEAR
Content-Domain: RFC822
Originator-Name: jefft@chirality.rsa.com
Originator-Certificate:
 MIIB0zCCAX0CEHvlDG8l4VHdqec4RvFBuGIwDQYJKoZIhvcNAQECBQAwbzELMAkG
 A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
 VQQLExNQZXJzb25hIENlcnRpZmljYXRlMSAwHgYDVQQDFBdqZWZmdEBjaGlyYWxp
 dHkucnNhLmNvbTAeFw05MzExMzAxOTE1NTFaFw05NTExMzAxOTE1NTFaMG8xCzAJ
 BgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoG
 A1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEgMB4GA1UEAxQXamVmZnRAY2hpcmFs
 aXR5LnJzYS5jb20wWDAKBgRVCAEBAgIB/gNKADBHAkAtAto1Bdion6FnjY2qkliO
 7n6RxmL68IJ8r5XMMPX5IERpo4pSEiE/Fbrw2jVlFUTbdQ36Y65tezhS1E4oNsUX
 AgMBAAEwDQYJKoZIhvcNAQECBQADQQAK/hg100zdjSCapJusmVSzwDaj6YKAa0p3
 GJBYYMMIMZbGlE2gx1bnMiI+twftqA2nRj7v7zlaWv3WiP+pihyx
MIC-Info: RSA-MD5,RSA,
 CT9gKhKXRWC6YviNQ5wEvitTiKpt9SWKHtTqS/hscHyMwNxOAEaU2EkqONHp15em
 cXowyetdnmJDW52rax9n3Q==

Ray,

Mark asked me to tell you about the new RIPEM 1.2 message format.

The use of the self-signed certificate and Recipient-Key-Asymmetric is
as we discussed it on certem.

As you can see in the header of this message, 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.  If you receive this message for the first time, RIPEM will
tell you that you don't have a validated cert for me and will display
my self-signed certificate digest.  You can call me 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 me.  From now
on, RIPEM uses it.

When you encrypt a message for me, the message includes something like

Recipient-Name: jefft@chirality.rsa.com
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 I see this while receiving the
message, I know the associated Key-Info is for me.  Using the public
key is nice because you don't have to know who I think my 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@chirality.rsa.com
UserDistinguishedName: CN = jefft@chirality.rsa.com, 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
persona-request@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 my plans are. ;-)  )

Lastly, RIPEM 1.2 doesn't make use of key servers except for backwards
compatibility.  Let me include a paragraph 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@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.

Let me know if you need more info.

- - Jeff
-----END PRIVACY-ENHANCED MESSAGE-----

