File: rfc1040.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 (1621 lines) | stat: -rw-r--r-- 74,655 bytes parent folder | download | duplicates (5)
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
Network Working Group                                    J. Linn (BBNCC)
Request for Comments: 1040                        IAB Privacy Task Force
Obsoletes RFCs: 989                                         January 1988


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


STATUS OF THIS MEMO

   This RFC suggests a proposed protocol for the Internet community, and
   requests discussion and suggestions for improvements.  Distribution
   of this memo is unlimited.

ACKNOWLEDGMENT

   This RFC is the outgrowth of a series of IAB Privacy Task Force
   meetings and of internal working papers distributed for those
   meetings.  I would like to thank the following Privacy Task Force
   members and meeting guests for their comments and contributions at
   the meetings which led to the preparation of this RFC:  David
   Balenson, Curt Barker, Matt Bishop, Danny Cohen, Tom Daniel, Charles
   Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner,
   Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker,
   and Steve Wilbur.

1.  Executive Summary

   This RFC defines message encipherment and authentication procedures,
   as the initial phase of an effort to provide privacy enhancement
   services for electronic mail transfer in the Internet.  Detailed key
   management mechanisms to support these procedures will be defined in
   a subsequent RFC.  As a goal of this initial phase, it is intended
   that the procedures defined here be compatible with a wide range of
   key management approaches, including both conventional (symmetric)
   and public-key (asymmetric) approaches for encryption of data
   encrypting keys.  Use of conventional cryptography for message text
   encryption and/or integrity check computation is anticipated.

   Privacy enhancement services (confidentiality, authentication, and
   message integrity assurance) are offered through the use of
   end-to-end cryptography between originator and recipient User Agent
   processes, with no special processing requirements imposed on the
   Message Transfer System at endpoints or at intermediate relay
   sites.  This approach allows privacy enhancement facilities to be
   incorporated on a site-by-site or user-by-user basis without impact
   on other Internet entities.  Interoperability among heterogeneous



Linn                                                            [Page 1]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   components and mail transport facilities is supported.

2.  Terminology

   For descriptive purposes, this RFC uses some terms defined in the OSI
   X.400 Message Handling System Model per the 1984 CCITT
   Recommendations.  This section replicates a portion of 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 User
   Agent.  A User Agent (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.

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
   sender and recipient UAs.  No privacy enhancements are offered for
   message fields which are added or transformed by intermediate relay
   points.

   Authentication and integrity facilities are always applied to the
   entirety of a message's text.  No facility for confidentiality
   service without authentication is provided.  Encryption facilities
   may be applied selectively to portions of a message's contents; this
   allows less sensitive portions of messages (e.g., descriptive fields)
   to be processed by a recipient's delegate in the absence of the



Linn                                                            [Page 2]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   recipient's personal cryptographic keys.  In the limiting case, where
   the entirety of message text is excluded from encryption, this
   feature can be used to yield the effective combination of
   authentication and integrity services without confidentiality.

   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 sender to be cognizant
           of whether a message's intended recipient implements privacy
           enhancements, in order that encoding and possible
           encipherment will not be performed on a message whose
           destination is not equipped to perform corresponding inverse
           transformations.

       3.  The defined mechanisms are compatible with a range of mail
           transport facilities (MTAs).  Within the Internet,
           electronic mail transport is effected by a variety of SMTP
           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 offer compatibility 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 an electronic mail privacy
           enhancement be available to the broadest possible user
           community, the selected mechanism should be usable with the
           widest possible variety of existing UA programs.  For



Linn                                                            [Page 3]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


           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
           enhanced privacy 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 privacy-enhanced mail with a higher assurance
           level than a strictly UA-based approach would allow.

       6.  The defined mechanisms support privacy protection of
           electronic mail addressed to mailing lists.

   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 modifications
   throughout the Internet, three basic restrictions are imposed on the
   set of measures to be considered in this RFC:

       1.  Measures will be restricted to implementation at endpoints
           and will be amenable to integration at the user agent (UA)
           level or above, rather than necessitating 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.  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.






Linn                                                            [Page 4]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   As a result of these restrictions, the following facilities can be
   provided:

           1.  disclosure protection,

           2.  sender authenticity, and

           3.  message integrity measures,

   but the following privacy-relevant concerns are not addressed:

           1.  access control,

           2.  traffic flow confidentiality,

           3.  address list accuracy,

           4.  routing control,

           5.  issues relating to the 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.

   An important goal is that privacy enhancement mechanisms impose a
   minimum of burden on the users they serve.  In particular, this goal
   suggests eventual automation of the key management mechanisms
   supporting message encryption and authentication.  In order to
   facilitate deployment and testing of pilot privacy enhancement
   implementations in the near term, however, compatibility with
   out-of-band (e.g., manual) key distribution must also be supported.

   A message's sender will determine whether privacy enhancements are to
   be performed on a particular message.  Therefore, a sender must be
   able to determine whether particular recipients are equipped to
   process privacy-enhanced mail.  In a general architecture, these
   mechanisms will be based on server queries; thus, the query function
   could be integrated into a UA to avoid imposing burdens or
   inconvenience on electronic mail users.





Linn                                                            [Page 5]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


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.

   A two-level keying hierarchy is used to support privacy-enhanced
   message 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 quantities (MICs).  DEKs are generated individually
           for each transmitted message; no predistribution of DEKs is
           needed to support privacy-enhanced message transmission.

       2.  Interchange Keys (IKs) are used to encrypt DEKs for
           transmission within messages.  An IK may be a single
           symmetric cryptographic key or, where asymmetric
           (public-key) cryptography is used to encrypt DEKs, the
           composition of a public component used by an originator and
           a secret component used by a recipient.  Ordinarily, the
           same IK will be used for all messages sent between a given
           originator-recipient pair over a period of time.  Each
           transmitted message includes a representation of the DEK(s)
           used for message encryption and/or authentication,
           encrypted under an individual IK per named recipient.  This
           representation is associated with sender and recipient
           identification header fields, which enable recipients to
           identify the IKs used.  With this information, the recipient
           can decrypt the transmitted DEK representation, yielding
           the DEK required for message text decryption and/or MIC
           verification.

   When privacy enhancement processing is to be performed on an outgoing
   message, a DEK is generated [1] for use in message encryption and a
   variant of the DEK is formed (if the chosen MIC algorithm requires a
   key) for use in MIC computation.  An "X-Sender-ID:" field is included
   in the header to provide one identification component for the IK(s)
   used for message processing.  An IK is selected for each individually
   identified recipient; a corresponding "X-Recipient-ID:" field,
   interpreted in the context of a prior "X-Sender-ID:" field, serves to
   identify each IK.  Each "X-Recipient-ID:" field is followed by an
   "X-Key-Info:" field, which transfers the DEK and computed MIC.  The
   DEK and MIC are encrypted for transmission under the appropriate IK.



Linn                                                            [Page 6]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   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 system to be
   decrypted on a different type.  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 encryption and MIC computation processes.

   For encryption purposes, the canonical representation is padded as
   required by the encryption algorithm.  The padded canonical
   representation is encrypted (except for any regions explicitly
   excluded from encryption).  The canonically encoded representation is
   encoded, after encryption, 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.

   The output of the encoding procedure is combined with a set of header
   fields carrying cryptographic control information.  The result is
   passed to the electronic mail system to be encapsulated as the text
   portion of a transmitted message.

   When a privacy-enhanced message is received, the cryptographic
   control fields within its text portion provide the information
   required for the authorized recipient to perform MIC verification and
   decryption of the received message text.  First, the printable
   encoding is converted to a bitstring.  The MIC is verified.
   Encrypted portions of the transmitted message are decrypted, and the
   canonical representation is converted to the recipient's local form,
   which need not be the same as the sender's local form.

4.2  Encryption Algorithms and Modes

   For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined
   in ISO draft international standard DIS 8227 [2] shall be used for
   encryption of message text.  The DEA-1 is equivalent to the Data
   Encryption Standard (DES), as defined in FIPS PUB 46 [3].  When used
   for encryption of text, the DEA-1 shall be used in the Cipher Block
   Chaining (CBC) mode, as defined in ISO DIS 8372 [4].  The CBC mode
   definition in DIS 8372 is equivalent to that provided in FIPS PUB 81
   [5].  A unique initializing vector (IV) will be generated for and
   transmitted with each privacy-enhanced electronic mail message.







Linn                                                            [Page 7]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   An algorithm other than DEA-1 may be employed, provided that it
   satisfies the following requirements:

           1.  It must be a 64-bit block cipher, enciphering and
               deciphering in 8-octet blocks.

           2.  It is usable in the ECB and CBC modes defined in DIS
               8372.

           3.  It is able to be keyed using the procedures and
               parameters defined in this RFC.

           4.  It is appropriate for MIC computation, if the selected
               MIC computation algorithm is eCcryption-based.

           5.  Cryptographic key field lengths are limited to 16 octets
               in length.

   Certain operations require that one key be encrypted under another
   key (interchange key) for purposes of transmission.  This encryption
   may be performed using symmetric cryptography by using DEA-1 in
   Electronic Codebook (ECB) mode.  A header facility is available to
   indicate that an associated key is to be used for encryption in
   another mode (e.g., the Encrypt-Decrypt-Encrypt (EDE) mode used for
   key encryption and decryption with pairs of 64-bit keys, as described
   by ASC X3T1 [6], or public-key algorithms).

   Support of public key algorithms for key encryption is under active
   consideration, and it is intended that the procedures defined in this
   RFC be appropriate to allow such usage.  Support of key encryption
   modes other than ECB is optional for implementations, however.
   Therefore, in support of universal interoperability, interchange key
   providers should not specify other modes in the absence of a priori
   information indicating that recipients are equipped to perform key
   encryption in other modes.

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 transport facilities.  An encryption mechanism must also be
   compatible with the local conventions of the computer systems which
   it interconnects.  In our approach, a canonicalization step is
   performed to abstract out local conventions and a subsequent encoding



Linn                                                            [Page 8]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   step is performed to conform to the characteristics of the underlying
   mail transport medium (SMTP).  The encoding conforms to SMTP
   constraints, established to support interpersonal messaging.  SMTP's
   rules are also used independently in the canonicalization process.
   RFC-821's [7] Section 4.5 details SMTP's transparency constraints.

   To encode 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 use a different native
   representation to delimit lines.  For example, the <CR><LF> sequences
   delimiting lines in mail inbound to UNIX(tm) 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 [8] server.
   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 9]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


4.3.2  Approach

   Our approach to supporting privacy-enhanced mail across an
   environment in which intermediate conversions may occur encodes mail
   in a fashion which is uniformly representable across the set of
   privacy-enhanced UAs regardless of their systems' native character
   sets.  This encoded form is used to represent mail text from sender
   to recipient, but the encoding is not applied to enclosing mail
   transport headers or to encapsulated headers inserted to carry
   control information between privacy-enhanced UAs.  The encoding's
   characteristics are such that the transformations anticipated between
   sender and recipient UAs will not prevent an encoded message from
   being decoded properly at its destination.

   A sender may exclude one or more portions of a message from
   encryption processing.  Authentication processing is always applied
   to the entirety of message text.  Explicit action is required to
   exclude a portion of a message from encryption processing; by
   default, encryption is applied to the entirety of message text.  The
   user-level delimiter which specifies such exclusion is a local
   matter, and hence may vary between sender and recipient, but all
   systems should provide a means for unambiguous identification of
   areas excluded from encryption processing.

   An outbound privacy-enhanced message undergoes four transformation
   steps, described in the following four subsections.

4.3.2.1  Step 1: Local Form

   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

   The entire message text, including both those portions subject to
   encipherment processing and those portions excluded from such
   processing, is converted to the universal canonical form,
   equivalent to the inter-SMTP representation [9] as defined in
   RFC-821 and RFC-822 [10] (ASCII character set, <CR><LF> line
   delimiters).  The processing required to perform this conversion is
   minimal on systems whose native character set is ASCII.  Since a
   message is converted to a standard character set and representation
   before encryption, it can be decrypted and its MIC can be verified
   at any destination system before any conversion necessary to
   transform the message into a destination-specific local form is
   performed.





Linn                                                           [Page 10]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


4.3.2.3  Step 3: Authentication and Encipherment

   The canonical form is input to the selected MIC computation algorithm
   in order to compute an 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.

   Padding is applied to the canonical form as needed to perform
   encryption in the DEA-1 CBC mode, as follows:  The number of octets
   to be encrypted is determined by subtracting the number of octets
   excluded from encryption from the total length of the encapsulated
   text.  Octets with the hexadecimal value FF (all ones) are appended
   to the canonical form as needed so that the text octets to be
   encrypted, along with the added padding octets, fill an integral
   number of 8-octet encryption quanta.  No padding is applied if the
   number of octets to be encrypted is already an integral multiple of
   8.  The use of hexadecimal FF (a value outside the 7-bit ASCII set)
   as a padding value allows padding octets to be distinguished from
   valid data without inclusion of an explicit padding count indicator.

   The regions of the message which have not been excluded from
   encryption are encrypted.  To support selective encipherment
   processing, an implementation must retain internal indications of the
   positions of excluded areas excluded from encryption with relation to
   non-excluded areas, so that those areas can be properly delimited in
   the encoding procedure defined in step 4.  If a region excluded from
   encryption intervenes between encrypted regions, cryptographic state
   (e.g., IVs and accumulation of octets into encryption quanta) is
   preserved and continued after the excluded region.

4.3.2.4  Step 4: Printable Encoding

   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).  This encoding step is
   performed for all privacy-enhanced messages.

   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.)
   Two additional characters, "=" and "*", are used to signify special
   processing functions.  The character "=" is used for padding within
   the printable encoding procedure.  The character "*" is used to
   delimit the beginning and end of a region which has been excluded



Linn                                                           [Page 11]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   from encipherment processing.  The encoding function's output is
   delimited into text lines (using local conventions), with each line
   containing 64 printable characters.

   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>").

   Special processing is performed if fewer than 24-bits are available
   in an input group, either at the end of a message or (when the
   selective encryption facility is invoked) at the end of an encrypted
   region or an excluded region.  In other words, a full encoding
   quantum is always completed at the end of a message and before the
   delimiter "*" is output to initiate or terminate the representation
   of a block excluded from encryption.  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.

   In summary, the outbound message is subjected to the following
   composition of transformations:

         Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))

   The inverse transformations are performed, in reverse order, to
   process inbound privacy-enhanced mail:

         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 sender and recipient
   systems without loss of information.




Linn                                                           [Page 12]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


        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        (1)   *

   (1) The character "*" is used to delimit portions of an encoded
   message to which encryption processing has not been applied.

                       Printable Encoding Characters
                                  Table 1

4.4  Encapsulation Mechanism

   Encapsulation of privacy-enhanced messages within an enclosing layer
   of headers interpreted by the electronic mail transport system offers
   a number of advantages in comparison to a flat approach in which
   certain fields within a single header are encrypted and/or carry
   cryptographic control information.  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.  Further, privacy enhancement processing can be
   applied recursively.  As far as the MTS is concerned, information
   incorporated into cryptographic authentication or encryption
   processing will reside in a message's text portion, not its header
   portion.









Linn                                                           [Page 13]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   The encapsulation mechanism to be used for privacy-enhanced mail is
   derived from that described in RFC-934 [11] which is, in turn, based
   on precedents in the processing of message digests in the Internet
   community.  To prepare a user message for encrypted or authenticated
   transmission, it will be transformed into the representation shown in
   Figure 1.

   Enclosing Header Portion
           (Contains header fields per RFC-822)

   Blank Line
            (Separates Enclosing Header from Encapsulated Message)

   Encapsulated Message

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

      Encapsulated Header Portion
          (Contains encryption control fields inserted in plaintext.
          Examples include "X-IV:", "X-Sender-ID:", and "X-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 encoded
          Encapsulated Text Portion)

      Encapsulated Text Portion
          (Contains message data encoded as specified in Section 4.3;
          may incorporate protected copies of "Subject:", etc.)

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

                              Message Encapsulation
                                     Figure 1

   As a general design principle, sensitive data is protected by
   incorporating the data within the encapsulated text rather than by
   applying measures selectively to fields in the enclosing header.
   Examples of potentially sensitive header information may include
   fields such as "Subject:", with contents which are significant on an
   end-to-end, inter-user basis.  The (possibly empty) set of headers to
   which protection is to be applied is a user option.  It is strongly
   recommended, however, that all implementations should replicate



Linn                                                           [Page 14]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the
   encapsulated text and include those replicated fields in encryption
   and MIC computations.

   If a user wishes disclosure protection for header fields, they must
   occur only in the encapsulated text and not in the enclosing or
   encapsulated header.  If disclosure protection is desired for a
   message's subject indication, it is recommended that the enclosing
   header contain a "Subject:" field indicating that "Encrypted Mail
   Follows".

   If an authenticated version of header information is desired, that
   data can be replicated within the encapsulated text portion in
   addition to its inclusion in the enclosing header.  For example, a
   sender wishing to provide recipients with a protected indication of a
   message's position in a series of messages could include a copy of a
   timestamp or message counter field within the encapsulated text.

   A specific point regarding the integration of privacy-enhanced mail
   facilities with the message encapsulation mechanism is worthy of
   note.  The subset of IA5 selected for transmission encoding
   intentionally excludes the character "-", so encapsulated text can be
   distinguished unambiguously from a message's closing encapsulation
   boundary (Post-EB) without recourse to character stuffing.

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-
   perrecipient method.  The choice depends on the information available
   to the sender and on the sender's preference.

   If a message's sender addresses a message to a list name or alias,
   use of an IK associated with that name or alias as a entity (IK-
   perlist), 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.  For the case of public-key
   cryptography, the secret component of the composite IK must be
   available to all list members.  This alternative will be the normal
   case for messages sent via remote exploder sites, as a sender to such
   lists may not be cognizant of the set of individual recipients.
   Unfortunately, it implies an undesirable level of exposure for the
   shared IK or component, 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 sender to the list for
   authentication purposes.





Linn                                                           [Page 15]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   If, in contrast, a message's sender is equipped to expand the
   destination mailing list into its individual constituents and elects
   to do so (IK-per-recipient), the message's DEK and 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 X-Key-Info
   field, not for the message text which is, in general, much larger.
   Although more IKs are involved in processing under the IK-
   perrecipient 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.

4.6  Summary of Added Header and Control Fields

   This section summarizes the syntax and semantics of the new
   encapsulated header fields to be added to messages in the course of
   privacy enhancement processing.  In certain indicated cases, it is
   recommended that the fields be replicated within the encapsulated
   text portion as well.  Figure 2 shows the appearance of a small
   example encapsulated message using these fields.  The example assumes
   the use of symmetric cryptography; no "X-Certificate:" field is
   carried.  In all cases, hexadecimal quantities are represented as
   contiguous strings of digits, where each digit is represented by a
   character from the ranges "0"-"9" or upper case "A"-"F".  Unless
   otherwise specified, all arguments are to be processed in a
   casesensitive fashion.

   Although the encapsulated header fields resemble RFC-822 header
   fields, they are a disjoint set and will not in general be processed
   by the same parser which operates on enclosing header fields.  The
   complexity of lexical analysis needed and appropriate for
   encapsulated header field processing is significantly less than that
   appropriate to RFC-822 header processing.  For example, many
   characters with special significance to RFC-822 at the syntactic
   level have no such significance within encapsulated header fields.

   When the length of an encapsulated header field is longer than the
   size conveniently printable on a line, whitespace may be used between
   the subfields of these fields to fold them in the manner of RFC-822,
   section 3.1.1.  Any such inserted whitespace is not to be interpreted
   as a part of a subfield.









Linn                                                           [Page 16]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 2
   X-IV: F8143EDE5960C597
   X-Sender-ID: linn@ccy.bbn.com:::
   X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3:BMAC:ECB
   X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
   X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4:BMAC:ECB
   X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7

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

                       Example Encapsulated Message
                                 Figure 2

4.6.1  X-Certificate Field

   The X-Certificate encapsulated header field is used only when
   public-key certificate key management is employed.  It transfers a
   sender's certificate as a string of hexadecimal digits.  The
   semantics of a certificate are discussed in Section 5.3,
   Certificates.  The certificate carried in an X-Certificate field is
   used in conjunction with all subsequent X-Sender-ID and X-RecipientID
   fields until another X-Certificate field occurs; the ordinary case
   will be that only a single X-Certificate field will occur, prior to
   any X-Sender-ID and X-Recipient-ID fields.

   Due to the length of a certificate, it may need to be folded across
   multiple printed lines.  In order to enable such folding to be
   performed, the hexadecimal digits representing the contents of a
   certificate are to be divided into an ordered set (with more
   significant digits first) of zero or more 64-digit groups, followed
   by a final digit group which may be any length up to 64-digits.  A
   single whitespace character is interposed between each pair of groups
   so that folding (per RFC-822, section 3.1.1) may take place; this
   whitespace is ignored in parsing the received digit string.

4.6.2  X-IV Field

   The X-IV encapsulated header field carries the Initializing Vector
   used for message encryption.  Only one X-IV field occurs in a
   message.  It appears in all messages, even if the entirety of message
   text is excluded from encryption.  Following the field name, and one
   or more delimiting whitespace characters, a 64-bit Initializing
   Vector is represented as a contiguous string of 16 hexadecimal



Linn                                                           [Page 17]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   digits.

4.6.3  X-Key-Info Field

   The X-Key-Info encapsulated header field transfers two items: a DEK
   and a MIC.  One X-Key-Info field is included for each of a message's
   named recipients.  The DEK and MIC are encrypted under the IK
   identified by a preceding X-Recipient-ID field and prior X-Sender-ID
   field; they are represented as two strings of contiguous hexadecimal
   digits, separated by a comma.  For DEA-1, the DEK representation will
   be 16 hexadecimal digits (corresponding to a 64-bit key); this
   subfield can be extended to 32 hexadecimal digits (corresponding to a
   128-bit key), if required to support other algorithms.  MICs are also
   represented as contiguous strings of hexadecimal digits.  The size of
   a MIC is dependent on the choice of MIC algorithm as specified in the
   X-Recipient-ID field corresponding to a given recipient.

4.6.4  X-Proc-Type Field

   The X-Proc-Type encapsulated header field identifies the type of
   processing performed on the transmitted message.  Only one X-ProcType
   field occurs in a message.  It has one subfield, 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 "2".

4.6.5  X-Sender-ID Field

   The X-Sender-ID encapsulated header field provides the sender's
   interchange key identification component.  It should be replicated
   within the encapsulated text.  The interchange key identification
   component carried in an X-Sender-ID field is used in conjunction with
   all subsequent X-Recipient-ID fields until another X-Sender-ID field
   occurs; the ordinary case will be that only a single X-Sender-ID
   field will occur, prior to any X-Recipient-ID fields.

   The X-Sender-ID field contains (in order) an Entity Identifier
   subfield, an (optional) Issuing Authority subfield, an (optional)
   Version/Expiration subfield, and an (optional) IK Use Indicator
   subfield.  The optional subfields are omitted if their use is
   rendered redundant by information carried in subsequent X-RecipientID
   fields; this will ordinarily be the case where symmetric cryptography
   is used for key management.  The subfields are delimited by the colon
   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.



Linn                                                           [Page 18]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   Note that multiple X-Sender-ID fields may occur within a single
   encapsulated header.  All X-Recipient-ID fields are interpreted in
   the context of the most recent preceding X-Sender-ID field; it is
   illegal for an X-Recipient-ID field to occur in a header before an
   X-Sender-ID has been provided.

4.6.6  X-Recipient-ID Field

   The X-Recipient-ID encapsulated header field provides the recipient's
   interchange key identification component.  One X-Recipient-ID field
   is included for each of a message's named recipients.  It should be
   replicated within the encapsulated text.  The field contains (in
   order) an Entity Identifier subfield, an Issuing Authority subfield,
   a Version/Expiration subfield, a MIC algorithm indicator subfield,
   and an IK Use Indicator subfield.  The subfields are delimited by the
   colon character (":"), optionally followed by whitespace.

   The MIC algorithm indicator is an ASCII string, selected from the
   values defined in Appendix A of this RFC.  Section 5.2, Interchange
   Keys, discusses the semantics of the other subfields and specifies
   the alphabet from which they are chosen.  All X-Recipient-ID
   fields are interpreted in the context of the most recent preceding
   XSender-ID field; it is illegal for an X-Recipient-ID field to
   occur in a header before an X-Sender-ID has been provided.

5.  Key Management

   Several cryptographic constructs are involved in supporting the
   privacy-enhanced message processing procedure.  While (as noted in
   the Executive Summary section of this RFC), key management mechanisms
   have not yet been fully defined, a set of fundamental elements are
   assumed.  Data Encrypting Keys (DEKs) are used to encrypt message
   text and in the message integrity check (MIC) computation process.
   Interchange Keys (IKs) are used to encrypt DEKs for transmission with
   messages.  In an asymmetric key management architecture, certificates
   are used as a means to provide entities' public key 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 for computation of message integrity check quantities (MICs).  It
   is strongly recommended that DEKs be generated and used on a one-time
   basis.  A transmitted message will incorporate a representation of
   the DEK encrypted under an appropriate interchange key (IK) for each
   the authorized recipient.



Linn                                                           [Page 19]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   DEK generation can be performed either centrally by key distribution
   centers (KDCs) or by endpoint systems.  Dedicated KDC systems may be
   able to implement better algorithms for random DEK generation than
   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 a message's originator and recipient.  Moreover, decentralized
   DEK generation at endpoints reduces the frequency with which senders
   must make real-time queries of (potentially unique) servers in order
   to send mail, enhancing communications availability.

   When symmetric cryptography 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 senders.  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-sender secret IK components need not necessarily be
   shared with a KDC.

5.2  Interchange Keys (IKs)

   Interchange Keys (IKs) are used to encrypt Data Encrypting Keys.  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 privacy-enhanced
   electronic mail using conventional cryptography, they must first
   share a common interchange key.  When symmetric cryptography is used,
   the interchange key consists of a single component.  When asymmetric
   cryptography is used, an originator and recipient must possess an
   asymmetric key's public and secret components, as appropriate.  This
   pair of components, when composed, constitute an interchange key.

   While this RFC does not prescribe the means by which interchange keys
   are provided to appropriate parties, it is useful to note that 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 an IA generates and
   distributes an IK, associated control information is provided to
   direct how that IK is to be used.  In order to select the appropriate
   IK to use in message encryption, a sender 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.




Linn                                                           [Page 20]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   Since a message may be sent with multiple IK component
   representations, corresponding to multiple intended recipients, each
   recipient must be able to determine which IK component is intended
   for it.  Moreover, if no corresponding IK component is available in
   the recipient's database when a message arrives, the recipient must
   be able to determine which IK component to request and to 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 privacy-enhanced message is transmitted, an indication of the
   IK components used for DEK encryption must be included.  To this end,
   the "X-Sender-ID:" and "X-Recipient-ID:" encapsulated header fields
   provide 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.  Indicator of IK usage mode (IK use indicator subfield).

         4.  Version/Expiration subfield.

   The colon character (":") is used to delimit the subfields within an
   "X-Sender-ID:" or "X-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):

   IKsubfld       :=       1*ia-char

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

   An example X-Recipient-ID: field is as follows:

               X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:2:BMAC:ECB

   This example field indicates that IA "ptf-kmc" has issued an IK
   component for use on messages sent to "linn@ccy.bbn.com", that the IA



Linn                                                           [Page 21]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   has provided the number 2 as a version indicator for that IK
   component, that the BMAC MIC computation algorithm is to be used for
   the recipient, and that the IK component is to be used in ECB mode.

5.2.1  Subfield Definitions

   The following subsections define the subfields of "X-Sender-ID:" and
   "X-Recipient-ID:" fields.

5.2.1.1  Entity Identifier Subfield

   An entity identifier 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.

5.2.1.2  Issuing Authority Subfield

   An IA identifier subfield is constructed as an IKsubfld.  IA
   identifiers must be assigned in a manner which assures uniqueness.
   This can be done on a centralized or hierarchic basis.

5.2.1.3  Version/Expiration Subfield

   A version/expiration subfield is constructed as an IKsubfld.  The
   version/expiration subfield format may 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.

5.2.1.4  MIC Algorithm Identifier Subfield

   The MIC algorithm identifier, which occurs only within X-Recipient-ID
   fields, is used to identify the choice of message integrity check
   algorithm for a given recipient.  Appendix A of this RFC specifies
   the defined values for this subfield.




Linn                                                           [Page 22]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


5.2.1.5  IK Use Indicator Subfield

   The IK use indicator subfield is an optional facility, provided to
   identify the encryption mode in which an IK component is to be used.
   Currently, this subfield may assume the following reserved string
   values: "ECB", "EDE", "RSA256", "RSA512", and "RSA1024"; the default
   value is "ECB".

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
   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.

5.3 Certificates

   In an asymmetric key management architecture, a certificate binds an
   entity's public key component to a representation of the entity's
   identity and other attributes of the entity.  A certificate's issuing
   authority signs the certificate, vouching for the correspondence
   between the entity's identity, attributes, and associated public key
   component.  Once signed, certificate copies may be posted on multiple
   servers in order to make recipients' certificates directly accessible
   to originators at dispersed locations.  This allows privacy-enhanced
   mail to be sent between an originator and a recipient without prior
   placement of a pairwise key at the originator and recipient, greatly
   enhancing mail system flexibility.  The properties of a certificate's
   authority-applied signature make it unnecessary to be concerned about
   the prospect that servers, or other entities, could undetectably
   modify certificate contents so as to associate a public key with an
   inappropriate entity.

   Per the 1988 CCITT Recommendations X.411 [12] and X.509 [13], a
   subject's certificate is defined to contain the following parameters:

           1.  A signature algorithm identifier, identifying the
               algorithm used by the certificate's issuer to compute the
               signature applied to the certificate.




Linn                                                           [Page 23]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


           2.  Issuer identification, identifying the certificate's
               issuer with an O/R name.

           3.  Validity information, providing date and time limits
               before and after which the certificate should not be
               used.

           4.  Subject identification, identifying the certificate's
               subject with an O/R name.

           5.  Subject's public key.

           6.  Algorithm identifier, identifying the algorithm with
               which the subject's public key is to be used.

           7.  Signature, an asymmetrically encrypted, hashed version of
               the above parameters, computed by the certificate's
               issuer.

   The Recommendations specify an ASN.1 encoding to define a
   certificate.  Pending further study, it is recommended that
   electronic mail privacy enhancement implementations using asymmetric
   cryptography for key management employ this encoding for
   certificates.  Section 4.2.3 of RFC-987 [14] specifies a procedure
   for mapping RFC-822 addresses into the O/R names used in X.411/X.509
   certificates.

6.  User Naming

6.1  Current Approach

   Unique naming of electronic mail users, as is needed in order to
   select corresponding keys correctly, is an important topic and one
   requiring significant study.  A logical association exists between
   key distribution and name/directory server functions; their
   relationship is a topic deserving further consideration.  These
   issues have not been fully resolved at this writing.  The current
   architecture relies on association of IK components with user names
   represented in a universal form ("user@host"), relying on the
   following properties:

       1.  The universal form must be specifiable by an IA as it
           distributes IK components and known to a UA as it processes
           received IK components and IK component identifiers.  If a
           UA or IA uses addresses in a local form which is different
           from the universal form, it must be able to perform an
           unambiguous mapping from the universal form into the local
           representation.



Linn                                                           [Page 24]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


       2.  The universal form, when processed by a sender UA, must have
           a recognizable correspondence with the form of a recipient
           address as specified by a user (perhaps following local
           transformation from an alias into a universal form).

   It is difficult to ensure these properties throughout the Internet.
   For example, an MTS which transforms address representations between
   the local form used within an organization and the universal form as
   used for Internet mail transmission may cause property 2 to be
   violated.

6.2  Issues for Consideration

   The use of flat (non-hierarchic) electronic mail user identifiers,
   which are unrelated to the hosts on which the users reside, may offer
   value.  Personal characteristics, like social security numbers, might
   be considered.  Individually-selected identifiers could be registered
   with a central authority, but a means to resolve name conflicts would
   be necessary.

   A point of particular note is the desire to accommodate multiple
   names for a single individual, in order to represent and allow
   delegation of various roles in which that individual may act.  A
   naming mechanism that binds user roles to keys is needed.  Bindings
   cannot be immutable since roles sometimes change (e.g., the
   comptroller of a corporation is fired).

   It may be appropriate to examine the prospect of extending the
   DARPA/DoD domain system and its associated name servers to resolve
   user names to unique user IDs.  An additional issue arises with
   regard to mailing list support: name servers do not currently perform
   (potentially recursive) expansion of lists into users.  ISO and CSNet
   are working on user-level directory service mechanisms, which may
   also bear consideration.

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 prototype
   implementation.  This implementation is a standalone program which is
   invoked by a user, and lies above the existing UA sublayer.  In the
   UNIX(tm) 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



Linn                                                           [Page 25]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   message, the user prepares the message's text and invokes the
   standalone program (interacting with the program in order to provide
   address information and other data required to perform privacy
   enhancement processing), which in turn generates output suitable for
   transmission via the UA.  When a user receives a privacy-enhanced
   message, the UA 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.  This cache is,
   effectively, a simple database.  IK components are selected for
   transmitted messages based on the sender's identity and on recipient
   names, and corresponding "X-Sender-ID:" and "X-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
   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 "X-Sender-ID:"
   and "X-Recipient-ID:" fields.

8.  Areas For Further Study

   The procedures defined in this RFC are sufficient to support pilot
   implementation of privacy-enhanced electronic mail transmission among
   cooperating parties in the Internet.  Further effort will be needed,
   however, to enhance robustness, generality, and interoperability.  In
   particular, further work is needed in the following areas:

       1.  User naming techniques, and their relationship to the domain
           system, name servers, directory services, and key management
           functions.

       2.  Standardization of Issuing Authority functions, including
           protocols for communications among IAs and between User
           Agents and IAs.

       3.  Specification of public key encryption algorithms to encrypt
           data encrypting keys.

       4.  Interoperability with X.400 mail.



Linn                                                           [Page 26]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   We anticipate generation of subsequent RFCs which will address these
   topics.

9.  References

   This section identifies background references which may be useful to
   those contemplating use of the mechanisms defined in this RFC.

      ISO 7498/Part 2 - Security Architecture, prepared by ISO/TC97/SC
      21/WG 1 Ad hoc group on Security, extends the OSI Basic Reference
      Model to cover security aspects which are general architectural
      elements of communications protocols, and provides an annex with
      tutorial and background information.

      US Federal Information Processing Standards Publication (FIPS PUB)
      46, Data Encryption Standard, 15 January 1977, defines the
      encipherment algorithm used for message text encryption and
      Message Authentication Code (MAC) computation.

      FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines
      specific modes in which the Data Encryption Standard algorithm may
      to be used to perform encryption.

      FIPS PUB 113, Computer Data Authentication, May 1985, defines a
      specific procedure for use of the Data Encryption Standard
      algorithm to compute a MAC.

A.  Message Integrity Check Algorithms

   This appendix identifies the alternative algorithms which may be used
   to compute Message Integrity Check (MIC) values, and assigns them
   character string identifiers to be incorporated in "X-Recipient-ID:"
   fields to indicate the choice of algorithm employed for individual
   message recipients.

   MIC algorithms which utilize DEA-1 cryptography are computed using a
   key which is a variant of the DEK used for message text encryption.
   The variant is formed by modulo-2 addition of the hexadecimal
   quantity F0F0F0F0F0F0F0F0 to the encryption DEK.

A.1  Conventional MAC (MAC)

   A conventional MAC, denoted by the string "MAC", is computed using
   the DEA-1 algorithm in the fashion defined in FIPS PUB 113 [15].  Use
   of the conventional MAC is not recommended for multicast messages.
   The message's encapsulated text is padded at the end, per FIPS PUB
   113, with zero-valued octets as needed in order to form an integral
   number of 8-octet encryption quanta.  These padding octets are



Linn                                                           [Page 27]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   inserted implicitly and are not transmitted with a message.  The
   result of a conventional MAC computation is a single 64-bit value.

A.2  Bidirectional MAC (BMAC)

   A bidirectional MAC, denoted by the string "BMAC", yields a result
   which is transferred as a single 128-bit value.  The BMAC is computed
   in the following manner:  First, the encapsulated text is padded at
   the end with zero-valued octets as needed in order to form an
   integral number of 8-octet encryption quanta.  These padding octets
   are inserted implicitly and are not transmitted with a message.  A
   conventional MAC is computed on the padded form, and the resulting
   64-bits form the high-order 64-bits of the BMAC result.

   The low-order 64-bits of the BMAC result are also formed by computing
   a conventional MAC, but the order of the 8-octet encryption quanta is
   reversed for purposes of computation. In other words, the first
   quantum entered into this computation is the last quantum in the
   encapsulated text, and includes any added padding.  The first quantum
   in the text is the last quantum processed as input to this
   computation.  The octets within each 8-octet quantum are not
   reordered.

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.

     [2]  Information Processing Systems: Data Encipherment: Block
          Cipher Algorithm DEA 1.

     [3]  Federal Information Processing Standards Publication 46,
          Data Encryption Standard, 15 January 1977.

     [4]  Information Processing Systems: Data Encipherment: Modes of
          Operation of a 64-bit Block Cipher.

     [5]  Federal Information Processing Standards Publication 81,
          DES Modes of Operation, 2 December 1980.

     [6]  Addendum to the Transport Layer Protocol Definition for
          Providing Connection Oriented End to End Cryptographic Data
          Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft
          of 19 December 1985, Gaithersburg, MD, p. 15.




Linn                                                           [Page 28]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


     [7]  Postel, J., Simple Mail Transfer Protocol (RFC-821), August
          1982.

     [8]  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.

     [9]  Use of the SMTP canonicalization procedure at this stage
          was selected since it is widely used and implemented in the
          Internet community, not because SMTP interoperability with
          this intermediate result is required; no privacy-enhanced
          message will be passed to SMTP for transmission directly
          from this step in the four-phase transformation procedure.

     [10] Crocker, D., Standard for the Format of ARPA Internet Text
          Messages (RFC-822), August 1982.

     [11] Rose, M. T. and Stefferud, E. A., Proposed Standard for
          Message Encapsulation (RFC-934), January 1985.

     [12] CCITT Recommendation X.411 (1988), "Message Handling
          Systems: Message Transfer System: Abstract Service
          Definition and Procedures".

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

     [14] Kille, S. E., Mapping between X.400 and RFC-822 (RFC-987),
          June 1986.

     [15] Federal Information Processing Standards Publication 113,
          Computer Data Authentication, May 1985.


















Linn                                                           [Page 29]