File: rfc1421.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2355 lines) | stat: -rw-r--r-- 103,894 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355






Network Working Group                                            J. Linn
Request for Comments: 1421                    IAB IRTF PSRG, IETF PEM WG
Obsoletes: 1113                                            February 1993


           Privacy Enhancement for Internet Electronic Mail:
        Part I: Message Encryption and Authentication Procedures

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Acknowledgements

   This document is the outgrowth of a series of meetings of the Privacy
   and Security Research Group (PSRG) of the IRTF and the PEM Working
   Group of the IETF.  I would like to thank the members of the PSRG and
   the IETF PEM WG, as well as all participants in discussions on the
   "pem-dev@tis.com" mailing list, for their contributions to this
   document.

1.  Executive Summary

   This document defines message encryption and authentication
   procedures, in order to provide privacy-enhanced mail (PEM) services
   for electronic mail transfer in the Internet.  It is intended to
   become one member of a related set of four RFCs.  The procedures
   defined in the current document are intended to be compatible with a
   wide range of key management approaches, including both symmetric
   (secret-key) and asymmetric (public-key) approaches for encryption of
   data encrypting keys.  Use of symmetric cryptography for message text
   encryption and/or integrity check computation is anticipated. RFC
   1422 specifies supporting key management mechanisms based on the use
   of public-key certificates.  RFC 1423 specifies algorithms, modes,
   and associated identifiers relevant to the current RFC and to RFC
   1422.  RFC 1424 provides details of paper and electronic formats and
   procedures for the key management infrastructure being established in
   support of these services.

   Privacy enhancement services (confidentiality, authentication,
   message integrity assurance, and non-repudiation of origin) are
   offered through the use of end-to-end cryptography between originator
   and recipient processes at or above the User Agent level.  No special
   processing requirements are imposed on the Message Transfer System at



Linn                                                            [Page 1]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   endpoints or at intermediate relay sites.  This approach allows
   privacy enhancement facilities to be incorporated selectively on a
   site-by-site or user-by-user basis without impact on other Internet
   entities.  Interoperability among heterogeneous components and mail
   transport facilities is supported.

   The current specification's scope is confined to PEM processing
   procedures for the RFC-822 textual mail environment, and defines the
   Content-Domain indicator value "RFC822" to signify this usage.
   Follow-on work in integration of PEM capabilities with other
   messaging environments (e.g., MIME) is anticipated and will be
   addressed in separate and/or successor documents, at which point
   additional Content-Domain indicator values will be defined.

2.  Terminology

   For descriptive purposes, this RFC uses some terms defined in the OSI
   X.400 Message Handling System Model per the CCITT Recommendations.
   This section replicates a portion of (1984) X.400's Section 2.2.1,
   "Description of the MHS Model: Overview" in order to make the
   terminology clear to readers who may not be familiar with the OSI MHS
   Model.

   In the [MHS] model, a user is a person or a computer application.  A
   user is referred to as either an originator (when sending a message)
   or a recipient (when receiving one).  MH Service elements define the
   set of message types and the capabilities that enable an originator
   to transfer messages of those types to one or more recipients.

   An originator prepares messages with the assistance of his or her
   User Agent (UA).  A UA is an application process that interacts with
   the Message Transfer System (MTS) to submit messages.  The MTS
   delivers to one or more recipient UAs the messages submitted to it.
   Functions performed solely by the UA and not standardized as part of
   the MH Service elements are called local UA functions.

   The MTS is composed of a number of Message Transfer Agents (MTAs).
   Operating together, the MTAs relay messages and deliver them to the
   intended recipient UAs, which then make the messages available to the
   intended recipients.

   The collection of UAs and MTAs is called the Message Handling System
   (MHS).  The MHS and all of its users are collectively referred to as
   the Message Handling Environment.







Linn                                                            [Page 2]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


3.  Services, Constraints, and Implications

   This RFC defines mechanisms to enhance privacy for electronic mail
   transferred in the Internet. The facilities discussed in this RFC
   provide privacy enhancement services on an end-to-end basis between
   originator and recipient processes residing at the UA level or above.
   No privacy enhancements are offered for message fields which are
   added or transformed by intermediate relay points between PEM
   processing components.

   If an originator elects to perform PEM processing on an outbound
   message, all PEM-provided security services are applied to the PEM
   message's body in its entirety; selective application to portions of
   a PEM message is not supported. Authentication, integrity, and (when
   asymmetric key management is employed) non-repudiation of origin
   services are applied to all PEM messages; confidentiality services
   are optionally selectable.

   In keeping with the Internet's heterogeneous constituencies and usage
   modes, the measures defined here are applicable to a broad range of
   Internet hosts and usage paradigms.  In particular, it is worth
   noting the following attributes:

        1.  The mechanisms defined in this RFC are not restricted to a
            particular host or operating system, but rather allow
            interoperability among a broad range of systems.  All
            privacy enhancements are implemented at the application
            layer, and are not dependent on any privacy features at
            lower protocol layers.

        2.  The defined mechanisms are compatible with non-enhanced
            Internet components.  Privacy enhancements are implemented
            in an end-to-end fashion which does not impact mail
            processing by intermediate relay hosts which do not
            incorporate privacy enhancement facilities.  It is
            necessary, however, for a message's originator to be
            cognizant of whether a message's intended recipient
            implements privacy enhancements, in order that encoding and
            possible encryption will not be performed on a message whose
            destination is not equipped to perform corresponding inverse
            transformations.  (Section 4.6.1.1.3 of this RFC describes a
            PEM message type ("MIC-CLEAR") which represents a signed,
            unencrypted PEM message in a form readable without PEM
            processing capabilities yet validatable by PEM-equipped
            recipients.)

        3.  The defined mechanisms are compatible with a range of mail
            transport facilities (MTAs).  Within the Internet,



Linn                                                            [Page 3]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


            electronic mail transport is effected by a variety of SMTP
            [2] implementations.  Certain sites, accessible via SMTP,
            forward mail into other mail processing environments (e.g.,
            USENET, CSNET, BITNET).  The privacy enhancements must be
            able to operate across the SMTP realm; it is desirable that
            they also be compatible with protection of electronic mail
            sent between the SMTP environment and other connected
            environments.

        4.  The defined mechanisms are compatible with a broad range of
            electronic mail user agents (UAs).  A large variety of
            electronic mail user agent programs, with a corresponding
            broad range of user interface paradigms, is used in the
            Internet.  In order that electronic mail privacy
            enhancements be available to the broadest possible user
            community, selected mechanisms should be usable with the
            widest possible variety of existing UA programs.  For
            purposes of pilot implementation, it is desirable that
            privacy enhancement processing be incorporable into a
            separate program, applicable to a range of UAs, rather than
            requiring internal modifications to each UA with which PEM
            services are to be provided.

        5.  The defined mechanisms allow electronic mail privacy
            enhancement processing to be performed on personal computers
            (PCs) separate from the systems on which UA functions are
            implemented.  Given the expanding use of PCs and the limited
            degree of trust which can be placed in UA implementations on
            many multi-user systems, this attribute can allow many users
            to process PEM with a higher assurance level than a strictly
            UA-integrated approach would allow.

        6.  The defined mechanisms support privacy protection of
            electronic mail addressed to mailing lists (distribution
            lists, in ISO parlance).

        7.  The mechanisms defined within this RFC are compatible with a
            variety of supporting key management approaches, including
            (but not limited to) manual pre-distribution, centralized
            key distribution based on symmetric cryptography, and the
            use of public-key certificates per RFC 1422.  Different
            key management mechanisms may be used for different
            recipients of a multicast message.  For two PEM
            implementations to interoperate, they must share a common
            key management mechanism; support for the mechanism defined
            in RFC 1422 is strongly encouraged.





Linn                                                            [Page 4]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   In order to achieve applicability to the broadest possible range of
   Internet hosts and mail systems, and to facilitate pilot
   implementation and testing without the need for prior and pervasive
   modifications throughout the Internet, the following design
   principles were applied in selecting the set of features specified in
   this RFC:

        1.  This RFC's measures are restricted to implementation at
            endpoints and are amenable to integration with existing
            Internet mail protocols at the user agent (UA) level or
            above, rather than necessitating modifications to existing
            mail protocols or integration into the message transport
            system (e.g., SMTP servers).

        2.  The set of supported measures enhances rather than restricts
            user capabilities.  Trusted implementations, incorporating
            integrity features protecting software from subversion by
            local users, cannot be assumed in general.  No mechanisms
            are assumed to prevent users from sending, at their
            discretion, messages to which no PEM processing has been
            applied. In the absence of such features, it appears more
            feasible to provide facilities which enhance user services
            (e.g., by protecting and authenticating inter-user traffic)
            than to enforce restrictions (e.g., inter-user access
            control) on user actions.

        3.  The set of supported measures focuses on a set of functional
            capabilities selected to provide significant and tangible
            benefits to a broad user community.  By concentrating on the
            most critical set of services, we aim to maximize the added
            privacy value that can be provided with a modest level of
            implementation effort.

   Based on these principles, the following facilities are provided:

        1.  disclosure protection,

        2.  originator authenticity,

        3.  message integrity measures, and

        4.  (if asymmetric key management is used) non-repudiation of
            origin,

   but the following privacy-relevant concerns are not addressed:

        1.  access control,




Linn                                                            [Page 5]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


        2.  traffic flow confidentiality,

        3.  address list accuracy,

        4.  routing control,

        5.  issues relating to the casual serial reuse of PCs by
            multiple users,

        6.  assurance of message receipt and non-deniability of receipt,

        7.  automatic association of acknowledgments with the messages
            to which they refer, and

        8.  message duplicate detection, replay prevention, or other
            stream-oriented services

4.  Processing of Messages

4.1  Message Processing Overview

   This subsection provides a high-level overview of the components and
   processing steps involved in electronic mail privacy enhancement
   processing.  Subsequent subsections will define the procedures in
   more detail.

4.1.1  Types of Keys

   A two-level keying hierarchy is used to support PEM transmission:

        1.  Data Encrypting Keys (DEKs) are used for encryption of
            message text and (with certain choices among a set of
            alternative algorithms) for computation of message integrity
            check (MIC) quantities.  In the asymmetric key management
            environment, DEKs are also used to encrypt the signed
            representations of MICs in PEM messages to which
            confidentiality has been applied. DEKs are generated
            individually for each transmitted message; no
            predistribution of DEKs is needed to support PEM
            transmission.

        2.  Interchange Keys (IKs) are used to encrypt DEKs for
            transmission within messages.  Ordinarily, the same IK will
            be used for all messages sent from a given originator to a
            given recipient over a period of time.  Each transmitted
            message includes a representation of the DEK(s) used for
            message encryption and/or MIC computation, encrypted under
            an individual IK per named recipient.  The representation is



Linn                                                            [Page 6]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


            associated with Originator-ID and Recipient-ID fields
            (defined in different forms so as to distinguish symmetric
            from asymmetric cases), which allow each individual
            recipient to identify the IK used to encrypt DEKs and/or
            MICs for that recipient's use.  Given an appropriate IK, a
            recipient can decrypt the corresponding transmitted DEK
            representation, yielding the DEK required for message text
            decryption and/or MIC validation.  The definition of an IK
            differs depending on whether symmetric or asymmetric
            cryptography is used for DEK encryption:

                 2a. When symmetric cryptography is used for DEK
                     encryption, an IK is a single symmetric key shared
                     between an originator and a recipient.  In this
                     case, the same IK is used to encrypt MICs as well
                     as DEKs for transmission.  Version/expiration
                     information and IA identification associated with
                     the originator and with the recipient must be
                     concatenated in order to fully qualify a symmetric
                     IK.

                 2b. When asymmetric cryptography is used, the IK
                     component used for DEK encryption is the public
                     component [8] of the recipient.  The IK component
                     used for MIC encryption is the private component of
                     the originator, and therefore only one encrypted
                     MIC representation need be included per message,
                     rather than one per recipient.  Each of these IK
                     components can be fully qualified in a Recipient-ID
                     or Originator-ID field, respectively.
                     Alternatively, an originator's IK component may be
                     determined from a certificate carried in an
                     "Originator-Certificate:" field.

4.1.2  Processing Procedures

   When PEM processing is to be performed on an outgoing message, a DEK
   is generated [1] for use in message encryption and (if a chosen MIC
   algorithm requires a key) a variant of the DEK is formed for use in
   MIC computation.  DEK generation can be omitted for the case of a
   message where confidentiality is not to be applied, unless a chosen
   MIC computation algorithm requires a DEK.  Other parameters (e.g.,
   Initialization Vectors (IVs)) as required by selected encryption
   algorithms are also generated.

   One or more Originator-ID and/or "Originator-Certificate:" fields are
   included in a PEM message's encapsulated header to provide recipients
   with an identification component for the IK(s) used for message



Linn                                                            [Page 7]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   processing.  All of a message's Originator-ID and/or "Originator-
   Certificate:" fields are assumed to correspond to the same principal;
   the facility for inclusion of multiple such fields accomodates the
   prospect that different keys, algorithms, and/or certification paths
   may be required for processing by different recipients.  When a
   message includes recipients for which asymmetric key management is
   employed as well as recipients for which symmetric key management is
   employed, a separate Originator-ID or "Originator-Certificate:" field
   precedes each set of recipients.

   In the symmetric case, per-recipient IK components are applied for
   each individually named recipient in preparation of ENCRYPTED, MIC-
   ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID-
   Symmetric:" field, interpreted in the context of the most recent
   preceding "Originator-ID-Symmetric:" field, serves to identify each
   IK.  In the asymmetric case, per-recipient IK components are applied
   only for ENCRYPTED messages, are independent of originator-oriented
   header elements, and are identified by "Recipient-ID-Asymmetric:"
   fields.  Each Recipient-ID field is followed by a "Key-Info:" field,
   which transfers the message's DEK encrypted under the IK appropriate
   for the specified recipient.

   When symmetric key management is used for a given recipient, the
   "Key-Info:" field following the corresponding "Recipient-ID-
   Symmetric:" field also transfers the message's computed MIC,
   encrypted under the recipient's IK. When asymmetric key management is
   used, a "MIC-Info:" field associated with an "Originator-ID-
   Asymmetric:" or "Originator-Certificate:" field carries the message's
   MIC, asymmetrically signed using the private component of the
   originator.  If the PEM message is of type ENCRYPTED (as defined in
   Section 4.6.1.1.1 of this RFC), the asymmetrically signed MIC is
   symmetrically encrypted using the same DEK, algorithm, encryption
   mode and other cryptographic parameters as used to encrypt the
   message text, prior to inclusion in the "MIC-Info:" field.

4.1.2.1  Processing Steps

   A four-phase transformation procedure is employed in order to
   represent encrypted message text in a universally transmissible form
   and to enable messages encrypted on one type of host computer to be
   decrypted on a different type of host computer.  A plaintext message
   is accepted in local form, using the host's native character set and
   line representation.  The local form is converted to a canonical
   message text representation, defined as equivalent to the inter-SMTP
   representation of message text.  This canonical representation forms
   the input to the MIC computation step (applicable to ENCRYPTED, MIC-
   ONLY, and MIC-CLEAR messages) and the encryption process (applicable
   to ENCRYPTED messages only).



Linn                                                            [Page 8]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   For ENCRYPTED PEM messages, the canonical representation is padded as
   required by the encryption algorithm, and this padded canonical
   representation is encrypted. The encrypted text (for an ENCRYPTED
   message) or the unpadded canonical form (for a MIC-ONLY message) is
   then encoded into a printable form.  The printable form is composed
   of a restricted character set which is chosen to be universally
   representable across sites, and which will not be disrupted by
   processing within and between MTS entities. MIC-CLEAR PEM messages
   omit the printable encoding step.

   The output of the previous processing steps is combined with a set of
   header fields carrying cryptographic control information.  The
   resulting PEM message is passed to the electronic mail system to be
   included within the text portion of a transmitted message. There is
   no requirement that a PEM message comprise the entirety of an MTS
   message's text portion; this allows PEM-protected information to be
   accompanied by (unprotected) annotations.  It is also permissible for
   multiple PEM messages (and associated unprotected text, outside the
   PEM message boundaries) to be represented within the encapsulated
   text of a higher-level PEM message. PEM message signatures are
   forwardable when asymmetric key management is employed; an authorized
   recipient of a PEM message with confidentiality applied can reduce
   that message to a signed but unencrypted form for forwarding purposes
   or can re-encrypt that message for subsequent transmission.

   When a PEM message is received, the cryptographic control fields
   within its encapsulated header provide the information required for
   each authorized recipient to perform MIC validation and decryption of
   the received message text.  For ENCRYPTED and MIC-ONLY messages, the
   printable encoding is converted to a bitstring.  Encrypted portions
   of the transmitted message are decrypted.  The MIC is validated.
   Then, the recipient PEM process converts the canonical representation
   to its appropriate local form.

4.1.2.2  Error Cases

   A variety of error cases may occur and be detected in the course of
   processing a received PEM message. The specific actions to be taken
   in response to such conditions are local matters, varying as
   functions of user preferences and the type of user interface provided
   by a particular PEM implementation, but certain general
   recommendations are appropriate. Syntactically invalid PEM messages
   should be flagged as such, preferably with collection of diagnostic
   information to support debugging of incompatibilities or other
   failures.  RFC 1422 defines specific error processing requirements
   relevant to the certificate-based key management mechanisms defined
   therein.




Linn                                                            [Page 9]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   Syntactically valid PEM messages which yield MIC failures raise
   special concern, as they may result from attempted attacks or forged
   messages.  As such, it is unsuitable to display their contents to
   recipient users without first indicating the fact that the contents'
   authenticity and integrity cannot be guaranteed and then receiving
   positive user confirmation of such a warning.  MIC-CLEAR messages
   (discussed in Section 4.6.1.1.3 of this RFC) raise special concerns,
   as MIC failures on such messages may occur for a broader range of
   benign causes than are applicable to other PEM message types.

4.2  Encryption Algorithms, Modes, and Parameters

   For use in conjunction with this RFC, RFC 1423 defines the
   appropriate algorithms, modes, and associated identifiers to be used
   for encryption of message text with DEKs.

   The mechanisms defined in this RFC incorporate facilities for
   transmission of cryptographic parameters (e.g., pseudorandom
   Initializing Vectors (IVs)) with PEM messages to which the
   confidentiality service is applied, when required by symmetric
   message encryption algorithms and modes specified in RFC 1423.

   Certain operations require encryption of DEKs, MICs, and digital
   signatures under an IK for purposes of transmission.  A header
   facility indicates the mode in which the IK is used for encryption.
   RFC 1423 specifies encryption algorithm and mode identifiers and
   minimum essential support requirements for key encryption processing.

   RFC 1422 specifies asymmetric, certificate-based key management
   procedures based on CCITT Recommendation X.509 to support the message
   processing procedures defined in this document. Support for the key
   management approach defined in RFC 1422 is strongly recommended.  The
   message processing procedures can also be used with symmetric key
   management, given prior distribution of suitable symmetric IKs, but
   no current RFCs specify key distribution procedures for such IKs.

4.3  Privacy Enhancement Message Transformations

4.3.1  Constraints

   An electronic mail encryption mechanism must be compatible with the
   transparency constraints of its underlying electronic mail
   facilities.  These constraints are generally established based on
   expected user requirements and on the characteristics of anticipated
   endpoint and transport facilities.  An encryption mechanism must also
   be compatible with the local conventions of the computer systems
   which it interconnects.  Our approach uses a canonicalization step to
   abstract out local conventions and a subsequent encoding step to



Linn                                                           [Page 10]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   conform to the characteristics of the underlying mail transport
   medium (SMTP).  The encoding conforms to SMTP constraints.  Section
   4.5 of RFC 821 [2] details SMTP's transparency constraints.

   To prepare a message for SMTP transmission, the following
   requirements must be met:

        1.  All characters must be members of the 7-bit ASCII character
            set.

        2.  Text lines, delimited by the character pair <CR><LF>, must
            be no more than 1000 characters long.

        3.  Since the string <CR><LF>.<CR><LF> indicates the end of a
            message, it must not occur in text prior to the end of a
            message.

   Although SMTP specifies a standard representation for line delimiters
   (ASCII <CR><LF>), numerous systems in the Internet use a different
   native representation to delimit lines.  For example, the <CR><LF>
   sequences delimiting lines in mail inbound to UNIX systems are
   transformed to single <LF>s as mail is written into local mailbox
   files.  Lines in mail incoming to record-oriented systems (such as
   VAX VMS) may be converted to appropriate records by the destination
   SMTP server [3].  As a result, if the encryption process generated
   <CR>s or <LF>s, those characters might not be accessible to a
   recipient UA program at a destination which uses different line
   delimiting conventions.  It is also possible that conversion between
   tabs and spaces may be performed in the course of mapping between
   inter-SMTP and local format; this is a matter of local option.  If
   such transformations changed the form of transmitted ciphertext,
   decryption would fail to regenerate the transmitted plaintext, and a
   transmitted MIC would fail to compare with that computed at the
   destination.

   The conversion performed by an SMTP server at a system with EBCDIC as
   a native character set has even more severe impact, since the
   conversion from EBCDIC into ASCII is an information-losing
   transformation.  In principle, the transformation function mapping
   between inter-SMTP canonical ASCII message representation and local
   format could be moved from the SMTP server up to the UA, given a
   means to direct that the SMTP server should no longer perform that
   transformation.  This approach has a major disadvantage: internal
   file (e.g., mailbox) formats would be incompatible with the native
   forms used on the systems where they reside.  Further, it would
   require modification to SMTP servers, as mail would be passed to SMTP
   in a different representation than it is passed at present.




Linn                                                           [Page 11]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


4.3.2  Approach

   Our approach to supporting PEM across an environment in which
   intermediate conversions may occur defines an encoding for mail which
   is uniformly representable across the set of PEM UAs regardless of
   their systems' native character sets.  This encoded form is used (for
   specified PEM message types) to represent mail text in transit from
   originator to recipient, but the encoding is not applied to enclosing
   MTS headers or to encapsulated headers inserted to carry control
   information between PEM UAs.  The encoding's characteristics are such
   that the transformations anticipated between originator and recipient
   UAs will not prevent an encoded message from being decoded properly
   at its destination.

   Four transformation steps, described in the following four
   subsections, apply to outbound PEM message processing:

4.3.2.1  Step 1: Local Form

   This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and
   MIC-CLEAR.  The message text is created in the system's native
   character set, with lines delimited in accordance with local
   convention.

4.3.2.2  Step 2: Canonical Form

   This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and
   MIC-CLEAR.  The message text is converted to a universal canonical
   form, similar to the inter-SMTP representation [4] as defined in RFC
   821 [2] and RFC 822 [5]. The procedures performed in order to
   accomplish this conversion are dependent on the characteristics of
   the local form and so are not specified in this RFC.

   PEM canonicalization assures that the message text is represented
   with the ASCII character set and "<CR><LF>" line delimiters, but does
   not perform the dot-stuffing transformation discussed in RFC 821,
   Section 4.5.2.  Since a message is converted to a standard character
   set and representation before encryption, a transferred PEM message
   can be decrypted and its MIC can be validated at any type of
   destination host computer.  Decryption and MIC validation is
   performed before any conversions which may be necessary to transform
   the message into a destination-specific local form.

4.3.2.3  Step 3: Authentication and Encryption

   Authentication processing is applicable to PEM message types
   ENCRYPTED, MIC-ONLY, and MIC-CLEAR.  The canonical form is input to
   the selected MIC computation algorithm in order to compute an



Linn                                                           [Page 12]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   integrity check quantity for the message.  No padding is added to the
   canonical form before submission to the MIC computation algorithm,
   although certain MIC algorithms will apply their own padding in the
   course of computing a MIC.

   Encryption processing is applicable only to PEM message type
   ENCRYPTED.  RFC 1423 defines the padding technique used to support
   encryption of the canonically-encoded message text.

4.3.2.4  Step 4: Printable Encoding

   This printable encoding step is applicable to PEM message types
   ENCRYPTED and MIC-ONLY.  The same processing is also employed in
   representation of certain specifically identified PEM encapsulated
   header field quantities as cited in Section 4.6.  Proceeding from
   left to right, the bit string resulting from step 3 is encoded into
   characters which are universally representable at all sites, though
   not necessarily with the same bit patterns (e.g., although the
   character "E" is represented in an ASCII-based system as hexadecimal
   45 and as hexadecimal C5 in an EBCDIC-based system, the local
   significance of the two representations is equivalent).

   A 64-character subset of International Alphabet IA5 is used, enabling
   6 bits to be represented per printable character.  (The proposed
   subset of characters is represented identically in IA5 and ASCII.)
   The character "=" signifies a special processing function used for
   padding within the printable encoding procedure.

   To represent the encapsulated text of a PEM message, the encoding
   function's output is delimited into text lines (using local
   conventions), with each line except the last containing exactly 64
   printable characters and the final line containing 64 or fewer
   printable characters.  (This line length is easily printable and is
   guaranteed to satisfy SMTP's 1000-character transmitted line length
   limit.) This folding requirement does not apply when the encoding
   procedure is used to represent PEM header field quantities; Section
   4.6 discusses folding of PEM encapsulated header fields.

   The encoding process represents 24-bit groups of input bits as output
   strings of 4 encoded characters. Proceeding from left to right across
   a 24-bit input group extracted from the output of step 3, each 6-bit
   group is used as an index into an array of 64 printable characters.
   The character referenced by the index is placed in the output string.
   These characters, identified in Table 1, are selected so as to be
   universally representable, and the set excludes characters with
   particular significance to SMTP (e.g., ".", "<CR>", "<LF>").





Linn                                                           [Page 13]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   Special processing is performed if fewer than 24 bits are available
   in an input group at the end of a message.  A full encoding quantum
   is always completed at the end of a message.  When fewer than 24
   input bits are available in an input group, zero bits are added (on
   the right) to form an integral number of 6-bit groups.  Output
   character positions which are not required to represent actual input
   data are set to the character "=".  Since all canonically encoded
   output is an integral number of octets, only the following cases can
   arise: (1) the final quantum of encoding input is an integral
   multiple of 24 bits; here, the final unit of encoded output will be
   an integral multiple of 4 characters with no "=" padding, (2) the
   final quantum of encoding input is exactly 8 bits; here, the final
   unit of encoded output will be two characters followed by two "="
   padding characters, or (3) the final quantum of encoding input is
   exactly 16 bits; here, the final unit of encoded output will be three
   characters followed by one "=" padding character.


   Value Encoding  Value Encoding  Value Encoding  Value Encoding
       0 A            17 R            34 i            51 z
       1 B            18 S            35 j            52 0
       2 C            19 T            36 k            53 1
       3 D            20 U            37 l            54 2
       4 E            21 V            38 m            55 3
       5 F            22 W            39 n            56 4
       6 G            23 X            40 o            57 5
       7 H            24 Y            41 p            58 6
       8 I            25 Z            42 q            59 7
       9 J            26 a            43 r            60 8
      10 K            27 b            44 s            61 9
      11 L            28 c            45 t            62 +
      12 M            29 d            46 u            63 /
      13 N            30 e            47 v
      14 O            31 f            48 w         (pad) =
      15 P            32 g            49 x
      16 Q            33 h            50 y

                  Printable Encoding Characters
                             Table 1


4.3.2.5  Summary of Transformations

   In summary, the outbound message is subjected to the following
   composition of transformations (or, for some PEM message types, a
   subset thereof):

         Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))



Linn                                                           [Page 14]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   The inverse transformations are performed, in reverse order, to
   process inbound PEM messages:

       Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))

   Note that the local form and the functions to transform messages to
   and from canonical form may vary between the originator and recipient
   systems without loss of information.

4.4  Encapsulation Mechanism

   The encapsulation techniques defined in RFC-934 [6] are adopted for
   encapsulation of PEM messages within separate enclosing MTS messages
   carrying associated MTS headers. This approach offers a number of
   advantages relative to a flat approach in which certain fields within
   a single header are encrypted and/or carry cryptographic control
   information.  As far as the MTS is concerned, the entirety of a PEM
   message will reside in an MTS message's text portion, not the MTS
   message's header portion. Encapsulation provides generality and
   segregates fields with user-to-user significance from those
   transformed in transit.  All fields inserted in the course of
   encryption/authentication processing are placed in the encapsulated
   header.  This facilitates compatibility with mail handling programs
   which accept only text, not header fields, from input files or from
   other programs.

   The encapsulation techniques defined in RFC-934 are consistent with
   existing Internet mail forwarding and bursting mechanisms.  These
   techniques are designed so that they may be used in a nested manner.
   The encapsulation techniques may be used to encapsulate one or more
   PEM messages for forwarding to a third party, possibly in conjunction
   with interspersed (non-PEM) text which serves to annotate the PEM
   messages.

   Two encapsulation boundaries (EB's) are defined for delimiting
   encapsulated PEM messages and for distinguishing encapsulated PEM
   messages from interspersed (non-PEM) text.  The pre-EB is the string
   "-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that an
   encapsulated PEM message follows.  The post-EB is either (1) another
   pre-EB indicating that another encapsulated PEM message follows, or
   (2) the string "-----END PRIVACY-ENHANCED MESSAGE-----" indicating
   that any text that immediately follows is non-PEM text.  A special
   point must be noted for the case of MIC-CLEAR messages, the text
   portions of which may contain lines which begin with the "-"
   character and which are therefore subject to special processing per
   RFC-934 forwarding procedures.  When the string "- " must be
   prepended to such a line in the course of a forwarding operation in
   order to distinguish that line from an encapsulation boundary, MIC



Linn                                                           [Page 15]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   computation is to be performed prior to prepending the "- " string.
   Figure 1 depicts the encapsulation of a single PEM message.

   This RFC places no a priori limits on the depth to which such
   encapsulation may be nested nor on the number of PEM messages which
   may be grouped in this fashion at a single nesting level for
   forwarding.  A implementation compliant with this RFC must not
   preclude a user from submitting or receiving PEM messages which
   exploit this encapsulation capability.  However, no specific
   requirements are levied upon implementations with regard to how this
   capability is made available to the user.  Thus, for example, a
   compliant PEM implementation is not required to automatically detect
   and process encapsulated PEM messages.

   In using this encapsulation facility, it is important to note that it
   is inappropriate to forward directly to a third party a message that
   is ENCRYPTED because recipients of such a message would not have
   access to the DEK required to decrypt the message.  Instead, the user
   forwarding the message must transform the ENCRYPTED message into a
   MIC-ONLY or MIC-CLEAR form prior to forwarding.  Thus, in order to
   comply with this RFC, a PEM implementation must provide a facility to
   enable a user to perform this transformation, while preserving the
   MIC associated with the original message.

   If a user wishes PEM-provided confidentiality protection for
   transmitted information, such information must occur in the
   encapsulated text of an ENCRYPTED PEM message, not in the enclosing
   MTS header or PEM encapsulated header. If a user wishes to avoid























Linn                                                           [Page 16]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   Encapsulated Message

       Pre-Encapsulation Boundary (Pre-EB)
           -----BEGIN PRIVACY-ENHANCED MESSAGE-----

       Encapsulated Header Portion
           (Contains encryption control fields inserted in plaintext.
           Examples include "DEK-Info:" and "Key-Info:".
           Note that, although these control fields have line-oriented
           representations similar to RFC 822 header fields, the set
           of fields valid in this context is disjoint from those used
           in RFC 822 processing.)

       Blank Line
           (Separates Encapsulated Header from subsequent
           Encapsulated Text Portion)

       Encapsulated Text Portion
           (Contains message data encoded as specified in Section 4.3.)

       Post-Encapsulation Boundary (Post-EB)
           -----END PRIVACY-ENHANCED MESSAGE-----


                   Encapsulated Message Format
                            Figure 1


   disclosing the actual subject of a message to unintended parties, it
   is suggested that the enclosing MTS header contain a "Subject:" field
   indicating that "Encrypted Mail Follows".

   If an integrity-protected representation of information which occurs
   within an enclosing header (not necessarily in the same format as
   that in which it occurs within that header) is desired, that data can
   be included within the encapsulated text portion in addition to its
   inclusion in the enclosing MTS header.  For example, an originator
   wishing to provide recipients with a protected indication of a
   message's position in a series of messages could include within the
   encapsulated text a copy of a timestamp or message counter value
   possessing end-to-end significance and extracted from an enclosing
   MTS header field.  (Note: mailbox specifiers as entered by end users
   incorporate local conventions and are subject to modification at
   intermediaries, so inclusion of such specifiers within encapsulated
   text should not be regarded as a suitable alternative to the
   authentication semantics defined in RFC 1422 and based on X.500
   Distinguished Names.) The set of header information (if any) included
   within the encapsulated text of messages is a local matter, and this



Linn                                                           [Page 17]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   RFC does not specify formatting conventions to distinguish replicated
   header fields from other encapsulated text.

4.5  Mail for Mailing Lists

   When mail is addressed to mailing lists, two different methods of
   processing can be applicable: the IK-per-list method and the IK-per-
   recipient method.  Hybrid approaches are also possible, as in the
   case of IK-per-list protection of a message on its path from an
   originator to a PEM-equipped mailing list exploder, followed by IK-
   per-recipient protection from the exploder to individual list
   recipients.

   If a message's originator is equipped to expand a destination mailing
   list into its individual constituents and elects to do so (IK-per-
   recipient), the message's DEK (and, in the symmetric key management
   case, MIC) will be encrypted under each per-recipient IK and all such
   encrypted representations will be incorporated into the transmitted
   message.  Note that per-recipient encryption is required only for the
   relatively small DEK and MIC quantities carried in the "Key-Info:"
   field, not for the message text which is, in general, much larger.
   Although more IKs are involved in processing under the IK-per-
   recipient method, the pairwise IKs can be individually revoked and
   possession of one IK does not enable a successful masquerade of
   another user on the list.

   If a message's originator addresses a message to a list name or
   alias, use of an IK associated with that name or alias as a entity
   (IK-per-list), rather than resolution of the name or alias to its
   constituent destinations, is implied. Such an IK must, therefore, be
   available to all list members. Unfortunately, it implies an
   undesirable level of exposure for the shared IK, and makes its
   revocation difficult.  Moreover, use of the IK-per-list method allows
   any holder of the list's IK to masquerade as another originator to
   the list for authentication purposes.

   Pure IK-per-list key management in the asymmetric case (with a common
   private key shared among multiple list members) is particularly
   disadvantageous in the asymmetric environment, as it fails to
   preserve the forwardable authentication and non-repudiation
   characteristics which are provided for other messages in this
   environment.  Use of a hybrid approach with a PEM-capable exploder is
   therefore particularly recommended for protection of mailing list
   traffic when asymmetric key management is used; such an exploder
   would reduce (per discussion in Section 4.4 of this RFC) incoming
   ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding
   them (perhaps re-encrypted under individual, per-recipient keys) to
   list members.



Linn                                                           [Page 18]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


4.6  Summary of Encapsulated Header Fields

   This section defines the syntax and semantics of the encapsulated
   header fields to be added to messages in the course of privacy
   enhancement processing.

   The fields are presented in three groups.  Normally, the groups will
   appear in encapsulated headers in the order in which they are shown,
   though not all fields in each group will appear in all messages.  The
   following figures show the appearance of small example encapsulated
   messages.  Figure 2 assumes the use of symmetric cryptography for key
   management.  Figure 3 illustrates an example encapsulated ENCRYPTED
   message in which asymmetric key management is used.


   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,ENCRYPTED
   Content-Domain: RFC822
   DEK-Info: DES-CBC,F8143EDE5960C597
   Originator-ID-Symmetric: linn@zendia.enet.dec.com,,
   Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3
   Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
             B70665BB9BF7CBCDA60195DB94F727D3
   Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
   Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
             E2EF532C65CBCFF79F83A2658132DB47

   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
   dXd/H5LMDWnonNvPCwQUHt==
   -----END PRIVACY-ENHANCED MESSAGE-----

          Example Encapsulated Message (Symmetric Case)
                            Figure 2


   Figure 4 illustrates an example encapsulated MIC-ONLY message in
   which asymmetric key management is used; since no per-recipient keys
   are involved in preparation of asymmetric-case MIC-ONLY messages,
   this example should be processable for test purposes by arbitrary PEM
   implementations.

   Fully-qualified domain names (FQDNs) for hosts, appearing in the
   mailbox names found in entity identifier subfields of "Originator-
   ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed in
   a case-insensitive fashion.  Unless specified to the contrary, other
   field arguments (including the user name components of mailbox names)



Linn                                                           [Page 19]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   are to be processed in a case-sensitive fashion.

   In most cases, numeric quantities are represented in header fields as
   contiguous strings of hexadecimal digits, where each digit is
   represented by a character from the ranges "0"-"9" or upper case
   "A"-"F".  Since public-key certificates and quantities encrypted













































Linn                                                           [Page 20]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,ENCRYPTED
   Content-Domain: RFC822
   DEK-Info: DES-CBC,BFF968AA74691AC1
   Originator-Certificate:
    MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
    BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
    CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
    MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
    yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
    LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
    iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
    5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
   Key-Info: RSA,
    I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+
    wGrtiUm/ovtKdinz6ZQ/aQ==
   Issuer-Certificate:
    MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
    BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
    CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
    BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
    XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
    cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
    MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
    dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
    EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
   MIC-Info: RSA-MD5,RSA,
    UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv
    AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG
   Recipient-ID-Asymmetric:
    MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
    LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,
    66
   Key-Info: RSA,
    O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv
    7x0Z3Jx2vTAhOYHMcqqCjA==

   qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d
   jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA==
   -----END PRIVACY-ENHANCED MESSAGE-----

    Example Encapsulated ENCRYPTED Message (Asymmetric Case)
                            Figure 3






Linn                                                           [Page 21]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   using asymmetric algorithms are large in size, use of a more space-
   efficient encoding technique is appropriate for such quantities, and
   the encoding mechanism defined in Section 4.3.2.4 of this RFC,
   representing 6 bits per printed character, is adopted for this
   purpose.

   Encapsulated headers of PEM messages are folded using whitespace per
   RFC 822 header folding conventions; no PEM-specific conventions are
   defined for encapsulated header folding.  The example shown in Figure
   4 shows (in its "MIC-Info:" field) an asymmetrically encrypted
   quantity in its printably encoded representation, illustrating the
   use of RFC 822 folding.

   In contrast to the encapsulated header representations defined in RFC
   1113 and its precursors, the field identifiers adopted in this RFC do
   not begin with the prefix "X-" (for example, the field previously
   denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes
   are not to be emitted by implementations conformant to this RFC.  To
   simplify transition and interoperability with earlier
   implementations, it is suggested that implementations based on this
   RFC accept incoming encapsulated header fields carrying the "X-"
   prefix and act on such fields as if the "X-" were not present.





























Linn                                                           [Page 22]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,MIC-ONLY
   Content-Domain: RFC822
   Originator-Certificate:
    MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
    BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
    CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
    MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
    yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
    LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
    iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
    5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
   Issuer-Certificate:
    MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
    BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
    CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
    BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
    XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
    cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
    MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
    dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
    EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
   MIC-Info: RSA-MD5,RSA,
    jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6
    EtE7K2QDeVMCyXsdJlA8fA==

   LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg
   YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo=
   -----END PRIVACY-ENHANCED MESSAGE-----

     Example Encapsulated MIC-ONLY Message (Asymmetric Case)
                            Figure 4


4.6.1  Per-Message Encapsulated Header Fields

   This group of encapsulated header fields contains fields which occur
   no more than once in a PEM message, generally preceding all other
   encapsulated header fields.

4.6.1.1  Proc-Type Field

   The "Proc-Type:" encapsulated header field, required for all PEM
   messages, identifies the type of processing performed on the
   transmitted message.  Only one "Proc-Type:" field occurs in a
   message; the "Proc-Type:" field must be the first encapsulated header



Linn                                                           [Page 23]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   field in the message.

   The "Proc-Type:" field has two subfields, separated by a comma.  The
   first subfield is a decimal number which is used to distinguish among
   incompatible encapsulated header field interpretations which may
   arise as changes are made to this standard.  Messages processed
   according to this RFC will carry the subfield value "4" to
   distinguish them from messages processed in accordance with prior PEM
   RFCs.  The second subfield assumes one of a set of string values,
   defined in the following subsections.

4.6.1.1.1  ENCRYPTED

   The "ENCRYPTED" specifier signifies that confidentiality,
   authentication, integrity, and (given use of asymmetric key
   management) non-repudiation of origin security services have been
   applied to a PEM message's encapsulated text.  ENCRYPTED messages
   require a "DEK-Info:" field and individual Recipient-ID and "Key-
   Info:" fields for all message recipients.

4.6.1.1.2  MIC-ONLY

   The "MIC-ONLY" specifier signifies that all of the security services
   specified for ENCRYPTED messages, with the exception of
   confidentiality, have been applied to a PEM message's encapsulated
   text. MIC-ONLY messages are encoded (per Section 4.3.2.4 of this RFC)
   to protect their encapsulated text against modifications at message
   transfer or relay points.

   Specification of MIC-ONLY, when applied in conjunction with certain
   combinations of key management and MIC algorithm options, permits
   certain fields which are superfluous in the absence of encryption to
   be omitted from the encapsulated header.  In particular, when a
   keyless MIC computation is employed for recipients for whom
   asymmetric cryptography is used, "Recipient-ID-Asymmetric:" and
   "Key-Info:" fields can be omitted.  The "DEK-Info:" field can be
   omitted for all "MIC-ONLY" messages.

4.6.1.1.3  MIC-CLEAR

   The "MIC-CLEAR" specifier represents a PEM message with the same
   security service selection as for a MIC-ONLY message.  The set of
   encapsulated header fields required in a MIC-CLEAR message is the
   same as that required for a MIC-ONLY message.

   MIC-CLEAR message processing omits the encoding step defined in
   Section 4.3.2.4 of this RFC to protect a message's encapsulated text
   against modifications within the MTS.  As a result, a MIC-CLEAR



Linn                                                           [Page 24]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   message's text can be read by recipients lacking access to PEM
   software, even though such recipients cannot validate the message's
   signature. The canonical encoding discussed in Section 4.3.2.2 is
   performed, so interoperation among sites with different native
   character sets and line representations is not precluded so long as
   those native formats are unambiguously translatable to and from the
   canonical form.  (Such interoperability is feasible only for those
   characters which are included in the canonical representation set.)

   Omission of the printable encoding step implies that MIC-CLEAR
   message MICs will be validatable only in environments where the MTS
   does not modify messages in transit, or where the modifications
   performed can be determined and inverted before MIC validation
   processing.  Failed MIC validation on a MIC-CLEAR message does not,
   therefore, necessarily signify a security-relevant event; as a
   result, it is recommended that PEM implementations reflect to their
   users (in a suitable local fashion) the type of PEM message being
   processed when reporting a MIC validation failure.

   A case of particular relevance arises for inbound SMTP processing on
   systems which delimit text lines with local native representations
   other than the SMTP-conventional <CR><LF>.  When mail is delivered to
   a UA on such a system and presented for PEM processing, the <CR><LF>
   has already been translated to local form.  In order to validate a
   MIC-CLEAR message's MIC in this situation, the PEM module must
   recanonicalize the incoming message in order to determine the inter-
   SMTP representation of the canonically encoded message (as defined in
   Section 4.3.2.2 of this RFC), and must compute the reference MIC
   based on that representation.

4.6.1.1.4  CRL

   The "CRL" specifier indicates a special PEM message type, used to
   transfer one or more Certificate Revocation Lists.  The format of PEM
   CRLs is defined in RFC 1422.  No user data or encapsulated text
   accompanies an encapsulated header specifying the CRL message type; a
   correctly-formed CRL message's PEM header is immediately followed by
   its terminating message boundary line, with no blank line
   intervening.

   Only three types of fields are valid in the encapsulated header
   comprising a CRL message.  The "CRL:" field carries a printable
   representation of a CRL, encoded using the procedures defined in
   Section 4.3.2.4 of this RFC. "CRL:" fields may (as an option) be
   followed by no more than one "Originator-Certificate:" field and any
   number of "Issuer-Certificate:" fields. The "Originator-Certificate:"
   and "Issuer-Certificate:" fields refer to the most recently previous
   "CRL:" field, and provide certificates useful in validating the



Linn                                                           [Page 25]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   signature included in the CRL.  "Originator-Certificate:" and
   "Issuer-Certificate:" fields' contents are the same for CRL messages
   as they are for other PEM message types.

4.6.1.2  Content-Domain Field

   The "Content-Domain:" encapsulated header field describes the type of
   content which is represented within a PEM message's encapsulated
   text.  It carries one string argument, whose value is defined as
   "RFC822" to indicate processing of RFC-822 mail as defined in this
   specification.  It is anticipated that additional "Content-Domain:"
   values will be defined subsequently, in additional or successor
   documents to this specification. Only one "Content-Domain:" field
   occurs in a PEM message; this field is the PEM message's second
   encapsulated header field, immediately following the "Proc-Type:"
   field.

4.6.1.3  DEK-Info Field

   The "DEK-Info:" encapsulated header field identifies the message text
   encryption algorithm and mode, and also carries any cryptographic
   parameters (e.g., IVs) used for message encryption.  No more than one
   "DEK-Info:" field occurs in a message; the field is required for all
   messages specified as "ENCRYPTED" in the "Proc-Type:" field.

   The "DEK-Info:" field carries either one argument or two arguments
   separated by a comma.  The first argument identifies the algorithm
   and mode used for message text encryption.  The second argument, if
   present, carries any cryptographic parameters required by the
   algorithm and mode identified in the first argument.  Appropriate
   message encryption algorithms, modes and identifiers and
   corresponding cryptographic parameters and formats are defined in RFC
   1423.

4.6.2  Encapsulated Header Fields Normally Per-Message

   This group of encapsulated header fields contains fields which
   ordinarily occur no more than once per message.  Depending on the key
   management option(s) employed, some of these fields may be absent
   from some messages.

4.6.2.1  Originator-ID Fields

   Originator-ID encapsulated header fields identify a message's
   originator and provide the originator's IK identification component.
   Two varieties of Originator-ID fields are defined, the "Originator-
   ID-Asymmetric:" and "Originator-ID-Symmetric:" field.  An
   "Originator-ID-Symmetric:" header field is required for all PEM



Linn                                                           [Page 26]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   messages employing symmetric key management.  The analogous
   "Originator-ID-Asymmetric:" field, for the asymmetric key management
   case, is used only when no corresponding "Originator-Certificate:"
   field is included.

   Most commonly, only one Originator-ID or "Originator-Certificate:"
   field will occur within a message. For the symmetric case, the IK
   identification component carried in an "Originator-ID-Symmetric:"
   field applies to processing of all subsequent "Recipient-ID-
   Symmetric:" fields until another "Originator-ID-Symmetric:" field
   occurs.  It is illegal for a "Recipient-ID-Symmetric:" field to occur
   before a corresponding "Originator-ID-Symmetric:" field has been
   provided.  For the asymmetric case, processing of "Recipient-ID-
   Asymmetric:" fields is logically independent of preceding
   "Originator-ID-Asymmetric:" and "Originator-Certificate:" fields.

   Multiple Originator-ID and/or "Originator-Certificate:" fields may
   occur in a message when different originator-oriented IK components
   must be used by a message's originator in order to prepare a message
   so as to be suitable for processing by different recipients. In
   particular, multiple such fields will occur when both symmetric and
   asymmetric cryptography are applied to a single message in order to
   process the message for different recipients.

   Originator-ID subfields are delimited by the comma character (","),
   optionally followed by whitespace.  Section 5.2, Interchange Keys,
   discusses the semantics of these subfields and specifies the alphabet
   from which they are chosen.

4.6.2.1.1  Originator-ID-Asymmetric Field

   The "Originator-ID-Asymmetric:" field contains an Issuing Authority
   subfield, and then a Version/Expiration subfield.  This field is used
   only when the information it carries is not available from an
   included "Originator-Certificate:" field.

4.6.2.1.2  Originator-ID-Symmetric Field

   The "Originator-ID-Symmetric:" field contains an Entity Identifier
   subfield, followed by an (optional) Issuing Authority subfield, and
   then an (optional) Version/Expiration subfield.  Optional
   "Originator-ID-Symmetric:" subfields may be omitted only if rendered
   redundant by information carried in subsequent "Recipient-ID-
   Symmetric:" fields, and will normally be omitted in such cases.







Linn                                                           [Page 27]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


4.6.2.2  Originator-Certificate Field

   The "Originator-Certificate:" encapsulated header field is used only
   when asymmetric key management is employed for one or more of a
   message's recipients.  To facilitate processing by recipients (at
   least in advance of general directory server availability), inclusion
   of this field in all messages is strongly recommended.  The field
   transfers an originator's certificate as a numeric quantity,
   comprised of the certificate's DER encoding, represented in the
   header field with the encoding mechanism defined in Section 4.3.2.4
   of this RFC.  The semantics of a certificate are discussed in RFC
   1422.

4.6.2.3  MIC-Info Field

   The "MIC-Info:" encapsulated header field, used only when asymmetric
   key management is employed for at least one recipient of a message,
   carries three arguments, separated by commas.  The first argument
   identifies the algorithm under which the accompanying MIC is
   computed.  The second argument identifies the algorithm under which
   the accompanying MIC is signed.  The third argument represents a MIC
   signed with an originator's private key.

   For the case of ENCRYPTED PEM messages, the signed MIC is, in turn,
   symmetrically encrypted using the same DEK, algorithm, mode and
   cryptographic parameters as are used to encrypt the message's
   encapsulated text.  This measure prevents unauthorized recipients
   from determining whether an intercepted message corresponds to a
   predetermined plaintext value.

   Appropriate MIC algorithms and identifiers, signature algorithms and
   identifiers, and signed MIC formats are defined in RFC 1423.

   A "MIC-Info:" field will occur after a sequence of fields beginning
   with a "Originator-ID-Asymmetric:" or "Originator-Certificate:" field
   and followed by any associated "Issuer-Certificate:" fields.  A
   "MIC-Info:" field applies to all subsequent recipients for whom
   asymmetric key management is used, until and unless overridden by a
   subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:"
   and corresponding "MIC-Info:".

4.6.3  Encapsulated Header Fields with Variable Occurrences

   This group of encapsulated header fields contains fields which will
   normally occur variable numbers of times within a message, with
   numbers of occurrences ranging from zero to non-zero values which are
   independent of the number of recipients.




Linn                                                           [Page 28]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


4.6.3.1  Issuer-Certificate Field

   The "Issuer-Certificate:" encapsulated header field is meaningful
   only when asymmetric key management is used for at least one of a
   message's recipients.  A typical "Issuer-Certificate:" field would
   contain the certificate containing the public component used to sign
   the certificate carried in the message's "Originator-Certificate:"
   field, for recipients' use in chaining through that certificate's
   certification path.  Other "Issuer-Certificate:" fields, typically
   representing higher points in a certification path, also may be
   included by an originator.  It is recommended that the "Issuer-
   Certificate:" fields be included in an order corresponding to
   successive points in a certification path leading from the originator
   to a common point shared with the message's recipients (i.e., the
   Internet Certification Authority (ICA), unless a lower Policy
   Certification Authority (PCA) or CA is common to all recipients.)
   More information on certification paths can be found in RFC 1422.

   The certificate is represented in the same manner as defined for the
   "Originator-Certificate:" field (transporting an encoded
   representation of the certificate in X.509 [7] DER form), and any
   "Issuer-Certificate:" fields will ordinarily follow the "Originator-
   Certificate:" field directly.  Use of the "Issuer-Certificate:" field
   is optional even when asymmetric key management is employed, although
   its incorporation is strongly recommended in the absence of alternate
   directory server facilities from which recipients can access issuers'
   certificates.

4.6.4  Per-Recipient Encapsulated Header Fields

   The encapsulated header fields in this group appear for each of an
   "ENCRYPTED" message's named recipients.  For "MIC-ONLY" and "MIC-
   CLEAR" messages, these fields are omitted for recipients for whom
   asymmetric key management is employed in conjunction with a keyless
   MIC algorithm but the fields appear for recipients for whom symmetric
   key management or a keyed MIC algorithm is employed.

4.6.4.1  Recipient-ID Fields

   A Recipient-ID encapsulated header field identifies a recipient and
   provides the recipient's IK identification component.  One
   Recipient-ID field is included for each of a message's named
   recipients. Section 5.2, Interchange Keys, discusses the semantics of
   the subfields and specifies the alphabet from which they are chosen.
   Recipient-ID subfields are delimited by the comma character (","),
   optionally followed by whitespace.





Linn                                                           [Page 29]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   For the symmetric case, all "Recipient-ID-Symmetric:" fields are
   interpreted in the context of the most recent preceding "Originator-
   ID-Symmetric:" field.  It is illegal for a "Recipient-ID-Symmetric:"
   field to occur in a header before the occurrence of a corresponding
   "Originator-ID-Symmetric:" field.  For the asymmetric case,
   "Recipient-ID-Asymmetric:" fields are logically independent of a
   message's "Originator-ID-Asymmetric:" and "Originator-Certificate:"
   fields.  "Recipient-ID-Asymmetric:" fields, and their associated
   "Key-Info:" fields, are included following a header's originator-
   oriented fields.

4.6.4.1.1  Recipient-ID-Asymmetric Field

   The "Recipient-ID-Asymmetric:" field contains, in order, an Issuing
   Authority subfield and a Version/Expiration subfield.

4.6.4.1.2  Recipient-ID-Symmetric Field

   The "Recipient-ID-Symmetric:" field contains, in order, an Entity
   Identifier subfield, an (optional) Issuing Authority subfield, and an
   (optional) Version/Expiration subfield.

4.6.4.2  Key-Info Field

   One "Key-Info:" field is included for each of a message's named
   recipients.  In addition, it is recommended that PEM implementations
   support (as a locally-selectable option) the ability to include a
   "Key-Info:" field corresponding to a PEM message's originator,
   following an Originator-ID or "Originator-Certificate:" field and
   before any associated Recipient-ID fields, but inclusion of such a
   field is not a requirement for conformance with this RFC.

   Each "Key-Info:" field is interpreted in the context of the most
   recent preceding Originator-ID, "Originator-Certificate:", or
   Recipient-ID field; normally, a "Key-Info:" field will immediately
   follow its associated predecessor field. The "Key-Info:" field's
   argument(s) differ depending on whether symmetric or asymmetric key
   management is used for a particular recipient.

4.6.4.2.1  Symmetric Key Management

   When symmetric key management is employed for a given recipient, the
   "Key-Info:" encapsulated header field transfers four items, separated
   by commas: an IK Use Indicator, a MIC Algorithm Indicator, a DEK and
   a MIC.  The IK Use Indicator identifies the algorithm and mode in
   which the identified IK was used for DEK and MIC encryption for a
   particular recipient.  The MIC Algorithm Indicator identifies the MIC
   computation algorithm used for a particular recipient.  The DEK and



Linn                                                           [Page 30]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   MIC are symmetrically encrypted under the IK identified by a
   preceding "Recipient-ID-Symmetric:" field and/or prior "Originator-
   ID-Symmetric:" field.

   Appropriate symmetric encryption algorithms, modes and identifiers,
   MIC computation algorithms and identifiers, and encrypted DEK and MIC
   formats are defined in RFC 1423.

4.6.4.2.2  Asymmetric Key Management

   When asymmetric key management is employed for a given recipient, the
   "Key-Info:" field transfers two quantities, separated by a comma.
   The first argument is an IK Use Indicator identifying the algorithm
   and mode in which the DEK is asymmetrically encrypted.  The second
   argument is a DEK, asymmetrically encrypted under the recipient's
   public component.

   Appropriate asymmetric encryption algorithms and identifiers, and
   encrypted DEK formats are defined in RFC 1423.

5.  Key Management

   Several cryptographic constructs are involved in supporting the PEM
   message processing procedure.  A set of fundamental elements is
   assumed.  Data Encrypting Keys (DEKs) are used to encrypt message
   text and (for some MIC computation algorithms) in the message
   integrity check (MIC) computation process.  Interchange Keys (IKs)
   are used to encrypt DEKs and MICs for transmission with messages.  In
   a certificate-based asymmetric key management architecture,
   certificates are used as a means to provide entities' public
   components and other information in a fashion which is securely bound
   by a central authority.  The remainder of this section provides more
   information about these constructs.

5.1  Data Encrypting Keys (DEKs)

   Data Encrypting Keys (DEKs) are used for encryption of message text
   and (with some MIC computation algorithms) for computation of message
   integrity check quantities (MICs).  In the asymmetric key management
   case, they are also used for encrypting signed MICs in ENCRYPTED PEM
   messages.  It is strongly recommended that DEKs be generated and used
   on a one-time, per-message, basis.  A transmitted message will
   incorporate a representation of the DEK encrypted under an
   appropriate interchange key (IK) for each of the named recipients.

   DEK generation can be performed either centrally by key distribution
   centers (KDCs) or  by endpoint systems.  Dedicated KDC systems may be
   able to  implement stronger algorithms for random DEK generation than



Linn                                                           [Page 31]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   can be supported in endpoint systems.  On the other hand,
   decentralization allows endpoints to be relatively self-sufficient,
   reducing the level of trust which must be placed in components other
   than those of a message's originator and recipient.  Moreover,
   decentralized DEK generation at endpoints reduces the frequency with
   which originators must make real-time queries of (potentially unique)
   servers in order to send mail, enhancing communications availability.

   When symmetric key management is used, one advantage of centralized
   KDC-based generation is that DEKs can be returned to endpoints
   already encrypted under the IKs of message recipients rather than
   providing the IKs to the originators.  This reduces IK exposure and
   simplifies endpoint key management requirements.  This approach has
   less value if asymmetric cryptography is used for key management,
   since per-recipient public IK components are assumed to be generally
   available and per-originator private IK components need not
   necessarily be shared with a KDC.

5.2  Interchange Keys (IKs)

   Interchange Key (IK) components are used to encrypt DEKs and MICs.
   In general, IK granularity is at the pairwise per-user level except
   for mail sent to address lists comprising multiple users.  In order
   for two principals to engage in a useful exchange of PEM using
   conventional cryptography, they must first possess common IK
   components (when symmetric key management is used) or complementary
   IK components (when asymmetric key management is used).  When
   symmetric cryptography is used, the IK consists of a single
   component, used to encrypt both DEKs and MICs.  When asymmetric
   cryptography is used, a recipient's public component is used as an IK
   to encrypt DEKs (a transformation invertible only by a recipient
   possessing the corresponding private component), and the originator's
   private component is used to encrypt MICs (a transformation
   invertible by all recipients, since the originator's certificate
   provides all recipients with the public component required to perform
   MIC validation.

   This RFC does not prescribe the means by which interchange keys are
   made available to appropriate parties; such means may be centralized
   (e.g., via key management servers) or decentralized (e.g., via
   pairwise agreement and direct distribution among users).  In any
   case, any given IK component is associated with a responsible Issuing
   Authority (IA).  When certificate-based asymmetric key management, as
   discussed in RFC [1422, is employed, the IA function is performed by
   a Certification Authority (CA).

   When an IA generates and distributes an IK component, associated
   control information is provided to direct how it is to be used.  In



Linn                                                           [Page 32]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   order to select the appropriate IK(s) to use in message encryption,
   an originator must retain a correspondence between IK components and
   the recipients with which they are associated.  Expiration date
   information must also be retained, in order that cached entries may
   be invalidated and replaced as appropriate.

   Since a message may be sent with multiple IK components identified,
   corresponding to multiple intended recipients, each recipient's UA
   must be able to determine that recipient's intended IK component.
   Moreover, if no corresponding IK component is available in the
   recipient's database when a message arrives, the recipient must be
   able to identify the required IK component and identify that IK
   component's associated IA.  Note that different IKs may be used for
   different messages between a pair of communicants.  Consider, for
   example, one message sent from A to B and another message sent (using
   the IK-per-list method) from A to a mailing list of which B is a
   member.  The first message would use IK components associated
   individually with A and B, but the second would use an IK component
   shared among list members.

   When a PEM message is transmitted, an indication of the IK components
   used for DEK and MIC encryption must be included.  To this end,
   Originator-ID and Recipient-ID encapsulated header fields provide
   (some or all of) the following data:

        1.  Identification of the relevant Issuing Authority (IA
            subfield)

        2.  Identification of an entity with which a particular IK
            component is associated (Entity Identifier or EI subfield)

        3.  Version/Expiration subfield

   In the asymmetric case, all necessary information associated with an
   originator can be acquired by processing the certificate carried in
   an "Originator-Certificate:" field; to avoid redundancy in this case,
   no "Originator-ID-Asymmetric:" field is included if a corresponding
   "Originator-Certificate:" appears.

   The comma character (",") is used to delimit the subfields within an
   Originator-ID or Recipient-ID.  The IA, EI, and version/expiration
   subfields are generated from a restricted character set, as
   prescribed by the following BNF (using notation as defined in RFC
   822, Sections 2 and 3.3):







Linn                                                           [Page 33]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   IKsubfld       :=       1*ia-char

   ia-char        :=       DIGIT / ALPHA / "'" / "+" / "(" / ")" /
                           "." / "/" / "=" / "?" / "-" / "@" /
                           "%" / "!" / '"' / "_" / "<" / ">"



   An example Recipient-ID field for the symmetric case is as follows:

   Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,2

   This example field indicates that IA "ptf-kmc" has issued an IK
   component for use on messages sent  to "linn@zendia.enet.dec.com",
   and that the IA has provided the number 2 as a version indicator for
   that IK component.

   An example Recipient-ID field for the asymmetric case is as follows:

   Recipient-ID-Asymmetric:
    MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
    LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,66

   This example field includes the printably encoded BER representation
   of a certificate's issuer distinguished name, along with the
   certificate serial number 66 as assigned by that issuer.

5.2.1  Subfield Definitions

   The following subsections define the subfields of Originator-ID and
   Recipient-ID fields.

5.2.1.1  Entity Identifier Subfield

   An entity identifier (used only for "Originator-ID-Symmetric:" and
   "Recipient-ID-Symmetric:" fields) is constructed as an IKsubfld.
   More restrictively, an entity identifier subfield assumes the
   following form:

                      <user>@<domain-qualified-host>

   In order to support universal interoperability, it is necessary to
   assume a universal form for the naming information.  For the case of
   installations which transform local host names before transmission
   into the broader Internet, it is strongly recommended that the host
   name as presented to the Internet be employed.





Linn                                                           [Page 34]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


5.2.1.2  Issuing Authority Subfield

   An IA identifier subfield is constructed as an IKsubfld.  This RFC
   does not define this subfield's contents for the symmetric key
   management case. Any prospective IAs which are to issue symmetric
   keys for use in conjunction with this RFC must coordinate assignment
   of IA identifiers in a manner (centralized or hierarchic) which
   assures uniqueness.

   For the asymmetric key management case, the IA identifier subfield
   will be formed from the ASN.1 BER representation of the distinguished
   name of the issuing organization or organizational unit.  The
   distinguished encoding rules specified in Clause 8.7 of
   Recommendation X.509 ("X.509 DER") are to be employed in generating
   this representation.  The encoded binary result will be represented
   for inclusion in a transmitted header using the procedure defined in
   Section 4.3.2.4 of this RFC.

5.2.1.3  Version/Expiration Subfield

   A version/expiration subfield is constructed as an IKsubfld.  For the
   symmetric key management case, the version/expiration subfield format
   is permitted to vary among different IAs, but must satisfy certain
   functional constraints.  An IA's version/expiration subfields must be
   sufficient to distinguish among the set of IK components issued by
   that IA for a given identified entity.  Use of a monotonically
   increasing number is sufficient to distinguish among the IK
   components provided for an entity by an IA; use of a timestamp
   additionally allows an expiration time or date to be prescribed for
   an IK component.

   For the asymmetric key management case, the version/expiration
   subfield's value is the hexadecimal serial number of the certificate
   being used in conjunction with the originator or recipient specified
   in the "Originator-ID-Asymmetric:" or "Recipient-ID-Asymmetric:"
   field in which the subfield occurs.

5.2.2  IK Cryptoperiod Issues

   An IK component's cryptoperiod is dictated in part by a tradeoff
   between key management overhead and revocation responsiveness.  It
   would be undesirable to delete an IK component permanently before
   receipt of a message encrypted using that IK component, as this would
   render the message permanently undecipherable.  Access to an expired
   IK component would be needed, for example, to process mail received
   by a user (or system) which had been inactive for an extended period
   of time.  In order to enable very old IK components to be deleted, a
   message's recipient desiring encrypted local long term storage should



Linn                                                           [Page 35]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   transform the DEK used for message text encryption via re-encryption
   under a locally maintained IK, rather than relying on IA maintenance
   of old IK components for indefinite periods.

6.  User Naming

   Unique naming of electronic mail users, as is needed in order to
   select corresponding keys correctly, is an important topic and one
   which has received (and continues to receive) significant study.  For
   the symmetric case, IK components are identified in PEM headers
   through use of mailbox specifiers in traditional Internet-wide form
   ("user@domain-qualified-host"). Successful operation in this mode
   relies on users (or their PEM implementations) being able to
   determine the universal-form names corresponding to PEM originators
   and recipients.  If a PEM implementation operates in an environment
   where addresses in a local form differing from the universal form are
   used, translations must be performed in order to map between the
   universal form and that local representation.

   The use of user identifiers unrelated to the hosts on which the
   users' mailboxes reside offers generality and value.  X.500
   distinguished names, as employed in the certificates of the
   recommended key management infrastructure defined in RFC 1422,
   provide a basis for such user identification. As directory services
   become more pervasive, they will offer originators a means to search
   for desired recipients which is based on a broader set of attributes
   than mailbox specifiers alone. Future work is anticipated in
   integration with directory services, particularly the mechanisms and
   naming schema of the Internet OSI directory pilot activity.

7.  Example User Interface and Implementation

   In order to place the mechanisms and approaches discussed in this RFC
   into context, this section presents an overview of a hypothetical
   prototype implementation.   This implementation is a standalone
   program   which is invoked by a user, and   lies above the existing
   UA sublayer.  In the UNIX system, and possibly in other environments
   as well,  such a program can be invoked as a "filter" within an
   electronic mail UA or a  text editor, simplifying the sequence of
   operations which must be performed by  the user. This form of
   integration offers the  advantage that the program can be used in
   conjunction with a range of UA  programs, rather than being
   compatible only with a particular UA.

   When a user wishes to apply privacy enhancements to an outgoing
   message, the user prepares the message's text and invokes the
   standalone program, which in turn generates output suitable for
   transmission via the UA.  When a user receives a PEM message, the UA



Linn                                                           [Page 36]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   delivers the message in encrypted form, suitable for decryption and
   associated processing by the standalone program.

   In this prototype implementation, a cache of IK components is
   maintained in a local file, with entries managed manually based on
   information provided by originators and recipients.  For the
   asymmetric key management case, certificates are acquired for a
   user's PEM correspondents; in advance and/or in addition to retrieval
   of certificates from directories, they can be extracted from the
   "Originator-Certificate:" fields of received PEM messages.

   The IK/certificate cache is, effectively, a simple database indexed
   by mailbox names.  IK components are selected for transmitted
   messages based on the originator's identity and on recipient names,
   and corresponding Originator-ID, "Originator-Certificate:", and
   Recipient-ID fields are placed into the message's encapsulated
   header.  When a message is received, these fields are used as a basis
   for a lookup in the database, yielding the appropriate IK component
   entries.  DEKs and cryptographic parameters (e.g., IVs) are generated
   dynamically within the program.

   Options and destination addresses are selected by command line
   arguments to the standalone program.  The function of specifying
   destination addresses to the privacy enhancement program is logically
   distinct from the function of specifying the corresponding addresses
   to the UA for use by the MTS.  This separation results from the fact
   that, in many cases, the local form of an address as specified to a
   UA differs from the Internet global form as used in "Originator-ID-
   Symmetric:" and "Recipient-ID-Symmetric:" fields.

8.  Minimum Essential Requirements

   This section summarizes particular capabilities which an
   implementation must provide for full conformance with this RFC.

   RFC 1422 specifies asymmetric, certificate-based key management
   procedures to support the message processing procedures defined in
   this document; PEM implementation support for these key management
   procedures is strongly encouraged.  Implementations supporting these
   procedures must also be equipped to display the names of originator
   and recipient PEM users in the X.500 DN form as authenticated by the
   procedures of RFC 1422.

   The message processing procedures defined here can also be used with
   symmetric key management techniques, though no RFCs analogous to RFC
   1422 are currently available to provide correspondingly detailed
   description of suitable symmetric key management procedures.   A
   complete PEM implementation must support at least one of these



Linn                                                           [Page 37]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   asymmetric and/or symmetric key management modes.

   A full implementation of PEM is expected to be able to send and
   receive ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages, and to receive
   CRL messages.  Some level of support for generating and processing
   nested and annotated PEM messages (for forwarding purposes) is to be
   provided, and an implementation should be able to reduce ENCRYPTED
   messages to MIC-ONLY or MIC-CLEAR for forwarding. Fully-conformant
   implementations must be able to emit Certificate and Issuer-
   Certificate fields, and to include a Key-Info field corresponding to
   the originator, but users or configurers of PEM implementations may
   be allowed the option of deactivating those features.

9.  Descriptive Grammar

   This section provides a grammar describing the construction of a PEM
   message.

   ; PEM BNF representation, using RFC 822 notation.

   ; imports field meta-syntax (field, field-name, field-body,
   ; field-body-contents) from RFC-822, sec. 3.2
   ; imports DIGIT, ALPHA, CRLF, text from RFC-822
   ; Note: algorithm and mode specifiers are officially defined
   ; in RFC 1423

   <pemmsg> ::= <preeb>
                <pemhdr>
                [CRLF <pemtext>]   ; absent for CRL message
                <posteb>

   <preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF
   <posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb>

   <pemtext> ::= <encbinbody>      ; for ENCRYPTED or MIC-ONLY messages
               / *(<text> CRLF)    ; for MIC-CLEAR

   <pemhdr> ::= <normalhdr> / <crlhdr>

   <normalhdr> ::=  <proctype>

               <contentdomain>
               [<dekinfo>]         ; needed if ENCRYPTED
               (1*(<origflds> *<recipflds>)) ; symmetric case --
                            ; recipflds included for all proc types
               / ((1*<origflds>) *(<recipflds>)) ; asymmetric case --
                            ; recipflds included for ENCRYPTED proc type




Linn                                                           [Page 38]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   <crlhdr> ::= <proctype>
               1*(<crl> [<cert>] *(<issuercert>))

   <asymmorig> ::= <origid-asymm> / <cert>

   <origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>)
                  <micinfo>                        ; asymmetric
                  / <origid-symm> [<keyinfo>]      ; symmetric

   <recipflds> ::= <recipid> <keyinfo>

   ; definitions for PEM header fields

   <proctype> ::= "Proc-Type" ":" "4" "," <pemtypes> CRLF
   <contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF
   <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
   <symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>]
   <asymmid> ::= <IKsubfld> "," <IKsubfld>
   <origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF
   <origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF
   <recipid> ::= <recipid-asymm> / <recipid-symm>
   <recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
   <recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
   <cert> ::= "Originator-Certificate" ":" <encbin> CRLF
   <issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
   <micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
                  <asymsignmic> CRLF
   <keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
                 <symencdek> "," <symencmic> CRLF     ; symmetric case
                 / "Key-Info" ":" <ikalgid> "," <asymencdek>
                 CRLF                                ; asymmetric case
   <crl> ::= "CRL" ":" <encbin> CRLF

   <pemtypes> ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" / "CRL"

   <encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
   <encbingrp> ::= 4*4<encbinchar>
   <encbin> ::= 1*<encbingrp>
   <encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF]
   <IKsubfld> ::= 1*<ia-char>
   ; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID
   ; fields can be delimited with commas (not colons) like all other
   ; fields
   <ia-char> ::=  DIGIT / ALPHA / "'" / "+" / "(" / ")" /
                  "." / "/" / "=" / "?" / "-" / "@" /
                  "%" / "!" / '"' / "_" / "<" / ">"
   <hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
                                                      ; no lower case



Linn                                                           [Page 39]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   ; This specification defines one value ("RFC822") for
   ; <contentdescrip>: other values may be defined in future in
   ; separate or successor documents
   ;
   <contentdescrip> ::= "RFC822"

   ; The following items are defined in RFC 1423
   ;  <dekalgid>
   ;  <dekparameters>
   ;  <micalgid>
   ;  <ikalgid>
   ;  <asymsignmic>
   ;  <symencdek>
   ;  <symencmic>
   ;  <asymencdek>


NOTES:

     [1]  Key generation for MIC computation and message text encryption
          may either be performed by the sending host or by a
          centralized server.  This RFC does not constrain this design
          alternative.  Section 5.1 identifies possible advantages of a
          centralized server approach if symmetric key management is
          employed.

     [2]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
          RFC 821, August 1982.

     [3]  This transformation should occur only at an SMTP endpoint, not
          at an intervening relay, but may take place at a gateway
          system linking the SMTP realm with other environments.

     [4]  Use of a canonicalization procedure similar to that of SMTP
          was selected because its functions are widely used and
          implemented within the Internet mail community, not for
          purposes of SMTP interoperability with this intermediate
          result.

     [5]  Crocker, D., "Standard for the Format of ARPA Internet Text
          Messages", STD 11, RFC 822, August 1982.

     [6]  Rose, M. T. and Stefferud, E. A., "Proposed Standard for
          Message Encapsulation", RFC 934, January 1985.

     [7]  CCITT Recommendation X.509 (1988), "The Directory -
          Authentication Framework".




Linn                                                           [Page 40]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


     [8]  Throughout this RFC we have adopted the terms "private
          component" and "public component" to refer to the quantities
          which are, respectively, kept secret and made publicly
          available in asymmetric cryptosystems.  This convention is
          adopted to avoid possible confusion arising from use of the
          term "secret key" to refer to either the former quantity or to
          a key in a symmetric cryptosystem.

Patent Statement

   This version of Privacy Enhanced Mail (PEM) relies on the use of
   patented public key encryption technology for authentication and
   encryption.  The Internet Standards Process as defined in RFC 1310
   requires a written statement from the Patent holder that a license
   will be made available to applicants under reasonable terms and
   conditions prior to approving a specification as a Proposed, Draft or
   Internet Standard.

   The Massachusetts Institute of Technology and the Board of Trustees
   of the Leland Stanford Junior University have granted Public Key
   Partners (PKP) exclusive sub-licensing rights to the following
   patents issued in the United States, and all of their corresponding
   foreign patents:

      Cryptographic Apparatus and Method
      ("Diffie-Hellman")............................... No. 4,200,770

      Public Key Cryptographic Apparatus
      and Method ("Hellman-Merkle").................... No. 4,218,582

      Cryptographic Communications System and
      Method ("RSA")................................... No. 4,405,829

      Exponential Cryptographic Apparatus
      and Method ("Hellman-Pohlig").................... No. 4,424,414

   These patents are stated by PKP to cover all known methods of
   practicing the art of Public Key encryption, including the variations
   collectively known as El Gamal.

   Public Key Partners has provided written assurance to the Internet
   Society that parties will be able to obtain, under reasonable,
   nondiscriminatory terms, the right to use the technology covered by
   these patents.  This assurance is documented in RFC 1170 titled
   "Public Key Standards and Licenses".  A copy of the written assurance
   dated April 20, 1990, may be obtained from the Internet Assigned
   Number Authority (IANA).




Linn                                                           [Page 41]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   The Internet Society, Internet Architecture Board, Internet
   Engineering Steering Group and the Corporation for National Research
   Initiatives take no position on the validity or scope of the patents
   and patent applications, nor on the appropriateness of the terms of
   the assurance.  The Internet Society and other groups mentioned above
   have not made any determination as to any other intellectual property
   rights which may apply to the practice of this standard. Any further
   consideration of these matters is the user's own responsibility.

Security Considerations

   This entire document is about security.

Author's Address

   John Linn

   EMail: 104-8456@mcimail.com

































Linn                                                           [Page 42]