





                      RIPEM Message and File Formats

                               Mark Riordan

                  modified by Jeff Thompson for RIPEM 2.0
                              September 1994

This document describes the  syntax of messages produced  by RIPEM, and  of
files maintained by RIPEM.

Format Standards Followed by RIPEM

RIPEM messages generally follow the format described in Internet RFC  1421.
(In non-PEM mode, -M ripem1, some of the fields are different, to allow for
non-hierarchical certification models.)   MIME extensions are described  in
the Internet Engineering Task  Force Draft entitled "MIME-PEM  Interaction"
(draft-ietf-pem-mime-02.txt).

Where applicable, RIPEM databases contain fields in formats conformant with
RSA Data Security's Public Key Cryptography  Standards.  See the  documents
in the pkcs directory on FTP site rsa.com.

Messages produced by RIPEM and files maintained by RIPEM are kept  entirely
in 7-bit ASCII format.  Information which is inherently non-ASCII ("binary"
data such as  the output from  DES encryption) is  encoded either in  ASCII
hexadecimal, or in a uuencode-like format called base-64 in which three 8-
bit bytes are represented with four ASCII characters.  (The details of this
encoding, which are not  identical to those of  the Unix uuencode program,
are described in  RFC 1421.)   Complex  structured information,  such as  a
public key (which contains both a  modulus and a public exponent) is  first
transformed into a portable binary format before being ASCII-encoded.   The
portable structured  format  is  called  DER  encoding  (for  Distinguished
Encoding Rules).  Descriptions  of DER encoding can  be found in  documents
written by Burt Kaliski and available from the FTP site rsa.com in the pkcs
directory.

Factors Affecting Message Formats

Each RIPEM-encrypted message consists of two  fundamental parts:  a set  of
"headers" containing bookkeeping information such as the sender's identity,
encryption modes used, etc; and a "body" containing the (usually) encrypted
message itself.  The precise format  of RIPEM message headers depends  upon
several factors:

. Whether the message is enciphered in "RIPEM mode", -M ripem1, which does
  not support certificates, or "PEM mode", -M pem, which does.
. Whether the message is encrypted, or just signed.
. Whether MIME ("Multipurpose  Internet Mail Extensions")  is used.   MIME
  format is generally used  only when the  message being encrypted  is not
  plain ASCII.

PEM-Mode Messages





We will start by describing RIPEM messages in PEM mode, which are  produced
by using  "-M  pem"  when  enciphering.   Here  is  an  annotated  example.
(Annotations are indented.)

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
     All RIPEM messages start with this line.
Proc-Type: 4,ENCRYPTED
     "4" indicates standard Internet RFC 1421 PEM.
     The second parameter can be ENCRYPTED, MIC-ONLY, or MIC-CLEAR.  The
     message is encrypted only in the case of ENCRYPTED, but a signature is
     always computed.
Content-Domain: RFC822
     RFC822 indicates that the message plaintext is in standard email
     (ASCII-only) form.  This is currently the only allowable value for
     this field.
DEK-Info: DES-CBC,401E9139E4867FF7
     This field is present only for ENCRYPTED messages, and indicates the
     message data encryption algorithm and mode (always DES-CBC), and the
     initialization vector in hex.
Originator-Certificate:
 MIIBpjCCAUICARYwDQYJKoZIhvcNAQECBQAwTTELMAkGA1UEBhMCVVMxIDAeBgNV
 BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJzb25hIENl
 cnRpZmljYXRlMB4XDTkzMDQxOTIwMDI1MFoXDTk1MDQxOTAwMDAwMFowZDELMAkG
 A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
 VQQLExNQZXJzb25hIENlcnRpZmljYXRlMRUwEwYDVQQDEwxNYXJrIFJpb3JkYW4w
 WTAKBgRVCAEBAgICBgNLADBIAkEylZc/H+pNFRQqHC4abJQV4gTzRuGoXmOFgdeP
 kDshmAB4dAa6qY8ypsLqDFmXfbEInjzwxz8weBHGRnTZwFcrMwIDAQABMA0GCSqG
 SIb3DQEBAgUAA08ABMavdfXztriNQZwk8Ma/YbMOd81sg/bASPXKi2FhmDn2WhdZ
 967PW+ZPYkCDn0JdUikP/41xvKuHhOPDNROvN+Sltgf0aFenF2m8/voX
     This is the certificate of the sender of the message.  It contains the
     sender's public key.  See the section below on certificates. In PEM
     mode, RIPEM tries to follow RFC 1422 which expects that each user is
     certified by only one certificate chain. Therefor, the originator
     certificate is the certificate from the originator's issuer. However,
     if RIPEM finds certificates for the originator from more than one
     issuer, then it doesn't know which one to put in the Originator-
     Certificate field. In this case, it places the originator's self-
     signed certificate here, as in the RIPEM format message described
     below. Also, if there is no certificate chain for the originator,
     RIPEM places the self-signed certificate here which is useful for
     making a certification request message, as described in the user
     manual.
Issuer-Certificate:
 MIIBxjCCAVACBF4AAAMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxIDAe
 BgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVMb3cgQXNz
 dXJhbmNlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTkyMTIyMzA4MDAwMFoX
 DTk0MDEwMTA3NTk1OVowTTELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRh
 IFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJzb25hIENlcnRpZmljYXRlMGkw
 DQYJKoZIhvcNAQEBBQADWAAwVQJOBqoIUA2vV4v9swHWBKiVSHGIZSzdRaSPbV0N
 Zus2d/T2FyvFIaI9BLO5Fkb/IQtOL6pDisJ3Vm81bb6B0Dpj/JzpJLgYvgEL4BaE
 XIDlAgMBAAEwDQYJKoZIhvcNAQECBQADYQCPF1HZAPzWWKSyspFjbUGkmQAWGLtz
 3Zvl1nn3EztPPVtR6GirTpFRa07ov7isHWEdZxGKIwbmFPJuh8pn8tTrSyYfWfD6
 /CHEa04fhZ4jVoAmKmjdgbRTqfraABsBAC8=





     Issuer-Certificates fields contain certificates that follow a
     certification chain up from the Originator-Certificate to the root of
     the hierarchy. This field may be followed by the certificate of the
     authority that issued this certificate, and so on up to the root of
     the hierarchy. If the recipient trusts the root of the hierarchy, then
     the Issuer-Certificates will let the recipient trust the originator.
MIC-Info: RSA-MD5,RSA,
 93KkysZ67I408OZOr6GaimrSez7XUW9ezIWhqtDeXSNNomyeBPrr9EAPDKb52Y97
 KKhSksBlJKaF5J+1KclEihUns91EGUfA
     MIC-Info gives the message digest of the message, encrypted with the
     sender's private component.  That is, this is the "signature".
     The first parameter is the message digest algorithm.  RIPEM always
     uses RSA-MD5 during encryption, but will also recognize RSA-MD2 upon
     decryption.
     The second parameter specifies the public key cipher used to encrypt
     the digest.  This is always RSA.
Recipient-ID-Asymmetric:
 ME0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
 LjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZQ==,12
     This field identifies a recipient, and may occur multiple times.  The
     first parameter is an encoding of the name of the issuer of the
     recipient's certificate, and the second parameter is the serial number
     of the recipient's certificate.  Thus, the recipient is not identified
     directly.  If you decode this particular example, you will see that it
     says that this recipient is the owner of the 12th certificate issued
     by RSA Data Security, Inc.
Key-Info: RSA,
 UCoYCx7e3nap6HvKN3w5dVs6Nv4Vzw7kwvxE6SRq4c/fr0SL4hJGCZLKTerhb5Ly
 KvUrRTm/9MAmWJNhmT+Hqi925V66QVrDmzazDSMfESM81ovc5APWr2Eb7xNrOEM1
     Key-Info describes the message key as encrypted under the public key
     of the most recently-named recipient. The "RSA" here indicates use of
     the RSA public key algorithm; there are no other legal values for the
     first parameter.
Recipient-ID-Asymmetric:
 ME0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
 LjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZQ==,16
Key-Info: RSA,
 LookV1eGyPwZJ4sz2Eyf1ak3re3Sti2JeSIIaost1SeW93L3eqcXCAqGz7GBBJfN
 hSziXJDIbNEGGXdm9Zuoc0E=
     In this example, there are two recipients; hence, there are two
     occurrences of the recipient identifier & message key fields.  Note
     that in many cases, the first parameter of Recipient-ID-Asymmetric
     will be identical from one recipient to the next, since often several
     recipients will have obtained their certificates from the same issuer.

     A single blank line separates the headers from the encrypted message.
     The encrypted message is printably encoded and written out in lines of
     64 ASCII characters each (except the last line).
vJZOOU8izhi44YZgbGy2U2/oPe+RluWAo6SmPBgVjtgQ+xeZA84uL0Pnljj4moL/
IrzUDgpnzsBqnWcAW2YD7xa7FbJuTC8/cOtgSDLBtmPfc1NhL0JY5eY8Ts7fGSt0
gG0hlfA4deo=
-----END PRIVACY-ENHANCED MESSAGE-----
     All RIPEM messages end with this line.





Certificates

A certificate  is a  "document"  that states  a  user, his/her  public  key
component, and validity information.   Certificates are  printably-encoded.
Specifically, a certificate contains the following items.  Items of special
interest, and most  likely to  vary from  one certificate  to another,  are
marked with a *.

. A version  number  that  applies  to  the  format  of  the  certificate;
  currently, this is always zero.
. * A  serial  number.   This  serial number  is  unique  amongst all  the
  certificates issued by a given certifying authority.
. The identifier  of the  algorithm used  to sign  the certificate.   This
  currently is always the same, and specifies the RSA algorithm.
. * The multi-part name  of the issuer of  the certificate.  There  can be
  many different issuers, but in practice the  number of different issuers
  is likely to be small for the near future.
. The date  range  during  which  the  certificate is  valid.    Typically
  certificates are valid for two years.
. * The multi-part name  of the person or  entity to whom  the certificate
  was issued.   This typically contains  not only the  proper name  of the
  issuee (e.g., "John  Smith"), but  the domain with  which the  issuee is
  associated (e.g., the issuee's company name ("Acme Widgets") and country
  ("US")).
. * The public key of the issuee of the certificate.   This, obviously, is
  the whole point of the certificate.
. * The signature of all of the above information in the certificate, done
  by the issuer  with its private  key.  If  you know the  issuer's public
  key, you can verify this signature.



RIPEM-Mode Messages

RIPEM-mode messages are produced by enciphering with the -M ripem1  option.
This is the default.  These will be accepted by RIPEM versions before  2.0.
Note that,  when  deciphering,  RIPEM  accepts  either  PEM  or  RIPEM-mode
messages.

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 2001,ENCRYPTED
     Note that the version number is 2001, distinct from the 4 for PEM.
DEK-Info: DES-CBC,194E5E0350762C82
Originator-Name: mrr@scss3.cl.msu.edu
     This is for compatibility with RIPEM versions 1.1 and earlier. RIPEM
     versions 1.2 and later use the Originator-Certificate field.
Originator-Certificate:
 MIIBpjCCAUICARYwDQYJKoZIhvcNAQECBQAwTTELMAkGA1UEBhMCVVMxIDAeBgNV
 BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJzb25hIENl
 cnRpZmljYXRlMB4XDTkzMDQxOTIwMDI1MFoXDTk1MDQxOTAwMDAwMFowZDELMAkG
 A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
 VQQLExNQZXJzb25hIENlcnRpZmljYXRlMRUwEwYDVQQDEwxNYXJrIFJpb3JkYW4w
 WTAKBgRVCAEBAgICBgNLADBIAkEylZc/H+pNFRQqHC4abJQV4gTzRuGoXmOFgdeP
 kDshmAB4dAa6qY8ypsLqDFmXfbEInjzwxz8weBHGRnTZwFcrMwIDAQABMA0GCSqG





 SIb3DQEBAgUAA08ABMavdfXztriNQZwk8Ma/YbMOd81sg/bASPXKi2FhmDn2WhdZ
 967PW+ZPYkCDn0JdUikP/41xvKuHhOPDNROvN+Sltgf0aFenF2m8/voX
     This is the certificate of the sender of the message.  It contains the
     sender's public key.  See the section below on certificates. RIPEM
     places a self-signed certificate from the originator in this field so
     that the recipient can check the self-signed certificate digest when
     validating it for the first time. Also, since the recipient may have
     many certification paths which validate the originator, the self-
     signed certificate can be used as a starting point for finding any of
     them.
Issuer-Certificate:
 MIIBxjCCAVACBF4AAAMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxIDAe
 BgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVMb3cgQXNz
 dXJhbmNlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTkyMTIyMzA4MDAwMFoX
 DTk0MDEwMTA3NTk1OVowTTELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRh
 IFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJzb25hIENlcnRpZmljYXRlMGkw
 DQYJKoZIhvcNAQEBBQADWAAwVQJOBqoIUA2vV4v9swHWBKiVSHGIZSzdRaSPbV0N
 Zus2d/T2FyvFIaI9BLO5Fkb/IQtOL6pDisJ3Vm81bb6B0Dpj/JzpJLgYvgEL4BaE
 XIDlAgMBAAEwDQYJKoZIhvcNAQECBQADYQCPF1HZAPzWWKSyspFjbUGkmQAWGLtz
 3Zvl1nn3EztPPVtR6GirTpFRa07ov7isHWEdZxGKIwbmFPJuh8pn8tTrSyYfWfD6
 /CHEa04fhZ4jVoAmKmjdgbRTqfraABsBAC8=
     Issuer-Certificates fields contain certificates that follow a
     certification chain up from the Originator-Certificate to the root of
     the hierarchy. If the recipient trusts the root of the hierarchy, then
     the Issuer-Certificates will let the recipient trust the originator.
     Since RIPEM places a self-signed certificate in the Originator-
     Certificate, then the first Issuer-Certificate is actually a
     certificate for the originator from an issuer such as the Persona
     Certification Authority.
Issuer-Certificate:
 MIIBxzCCAVECBQJAAAAUMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMSAw
 HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UECxMlTG93IEFz
 c3VyYW5jZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NDAxMDcwMDAwMDBa
 Fw05NjAxMDcyMzU5NTlaME0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0
 YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTBp
 MA0GCSqGSIb3DQEBAQUAA1gAMFUCTgaqCFANr1eL/bMB1gSolUhxiGUs3UWkj21d
 DWbrNnf09hcrxSGiPQSzuRZG/yELTi+qQ4rCd1ZvNW2+gdA6Y/yc6SS4GL4BC+AW
 hFyA5QIDAQABMA0GCSqGSIb3DQEBAgUAA2EAP/lSjvEN2nj2hmb0ag1w+FlxbV76
 eiMu8ddYBT8IGTB9xH4VJ/iFDl4W7UCNi/pap/jfRd70S3n6OCcxOKrgufCBN0Dz
 FBfh6UnP1DNChuQTddU6NUC0IVyaKKfzREHw
     This is another issuer certificate further up the chain. In this case
     it is a certificate for the Persona Certification Authority issued by
     the Low Assurance Certification Authority.
Key-Info: RSA,
 IVFGLgKdlQ9pF+qtZpqtJtdxCOJU3ie1SaiVohlmj5zOjs5dl7HZ0UOywTsrR8FN
 /2jrVT3zg1pphJyE+8M9OJY=
MIC-Info: RSA-MD5,RSA,
 hkoroUoBWqFb5HZDcL3M/DhitmLVX+NyhVobd2Eyde5yZEoLbx3f+TLEahJPkrwM
 i9PKBur+9O7H+EmLmrqzRCbPFxL2zHKt
Recipient-Name: test
     This field is only included for compatibility with RIPEM 1.1 and
     earlier. RIPEM really uses Recipient-Key-Asymmetric when deciphering.
Recipient-Key-Asymmetric:
 MFkwCgYEVQgBAQICAgADSwAwSAJBAOlNwoWcCD9XK2BQG+7RMg99r/Y1U89/nFUE





 YdyvViHFa7+fDj0lL0MwrpfW6zSlb8MEBzJo1FJSNFeOE/N/ldcCAwEAAQ==
     This contains the recipient's public key. When the recipient sees
     their key, they know the following Key-Info field is for them. Note
     that this field is different from Recipient-ID-Asymmetric as used in
     PEM mode. Using just the public key to identify the recipient, instead
     of an issuer and serial number, has the advantage that an originator
     and recipient can communicate without needing a third party issuer.
Key-Info: RSA,
 Atleg3hO2yJfjdEZfGW9FVZcP9CcrEPus5WIzTfqcQzQSgTyldyV5XPMs/87J6xE
 MSaytHpMaThNxZuOnc+EaBs=
Recipient-Name: raylau@mit.edu
Recipient-Key-Asymmetric:
 MFkwCAOlNwoWcCD9XK2BQG+7RMg99r/Y1U89/nFUEgYEVQgBAQICAgADSwAwSAJB
 YdyvViHFa7+fDj0SNFeOE/N/ldcCAwEAlL0MwrpfW6zSlb8MEBzJo1FJAQ==
Key-Info: RSA,
 RmaSSj2jz1ZU0j9RWFpSTOp01d1iqB2CsPIBH1vaObjC+r2a4U7sOnyfouZMe2+Q
 LVIgy6Vzz862e/K0LwKXbyZaaqrE/swAR6QQZqiTLU53/rPLIJGCRTuCPKYCyTAw

UeluB7ffHqprsJ1cIrD1uJlBmqk90kyML/LEHnyGJys=
-----END PRIVACY-ENHANCED MESSAGE-----



RIPEM Preferences File

The RIPEM  preferences are  kept in  the file  preferen in  the RIPEM  home
directory. The preferences for  each user (as  distinguished by a  separate
public key) is separated in the  file by a blank  line. Here is an  example
entry for one user:

MD5OfPublicKey: D5484C3084F2E4C6FE25EDE7A8533E9C
     This is the hex of the DER encoding of the user's public key.
PreferencesInfo:
 MGEwPjAMBggqhkiG9w0CBQUAMC4wFQQQJJi9XOPFee6Qhh1TEg3iCQIBAjAVBBBi
 9rYSvvxqW3k5wFxhRobmAgECMAwGCCqGSIb3DQIFBQADEQCfvyz2kkG938zxg27P
 Yn48
     This is the base-64 encoding of the DER encoding of the
     RIPEMPreferences for the user, signed as explained below.

The RIPEMPreferences type is defined as follows:

RIPEMPreferences ::= SIGNED SEQUENCE {
  signatureAlgorithm   AlgorithmIdentifier,
  chainLengthsAllowed  SEQUENCE OF ChainLengthAllowedInfo
           -- sequence of zero entries if no chain length allowed info
  currentCRLLastUpdate UTCTime OPTIONAL }

ChainLengthAllowedInfo ::= SEQUENCE {
  publickeyDigest OCTET STRING (16),
     -- the MD5 digest of the DER encoding of the public key
  chainLengthAllowed INTEGER }

The SIGNED SEQUENCE macro means that the info is placed in a sequence  with
the signature algorithm and a bit string containing the signature. This  is





the same macro used for certificates and CRLs. In this case, the  signature
algorithm is actually a digest algorithm identifier because the "signature"
is computed as the digest of the DER-encoded RIPEMPreferences  concatenated
with a password digest.  This technique is simpler  than an RSA  signature,
but only  a single  user can  create and  verify the  signature, since  the
password is secret. The  password digest is  concatenated (instead of  just
the password) since the "signature" must be checked over and over after the
user has entered the password. It is  simpler and more secure to store  the
digest of the password, rather than the raw password, in memory during  the
RIPEM session.