File: rfc2630.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 (3363 lines) | stat: -rw-r--r-- 128,599 bytes parent folder | download | duplicates (6)
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
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363






Network Working Group                                        R. Housley
Request for Comments: 2630                                       SPYRUS
Category: Standards Track                                     June 1999


                      Cryptographic Message Syntax

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary messages.

   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
   as specified in RFC 2315 [PKCS#7].  Wherever possible, backward
   compatibility is preserved; however, changes were necessary to
   accommodate attribute certificate transfer and key agreement
   techniques for key management.





















Housley                     Standards Track                     [Page 1]

RFC 2630              Cryptographic Message Syntax             June 1999


Table of Contents

   1   Introduction .................................................  4
   2   General Overview .............................................  4
   3   General Syntax ...............................................  5
   4   Data Content Type ............................................  5
   5   Signed-data Content Type .....................................  6
       5.1  SignedData Type .........................................  7
       5.2  EncapsulatedContentInfo Type ............................  8
       5.3  SignerInfo Type .........................................  9
       5.4  Message Digest Calculation Process ...................... 11
       5.5  Message Signature Generation Process .................... 12
       5.6  Message Signature Verification Process .................. 12
   6   Enveloped-data Content Type .................................. 12
       6.1  EnvelopedData Type ...................................... 14
       6.2  RecipientInfo Type ...................................... 15
            6.2.1  KeyTransRecipientInfo Type ....................... 16
            6.2.2  KeyAgreeRecipientInfo Type ....................... 17
            6.2.3  KEKRecipientInfo Type ............................ 19
       6.3  Content-encryption Process .............................. 20
       6.4  Key-encryption Process .................................. 20
   7   Digested-data Content Type ................................... 21
   8   Encrypted-data Content Type .................................. 22
   9   Authenticated-data Content Type .............................. 23
       9.1  AuthenticatedData Type .................................. 23
       9.2  MAC Generation .......................................... 25
       9.3  MAC Verification ........................................ 26
   10  Useful Types ................................................. 27
       10.1  Algorithm Identifier Types ............................. 27
             10.1.1  DigestAlgorithmIdentifier ...................... 27
             10.1.2  SignatureAlgorithmIdentifier ................... 27
             10.1.3  KeyEncryptionAlgorithmIdentifier ............... 28
             10.1.4  ContentEncryptionAlgorithmIdentifier ........... 28
             10.1.5  MessageAuthenticationCodeAlgorithm ............. 28
       10.2  Other Useful Types ..................................... 28
             10.2.1  CertificateRevocationLists ..................... 28
             10.2.2  CertificateChoices ............................. 29
             10.2.3  CertificateSet ................................. 29
             10.2.4  IssuerAndSerialNumber .......................... 30
             10.2.5  CMSVersion ..................................... 30
             10.2.6  UserKeyingMaterial ............................. 30
             10.2.7  OtherKeyAttribute .............................. 30









Housley                     Standards Track                     [Page 2]

RFC 2630              Cryptographic Message Syntax             June 1999


   11  Useful Attributes ............................................ 31
       11.1  Content Type ........................................... 31
       11.2  Message Digest ......................................... 32
       11.3  Signing Time ........................................... 32
       11.4  Countersignature ....................................... 34
   12  Supported Algorithms ......................................... 35
       12.1  Digest Algorithms ...................................... 35
             12.1.1  SHA-1 .......................................... 35
             12.1.2  MD5 ............................................ 35
       12.2  Signature Algorithms ................................... 36
             12.2.1  DSA ............................................ 36
             12.2.2  RSA ............................................ 36
       12.3  Key Management Algorithms .............................. 36
             12.3.1  Key Agreement Algorithms ....................... 36
                     12.3.1.1  X9.42 Ephemeral-Static Diffie-Hellman. 37
             12.3.2  Key Transport Algorithms ....................... 38
                     12.3.2.1  RSA .................................. 39
             12.3.3  Symmetric Key-Encryption Key Algorithms ........ 39
                     12.3.3.1  Triple-DES Key Wrap .................. 40
                     12.3.3.2  RC2 Key Wrap ......................... 41
      12.4  Content Encryption Algorithms ........................... 41
            12.4.1  Triple-DES CBC .................................. 42
            12.4.2  RC2 CBC ......................................... 42
      12.5  Message Authentication Code Algorithms .................. 42
            12.5.1  HMAC with SHA-1 ................................. 43
      12.6  Triple-DES and RC2 Key Wrap Algorithms .................. 43
            12.6.1  Key Checksum .................................... 44
            12.6.2  Triple-DES Key Wrap ............................. 44
            12.6.3  Triple-DES Key Unwrap ........................... 44
            12.6.4  RC2 Key Wrap .................................... 45
            12.6.5  RC2 Key Unwrap .................................. 46
   Appendix A:  ASN.1 Module ........................................ 47
   References ....................................................... 55
   Security Considerations .......................................... 56
   Acknowledgments .................................................. 58
   Author's Address ................................................. 59
   Full Copyright Statement ......................................... 60














Housley                     Standards Track                     [Page 3]

RFC 2630              Cryptographic Message Syntax             June 1999


1  Introduction

   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary messages.

   The Cryptographic Message Syntax describes an encapsulation syntax
   for data protection.  It supports digital signatures, message
   authentication codes, and encryption.  The syntax allows multiple
   encapsulation, so one encapsulation envelope can be nested inside
   another.  Likewise, one party can digitally sign some previously
   encapsulated data.  It also allows arbitrary attributes, such as
   signing time, to be signed along with the message content, and
   provides for other attributes such as countersignatures to be
   associated with a signature.

   The Cryptographic Message Syntax can support a variety of
   architectures for certificate-based key management, such as the one
   defined by the PKIX working group.

   The Cryptographic Message Syntax values are generated using ASN.1
   [X.208-88], using BER-encoding [X.209-88].  Values are typically
   represented as octet strings.  While many systems are capable of
   transmitting arbitrary octet strings reliably, it is well known that
   many electronic-mail systems are not.  This document does not address
   mechanisms for encoding octet strings for reliable transmission in
   such environments.

2  General Overview

   The Cryptographic Message Syntax (CMS) is general enough to support
   many different content types.  This document defines one protection
   content, ContentInfo.  ContentInfo encapsulates a single identified
   content type, and the identified type may provide further
   encapsulation.  This document defines six content types: data,
   signed-data, enveloped-data, digested-data, encrypted-data, and
   authenticated-data.  Additional content types can be defined outside
   this document.

   An implementation that conforms to this specification must implement
   the protection content, ContentInfo, and must implement the data,
   signed-data, and enveloped-data content types.  The other content
   types may be implemented if desired.

   As a general design philosophy, each content type permits single pass
   processing using indefinite-length Basic Encoding Rules (BER)
   encoding.  Single-pass operation is especially helpful if content is
   large, stored on tapes, or is "piped" from another process.  Single-



Housley                     Standards Track                     [Page 4]

RFC 2630              Cryptographic Message Syntax             June 1999


   pass operation has one significant drawback: it is difficult to
   perform encode operations using the Distinguished Encoding Rules
   (DER) [X.509-88] encoding in a single pass since the lengths of the
   various components may not be known in advance.  However, signed
   attributes within the signed-data content type and authenticated
   attributes within the authenticated-data content type require DER
   encoding.  Signed attributes and authenticated attributes must be
   transmitted in DER form to ensure that recipients can verify a
   content that contains one or more unrecognized attributes.  Signed
   attributes and authenticated attributes are the only CMS data types
   that require DER encoding.

3  General Syntax

   The Cryptographic Message Syntax (CMS) associates a content type
   identifier with a content.  The syntax shall have ASN.1 type
   ContentInfo:

      ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

      ContentType ::= OBJECT IDENTIFIER

   The fields of ContentInfo have the following meanings:

      contentType indicates the type of the associated content.  It is
      an object identifier; it is a unique string of integers assigned
      by an authority that defines the content type.

      content is the associated content.  The type of content can be
      determined uniquely by contentType.  Content types for data,
      signed-data, enveloped-data, digested-data, encrypted-data, and
      authenticated-data are defined in this document.  If additional
      content types are defined in other documents, the ASN.1 type
      defined should not be a CHOICE type.

4  Data Content Type

   The following object identifier identifies the data content type:

      id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   The data content type is intended to refer to arbitrary octet
   strings, such as ASCII text files; the interpretation is left to the
   application.  Such strings need not have any internal structure




Housley                     Standards Track                     [Page 5]

RFC 2630              Cryptographic Message Syntax             June 1999


   (although they could have their own ASN.1 definition or other
   structure).

   The data content type is generally encapsulated in the signed-data,
   enveloped-data, digested-data, encrypted-data, or authenticated-data
   content type.

5  Signed-data Content Type

   The signed-data content type consists of a content of any type and
   zero or more signature values.  Any number of signers in parallel can
   sign any type of content.

   The typical application of the signed-data content type represents
   one signer's digital signature on content of the data content type.
   Another typical application disseminates certificates and certificate
   revocation lists (CRLs).

   The process by which signed-data is constructed involves the
   following steps:

      1.  For each signer, a message digest, or hash value, is computed
      on the content with a signer-specific message-digest algorithm.
      If the signer is signing any information other than the content,
      the message digest of the content and the other information are
      digested with the signer's message digest algorithm (see Section
      5.4), and the result becomes the "message digest."

      2.  For each signer, the message digest is digitally signed using
      the signer's private key.

      3.  For each signer, the signature value and other signer-specific
      information are collected into a SignerInfo value, as defined in
      Section 5.3.  Certificates and CRLs for each signer, and those not
      corresponding to any signer, are collected in this step.

      4.  The message digest algorithms for all the signers and the
      SignerInfo values for all the signers are collected together with
      the content into a SignedData value, as defined in Section 5.1.

   A recipient independently computes the message digest.  This message
   digest and the signer's public key are used to verify the signature
   value.  The signer's public key is referenced either by an issuer
   distinguished name along with an issuer-specific serial number or by
   a subject key identifier that uniquely identifies the certificate
   containing the public key.  The signer's certificate may be included
   in the SignedData certificates field.




Housley                     Standards Track                     [Page 6]

RFC 2630              Cryptographic Message Syntax             June 1999


   This section is divided into six parts.  The first part describes the
   top-level type SignedData, the second part describes
   EncapsulatedContentInfo, the third part describes the per-signer
   information type SignerInfo, and the fourth, fifth, and sixth parts
   describe the message digest calculation, signature generation, and
   signature verification processes, respectively.

5.1  SignedData Type

   The following object identifier identifies the signed-data content
   type:

      id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

   The signed-data content type shall have ASN.1 type SignedData:

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
        signerInfos SignerInfos }

      DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

      SignerInfos ::= SET OF SignerInfo

   The fields of type SignedData have the following meanings:

      version is the syntax version number.  If no attribute
      certificates are present in the certificates field, the
      encapsulated content type is id-data, and all of the elements of
      SignerInfos are version 1, then the value of version shall be 1.
      Alternatively, if attribute certificates are present, the
      encapsulated content type is other than id-data, or any of the
      elements of SignerInfos are version 3, then the value of version
      shall be 3.

      digestAlgorithms is a collection of message digest algorithm
      identifiers.  There may be any number of elements in the
      collection, including zero.  Each element identifies the message
      digest algorithm, along with any associated parameters, used by
      one or more signer.  The collection is intended to list the
      message digest algorithms employed by all of the signers, in any
      order, to facilitate one-pass signature verification.  The message
      digesting process is described in Section 5.4.



Housley                     Standards Track                     [Page 7]

RFC 2630              Cryptographic Message Syntax             June 1999


      encapContentInfo is the signed content, consisting of a content
      type identifier and the content itself.  Details of the
      EncapsulatedContentInfo type are discussed in section 5.2.

      certificates is a collection of certificates.  It is intended that
      the set of certificates be sufficient to contain chains from a
      recognized "root" or "top-level certification authority" to all of
      the signers in the signerInfos field.  There may be more
      certificates than necessary, and there may be certificates
      sufficient to contain chains from two or more independent top-
      level certification authorities.  There may also be fewer
      certificates than necessary, if it is expected that recipients
      have an alternate means of obtaining necessary certificates (e.g.,
      from a previous set of certificates).  As discussed above, if
      attribute certificates are present, then the value of version
      shall be 3.

      crls is a collection of certificate revocation lists (CRLs).  It
      is intended that the set contain information sufficient to
      determine whether or not the certificates in the certificates
      field are valid, but such correspondence is not necessary.  There
      may be more CRLs than necessary, and there may also be fewer CRLs
      than necessary.

      signerInfos is a collection of per-signer information.  There may
      be any number of elements in the collection, including zero.  The
      details of the SignerInfo type are discussed in section 5.3.

5.2  EncapsulatedContentInfo Type

   The content is represented in the type EncapsulatedContentInfo:

      EncapsulatedContentInfo ::= SEQUENCE {
        eContentType ContentType,
        eContent [0] EXPLICIT OCTET STRING OPTIONAL }

      ContentType ::= OBJECT IDENTIFIER

   The fields of type EncapsulatedContentInfo have the following
   meanings:

      eContentType is an object identifier that uniquely specifies the
      content type.

      eContent is the content itself, carried as an octet string.  The
      eContent need not be DER encoded.





Housley                     Standards Track                     [Page 8]

RFC 2630              Cryptographic Message Syntax             June 1999


   The optional omission of the eContent within the
   EncapsulatedContentInfo field makes it possible to construct
   "external signatures."  In the case of external signatures, the
   content being signed is absent from the EncapsulatedContentInfo value
   included in the signed-data content type.  If the eContent value
   within EncapsulatedContentInfo is absent, then the signatureValue is
   calculated and the eContentType is assigned as though the eContent
   value was present.

   In the degenerate case where there are no signers, the
   EncapsulatedContentInfo value being "signed" is irrelevant.  In this
   case, the content type within the EncapsulatedContentInfo value being
   "signed" should be id-data (as defined in section 4), and the content
   field of the EncapsulatedContentInfo value should be omitted.

5.3  SignerInfo Type

   Per-signer information is represented in the type SignerInfo:

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

      SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

      SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

      AttributeValue ::= ANY

      SignatureValue ::= OCTET STRING

   The fields of type SignerInfo have the following meanings:

      version is the syntax version number.  If the SignerIdentifier is
      the CHOICE issuerAndSerialNumber, then the version shall be 1.  If



Housley                     Standards Track                     [Page 9]

RFC 2630              Cryptographic Message Syntax             June 1999


      the SignerIdentifier is subjectKeyIdentifier, then the version
      shall be 3.

      sid specifies the signer's certificate (and thereby the signer's
      public key).  The signer's public key is needed by the recipient
      to verify the signature.  SignerIdentifier provides two
      alternatives for specifying the signer's public key.  The
      issuerAndSerialNumber alternative identifies the signer's
      certificate by the issuer's distinguished name and the certificate
      serial number; the subjectKeyIdentifier identifies the signer's
      certificate by the X.509 subjectKeyIdentifier extension value.

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer.  The message digest is
      computed on either the content being signed or the content
      together with the signed attributes using the process described in
      section 5.4.  The message digest algorithm should be among those
      listed in the digestAlgorithms field of the associated SignerData.

      signedAttributes is a collection of attributes that are signed.
      The field is optional, but it must be present if the content type
      of the EncapsulatedContentInfo value being signed is not id-data.
      Each SignedAttribute in the SET must be DER encoded.  Useful
      attribute types, such as signing time, are defined in Section 11.
      If the field is present, it must contain, at a minimum, the
      following two attributes:

         A content-type attribute having as its value the content type
         of the EncapsulatedContentInfo value being signed.  Section
         11.1 defines the content-type attribute.  The content-type
         attribute is not required when used as part of a
         countersignature unsigned attribute as defined in section 11.4.

         A message-digest attribute, having as its value the message
         digest of the content.  Section 11.2 defines the message-digest
         attribute.

      signatureAlgorithm identifies the signature algorithm, and any
      associated parameters, used by the signer to generate the digital
      signature.

      signature is the result of digital signature generation, using the
      message digest and the signer's private key.

      unsignedAttributes is a collection of attributes that are not
      signed.  The field is optional.  Useful attribute types, such as
      countersignatures, are defined in Section 11.




Housley                     Standards Track                    [Page 10]

RFC 2630              Cryptographic Message Syntax             June 1999


   The fields of type SignedAttribute and UnsignedAttribute have the
   following meanings:

      attrType indicates the type of attribute.  It is an object
      identifier.

      attrValues is a set of values that comprise the attribute.  The
      type of each value in the set can be determined uniquely by
      attrType.

5.4  Message Digest Calculation Process

   The message digest calculation process computes a message digest on
   either the content being signed or the content together with the
   signed attributes.  In either case, the initial input to the message
   digest calculation process is the "value" of the encapsulated content
   being signed.  Specifically, the initial input is the
   encapContentInfo eContent OCTET STRING to which the signing process
   is applied.  Only the octets comprising the value of the eContent
   OCTET STRING are input to the message digest algorithm, not the tag
   or the length octets.

   The result of the message digest calculation process depends on
   whether the signedAttributes field is present.  When the field is
   absent, the result is just the message digest of the content as
   described above.  When the field is present, however, the result is
   the message digest of the complete DER encoding of the
   SignedAttributes value contained in the signedAttributes field.
   Since the SignedAttributes value, when present, must contain the
   content type and the content message digest attributes, those values
   are indirectly included in the result.  The content type attribute is
   not required when used as part of a countersignature unsigned
   attribute as defined in section 11.4.  A separate encoding of the
   signedAttributes field is performed for message digest calculation.
   The IMPLICIT [0] tag in the signedAttributes field is not used for
   the DER encoding, rather an EXPLICIT SET OF tag is used.  That is,
   the DER encoding of the SET OF tag, rather than of the IMPLICIT [0]
   tag, is to be included in the message digest calculation along with
   the length and content octets of the SignedAttributes value.

   When the signedAttributes field is absent, then only the octets
   comprising the value of the signedData encapContentInfo eContent
   OCTET STRING (e.g., the contents of a file) are input to the message
   digest calculation.  This has the advantage that the length of the
   content being signed need not be known in advance of the signature
   generation process.





Housley                     Standards Track                    [Page 11]

RFC 2630              Cryptographic Message Syntax             June 1999


   Although the encapContentInfo eContent OCTET STRING tag and length
   octets are not included in the message digest calculation, they are
   still protected by other means.  The length octets are protected by
   the nature of the message digest algorithm since it is
   computationally infeasible to find any two distinct messages of any
   length that have the same message digest.

5.5  Message Signature Generation Process

   The input to the signature generation process includes the result of
   the message digest calculation process and the signer's private key.
   The details of the signature generation depend on the signature
   algorithm employed.  The object identifier, along with any
   parameters, that specifies the signature algorithm employed by the
   signer is carried in the signatureAlgorithm field.  The signature
   value generated by the signer is encoded as an OCTET STRING and
   carried in the signature field.

5.6  Message Signature Verification Process

   The input to the signature verification process includes the result
   of the message digest calculation process and the signer's public
   key.  The recipient may obtain the correct public key for the signer
   by any means, but the preferred method is from a certificate obtained
   from the SignedData certificates field.  The selection and validation
   of the signer's public key may be based on certification path
   validation (see [PROFILE]) as well as other external context, but is
   beyond the scope of this document.  The details of the signature
   verification depend on the signature algorithm employed.

   The recipient may not rely on any message digest values computed by
   the originator.  If the signedData signerInfo includes
   signedAttributes, then the content message digest must be calculated
   as described in section 5.4.  For the signature to be valid, the
   message digest value calculated by the recipient must be the same as
   the value of the messageDigest attribute included in the
   signedAttributes of the signedData signerInfo.

6  Enveloped-data Content Type

   The enveloped-data content type consists of an encrypted content of
   any type and encrypted content-encryption keys for one or more
   recipients.  The combination of the encrypted content and one
   encrypted content-encryption key for a recipient is a "digital
   envelope" for that recipient.  Any type of content can be enveloped
   for an arbitrary number of recipients using any of the three key
   management techniques for each recipient.




Housley                     Standards Track                    [Page 12]

RFC 2630              Cryptographic Message Syntax             June 1999


   The typical application of the enveloped-data content type will
   represent one or more recipients' digital envelopes on content of the
   data or signed-data content types.

   Enveloped-data is constructed by the following steps:

      1.  A content-encryption key for a particular content-encryption
      algorithm is generated at random.

      2.  The content-encryption key is encrypted for each recipient.
      The details of this encryption depend on the key management
      algorithm used, but three general techniques are supported:

         key transport:  the content-encryption key is encrypted in the
         recipient's public key;

         key agreement:  the recipient's public key and the sender's
         private key are used to generate a pairwise symmetric key, then
         the content-encryption key is encrypted in the pairwise
         symmetric key; and

         symmetric key-encryption keys:  the content-encryption key is
         encrypted in a previously distributed symmetric key-encryption
         key.

      3.  For each recipient, the encrypted content-encryption key and
      other recipient-specific information are collected into a
      RecipientInfo value, defined in Section 6.2.

      4.  The content is encrypted with the content-encryption key.
      Content encryption may require that the content be padded to a
      multiple of some block size; see Section 6.3.

      5.  The RecipientInfo values for all the recipients are collected
      together with the encrypted content to form an EnvelopedData value
      as defined in Section 6.1.

   A recipient opens the digital envelope by decrypting one of the
   encrypted content-encryption keys and then decrypting the encrypted
   content with the recovered content-encryption key.

   This section is divided into four parts.  The first part describes
   the top-level type EnvelopedData, the second part describes the per-
   recipient information type RecipientInfo, and the third and fourth
   parts describe the content-encryption and key-encryption processes.






Housley                     Standards Track                    [Page 13]

RFC 2630              Cryptographic Message Syntax             June 1999


6.1  EnvelopedData Type

   The following object identifier identifies the enveloped-data content
   type:

      id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

   The enveloped-data content type shall have ASN.1 type EnvelopedData:

      EnvelopedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

      OriginatorInfo ::= SEQUENCE {
        certs [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }

      RecipientInfos ::= SET OF RecipientInfo

      EncryptedContentInfo ::= SEQUENCE {
        contentType ContentType,
        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

      EncryptedContent ::= OCTET STRING

      UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

   The fields of type EnvelopedData have the following meanings:

      version is the syntax version number.  If originatorInfo is
      present, then version shall be 2.  If any of the RecipientInfo
      structures included have a version other than 0, then the version
      shall be 2.  If unprotectedAttrs is present, then version shall be
      2.  If originatorInfo is absent, all of the RecipientInfo
      structures are version 0, and unprotectedAttrs is absent, then
      version shall be 0.

      originatorInfo optionally provides information about the
      originator.  It is present only if required by the key management
      algorithm.  It may contain certificates and CRLs:

         certs is a collection of certificates.  certs may contain
         originator certificates associated with several different key



Housley                     Standards Track                    [Page 14]

RFC 2630              Cryptographic Message Syntax             June 1999


         management algorithms.  certs may also contain attribute
         certificates associated with the originator.  The certificates
         contained in certs are intended to be sufficient to make chains
         from a recognized "root" or "top-level certification authority"
         to all recipients.  However, certs may contain more
         certificates than necessary, and there may be certificates
         sufficient to make chains from two or more independent top-
         level certification authorities.  Alternatively, certs may
         contain fewer certificates than necessary, if it is expected
         that recipients have an alternate means of obtaining necessary
         certificates (e.g., from a previous set of certificates).

         crls is a collection of CRLs.  It is intended that the set
         contain information sufficient to determine whether or not the
         certificates in the certs field are valid, but such
         correspondence is not necessary.  There may be more CRLs than
         necessary, and there may also be fewer CRLs than necessary.

      recipientInfos is a collection of per-recipient information.
      There must be at least one element in the collection.

      encryptedContentInfo is the encrypted content information.

      unprotectedAttrs is a collection of attributes that are not
      encrypted.  The field is optional.  Useful attribute types are
      defined in Section 11.

   The fields of type EncryptedContentInfo have the following meanings:

      contentType indicates the type of content.

      contentEncryptionAlgorithm identifies the content-encryption
      algorithm, and any associated parameters, used to encrypt the
      content.  The content-encryption process is described in Section
      6.3.  The same content-encryption algorithm and content-encryption
      key is used for all recipients.

      encryptedContent is the result of encrypting the content.  The
      field is optional, and if the field is not present, its intended
      value must be supplied by other means.

   The recipientInfos field comes before the encryptedContentInfo field
   so that an EnvelopedData value may be processed in a single pass.

6.2  RecipientInfo Type

   Per-recipient information is represented in the type RecipientInfo.
   RecipientInfo has a different format for the three key management



Housley                     Standards Track                    [Page 15]

RFC 2630              Cryptographic Message Syntax             June 1999


   techniques that are supported: key transport, key agreement, and
   previously distributed symmetric key-encryption keys.  Any of the
   three key management techniques can be used for each recipient of the
   same encrypted content.  In all cases, the content-encryption key is
   transferred to one or more recipient in encrypted form.

      RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo }

      EncryptedKey ::= OCTET STRING

6.2.1  KeyTransRecipientInfo Type

   Per-recipient information using key transport is represented in the
   type KeyTransRecipientInfo.  Each instance of KeyTransRecipientInfo
   transfers the content-encryption key to one recipient.

      KeyTransRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 0 or 2
        rid RecipientIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

      RecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

   The fields of type KeyTransRecipientInfo have the following meanings:

      version is the syntax version number.  If the RecipientIdentifier
      is the CHOICE issuerAndSerialNumber, then the version shall be 0.
      If the RecipientIdentifier is subjectKeyIdentifier, then the
      version shall be 2.

      rid specifies the recipient's certificate or key that was used by
      the sender to protect the content-encryption key.  The
      RecipientIdentifier provides two alternatives for specifying the
      recipient's certificate, and thereby the recipient's public key.
      The recipient's certificate must contain a key transport public
      key.  The content-encryption key is encrypted with the recipient's
      public key.  The issuerAndSerialNumber alternative identifies the
      recipient's certificate by the issuer's distinguished name and the
      certificate serial number; the subjectKeyIdentifier identifies the
      recipient's certificate by the X.509 subjectKeyIdentifier
      extension value.




Housley                     Standards Track                    [Page 16]

RFC 2630              Cryptographic Message Syntax             June 1999


      keyEncryptionAlgorithm identifies the key-encryption algorithm,
      and any associated parameters, used to encrypt the content-
      encryption key for the recipient.  The key-encryption process is
      described in Section 6.4.

      encryptedKey is the result of encrypting the content-encryption
      key for the recipient.

6.2.2  KeyAgreeRecipientInfo Type

   Recipient information using key agreement is represented in the type
   KeyAgreeRecipientInfo.  Each instance of KeyAgreeRecipientInfo will
   transfer the content-encryption key to one or more recipient that
   uses the same key agreement algorithm and domain parameters for that
   algorithm.

      KeyAgreeRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 3
        originator [0] EXPLICIT OriginatorIdentifierOrKey,
        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        recipientEncryptedKeys RecipientEncryptedKeys }

      OriginatorIdentifierOrKey ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier,
        originatorKey [1] OriginatorPublicKey }

      OriginatorPublicKey ::= SEQUENCE {
        algorithm AlgorithmIdentifier,
        publicKey BIT STRING }

      RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

      RecipientEncryptedKey ::= SEQUENCE {
        rid KeyAgreeRecipientIdentifier,
        encryptedKey EncryptedKey }

      KeyAgreeRecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        rKeyId [0] IMPLICIT RecipientKeyIdentifier }

      RecipientKeyIdentifier ::= SEQUENCE {
        subjectKeyIdentifier SubjectKeyIdentifier,
        date GeneralizedTime OPTIONAL,
        other OtherKeyAttribute OPTIONAL }

      SubjectKeyIdentifier ::= OCTET STRING



Housley                     Standards Track                    [Page 17]

RFC 2630              Cryptographic Message Syntax             June 1999


   The fields of type KeyAgreeRecipientInfo have the following meanings:

      version is the syntax version number.  It shall always be 3.

      originator is a CHOICE with three alternatives specifying the
      sender's key agreement public key.  The sender uses the
      corresponding private key and the recipient's public key to
      generate a pairwise key.  The content-encryption key is encrypted
      in the pairwise key.  The issuerAndSerialNumber alternative
      identifies the sender's certificate, and thereby the sender's
      public key, by the issuer's distinguished name and the certificate
      serial number.  The subjectKeyIdentifier alternative identifies
      the sender's certificate, and thereby the sender's public key, by
      the X.509 subjectKeyIdentifier extension value.  The originatorKey
      alternative includes the algorithm identifier and sender's key
      agreement public key. Permitting originator anonymity since the
      public key is not certified.

      ukm is optional.  With some key agreement algorithms, the sender
      provides a User Keying Material (UKM) to ensure that a different
      key is generated each time the same two parties generate a
      pairwise key.

      keyEncryptionAlgorithm identifies the key-encryption algorithm,
      and any associated parameters, used to encrypt the content-
      encryption key in the key-encryption key.  The key-encryption
      process is described in Section 6.4.

      recipientEncryptedKeys includes a recipient identifier and
      encrypted key for one or more recipients.  The
      KeyAgreeRecipientIdentifier is a CHOICE with two alternatives
      specifying the recipient's certificate, and thereby the
      recipient's public key, that was used by the sender to generate a
      pairwise key-encryption key.  The recipient's certificate must
      contain a key agreement public key.  The content-encryption key is
      encrypted in the pairwise key-encryption key.  The
      issuerAndSerialNumber alternative identifies the recipient's
      certificate by the issuer's distinguished name and the certificate
      serial number; the RecipientKeyIdentifier is described below.  The
      encryptedKey is the result of encrypting the content-encryption
      key in the pairwise key-encryption key generated using the key
      agreement algorithm.

   The fields of type RecipientKeyIdentifier have the following
   meanings:

      subjectKeyIdentifier identifies the recipient's certificate by the
      X.509 subjectKeyIdentifier extension value.



Housley                     Standards Track                    [Page 18]

RFC 2630              Cryptographic Message Syntax             June 1999


      date is optional.  When present, the date specifies which of the
      recipient's previously distributed UKMs was used by the sender.

      other is optional.  When present, this field contains additional
      information used by the recipient to locate the public keying
      material used by the sender.

6.2.3  KEKRecipientInfo Type

   Recipient information using previously distributed symmetric keys is
   represented in the type KEKRecipientInfo.  Each instance of
   KEKRecipientInfo will transfer the content-encryption key to one or
   more recipients who have the previously distributed key-encryption
   key.

      KEKRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 4
        kekid KEKIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

      KEKIdentifier ::= SEQUENCE {
        keyIdentifier OCTET STRING,
        date GeneralizedTime OPTIONAL,
        other OtherKeyAttribute OPTIONAL }

   The fields of type KEKRecipientInfo have the following meanings:

      version is the syntax version number.  It shall always be 4.

      kekid specifies a symmetric key-encryption key that was previously
      distributed to the sender and one or more recipients.

      keyEncryptionAlgorithm identifies the key-encryption algorithm,
      and any associated parameters, used to encrypt the content-
      encryption key with the key-encryption key.  The key-encryption
      process is described in Section 6.4.

      encryptedKey is the result of encrypting the content-encryption
      key in the key-encryption key.

   The fields of type KEKIdentifier have the following meanings:

      keyIdentifier identifies the key-encryption key that was
      previously distributed to the sender and one or more recipients.

      date is optional.  When present, the date specifies a single key-
      encryption key from a set that was previously distributed.



Housley                     Standards Track                    [Page 19]

RFC 2630              Cryptographic Message Syntax             June 1999


      other is optional.  When present, this field contains additional
      information used by the recipient to determine the key-encryption
      key used by the sender.

6.3  Content-encryption Process

   The content-encryption key for the desired content-encryption
   algorithm is randomly generated.  The data to be protected is padded
   as described below, then the padded data is encrypted using the
   content-encryption key.  The encryption operation maps an arbitrary
   string of octets (the data) to another string of octets (the
   ciphertext) under control of a content-encryption key.  The encrypted
   data is included in the envelopedData encryptedContentInfo
   encryptedContent OCTET STRING.

   The input to the content-encryption process is the "value" of the
   content being enveloped.  Only the value octets of the envelopedData
   encryptedContentInfo encryptedContent OCTET STRING are encrypted; the
   OCTET STRING tag and length octets are not encrypted.

   Some content-encryption algorithms assume the input length is a
   multiple of k octets, where k is greater than one.  For such
   algorithms, the input shall be padded at the trailing end with
   k-(lth mod k) octets all having value k-(lth mod k), where lth is
   the length of the input.  In other words, the input is padded at
   the trailing end with one of the following strings:

                     01 -- if lth mod k = k-1
                  02 02 -- if lth mod k = k-2
                      .
                      .
                      .
            k k ... k k -- if lth mod k = 0

   The padding can be removed unambiguously since all input is padded,
   including input values that are already a multiple of the block size,
   and no padding string is a suffix of another.  This padding method is
   well defined if and only if k is less than 256.

6.4  Key-encryption Process

   The input to the key-encryption process -- the value supplied to the
   recipient's key-encryption algorithm -- is just the "value" of the
   content-encryption key.

   Any of the three key management techniques can be used for each
   recipient of the same encrypted content.




Housley                     Standards Track                    [Page 20]

RFC 2630              Cryptographic Message Syntax             June 1999


7  Digested-data Content Type

   The digested-data content type consists of content of any type and a
   message digest of the content.

   Typically, the digested-data content type is used to provide content
   integrity, and the result generally becomes an input to the
   enveloped-data content type.

   The following steps construct digested-data:

      1.  A message digest is computed on the content with a message-
      digest algorithm.

      2.  The message-digest algorithm and the message digest are
      collected together with the content into a DigestedData value.

   A recipient verifies the message digest by comparing the message
   digest to an independently computed message digest.

   The following object identifier identifies the digested-data content
   type:

      id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

   The digested-data content type shall have ASN.1 type DigestedData:

      DigestedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithm DigestAlgorithmIdentifier,
        encapContentInfo EncapsulatedContentInfo,
        digest Digest }

      Digest ::= OCTET STRING

   The fields of type DigestedData have the following meanings:

      version is the syntax version number.  If the encapsulated content
      type is id-data, then the value of version shall be 0; however, if
      the encapsulated content type is other than id-data, then the
      value of version shall be 2.

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, under which the content is digested.  The
      message-digesting process is the same as in Section 5.4 in the
      case when there are no signed attributes.




Housley                     Standards Track                    [Page 21]

RFC 2630              Cryptographic Message Syntax             June 1999


      encapContentInfo is the content that is digested, as defined in
      section 5.2.

      digest is the result of the message-digesting process.

   The ordering of the digestAlgorithm field, the encapContentInfo
   field, and the digest field makes it possible to process a
   DigestedData value in a single pass.

8  Encrypted-data Content Type

   The encrypted-data content type consists of encrypted content of any
   type.  Unlike the enveloped-data content type, the encrypted-data
   content type has neither recipients nor encrypted content-encryption
   keys.  Keys must be managed by other means.

   The typical application of the encrypted-data content type will be to
   encrypt the content of the data content type for local storage,
   perhaps where the encryption key is a password.

   The following object identifier identifies the encrypted-data content
   type:

      id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

   The encrypted-data content type shall have ASN.1 type EncryptedData:

      EncryptedData ::= SEQUENCE {
        version CMSVersion,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

   The fields of type EncryptedData have the following meanings:

      version is the syntax version number.  If unprotectedAttrs is
      present, then version shall be 2.  If unprotectedAttrs is absent,
      then version shall be 0.

      encryptedContentInfo is the encrypted content information, as
      defined in Section 6.1.

      unprotectedAttrs is a collection of attributes that are not
      encrypted.  The field is optional.  Useful attribute types are
      defined in Section 11.






Housley                     Standards Track                    [Page 22]

RFC 2630              Cryptographic Message Syntax             June 1999


9  Authenticated-data Content Type

   The authenticated-data content type consists of content of any type,
   a message authentication code (MAC), and encrypted authentication
   keys for one or more recipients.  The combination of the MAC and one
   encrypted authentication key for a recipient is necessary for that
   recipient to verify the integrity of the content.  Any type of
   content can be integrity protected for an arbitrary number of
   recipients.

   The process by which authenticated-data is constructed involves the
   following steps:

      1.  A message-authentication key for a particular message-
      authentication algorithm is generated at random.

      2.  The message-authentication key is encrypted for each
      recipient.  The details of this encryption depend on the key
      management algorithm used.

      3.  For each recipient, the encrypted message-authentication key
      and other recipient-specific information are collected into a
      RecipientInfo value, defined in Section 6.2.

      4.  Using the message-authentication key, the originator computes
      a MAC value on the content.  If the originator is authenticating
      any information in addition to the content (see Section 9.2), a
      message digest is calculated on the content, the message digest of
      the content and the other information are authenticated using the
      message-authentication key, and the result becomes the "MAC
      value."

9.1  AuthenticatedData Type

   The following object identifier identifies the authenticated-data
   content type:

      id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
          ct(1) 2 }











Housley                     Standards Track                    [Page 23]

RFC 2630              Cryptographic Message Syntax             June 1999


   The authenticated-data content type shall have ASN.1 type
   AuthenticatedData:

      AuthenticatedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        macAlgorithm MessageAuthenticationCodeAlgorithm,
        digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
        encapContentInfo EncapsulatedContentInfo,
        authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
        mac MessageAuthenticationCode,
        unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }

      AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

      MessageAuthenticationCode ::= OCTET STRING

   The fields of type AuthenticatedData have the following meanings:

      version is the syntax version number.  It shall be 0.

      originatorInfo optionally provides information about the
      originator.  It is present only if required by the key management
      algorithm.  It may contain certificates, attribute certificates,
      and CRLs, as defined in Section 6.1.

      recipientInfos is a collection of per-recipient information, as
      defined in Section 6.1.  There must be at least one element in the
      collection.

      macAlgorithm is a message authentication code (MAC) algorithm
      identifier.  It identifies the MAC algorithm, along with any
      associated parameters, used by the originator.  Placement of the
      macAlgorithm field facilitates one-pass processing by the
      recipient.

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used to compute a message digest on the
      encapsulated content if authenticated attributes are present.  The
      message digesting process is described in Section 9.2.  Placement
      of the digestAlgorithm field facilitates one-pass processing by
      the recipient.  If the digestAlgorithm field is present, then the
      authenticatedAttributes field must also be present.





Housley                     Standards Track                    [Page 24]

RFC 2630              Cryptographic Message Syntax             June 1999


      encapContentInfo is the content that is authenticated, as defined
      in section 5.2.

      authenticatedAttributes is a collection of authenticated
      attributes.  The authenticatedAttributes structure is optional,
      but it must be present if the content type of the
      EncapsulatedContentInfo value being authenticated is not id-data.
      If the authenticatedAttributes field is present, then the
      digestAlgorithm field must also be present.  Each
      AuthenticatedAttribute in the SET must be DER encoded.  Useful
      attribute types are defined in Section 11.  If the
      authenticatedAttributes field is present, it must contain, at a
      minimum, the following two attributes:

         A content-type attribute having as its value the content type
         of the EncapsulatedContentInfo value being authenticated.
         Section 11.1 defines the content-type attribute.

         A message-digest attribute, having as its value the message
         digest of the content.  Section 11.2 defines the message-digest
         attribute.

      mac is the message authentication code.

      unauthenticatedAttributes is a collection of attributes that are
      not authenticated.  The field is optional.  To date, no attributes
      have been defined for use as unauthenticated attributes, but other
      useful attribute types are defined in Section 11.

9.2  MAC Generation

   The MAC calculation process computes a message authentication code
   (MAC) on either the message being authenticated or a message digest
   of message being authenticated together with the originator's
   authenticated attributes.

   If authenticatedAttributes field is absent, the input to the MAC
   calculation process is the value of the encapContentInfo eContent
   OCTET STRING.  Only the octets comprising the value of the eContent
   OCTET STRING are input to the MAC algorithm; the tag and the length
   octets are omitted.  This has the advantage that the length of the
   content being authenticated need not be known in advance of the MAC
   generation process.

   If authenticatedAttributes field is present, the content-type
   attribute (as described in Section 11.1) and the message-digest
   attribute (as described in section 11.2) must be included, and the
   input to the MAC calculation process is the DER encoding of



Housley                     Standards Track                    [Page 25]

RFC 2630              Cryptographic Message Syntax             June 1999


   authenticatedAttributes.  A separate encoding of the
   authenticatedAttributes field is performed for message digest
   calculation.  The IMPLICIT [2] tag in the authenticatedAttributes
   field is not used for the DER encoding, rather an EXPLICIT SET OF tag
   is used.  That is, the DER encoding of the SET OF tag, rather than of
   the IMPLICIT [2] tag, is to be included in the message digest
   calculation along with the length and content octets of the
   authenticatedAttributes value.

   The message digest calculation process computes a message digest on
   the content being authenticated.  The initial input to the message
   digest calculation process is the "value" of the encapsulated content
   being authenticated.  Specifically, the input is the encapContentInfo
   eContent OCTET STRING to which the authentication process is applied.
   Only the octets comprising the value of the encapContentInfo eContent
   OCTET STRING are input to the message digest algorithm, not the tag
   or the length octets.  This has the advantage that the length of the
   content being authenticated need not be known in advance.  Although
   the encapContentInfo eContent OCTET STRING tag and length octets are
   not included in the message digest calculation, they are still
   protected by other means.  The length octets are protected by the
   nature of the message digest algorithm since it is computationally
   infeasible to find any two distinct messages of any length that have
   the same message digest.

   The input to the MAC calculation process includes the MAC input data,
   defined above, and an authentication key conveyed in a recipientInfo
   structure.  The details of MAC calculation depend on the MAC
   algorithm employed (e.g., HMAC).  The object identifier, along with
   any parameters, that specifies the MAC algorithm employed by the
   originator is carried in the macAlgorithm field.  The MAC value
   generated by the originator is encoded as an OCTET STRING and carried
   in the mac field.

9.3  MAC Verification

   The input to the MAC verification process includes the input data
   (determined based on the presence or absence of the
   authenticatedAttributes field, as defined in 9.2), and the
   authentication key conveyed in recipientInfo.  The details of the MAC
   verification process depend on the MAC algorithm employed.

   The recipient may not rely on any MAC values or message digest values
   computed by the originator.  The content is authenticated as
   described in section 9.2.  If the originator includes authenticated
   attributes, then the content of the authenticatedAttributes is
   authenticated as described in section 9.2.  For authentication to
   succeed, the message MAC value calculated by the recipient must be



Housley                     Standards Track                    [Page 26]

RFC 2630              Cryptographic Message Syntax             June 1999


   the same as the value of the mac field.  Similarly, for
   authentication to succeed when the authenticatedAttributes field is
   present, the content message digest value calculated by the recipient
   must be the same as the message digest value included in the
   authenticatedAttributes message-digest attribute.

10  Useful Types

   This section is divided into two parts.  The first part defines
   algorithm identifiers, and the second part defines other useful
   types.

10.1  Algorithm Identifier Types

   All of the algorithm identifiers have the same type:
   AlgorithmIdentifier.  The definition of AlgorithmIdentifier is
   imported from X.509 [X.509-88].

   There are many alternatives for each type of algorithm listed.  For
   each of these five types, Section 12 lists the algorithms that must
   be included in a CMS implementation.

10.1.1  DigestAlgorithmIdentifier

   The DigestAlgorithmIdentifier type identifies a message-digest
   algorithm.  Examples include SHA-1, MD2, and MD5.  A message-digest
   algorithm maps an octet string (the message) to another octet string
   (the message digest).

      DigestAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.2  SignatureAlgorithmIdentifier

   The SignatureAlgorithmIdentifier type identifies a signature
   algorithm.  Examples include DSS and RSA.  A signature algorithm
   supports signature generation and verification operations.  The
   signature generation operation uses the message digest and the
   signer's private key to generate a signature value.  The signature
   verification operation uses the message digest and the signer's
   public key to determine whether or not a signature value is valid.
   Context determines which operation is intended.

      SignatureAlgorithmIdentifier ::= AlgorithmIdentifier








Housley                     Standards Track                    [Page 27]

RFC 2630              Cryptographic Message Syntax             June 1999


10.1.3  KeyEncryptionAlgorithmIdentifier

   The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption
   algorithm used to encrypt a content-encryption key.  The encryption
   operation maps an octet string (the key) to another octet string (the
   encrypted key) under control of a key-encryption key.  The decryption
   operation is the inverse of the encryption operation.  Context
   determines which operation is intended.

   The details of encryption and decryption depend on the key management
   algorithm used.  Key transport, key agreement, and previously
   distributed symmetric key-encrypting keys are supported.

      KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.4  ContentEncryptionAlgorithmIdentifier

   The ContentEncryptionAlgorithmIdentifier type identifies a content-
   encryption algorithm.  Examples include Triple-DES and RC2.  A
   content-encryption algorithm supports encryption and decryption
   operations.  The encryption operation maps an octet string (the
   message) to another octet string (the ciphertext) under control of a
   content-encryption key.  The decryption operation is the inverse of
   the encryption operation.  Context determines which operation is
   intended.

      ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.5  MessageAuthenticationCodeAlgorithm

   The MessageAuthenticationCodeAlgorithm type identifies a message
   authentication code (MAC) algorithm.  Examples include DES-MAC and
   HMAC.  A MAC algorithm supports generation and verification
   operations.  The MAC generation and verification operations use the
   same symmetric key.  Context determines which operation is intended.

      MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

10.2  Other Useful Types

   This section defines types that are used other places in the
   document.  The types are not listed in any particular order.

10.2.1  CertificateRevocationLists

   The CertificateRevocationLists type gives a set of certificate
   revocation lists (CRLs). It is intended that the set contain
   information sufficient to determine whether the certificates and



Housley                     Standards Track                    [Page 28]

RFC 2630              Cryptographic Message Syntax             June 1999


   attribute certificates with which the set is associated are revoked
   or not.  However, there may be more CRLs than necessary or there may
   be fewer CRLs than necessary.

   The CertificateList may contain a CRL, an Authority Revocation List
   (ARL), a Delta Revocation List, or an Attribute Certificate
   Revocation List.  All of these lists share a common syntax.

   CRLs are specified in X.509 [X.509-97], and they are profiled for use
   in the Internet in RFC 2459 [PROFILE].

   The definition of CertificateList is imported from X.509.

      CertificateRevocationLists ::= SET OF CertificateList

10.2.2  CertificateChoices

   The CertificateChoices type gives either a PKCS #6 extended
   certificate [PKCS#6], an X.509 certificate, or an X.509 attribute
   certificate [X.509-97].  The PKCS #6 extended certificate is
   obsolete.  PKCS #6 certificates are included for backward
   compatibility, and their use should be avoided.  The Internet profile
   of X.509 certificates is specified in the "Internet X.509 Public Key
   Infrastructure: Certificate and CRL Profile" [PROFILE].

   The definitions of Certificate and AttributeCertificate are imported
   from X.509.

      CertificateChoices ::= CHOICE {
         certificate Certificate,                 -- See X.509
         extendedCertificate [0] IMPLICIT ExtendedCertificate,
                                                  -- Obsolete
         attrCert [1] IMPLICIT AttributeCertificate }
                                                  -- See X.509 and X9.57

10.2.3  CertificateSet

   The CertificateSet type provides a set of certificates.  It is
   intended that the set be sufficient to contain chains from a
   recognized "root" or "top-level certification authority" to all of
   the sender certificates with which the set is associated.  However,
   there may be more certificates than necessary, or there may be fewer
   than necessary.

   The precise meaning of a "chain" is outside the scope of this
   document.  Some applications may impose upper limits on the length of
   a chain; others may enforce certain relationships between the
   subjects and issuers of certificates within a chain.



Housley                     Standards Track                    [Page 29]

RFC 2630              Cryptographic Message Syntax             June 1999


      CertificateSet ::= SET OF CertificateChoices

10.2.4  IssuerAndSerialNumber

   The IssuerAndSerialNumber type identifies a certificate, and thereby
   an entity and a public key, by the distinguished name of the
   certificate issuer and an issuer-specific certificate serial number.

   The definition of Name is imported from X.501 [X.501-88], and the
   definition of CertificateSerialNumber is imported from X.509
   [X.509-97].

      IssuerAndSerialNumber ::= SEQUENCE {
        issuer Name,
        serialNumber CertificateSerialNumber }

      CertificateSerialNumber ::= INTEGER

10.2.5  CMSVersion

   The Version type gives a syntax version number, for compatibility
   with future revisions of this document.

      CMSVersion ::= INTEGER  { v0(0), v1(1), v2(2), v3(3), v4(4) }

10.2.6  UserKeyingMaterial

   The UserKeyingMaterial type gives a syntax for user keying material
   (UKM).  Some key agreement algorithms require UKMs to ensure that a
   different key is generated each time the same two parties generate a
   pairwise key.  The sender provides a UKM for use with a specific key
   agreement algorithm.

      UserKeyingMaterial ::= OCTET STRING

10.2.7  OtherKeyAttribute

   The OtherKeyAttribute type gives a syntax for the inclusion of other
   key attributes that permit the recipient to select the key used by
   the sender.  The attribute object identifier must be registered along
   with the syntax of the attribute itself.  Use of this structure
   should be avoided since it may impede interoperability.

      OtherKeyAttribute ::= SEQUENCE {
        keyAttrId OBJECT IDENTIFIER,
        keyAttr ANY DEFINED BY keyAttrId OPTIONAL }





Housley                     Standards Track                    [Page 30]

RFC 2630              Cryptographic Message Syntax             June 1999


11  Useful Attributes

   This section defines attributes that may be used with signed-data,
   enveloped-data, encrypted-data, or authenticated-data.  The syntax of
   Attribute is compatible with X.501 [X.501-88] and RFC 2459 [PROFILE].
   Some of the attributes defined in this section were originally
   defined in PKCS #9 [PKCS#9], others were not previously defined.  The
   attributes are not listed in any particular order.

   Additional attributes are defined in many places, notably the S/MIME
   Version 3 Message Specification [MSG] and the Enhanced Security
   Services for S/MIME [ESS], which also include recommendations on the
   placement of these attributes.

11.1  Content Type

   The content-type attribute type specifies the content type of the
   ContentInfo value being signed in signed-data.  The content-type
   attribute type is required if there are any authenticated attributes
   present.

   The content-type attribute must be a signed attribute or an
   authenticated attribute; it cannot be an unsigned attribute, an
   unauthenticated attribute, or an unprotectedAttribute.

   The following object identifier identifies the content-type
   attribute:

      id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

   Content-type attribute values have ASN.1 type ContentType:

      ContentType ::= OBJECT IDENTIFIER

   A content-type attribute must have a single attribute value, even
   though the syntax is defined as a SET OF AttributeValue.  There must
   not be zero or multiple instances of AttributeValue present.

   The SignedAttributes and AuthAttributes syntaxes are each defined as
   a SET OF Attributes.  The SignedAttributes in a signerInfo must not
   include multiple instances of the content-type attribute.  Similarly,
   the AuthAttributes in an AuthenticatedData must not include multiple
   instances of the content-type attribute.







Housley                     Standards Track                    [Page 31]

RFC 2630              Cryptographic Message Syntax             June 1999


11.2  Message Digest

   The message-digest attribute type specifies the message digest of the
   encapContentInfo eContent OCTET STRING being signed in signed-data
   (see section 5.4) or authenticated in authenticated-data (see section
   9.2).  For signed-data, the message digest is computed using the
   signer's message digest algorithm.  For authenticated-data, the
   message digest is computed using the originator's message digest
   algorithm.

   Within signed-data, the message-digest signed attribute type is
   required if there are any attributes present.  Within authenticated-
   data, the message-digest authenticated attribute type is required if
   there are any attributes present.

   The message-digest attribute must be a signed attribute or an
   authenticated attribute; it cannot be an unsigned attribute or an
   unauthenticated attribute.

   The following object identifier identifies the message-digest
   attribute:

      id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

   Message-digest attribute values have ASN.1 type MessageDigest:

      MessageDigest ::= OCTET STRING

   A message-digest attribute must have a single attribute value, even
   though the syntax is defined as a SET OF AttributeValue.  There must
   not be zero or multiple instances of AttributeValue present.

   The SignedAttributes syntax is defined as a SET OF Attributes.  The
   SignedAttributes in a signerInfo must not include multiple instances
   of the message-digest attribute.

11.3  Signing Time

   The signing-time attribute type specifies the time at which the
   signer (purportedly) performed the signing process.  The signing-time
   attribute type is intended for use in signed-data.

   The signing-time attribute may be a signed attribute; it cannot be an
   unsigned attribute, an authenticated attribute, or an unauthenticated
   attribute.





Housley                     Standards Track                    [Page 32]

RFC 2630              Cryptographic Message Syntax             June 1999


   The following object identifier identifies the signing-time
   attribute:

      id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

   Signing-time attribute values have ASN.1 type SigningTime:

      SigningTime ::= Time

      Time ::= CHOICE {
        utcTime          UTCTime,
        generalizedTime  GeneralizedTime }

   Note: The definition of Time matches the one specified in the 1997
   version of X.509 [X.509-97].

   Dates between 1 January 1950 and 31 December 2049 (inclusive) must be
   encoded as UTCTime.  Any dates with year values before 1950 or after
   2049 must be encoded as GeneralizedTime.

   UTCTime values must be expressed in Greenwich Mean Time (Zulu) and
   must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the
   number of seconds is zero.  Midnight (GMT) must be represented as
   "YYMMDD000000Z".  Century information is implicit, and the century
   must be determined as follows:

      Where YY is greater than or equal to 50, the year shall be
      interpreted as 19YY; and

      Where YY is less than 50, the year shall be interpreted as 20YY.

   GeneralizedTime values shall be expressed in Greenwich Mean Time
   (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ),
   even where the number of seconds is zero.  GeneralizedTime values
   must not include fractional seconds.

   A signing-time attribute must have a single attribute value, even
   though the syntax is defined as a SET OF AttributeValue.  There must
   not be zero or multiple instances of AttributeValue present.

   The SignedAttributes syntax is defined as a SET OF Attributes.  The
   SignedAttributes in a signerInfo must not include multiple instances
   of the signing-time attribute.

   No requirement is imposed concerning the correctness of the signing
   time, and acceptance of a purported signing time is a matter of a
   recipient's discretion.  It is expected, however, that some signers,



Housley                     Standards Track                    [Page 33]

RFC 2630              Cryptographic Message Syntax             June 1999


   such as time-stamp servers, will be trusted implicitly.

11.4  Countersignature

   The countersignature attribute type specifies one or more signatures
   on the contents octets of the DER encoding of the signatureValue
   field of a SignerInfo value in signed-data.  Thus, the
   countersignature attribute type countersigns (signs in serial)
   another signature.

   The countersignature attribute must be an unsigned attribute; it
   cannot be a signed attribute, an authenticated attribute, or an
   unauthenticated attribute.

   The following object identifier identifies the countersignature
   attribute:

      id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

   Countersignature attribute values have ASN.1 type Countersignature:

      Countersignature ::= SignerInfo

   Countersignature values have the same meaning as SignerInfo values
   for ordinary signatures, except that:

      1.  The signedAttributes field must contain a message-digest
      attribute if it contains any other attributes, but need not
      contain a content-type attribute, as there is no content type for
      countersignatures.

      2.  The input to the message-digesting process is the contents
      octets of the DER encoding of the signatureValue field of the
      SignerInfo value with which the attribute is associated.

   A countersignature attribute can have multiple attribute values.  The
   syntax is defined as a SET OF AttributeValue, and there must be one
   or more instances of AttributeValue present.

   The UnsignedAttributes syntax is defined as a SET OF Attributes.  The
   UnsignedAttributes in a signerInfo may include multiple instances of
   the countersignature attribute.

   A countersignature, since it has type SignerInfo, can itself contain
   a countersignature attribute.  Thus it is possible to construct
   arbitrarily long series of countersignatures.




Housley                     Standards Track                    [Page 34]

RFC 2630              Cryptographic Message Syntax             June 1999


12  Supported Algorithms

   This section lists the algorithms that must be implemented.
   Additional algorithms that should be implemented are also included.

12.1  Digest Algorithms

   CMS implementations must include SHA-1.  CMS implementations should
   include MD5.

   Digest algorithm identifiers are located in the SignedData
   digestAlgorithms field, the SignerInfo digestAlgorithm field, the
   DigestedData digestAlgorithm field, and the AuthenticatedData
   digestAlgorithm field.

   Digest values are located in the DigestedData digest field, and
   digest values are located in the Message Digest authenticated
   attribute.  In addition, digest values are input to signature
   algorithms.

12.1.1  SHA-1

   The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The
   algorithm identifier for SHA-1 is:

      sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
          oiw(14) secsig(3) algorithm(2) 26 }

   The AlgorithmIdentifier parameters field is optional.  If present,
   the parameters field must contain an ASN.1 NULL.  Implementations
   should accept SHA-1 AlgorithmIdentifiers with absent parameters as
   well as NULL parameters.  Implementations should generate SHA-1
   AlgorithmIdentifiers with NULL parameters.

12.1.2  MD5

   The MD5 digest algorithm is defined in RFC 1321 [MD5].  The algorithm
   identifier for MD5 is:

      md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
          rsadsi(113549) digestAlgorithm(2) 5 }

   The AlgorithmIdentifier parameters field must be present, and the
   parameters field must contain NULL.  Implementations may accept the
   MD5 AlgorithmIdentifiers with absent parameters as well as NULL
   parameters.





Housley                     Standards Track                    [Page 35]

RFC 2630              Cryptographic Message Syntax             June 1999


12.2  Signature Algorithms

   CMS implementations must include DSA.  CMS implementations may
   include RSA.

   Signature algorithm identifiers are located in the SignerInfo
   signatureAlgorithm field.  Also, signature algorithm identifiers are
   located in the SignerInfo signatureAlgorithm field of
   countersignature attributes.

   Signature values are located in the SignerInfo signature field.
   Also, signature values are located in the SignerInfo signature field
   of countersignature attributes.

12.2.1  DSA

   The DSA signature algorithm is defined in FIPS Pub 186 [DSS].  DSA is
   always used with the SHA-1 message digest algorithm.  The algorithm
   identifier for DSA is:

      id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
          us(840) x9-57 (10040) x9cm(4) 3 }

   The AlgorithmIdentifier parameters field must not be present.

12.2.2  RSA

   The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC
   2347 specifies the use of the RSA signature algorithm with the SHA-1
   and MD5 message digest algorithms.  The algorithm identifier for RSA
   is:

      rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

12.3  Key Management Algorithms

   CMS accommodates three general key management techniques: key
   agreement, key transport, and previously distributed symmetric key-
   encryption keys.

12.3.1  Key Agreement Algorithms

   CMS implementations must include key agreement using X9.42
   Ephemeral-Static Diffie-Hellman.

   Any symmetric encryption algorithm that a CMS implementation includes
   as a content-encryption algorithm must also be included as a key-



Housley                     Standards Track                    [Page 36]

RFC 2630              Cryptographic Message Syntax             June 1999


   encryption algorithm.  CMS implementations must include key agreement
   of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of
   Triple-DES content-encryption keys.  CMS implementations should
   include key agreement of RC2 pairwise key-encryption keys and RC2
   wrapping of RC2 content-encryption keys.  The key wrap algorithm for
   Triple-DES and RC2 is described in section 12.3.3.

   A CMS implementation may support mixed key-encryption and content-
   encryption algorithms.  For example, a 128-bit RC2 content-encryption
   key may be wrapped with 168-bit Triple-DES key-encryption key.
   Similarly, a 40-bit RC2 content-encryption key may be wrapped with
   128-bit RC2 key-encryption key.

   For key agreement of RC2 key-encryption keys, 128 bits must be
   generated as input to the key expansion process used to compute the
   RC2 effective key [RC2].

   Key agreement algorithm identifiers are located in the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
   AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
   keyEncryptionAlgorithm fields.

   Key wrap algorithm identifiers are located in the KeyWrapAlgorithm
   parameters within the EnvelopedData RecipientInfos
   KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.

   Wrapped content-encryption keys are located in the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
   encryptedKey field.  Wrapped message-authentication keys are located
   in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
   RecipientEncryptedKeys encryptedKey field.

12.3.1.1  X9.42 Ephemeral-Static Diffie-Hellman

   Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631
   [DH-X9.42].  When using Ephemeral-Static Diffie-Hellman, the
   EnvelopedData RecipientInfos KeyAgreeRecipientInfo and
   AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are
   used as follows:

      version must be 3.

      originator must be the originatorKey alternative.  The
      originatorKey algorithm fields must contain the dh-public-number
      object identifier with absent parameters.  The originatorKey
      publicKey field must contain the sender's ephemeral public key.
      The dh-public-number object identifier is:



Housley                     Standards Track                    [Page 37]

RFC 2630              Cryptographic Message Syntax             June 1999


         dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) ansi-x942(10046) number-type(2) 1 }

      ukm may be absent.  When present, the ukm is used to ensure that a
      different key-encryption key is generated when the ephemeral
      private key might be used more than once.

      keyEncryptionAlgorithm must be the id-alg-ESDH algorithm
      identifier.  The algorithm identifier parameter field for id-alg-
      ESDH is KeyWrapAlgorihtm, and this parameter must be present.  The
      KeyWrapAlgorithm denotes the symmetric encryption algorithm used
      to encrypt the content-encryption key with the pairwise key-
      encryption key generated using the Ephemeral-Static Diffie-Hellman
      key agreement algorithm.  Triple-DES and RC2 key wrap algorithms
      are discussed in section 12.3.3.  The id-alg-ESDH algorithm
      identifier and parameter syntax is:

       id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
           rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }

       KeyWrapAlgorithm ::= AlgorithmIdentifier

      recipientEncryptedKeys contains an identifier and an encrypted key
      for each recipient.  The RecipientEncryptedKey
      KeyAgreeRecipientIdentifier must contain either the
      issuerAndSerialNumber identifying the recipient's certificate or
      the RecipientKeyIdentifier containing the subject key identifier
      from the recipient's certificate.  In both cases, the recipient's
      certificate contains the recipient's static public key.
      RecipientEncryptedKey EncryptedKey must contain the content-
      encryption key encrypted with the Ephemeral-Static Diffie-Hellman
      generated pairwise key-encryption key using the algorithm
      specified by the KeyWrapAlgortihm.

12.3.2  Key Transport Algorithms

   CMS implementations should include key transport using RSA.  RSA
   implementations must include key transport of Triple-DES content-
   encryption keys.  RSA implementations should include key transport of
   RC2 content-encryption keys.

   Key transport algorithm identifiers are located in the EnvelopedData
   RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and
   AuthenticatedData RecipientInfos KeyTransRecipientInfo
   keyEncryptionAlgorithm fields.

   Key transport encrypted content-encryption keys are located in the
   EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey



Housley                     Standards Track                    [Page 38]

RFC 2630              Cryptographic Message Syntax             June 1999


   field.  Key transport encrypted message-authentication keys are
   located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo
   encryptedKey field.

12.3.2.1  RSA

   The RSA key transport algorithm is the RSA encryption scheme defined
   in RFC 2313 [PKCS#1], block type is 02, where the message to be
   encrypted is the content-encryption key.  The algorithm identifier
   for RSA is:

      rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

   The AlgorithmIdentifier parameters field must be present, and the
   parameters field must contain NULL.

   When using a Triple-DES content-encryption key, adjust the parity
   bits for each DES key comprising the Triple-DES key prior to RSA
   encryption.

   The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to
   provide confidentiality has a known vulnerability concerns.  The
   vulnerability is primarily relevant to usage in interactive
   applications rather than to store-and-forward environments.  Further
   information and proposed countermeasures are discussed in the
   Security Considerations section of this document.

   Note that the same encryption scheme is also defined in RFC 2437
   [NEWPKCS#1].  Within RFC 2437, this scheme is called
   RSAES-PKCS1-v1_5.

12.3.3  Symmetric Key-Encryption Key Algorithms

   CMS implementations may include symmetric key-encryption key
   management.  Such CMS implementations must include Triple-DES key-
   encryption keys wrapping Triple-DES content-encryption keys, and such
   CMS implementations should include RC2 key-encryption keys wrapping
   RC2 content-encryption keys.  Only 128-bit RC2 keys may be used as
   key-encryption keys, and they must be used with the
   RC2ParameterVersion parameter set to 58.  A CMS implementation may
   support mixed key-encryption and content-encryption algorithms.  For
   example, a 40-bit RC2 content-encryption key may be wrapped with
   168-bit Triple-DES key-encryption key or with a 128-bit RC2 key-
   encryption key.






Housley                     Standards Track                    [Page 39]

RFC 2630              Cryptographic Message Syntax             June 1999


   Key wrap algorithm identifiers are located in the EnvelopedData
   RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and
   AuthenticatedData RecipientInfos KEKRecipientInfo
   keyEncryptionAlgorithm fields.

   Wrapped content-encryption keys are located in the EnvelopedData
   RecipientInfos KEKRecipientInfo encryptedKey field.  Wrapped
   message-authentication keys are located in the AuthenticatedData
   RecipientInfos KEKRecipientInfo encryptedKey field.

   The output of a key agreement algorithm is a key-encryption key, and
   this key-encryption key is used to encrypt the content-encryption
   key.  In conjunction with key agreement algorithms, CMS
   implementations must include encryption of content-encryption keys
   with the pairwise key-encryption key generated using a key agreement
   algorithm.  To support key agreement, key wrap algorithm identifiers
   are located in the KeyWrapAlgorithm parameter of the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
   AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
   keyEncryptionAlgorithm fields.  Wrapped content-encryption keys are
   located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo
   RecipientEncryptedKeys encryptedKey field, wrapped message-
   authentication keys are located in the AuthenticatedData
   RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
   encryptedKey field.

12.3.3.1  Triple-DES Key Wrap

   Triple-DES key encryption has the algorithm identifier:

      id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

   The AlgorithmIdentifier parameter field must be NULL.

   The key wrap algorithm used to encrypt a Triple-DES content-
   encryption key with a Triple-DES key-encryption key is specified in
   section 12.6.

   Out-of-band distribution of the Triple-DES key-encryption key used to
   encrypt the Triple-DES content-encryption key is beyond of the scope
   of this document.









Housley                     Standards Track                    [Page 40]

RFC 2630              Cryptographic Message Syntax             June 1999


12.3.3.2  RC2 Key Wrap

   RC2 key encryption has the algorithm identifier:

      id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

   The AlgorithmIdentifier parameter field must be RC2wrapParameter:

      RC2wrapParameter ::= RC2ParameterVersion

      RC2ParameterVersion ::= INTEGER

   The RC2 effective-key-bits (key size) greater than 32 and less than
   256 is encoded in the RC2ParameterVersion.  For the effective-key-
   bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
   and 58 respectively.  These values are not simply the RC2 key length.
   Note that the value 160 must be encoded as two octets (00 A0),
   because the one octet (A0) encoding represents a negative number.

   Only 128-bit RC2 keys may be used as key-encryption keys, and they
   must be used with the RC2ParameterVersion parameter set to 58.

   The key wrap algorithm used to encrypt a RC2 content-encryption key
   with a RC2 key-encryption key is specified in section 12.6.

   Out-of-band distribution of the RC2 key-encryption key used to
   encrypt the RC2 content-encryption key is beyond of the scope of this
   document.

12.4  Content Encryption Algorithms

   CMS implementations must include Triple-DES in CBC mode.  CMS
   implementations should include RC2 in CBC mode.

   Content encryption algorithms identifiers are located in the
   EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the
   EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.

   Content encryption algorithms are used to encipher the content
   located in the EnvelopedData EncryptedContentInfo encryptedContent
   field and the EncryptedData EncryptedContentInfo encryptedContent
   field.








Housley                     Standards Track                    [Page 41]

RFC 2630              Cryptographic Message Syntax             June 1999


12.4.1  Triple-DES CBC

   The Triple-DES algorithm is described in ANSI X9.52 [3DES].  The
   Triple-DES is composed from three sequential DES [DES] operations:
   encrypt, decrypt, and encrypt.  Three-Key Triple-DES uses a different
   key for each DES operation.  Two-Key Triple-DES uses one key for the
   two encrypt operations and different key for the decrypt operation.
   The same algorithm identifiers are used for Three-Key Triple-DES and
   Two-Key Triple-DES.  The algorithm identifier for Triple-DES in
   Cipher Block Chaining (CBC) mode is:

      des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }

   The AlgorithmIdentifier parameters field must be present, and the
   parameters field must contain a CBCParameter:

      CBCParameter ::= IV

      IV ::= OCTET STRING  -- exactly 8 octets

12.4.2  RC2 CBC

   The RC2 algorithm is described in RFC 2268 [RC2].  The algorithm
   identifier for RC2 in CBC mode is:

      rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
          rsadsi(113549) encryptionAlgorithm(3) 2 }

   The AlgorithmIdentifier parameters field must be present, and the
   parameters field must contain a RC2CBCParameter:

      RC2CBCParameter ::= SEQUENCE {
        rc2ParameterVersion INTEGER,
        iv OCTET STRING  }  -- exactly 8 octets

   The RC2 effective-key-bits (key size) greater than 32 and less than
   256 is encoded in the rc2ParameterVersion.  For the effective-key-
   bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
   and 58 respectively.  These values are not simply the RC2 key length.
   Note that the value 160 must be encoded as two octets (00 A0), since
   the one octet (A0) encoding represents a negative number.

12.5  Message Authentication Code Algorithms

   CMS implementations that support authenticatedData must include HMAC
   with SHA-1.




Housley                     Standards Track                    [Page 42]

RFC 2630              Cryptographic Message Syntax             June 1999


   MAC algorithm identifiers are located in the AuthenticatedData
   macAlgorithm field.

   MAC values are located in the AuthenticatedData mac field.

12.5.1  HMAC with SHA-1

   The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC].  The
   algorithm identifier for HMAC with SHA-1 is:

      hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
          dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

   The AlgorithmIdentifier parameters field must be absent.

12.6  Triple-DES and RC2 Key Wrap Algorithms

   CMS implementations must include encryption of a Triple-DES content-
   encryption key with a Triple-DES key-encryption key using the
   algorithm specified in Sections 12.6.2 and 12.6.3.  CMS
   implementations should include encryption of a RC2 content-encryption
   key with a RC2 key-encryption key using the algorithm specified in
   Sections 12.6.4 and 12.6.5.  Triple-DES and RC2 content-encryption
   keys are encrypted in Cipher Block Chaining (CBC) mode [MODES].

   Key Transport algorithms allow for the content-encryption key to be
   directly encrypted; however, key agreement and symmetric key-
   encryption key algorithms encrypt the content-encryption key with a
   second symmetric encryption algorithm.  This section describes how
   the Triple-DES or RC2 content-encryption key is formatted and
   encrypted.

   Key agreement algorithms generate a pairwise key-encryption key, and
   a key wrap algorithm is used to encrypt the content-encryption key
   with the pairwise key-encryption key.  Similarly, a key wrap
   algorithm is used to encrypt the content-encryption key in a
   previously distributed key-encryption key.

   The key-encryption key is generated by the key agreement algorithm or
   distributed out of band.  For key agreement of RC2 key-encryption
   keys, 128 bits must be generated as input to the key expansion
   process used to compute the RC2 effective key [RC2].

   The same algorithm identifier is used for both 2-key and 3-key
   Triple-DES.  When the length of the content-encryption key to be
   wrapped is a 2-key Triple-DES key, a third key with the same value as
   the first key is created.  Thus, all Triple-DES content-encryption
   keys are wrapped like 3-key Triple-DES keys.



Housley                     Standards Track                    [Page 43]

RFC 2630              Cryptographic Message Syntax             June 1999


12.6.1  Key Checksum

   The CMS Checksum Algorithm is used to provide a content-encryption
   key integrity check value.  The algorithm is:

   1.  Compute a 20 octet SHA-1 [SHA1] message digest on the
       content-encryption key.
   2.  Use the most significant (first) eight octets of the message
       digest value as the checksum value.

12.6.2  Triple-DES Key Wrap

   The Triple-DES key wrap algorithm encrypts a Triple-DES content-
   encryption key with a Triple-DES key-encryption key.  The Triple-DES
   key wrap algorithm is:

   1.  Set odd parity for each of the DES key octets comprising
       the content-encryption key, call the result CEK.
   2.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1, call the result ICV.
   3.  Let CEKICV = CEK || ICV.
   4.  Generate 8 octets at random, call the result IV.
   5.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
       the random value generated in the previous step as the
       initialization vector (IV).  Call the ciphertext TEMP1.
   6.  Let TEMP2 = IV || TEMP1.
   7.  Reverse the order of the octets in TEMP2.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP3.
   8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
       an initialization vector (IV) of 0x4adda22c79e82105.
       The ciphertext is 40 octets long.

   Note:  When the same content-encryption key is wrapped in different
   key-encryption keys, a fresh initialization vector (IV) must be
   generated for each invocation of the key wrap algorithm.

12.6.3  Triple-DES Key Unwrap

   The Triple-DES key unwrap algorithm decrypts a Triple-DES content-
   encryption key using a Triple-DES key-encryption key.  The Triple-DES
   key unwrap algorithm is:

   1.  If the wrapped content-encryption key is not 40 octets, then
       error.
   2.  Decrypt the wrapped content-encryption key in CBC mode using
       the key-encryption key.  Use an initialization vector (IV)
       of 0x4adda22c79e82105.  Call the output TEMP3.



Housley                     Standards Track                    [Page 44]

RFC 2630              Cryptographic Message Syntax             June 1999


   3.  Reverse the order of the octets in TEMP3.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
       significant (first) 8 octets, and TEMP1 is the least significant
       (last) 32 octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
       the IV value from the previous step as the initialization vector.
       Call the ciphertext CEKICV.
   6.  Decompose the CEKICV into CEK and ICV. CEK is the most significant
       (first) 24 octets, and ICV is the least significant (last) 8 octets.
   7.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1.  If the computed key checksum value does not
       match the decrypted key checksum value, ICV, then error.
   8.  Check for odd parity each of the DES key octets comprising CEK.
       If parity is incorrect, then there is an error.
   9.  Use CEK as the content-encryption key.

12.6.4  RC2 Key Wrap

   The RC2 key wrap algorithm encrypts a RC2 content-encryption key with
   a RC2 key-encryption key.  The RC2 key wrap algorithm is:

   1.  Let the content-encryption key be called CEK, and let the length
       of the content-encryption key in octets be called LENGTH.  LENGTH
       is a single octet.
   2.  Let LCEK = LENGTH || CEK.
   3.  Let LCEKPAD = LCEK || PAD.  If the length of LCEK is a multiple
       of 8, the PAD has a length of zero.  If the length of LCEK is
       not a multiple of 8, then PAD contains the fewest number of
       random octets to make the length of LCEKPAD a multiple of 8.
   4.  Compute an 8 octet key checksum value on LCEKPAD as described
       above in Section 12.6.1, call the result ICV.
   5.  Let LCEKPADICV = LCEKPAD || ICV.
   6.  Generate 8 octets at random, call the result IV.
   7.  Encrypt LCEKPADICV in CBC mode using the key-encryption key.
       Use the random value generated in the previous step as the
       initialization vector (IV).  Call the ciphertext TEMP1.
   8.  Let TEMP2 = IV || TEMP1.
   9.  Reverse the order of the octets in TEMP2.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP3.
   10. Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
       an initialization vector (IV) of 0x4adda22c79e82105.

   Note:  When the same content-encryption key is wrapped in different
   key-encryption keys, a fresh initialization vector (IV) must be
   generated for each invocation of the key wrap algorithm.



Housley                     Standards Track                    [Page 45]

RFC 2630              Cryptographic Message Syntax             June 1999


12.6.5  RC2 Key Unwrap

   The RC2 key unwrap algorithm decrypts a RC2 content-encryption key
   using a RC2 key-encryption key.  The RC2 key unwrap algorithm is:

   1.  If the wrapped content-encryption key is not a multiple of 8
       octets, then error.
   2.  Decrypt the wrapped content-encryption key in CBC mode using
       the key-encryption key.  Use an initialization vector (IV)
       of 0x4adda22c79e82105.  Call the output TEMP3.
   3.  Reverse the order of the octets in TEMP3.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
       significant (first) 8 octets, and TEMP1 is the remaining octets.

   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
       the IV value from the previous step as the initialization vector.
       Call the plaintext LCEKPADICV.
   6.  Decompose the LCEKPADICV into LCEKPAD, and ICV.  ICV is the
       least significant (last) octet 8 octets.  LCEKPAD is the
       remaining octets.
   7.  Compute an 8 octet key checksum value on LCEKPAD as described
       above in Section 12.6.1.  If the computed key checksum value
       does not match the decrypted key checksum value, ICV, then error.
   8.  Decompose the LCEKPAD into LENGTH, CEK, and PAD.  LENGTH is the
       most significant (first) octet.  CEK is the following LENGTH
       octets.  PAD is the remaining octets, if any.
   9.  If the length of PAD is more than 7 octets, then error.
   10. Use CEK as the content-encryption key.





















Housley                     Standards Track                    [Page 46]

RFC 2630              Cryptographic Message Syntax             June 1999


Appendix A:  ASN.1 Module

CryptographicMessageSyntax
    { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- EXPORTS All
-- The types and values defined in this module are exported for use in
-- the other ASN.1 modules.  Other applications may use them for their
-- own purposes.

IMPORTS

  -- Directory Information Framework (X.501)
        Name
           FROM InformationFramework { joint-iso-itu-t ds(5) modules(1)
                informationFramework(1) 3 }

  -- Directory Authentication Framework (X.509)
        AlgorithmIdentifier, AttributeCertificate, Certificate,
        CertificateList, CertificateSerialNumber
           FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                module(1) authenticationFramework(7) 3 } ;


-- Cryptographic Message Syntax

ContentInfo ::= SEQUENCE {
  contentType ContentType,
  content [0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER

SignedData ::= SEQUENCE {
  version CMSVersion,
  digestAlgorithms DigestAlgorithmIdentifiers,
  encapContentInfo EncapsulatedContentInfo,
  certificates [0] IMPLICIT CertificateSet OPTIONAL,
  crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
  signerInfos SignerInfos }

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo




Housley                     Standards Track                    [Page 47]

RFC 2630              Cryptographic Message Syntax             June 1999


EncapsulatedContentInfo ::= SEQUENCE {
  eContentType ContentType,
  eContent [0] EXPLICIT OCTET STRING OPTIONAL }

SignerInfo ::= SEQUENCE {
  version CMSVersion,
  sid SignerIdentifier,
  digestAlgorithm DigestAlgorithmIdentifier,
  signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
  signatureAlgorithm SignatureAlgorithmIdentifier,
  signature SignatureValue,
  unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

SignerIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier }

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {
  attrType OBJECT IDENTIFIER,
  attrValues SET OF AttributeValue }

AttributeValue ::= ANY

SignatureValue ::= OCTET STRING

EnvelopedData ::= SEQUENCE {
  version CMSVersion,
  originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  encryptedContentInfo EncryptedContentInfo,
  unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

OriginatorInfo ::= SEQUENCE {
  certs [0] IMPLICIT CertificateSet OPTIONAL,
  crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }

RecipientInfos ::= SET OF RecipientInfo

EncryptedContentInfo ::= SEQUENCE {
  contentType ContentType,
  contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
  encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

EncryptedContent ::= OCTET STRING



Housley                     Standards Track                    [Page 48]

RFC 2630              Cryptographic Message Syntax             June 1999


UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  kekri [2] KEKRecipientInfo }

EncryptedKey ::= OCTET STRING

KeyTransRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 0 or 2
  rid RecipientIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

RecipientIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier }

KeyAgreeRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 3
  originator [0] EXPLICIT OriginatorIdentifierOrKey,
  ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  recipientEncryptedKeys RecipientEncryptedKeys }

OriginatorIdentifierOrKey ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier,
  originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
  algorithm AlgorithmIdentifier,
  publicKey BIT STRING }

RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

RecipientEncryptedKey ::= SEQUENCE {
  rid KeyAgreeRecipientIdentifier,
  encryptedKey EncryptedKey }

KeyAgreeRecipientIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  rKeyId [0] IMPLICIT RecipientKeyIdentifier }







Housley                     Standards Track                    [Page 49]

RFC 2630              Cryptographic Message Syntax             June 1999


RecipientKeyIdentifier ::= SEQUENCE {
  subjectKeyIdentifier SubjectKeyIdentifier,
  date GeneralizedTime OPTIONAL,
  other OtherKeyAttribute OPTIONAL }

SubjectKeyIdentifier ::= OCTET STRING

KEKRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 4
  kekid KEKIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

KEKIdentifier ::= SEQUENCE {
  keyIdentifier OCTET STRING,
  date GeneralizedTime OPTIONAL,
  other OtherKeyAttribute OPTIONAL }

DigestedData ::= SEQUENCE {
  version CMSVersion,
  digestAlgorithm DigestAlgorithmIdentifier,
  encapContentInfo EncapsulatedContentInfo,
  digest Digest }

Digest ::= OCTET STRING

EncryptedData ::= SEQUENCE {
  version CMSVersion,
  encryptedContentInfo EncryptedContentInfo,
  unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

AuthenticatedData ::= SEQUENCE {
  version CMSVersion,
  originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  macAlgorithm MessageAuthenticationCodeAlgorithm,
  digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
  encapContentInfo EncapsulatedContentInfo,
  authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
  mac MessageAuthenticationCode,
  unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }

AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

MessageAuthenticationCode ::= OCTET STRING




Housley                     Standards Track                    [Page 50]

RFC 2630              Cryptographic Message Syntax             June 1999


DigestAlgorithmIdentifier ::= AlgorithmIdentifier

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

CertificateRevocationLists ::= SET OF CertificateList

CertificateChoices ::= CHOICE {
  certificate Certificate,  -- See X.509
  extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- Obsolete
  attrCert [1] IMPLICIT AttributeCertificate }  -- See X.509 & X9.57

CertificateSet ::= SET OF CertificateChoices

IssuerAndSerialNumber ::= SEQUENCE {
  issuer Name,
  serialNumber CertificateSerialNumber }

CMSVersion ::= INTEGER  { v0(0), v1(1), v2(2), v3(3), v4(4) }

UserKeyingMaterial ::= OCTET STRING

OtherKeyAttribute ::= SEQUENCE {
  keyAttrId OBJECT IDENTIFIER,
  keyAttr ANY DEFINED BY keyAttrId OPTIONAL }


-- CMS Attributes

MessageDigest ::= OCTET STRING

SigningTime  ::= Time

Time ::= CHOICE {
  utcTime UTCTime,
  generalTime GeneralizedTime }

Countersignature ::= SignerInfo








Housley                     Standards Track                    [Page 51]

RFC 2630              Cryptographic Message Syntax             June 1999


-- Algorithm Identifiers

sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
    oiw(14) secsig(3) algorithm(2) 26 }

md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) digestAlgorithm(2) 5 }

id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
    us(840) x9-57 (10040) x9cm(4) 3 }

rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) ansi-x942(10046) number-type(2) 1 }

id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }

id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }

rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) encryptionAlgorithm(3) 2 }

hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
    dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }


-- Algorithm Parameters

KeyWrapAlgorithm ::= AlgorithmIdentifier

RC2wrapParameter ::= RC2ParameterVersion

RC2ParameterVersion ::= INTEGER

CBCParameter ::= IV

IV ::= OCTET STRING  -- exactly 8 octets




Housley                     Standards Track                    [Page 52]

RFC 2630              Cryptographic Message Syntax             June 1999


RC2CBCParameter ::= SEQUENCE {
  rc2ParameterVersion INTEGER,
  iv OCTET STRING  }  -- exactly 8 octets


-- Content Type Object Identifiers

id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
    ct(1) 6 }

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
    ct(1) 2 }


-- Attribute Object Identifiers

id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }







Housley                     Standards Track                    [Page 53]

RFC 2630              Cryptographic Message Syntax             June 1999


-- Obsolete Extended Certificate syntax from PKCS#6

ExtendedCertificate ::= SEQUENCE {
  extendedCertificateInfo ExtendedCertificateInfo,
  signatureAlgorithm SignatureAlgorithmIdentifier,
  signature Signature }

ExtendedCertificateInfo ::= SEQUENCE {
  version CMSVersion,
  certificate Certificate,
  attributes UnauthAttributes }

Signature ::= BIT STRING


END -- of CryptographicMessageSyntax



































Housley                     Standards Track                    [Page 54]

RFC 2630              Cryptographic Message Syntax             June 1999


References

   3DES       American National Standards Institute.  ANSI X9.52-1998,
              Triple Data Encryption Algorithm Modes of Operation. 1998.

   DES        American National Standards Institute.  ANSI X3.106,
              "American National Standard for Information Systems - Data
              Link Encryption".  1983.

   DH-X9.42   Rescorla, E., "Diffie-Hellman Key Agreement Method",
              RFC 2631, June 1999.

   DSS        National Institute of Standards and Technology.
              FIPS Pub 186: Digital Signature Standard.  19 May 1994.

   ESS        Hoffman, P., Editor, "Enhanced Security Services for
              S/MIME", RFC 2634, June 1999.

   HMAC       Krawczyk, H., "HMAC: Keyed-Hashing for Message
              Authentication", RFC 2104, February 1997.

   MD5        Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   MODES      National Institute of Standards and Technology.
              FIPS Pub 81: DES Modes of Operation.  2 December 1980.

   MSG        Ramsdell, B., Editor, "S/MIME Version 3 Message
              Specification", RFC 2633, June 1999.

   NEWPKCS#1  Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
              RFC 2347, October 1998.

   PROFILE    Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure: Certificate and CRL
              Profile", RFC 2459, January 1999.

   PKCS#1     Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.",
              RFC 2313, March 1998.

   PKCS#6     RSA Laboratories.  PKCS #6: Extended-Certificate Syntax
              Standard, Version 1.5.  November 1993.

   PKCS#7     Kaliski, B., "PKCS #7: Cryptographic Message Syntax,
              Version 1.5.", RFC 2315, March 1998.

   PKCS#9     RSA Laboratories.  PKCS #9: Selected Attribute Types,
              Version 1.1.  November 1993.



Housley                     Standards Track                    [Page 55]

RFC 2630              Cryptographic Message Syntax             June 1999


   RANDOM     Eastlake, D., Crocker, S. and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

   RC2        Rivest, R., "A Description of the RC2 (r) Encryption
              Algorithm", RFC 2268, March 1998.

   SHA1       National Institute of Standards and Technology.
              FIPS Pub 180-1: Secure Hash Standard.  17 April 1995.

   X.208-88   CCITT.  Recommendation X.208: Specification of Abstract
              Syntax Notation One (ASN.1).  1988.

   X.209-88   CCITT.  Recommendation X.209: Specification of Basic
              Encoding Rules for Abstract Syntax Notation One (ASN.1).
              1988.

   X.501-88   CCITT.  Recommendation X.501: The Directory - Models.
              1988.

   X.509-88   CCITT.  Recommendation X.509: The Directory -
              Authentication Framework.  1988.

   X.509-97   ITU-T.  Recommendation X.509: The Directory -
              Authentication Framework.  1997.

Security Considerations

   The Cryptographic Message Syntax provides a method for digitally
   signing data, digesting data, encrypting data, and authenticating
   data.

   Implementations must protect the signer's private key.  Compromise of
   the signer's private key permits masquerade.

   Implementations must protect the key management private key, the
   key-encryption key, and the content-encryption key.  Compromise of
   the key management private key or the key-encryption key may result
   in the disclosure of all messages protected with that key.
   Similarly, compromise of the content-encryption key may result in
   disclosure of the associated encrypted content.

   Implementations must protect the key management private key and the
   message-authentication key.  Compromise of the key management private
   key permits masquerade of authenticated data.  Similarly, compromise
   of the message-authentication key may result in undetectable
   modification of the authenticated content.





Housley                     Standards Track                    [Page 56]

RFC 2630              Cryptographic Message Syntax             June 1999


   Implementations must randomly generate content-encryption keys,
   message-authentication keys, initialization vectors (IVs), and
   padding.  Also, the generation of public/private key pairs relies on
   a random numbers.  The use of inadequate pseudo-random number
   generators (PRNGs) to generate cryptographic keys can result in
   little or no security.  An attacker may find it much easier to
   reproduce the PRNG environment that produced the keys, searching the
   resulting small set of possibilities, rather than brute force
   searching the whole key space.  The generation of quality random
   numbers is difficult.  RFC 1750 [RANDOM] offers important guidance in
   this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
   PRNG technique.

   When using key agreement algorithms or previously distributed
   symmetric key-encryption keys, a key-encryption key is used to
   encrypt the content-encryption key.  If the key-encryption and
   content-encryption algorithms are different, the effective security
   is determined by the weaker of the two algorithms.  If, for example,
   a message content is encrypted with 168-bit Triple-DES and the
   Triple-DES content-encryption key is wrapped with a 40-bit RC2 key,
   then at most 40 bits of protection is provided.  A trivial search to
   determine the value of the 40-bit RC2 key can recover Triple-DES key,
   and then the Triple-DES key can be used to decrypt the content.
   Therefore, implementers must ensure that key-encryption algorithms
   are as strong or stronger than content-encryption algorithms.

   Section 12.6 specifies key wrap algorithms used to encrypt a Triple-
   DES [3DES] content-encryption key with a Triple-DES key-encryption
   key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key-
   encryption key.  The key wrap algorithms make use of CBC mode
   [MODES].  These key wrap algorithms have been reviewed for use with
   Triple and RC2.  They have not been reviewed for use with other
   cryptographic modes or other encryption algorithms.  Therefore, if a
   CMS implementation wishes to support ciphers in addition to Triple-
   DES or RC2, then additional key wrap algorithms need to be defined to
   support the additional ciphers.

   Implementers should be aware that cryptographic algorithms become
   weaker with time.  As new cryptoanalysis techniques are developed and
   computing performance improves, the work factor to break a particular
   cryptographic algorithm will reduce.  Therefore, cryptographic
   algorithm implementations should be modular allowing new algorithms
   to be readily inserted.  That is, implementers should be prepared for
   the set of mandatory to implement algorithms to change over time.

   The countersignature unauthenticated attribute includes a digital
   signature that is computed on the content signature value, thus the
   countersigning process need not know the original signed content.



Housley                     Standards Track                    [Page 57]

RFC 2630              Cryptographic Message Syntax             June 1999


   This structure permits implementation efficiency advantages; however,
   this structure may also permit the countersigning of an inappropriate
   signature value.  Therefore, implementations that perform
   countersignatures should either verify the original signature value
   prior to countersigning it (this verification requires processing of
   the original content), or implementations should perform
   countersigning in a context that ensures that only appropriate
   signature values are countersigned.

   Users of CMS, particularly those employing CMS to support interactive
   applications, should be aware that PKCS #1 Version 1.5 as specified
   in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext
   attacks when applied for encryption purposes.  Exploitation of this
   identified vulnerability, revealing the result of a particular RSA
   decryption, requires access to an oracle which will respond to a
   large number of ciphertexts (based on currently available results,
   hundreds of thousands or more), which are constructed adaptively in
   response to previously-received replies providing information on the
   successes or failures of attempted decryption operations.  As a
   result, the attack appears significantly less feasible to perpetrate
   for store-and-forward S/MIME environments than for directly
   interactive protocols.  Where CMS constructs are applied as an
   intermediate encryption layer within an interactive request-response
   communications environment, exploitation could be more feasible.

   An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
   [NEWPKCS#1].  This new document will supersede RFC 2313.  PKCS #1
   Version 2.0 preserves support for the encryption padding format
   defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new
   alternative.  To resolve the adaptive chosen ciphertext
   vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
   of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
   is used to provide confidentiality.  Designers of protocols and
   systems employing CMS for interactive environments should either
   consider usage of OAEP, or should ensure that information which could
   reveal the success or failure of attempted PKCS #1 Version 1.5
   decryption operations is not provided.  Support for OAEP will likely
   be added to a future version of the CMS specification.

Acknowledgments

   This document is the result of contributions from many professionals.
   I appreciate the hard work of all members of the IETF S/MIME Working
   Group.  I extend a special thanks to Rich Ankney, Tim Dean, Steve
   Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson,
   Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn,
   John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave
   Solo for their efforts and support.



Housley                     Standards Track                    [Page 58]

RFC 2630              Cryptographic Message Syntax             June 1999


Author's Address

   Russell Housley
   SPYRUS
   381 Elden Street
   Suite 1120
   Herndon, VA 20170
   USA

   EMail: housley@spyrus.com









































Housley                     Standards Track                    [Page 59]

RFC 2630              Cryptographic Message Syntax             June 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Housley                     Standards Track                    [Page 60]