File: rfc2315.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 (1795 lines) | stat: -rw-r--r-- 69,679 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
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






Network Working Group                                          B. Kaliski
Request for Comments: 2315                         RSA Laboratories, East
Category: Informational                                        March 1998


                 PKCS #7: Cryptographic Message Syntax
                              Version 1.5

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Overview

   This document describes a general syntax for data that may have
   cryptography applied to it, such as digital signatures and digital
   envelopes. The syntax admits recursion, so that, for example, one
   envelope can be nested inside another, or one party can sign some
   previously enveloped digital data.  It also allows arbitrary
   attributes, such as signing time, to be authenticated along with the
   content of a message, and provides for other attributes such as
   countersignatures to be associated with a signature. A degenerate
   case of the syntax provides a means for disseminating certificates
   and certificate-revocation lists.

1. Scope

   This document is compatible with Privacy-Enhanced Mail (PEM) in that
   signed-data and signed-and-enveloped-data content, constructed in a
   PEM-compatible mode, can be converted into PEM messages without any
   cryptographic operations. PEM messages can similarly be converted
   into the signed-data and signed-and-enveloped data content types.

   This document can support a variety of architectures for
   certificate-based key management, such as the one proposed for
   Privacy-Enhanced Mail in RFC 1422. Architectural decisions such as
   what certificate issuers are considered "top-level," what entities
   certificate issuers are authorized to certify, what distinguished
   names are considered acceptable, and what policies certificate
   issuers must follow (such as signing only with secure hardware, or
   requiring entities to present specific forms of identification) are
   left outside the document.



Kaliski                      Informational                      [Page 1]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   The values produced according to this document are intended to be
   BER-encoded, which means that the values would typically be
   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 as (say) strings of ASCII
   characters or other techniques for enabling reliable transmission by
   re-encoding the octet string. RFC 1421 suggests one possible solution
   to this problem.

2. References

      FIPS PUB 46-1  National Bureau of Standards. FIPS PUB 46-1:
                Data Encryption Standard. January 1988.

      PKCS #1   RSA Laboratories. PKCS #1: RSA Encryption.
                Version 1.5, November 1993.

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

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

      RFC 1421  Linn, J., "Privacy Enhancement for
                Internet Electronic Mail: Part I: Message
                Encryption and Authentication Procedures," RFC 1421
                February 1993.

      RFC 1422  Kent, S., "Privacy Enhancement for
                Internet Electronic Mail: Part II: Certificate-
                Based Key Management," RFC 1422, February 1993.

      RFC 1423  Balenson, D., "Privacy Enhancement for
                Internet Electronic Mail: Part III: Algorithms,
                Modes, and Identifiers," RFC 1423, February 1993.

      RFC 1424  Kaliski, B., "Privacy Enhancement for
                Internet Electronic Mail: Part IV: Key
                Certification and Related Services," RFC 1424,
                February 1993.










Kaliski                      Informational                      [Page 2]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


      RFC 1319  Kaliski, B., "The MD2 Message-Digest
                Algorithm," RFC 1319, April 1992.

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

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

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

      X.500     CCITT. Recommendation X.500: The Directory--
                Overview of Concepts, Models and
                Services. 1988.

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

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

      [NIST91]  NIST. Special Publication 500-202: Stable
                Implementation Agreements for Open Systems
                Interconnection Protocols. Version 5, Edition 1,
                Part 12. December 1991.

      [RSA78]   R.L. Rivest, A. Shamir, and L. Adleman. A method
                for obtaining digital signatures and public-key
                cryptosystems. Communications of the ACM,
                21(2):120-126, February 1978.

3. Definitions

   For the purposes of this document, the following definitions apply.

   AlgorithmIdentifier: A type that identifies an algorithm (by object
   identifier) and associated parameters. This type is defined in X.509.

   ASN.1: Abstract Syntax Notation One, as defined in X.208.

   Attribute: A type that contains an attribute type (specified by
   object identifier) and one or more attribute values. This type is
   defined in X.501.

   BER: Basic Encoding Rules, as defined in X.209.




Kaliski                      Informational                      [Page 3]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   Certificate: A type that binds an entity's distinguished name to a
   public key with a digital signature. This type is defined in X.509.
   This type also contains the distinguished name of the certificate
   issuer (the signer), an issuer-specific serial number, the issuer's
   signature algorithm identifier, and a validity period.

   CertificateSerialNumber: A type that uniquely identifies a
   certificate (and thereby an entity and a public key) among those
   signed by a particular certificate issuer. This type is defined in
   X.509.

   CertificateRevocationList: A type that contains information about
   certificates whose validity an issuer has prematurely revoked. The
   information consists of an issuer name, the time of issue, the next
   scheduled time of issue, and a list of certificate serial numbers and
   their associated revocation times. The CRL is signed by the issuer.
   The type intended by this document is the one defined RFC 1422.

   DER: Distinguished Encoding Rules for ASN.1, as defined in X.509,
   Section 8.7.

   DES: Data Encryption Standard, as defined in FIPS PUB 46-1.

   desCBC: The object identifier for DES in cipher-block chaining (CBC)
   mode, as defined in [NIST91].

   ExtendedCertificate: A type that consists of an X.509 public-key
   certificate and a set of attributes, collectively signed by the
   issuer of the X.509 public-key certificate. This type is defined in
   PKCS #6.

   MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as
   defined in RFC 1319.

   md2: The object identifier for MD2, as defined in RFC 1319.

   MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as
   defined in RFC 1321.

   md5: The object identifier for MD5, as defined in RFC 1321.

   Name: A type that uniquely identifies or "distinguishes" objects in
   an X.500 directory. This type is defined in X.501. In an X.509
   certificate, the type identifies the certificate issuer and the
   entity whose public key is certified.

   PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424.




Kaliski                      Informational                      [Page 4]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   RSA: The RSA public-key cryptosystem, as defined in [RSA78].

   rsaEncryption: The object identifier for RSA encryption, as defined
   in PKCS #1.

4. Symbols and abbreviations

   No symbols or abbreviations are defined in this document.

5. General overview

   The following nine sections specify useful types, general syntax, six
   content types, and object identifiers.

   The syntax is general enough to support many different content types.
   This document defines six: data, signed data, enveloped data,
   signed-and-enveloped data, digested data, and encrypted data. Other
   content types may be added in the future. The use of content types
   defined outside this document is possible, but is subject to
   bilateral agreement between parties exchanging content.

   This document exports one type, ContentInfo, as well as the various
   object identifiers.

   There are two classes of content types: base and enhanced.  Content
   types in the base class contain "just data," with no cryptographic
   enhancements. Presently, one content type is in this class, the data
   content type. Content types in the enhanced class contain content of
   some type (possibly encrypted), and other cryptographic enhancements.
   For example, enveloped-data content can contain (encrypted) signed-
   data content, which can contain data content. The four non-data
   content types fall into the enhanced class.  The content types in the
   enhanced class thus employ encapsulation, giving rise to the terms
   "outer" content (the one containing the enhancements) and "inner"
   content (the one being enhanced).

   The document is designed such that the enhanced content types can be
   prepared in a single pass using indefinite-length BER encoding, and
   processed in a single pass in any BER encoding. Single-pass operation
   is especially helpful if content is stored on tapes, or is "piped"
   from another process. One of the drawbacks of single-pass operation,
   however, is that it is difficult to output a DER encoding in a single
   pass, since the lengths of the various components may not be known in
   advance. Since DER encoding is required by the signed-data, signed-
   and-enveloped data, and digested-data content types, an extra pass
   may be necessary when a content type other than data is the inner
   content of one of those content types.




Kaliski                      Informational                      [Page 5]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


6. Useful types

   This section defines types that are useful in at least two places in
   the document.

6.1 CertificateRevocationLists

   The CertificateRevocationLists type gives a set of certificate-
   revocation lists. It is intended that the set contain information
   sufficient to determine whether the certificates with which the set
   is associated are "hot listed," but there may be more certificate-
   revocation lists than necessary, or there may be fewer than
   necessary.

   CertificateRevocationLists ::=
     SET OF CertificateRevocationList

6.2 ContentEncryptionAlgorithmIdentifier

   The ContentEncryptionAlgorithmIdentifier type identifies a content-
   encryption algorithm such as DES. 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

6.3 DigestAlgorithmIdentifier

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

   DigestAlgorithmIdentifier ::= AlgorithmIdentifier

6.4 DigestEncryptionAlgorithmIdentifier

   The DigestEncryptionAlgorithmIdentifier type identifies a digest-
   encryption algorithm under which a message digest can be encrypted.
   One example is PKCS #1's rsaEncryption. A digest-encryption algorithm
   supports encryption and decryption operations. The encryption
   operation maps an octet string (the message digest) to another octet
   .bp string (the encrypted message digest) under control of a digest-
   encryption key. The decryption operation is the inverse of the



Kaliski                      Informational                      [Page 6]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   encryption operation. Context determines which operation is intended.

   DigestEncryptionAlgorithmIdentifier ::=
     AlgorithmIdentifier

6.5 ExtendedCertificateOrCertificate

   The ExtendedCertificateOrCertificate type gives either a PKCS #6
   extended certificate or an X.509 certificate.  This type follows the
   syntax recommended in Section 6 of PKCS #6:

   ExtendedCertificateOrCertificate ::= CHOICE {
     certificate Certificate, -- X.509

     extendedCertificate [0] IMPLICIT ExtendedCertificate }

6.6 ExtendedCertificatesAndCertificates

   The ExtendedCertificatesAndCertificates type gives a set of extended
   certificates and X.509 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 signers with which the set is
   associated, but there may be more certificates than necessary, or
   there may be fewer than necessary.

   ExtendedCertificatesAndCertificates ::=
     SET OF ExtendedCertificateOrCertificate

   Note. The precise meaning of a "chain" is outside the scope of this
   document. Some applications of this document may impose upper limits
   on the length of a chain; others may enforce certain relationships
   between the subjects and issuers of certificates in a chain. An
   example of such relationships has been proposed for Privacy-Enhanced
   Mail in RFC 1422.

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

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







Kaliski                      Informational                      [Page 7]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


6.8 KeyEncryptionAlgorithmIdentifier

   The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption
   algorithm under which a content-encryption key can be encrypted. One
   example is PKCS #1's rsaEncryption. A key-encryption algorithm
   supports encryption and decryption operations. 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.

   KeyEncryptionAlgorithmIdentifier ::=
     AlgorithmIdentifier

6.9 Version

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

   Version ::= INTEGER

7. General syntax

   The general syntax for content exchanged between entities according
   to this document associates a content type with content. The syntax
   shall have ASN.1 type ContentInfo:

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

   ContentType ::= OBJECT IDENTIFIER

   The fields of type ContentInfo have the following meanings:

        o    contentType indicates the type of content. It is
             an object identifier, which means it is a unique string of
             integers assigned by the authority that defines the content
             type. This document defines six content types (see Section
             14): data, signedData, envelopedData,
             signedAndEnvelopedData, digestedData, and encryptedData.

        o    content is the content. The field is optional, and
             if the field is not present, its intended value must be
             supplied by other means. Its type is defined along with the
             object identifier for contentType.




Kaliski                      Informational                      [Page 8]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   Notes.

        1.   The methods below assume that the type of content
             can be determined uniquely by contentType, so the type
             defined along with the object identifier should not be a
             CHOICE type.

        2.   When a ContentInfo value is the inner content of
             signed-data, signed-and-enveloped-data, or digested-data
             content, a message-digest algorithm is applied to the
             contents octets of the DER encoding of the content field.
             When a ContentInfo value is the inner content of
             enveloped-data or signed-and-enveloped-data content, a
             content-encryption algorithm is applied to the contents
             octets of a definite-length BER encoding of the content
             field.

        3.   The optional omission of the content field makes
             it possible to construct "external signatures," for
             example, without modification to or replication of the
             content to which the signatures apply. In the case of
             external signatures, the content being signed would be
             omitted from the "inner" encapsulated ContentInfo value
             included in the signed-data content type.

8. Data content type

   The data content type is just an octet string. It shall have ASN.1
   type Data:

   Data ::= OCTET STRING

   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
   (although they may; they could even be DER encodings).

9. Signed-data content type

   The signed-data content type consists of content of any type and
   encrypted message digests of the content for zero or more signers.
   The encrypted digest for a signer is a "digital signature" on the
   content for that signer. Any type of content can be signed by any
   number of signers in parallel. Furthermore, the syntax has a
   degenerate case in which there are no signers on the content. The
   degenerate case provides a means for disseminating certificates and
   certificate-revocation lists.




Kaliski                      Informational                      [Page 9]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   It is expected that the typical application of the signed-data
   content type will be to represent one signer's digital signature on
   content of the data content type. Another typical application will be
   to disseminate certificates and certificate-revocation lists.

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

        1.   For each signer, a message digest is computed on
             the content with a signer-specific message-digest
             algorithm. (If two signers employ the same message-digest
             algorithm, then the message digest need be computed for
             only one of them.) If the signer is authenticating any
             information other than the content (see Section 9.2), the
             message digest of the content and the other information are
             digested with the signer's message digest algorithm, and
             the result becomes the "message digest."

        2.   For each signer, the message digest and associated
             information are encrypted with the signer's private key.

        3.   For each signer, the encrypted message digest and
             other signer-specific information are collected into a
             SignerInfo value, defined in Section 9.2.  Certificates and
             certificate-revocation lists 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, defined
             in Section 9.1.

   A recipient verifies the signatures by decrypting the encrypted
   message digest for each signer with the signer's public key, then
   comparing the recovered message digest to an independently computed
   message digest. The signer's public key is either contained in a
   certificate included in the signer information, or is referenced by
   an issuer distinguished name and an issuer-specific serial number
   that uniquely identify the certificate for the public key.

   This section is divided into five parts. The first part describes the
   top-level type SignedData, the second part describes the per-signer
   information type SignerInfo, and the third and fourth parts describe
   the message-digesting and digest-encryption processes. The fifth part
   summarizes compatibility with Privacy-Enhanced Mail.






Kaliski                      Informational                     [Page 10]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


9.1 SignedData type

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

   SignedData ::= SEQUENCE {
     version Version,
     digestAlgorithms DigestAlgorithmIdentifiers,
     contentInfo ContentInfo,
     certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
          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:

        o    version is the syntax version number. It shall be
             1 for this version of the document.

        o    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
             (and any associated parameters) under which the
             content is digested for a some 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 9.3.

        o    contentInfo is the content that is signed. It can
             have any of the defined content types.

        o    certificates is a set of PKCS #6 extended
             certificates and X.509 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
             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



Kaliski                      Informational                     [Page 11]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


             top-level certification authorities. There may also be
             fewer certificates than necessary, if it is expected that
             those verifying the signatures have an alternate means of
             obtaining necessary certificates (e.g., from a previous set
             of certificates).

        o    crls is a set of certificate-revocation lists. It
             is intended that the set contain information sufficient to
             determine whether or not the certificates in the
             certificates field are "hot listed," but such
             correspondence is not necessary.  There may be more
             certificate-revocation lists than necessary, and there may
             also be fewer certificate-revocation lists than necessary.

        o    signerInfos is a collection of per-signer
             information. There may be any number of elements in the
             collection, including zero.

   Notes.

        1.   The fact that the digestAlgorithms field comes
             before the contentInfo field and the signerInfos field
             comes after it makes it possible to process a SignedData
             value in a single pass. (Single-pass processing is
             described in Section 5.)

        2.   The differences between version 1 SignedData and
             version 0 SignedData (defined in PKCS #7, Version 1.4) are
             the following:

                  o    the digestAlgorithms and signerInfos
                       fields may contain zero elements in version 1,
                       but not in version 0

                  o    the crls field is allowed in version 1,
                       but not in version 0

             Except for the difference in version number, version 0
             SignedData values are acceptable as version 1 values. An
             implementation can therefore process SignedData values of
             either version as though they were version 1 values. It is
             suggested that PKCS implementations generate only version 1
             SignedData values, but be prepared to process SignedData
             values of either version.







Kaliski                      Informational                     [Page 12]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


        3.   In the degenerate case where there are no signers
             on the content, the ContentInfo value being "signed" is
             irrelevant. It is recommended in that case that the content
             type of the ContentInfo value being "signed" be data, and
             the content field of the ContentInfo value be omitted.

9.2 SignerInfo type

   Per-signer information is represented in the type SignerInfo:

   SignerInfo ::= SEQUENCE {
     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber,
     digestAlgorithm DigestAlgorithmIdentifier,
     authenticatedAttributes
       [0] IMPLICIT Attributes OPTIONAL,
     digestEncryptionAlgorithm
       DigestEncryptionAlgorithmIdentifier,
     encryptedDigest EncryptedDigest,
     unauthenticatedAttributes
       [1] IMPLICIT Attributes OPTIONAL }

   EncryptedDigest ::= OCTET STRING

   The fields of type SignerInfo have the following meanings:

        o    version is the syntax version number. It shall be
             1 for this version of the document.

        o    issuerAndSerialNumber specifies the signer's
             certificate (and thereby the signer's distinguished name
             and public key) by issuer distinguished name and issuer-
             specific serial number.

        o    digestAlgorithm identifies the message-digest
             algorithm (and any associated parameters) under which the
             content and authenticated attributes (if present) are
             digested. It should be among those in the digestAlgorithms
             field of the superior SignerInfo value. The message-
             digesting process is described in Section 9.3.

        o    authenticatedAttributes is a set of attributes
             that are signed (i.e., authenticated) by the signer. The
             field is optional, but it must be present if the content
             type of the ContentInfo value being signed is not data. If
             the field is present, it must contain, at a minimum, two
             attributes:




Kaliski                      Informational                     [Page 13]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


                  1.   A PKCS #9 content-type attribute having
                       as its value the content type of the
                       ContentInfo value being signed.

                  2.   A PKCS #9 message-digest attribute,
                       having as its value the message digest
                       of the content (see below).

             Other attribute types that might be useful here, such as
             signing time, are also defined in PKCS #9.

        o    digestEncryptionAlgorithm identifies the digest-
             encryption algorithm (and any associated parameters) under
             which the message digest and associated information are
             encrypted with the signer's private key. The digest-
             encryption process is described in Section 9.4.

        o    encryptedDigest is the result of encrypting the
             message digest and associated information with the signer's
             private key.

        o    unauthenticatedAttributes is a set of attributes
             that are not signed (i.e., authenticated) by the signer.
             The field is optional. Attribute types that might be useful
             here, such as countersignatures, are defined in PKCS #9.

   Notes.

        1.   It is recommended in the interest of PEM
             compatibility that the authenticatedAttributes field be
             omitted whenever the content type of the ContentInfo value
             being signed is data and there are no other authenticated
             attributes.

        2.   The difference between version 1 SignerInfo and
             version 0 SignerInfo (defined in PKCS #7, Version 1.4) is
             in the message-digest encryption process (see Section 9.4).
             Only the PEM-compatible processes are different, reflecting
             changes in Privacy-Enhanced Mail signature methods. There
             is no difference in the non-PEM-compatible message-digest
             encryption process.

             It is suggested that PKCS implementations generate only
             version 1 SignedData values. Since the PEM signature method
             with which version 0 is compatible is obsolescent, it is
             suggested that PKCS implementations be prepared to receive
             only version 1 SignedData values.




Kaliski                      Informational                     [Page 14]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


9.3 Message-digesting process

   The message-digesting process computes a message digest on either the
   content being signed or the content together with the signer's
   authenticated attributes. In either case, the initial input to the
   message-digesting process is the "value" of the content being signed.
   Specifically, the initial input is the contents octets of the DER
   encoding of the content field of the ContentInfo value to which the
   signing process is applied. Only the contents octets of the DER
   encoding of that field are digested, not the identifier octets or the
   length octets.

   The result of the message-digesting process (which is called,
   informally, the "message digest") depends on whether the
   authenticatedAttributes field is present. When the field is absent,
   the result is just the message digest of the content. When the field
   is present, however, the result is the message digest of the complete
   DER encoding of the Attributes value containted in the
   authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in
   the authenticatedAttributes field is not part of the Attributes
   value. The Attributes value's tag is SET OF, and the DER encoding of
   the SET OF tag, rather than of the IMPLICIT [0] tag, is to be
   digested along with the length and contents octets of the Attributes
   value.) Since the Attributes value, when the field is present, must
   contain as attributes the content type and the message digest of the
   content, those values are indirectly included in the result.

   When the content being signed has content type data and the
   authenticatedAttributes field is absent, then just the value of the
   data (e.g., the contents of a file) is digested. This has the
   advantage that the length of the content being signed need not be
   known in advance of the encryption process. This method is compatible
   with Privacy-Enhanced Mail.

   Although the identifier octets and the length octets are not
   digested, they are still protected by other means. The length octets
   are protected by the nature of the message-digest algorithm since it
   is by assumption computationally infeasible to find any two distinct
   messages of any length that have the same message digest.
   Furthermore, assuming that the content type uniquely determines the
   identifier octets, the identifier octets are protected implicitly in
   one of two ways: either by the inclusion of the content type in the
   authenticated attributes, or by the use of the PEM-compatible
   alternative in Section 9.4 which implies that the content type is
   data.






Kaliski                      Informational                     [Page 15]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   Note. The fact that the message digest is computed on part of a DER
   encoding does not mean that DER is the required method of
   representing that part for data transfer. Indeed, it is expected that
   some implementations of this document may store objects in other than
   their DER encodings, but such practices do not affect message-digest
   computation.

9.4 Digest-encryption process

   The input to the digest-encryption process--the value supplied to the
   signer's digest-encryption algorithm--includes the result of the
   message-digesting process (informally, the "message digest") and the
   digest algorithm identifier (or object identifier). The result of the
   digest-encryption process is the encryption with the signer's private
   key of the BER encoding of a value of type DigestInfo:

   DigestInfo ::= SEQUENCE {
     digestAlgorithm DigestAlgorithmIdentifier,
     digest Digest }

   Digest ::= OCTET STRING

   The fields of type DigestInfo have the following meanings:

        o    digestAlgorithm identifies the message-digest
             algorithm (and any associated parameters) under which the
             content and authenticated attributes are digested. It
             should be the same as the digestAlgorithm field of the
             superior SignerInfo value.

        o    digest is the result of the message-digesting
             process.

   Notes.

        1.   The only difference between the signature process
             defined here and the signature algorithms defined in PKCS
             #1 is that signatures there are represented as bit strings,
             for consistency with the X.509 SIGNED macro. Here,
             encrypted message digests are octet strings.

        2.   The input to the encryption process typically will
             have 30 or fewer octets. If digestEncryptionAlgorithm is
             PKCS #1's rsaEncryption, then this means that the input can
             be encrypted in a single block as long as the length of the
             RSA modulus is at least 328 bits, which is reasonable and
             consistent with security recommendations.




Kaliski                      Informational                     [Page 16]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


        3.   A message-digest algorithm identifier is included
             in the DigestInfo value to limit the damage resulting from
             the compromise of one message-digest algorithm. For
             instance, suppose an adversary were able to find messages
             with a given MD2 message digest.  That adversary could then
             forge a signature by finding a message with the same MD2
             message digest as one that a signer previously signed, and
             presenting the previous signature as the signature on the
             new message.  This attack would succeed only if the signer
             previously used MD2, since the DigestInfo value contains
             the message-digest algorithm.  If a signer never trusted
             the MD2 algorithm and always used MD5, then the compromise
             of MD2 would not affect the signer. If the DigestInfo value
             contained only the message digest, however, the compromise
             of MD2 would affect signers that use any message-digest
             algorithm.

        4.   There is potential for ambiguity due to the fact
             that the DigestInfo value does not indicate whether the
             digest field contains just the message digest of the
             content or the message digest of the complete DER encoding
             of the authenticatedAttributes field. In other words, it is
             possible for an adversary to transform a signature on
             authenticated attributes to one that appears to be just on
             content by changing the content to be the DER encoding of
             the authenticatedAttributes field, and then removing the
             authenticatedAttributes field. (The reverse transformation
             is possible, but requires that the content be the DER
             encoding of an authenticated attributes value, which is
             unlikely.) This ambiguity is not a new problem, nor is it a
             significant one, as context will generally prevent misuse.
             Indeed, it is also possible for an adversary to transform a
             signature on a certificate or certificate-revocation list
             to one that appears to be just on signed-data content.

9.5 Compatibility with Privacy-Enhanced Mail

   Compatibility with the MIC-ONLY and MIC-CLEAR process types in PEM
   occurs when the content type of the ContentInfo value being signed is
   data, there are no authenticated attributes, the message-digest
   algorithm is md2 or md5, and the digest-encryption algorithm is PKCS
   #1's rsaEncryption. Under all those conditions, the encrypted message
   digest produced here matches the one produced in PEM because:

        1.   The value input to the message-digest algorithm in
             PEM is the same as in this document when there are no
             authenticated attributes. MD2 and MD5 in PEM are the same
             as md2 and md5.



Kaliski                      Informational                     [Page 17]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


        2.   The value encrypted with the signer's private key
             in PEM (as specified in RFC 1423) is the same as in this
             document when there are no authenticated attributes. RSA
             private-key encryption in PEM is the same as PKCS #1's
             rsaEncryption.

   The other parts of the signed-data content type (certificates, CRLs,
   algorithm identifiers, etc.) are easily translated to and from their
   corresponding PEM components.

10. Enveloped-data content type

   The enveloped-data content type consists of encrypted content of any
   type and encrypted content-encryption keys for one or more
   recipients. The combination of encrypted content and encrypted
   content-encryption key for a recipient is a "digital envelope" for
   that recipient. Any type of content can be enveloped for any number
   of recipients in parallel.

   It is expected that the typical application of the enveloped-data
   content type will be to represent one or more recipients' digital
   envelopes on content of the data, digested-data, or signed-data
   content types.

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

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

        2.   For each recipient, the content-encryption key is
             encrypted with the recipient's public key.

        3.   For each recipient, the encrypted content-
             encryption key and other recipient-specific information are
             collected into a RecipientInfo value, defined in Section
             10.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 10.3 for discussion.)

        5.   The RecipientInfo values for all the recipients
             are collected together with the encrypted content into a
             EnvelopedData value, defined in Section 10.1.





Kaliski                      Informational                     [Page 18]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   A recipient opens the envelope by decrypting the one of the encrypted
   content-encryption keys with the recipient's private key and
   decrypting the encrypted content with the recovered content-
   encryption key. The recipient's private key is referenced by an
   issuer distinguished name and an issuer-specific serial number that
   uniquely identify the certificate for the corresponding public 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.

   This content type is not compatible with Privacy-Enhanced Mail
   (although some processes it defines are compatible with their PEM
   counterparts), since Privacy-Enhanced Mail always involves digital
   signatures, never digital envelopes alone.

10.1 EnvelopedData type

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

   EnvelopedData ::= SEQUENCE {
     version Version,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo }

   RecipientInfos ::= SET OF RecipientInfo

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

   EncryptedContent ::= OCTET STRING

   The fields of type EnvelopedData have the following meanings:

        o    version is the syntax version number. It shall be
             0 for this version of the document.

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

        o    encryptedContentInfo is the encrypted content
             information.



Kaliski                      Informational                     [Page 19]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   The fields of type EncryptedContentInfo have the following meanings:

        o    contentType indicates the type of content.

        o    contentEncryptionAlgorithm identifies the content-
             encryption algorithm (and any associated
             parameters) under which the content is encrypted.
             The content-encryption process is described in
             Section 10.3. This algorithm is the same for all
             recipients.

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

   Note. The fact that the recipientInfos field comes before the
   encryptedContentInfo field makes it possible to process an
   EnvelopedData value in a single pass. (Single-pass processing is
   described in Section 5.)

10.2 RecipientInfo type

   Per-recipient information is represented in the type RecipientInfo:

   RecipientInfo ::= SEQUENCE {
     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber,
     keyEncryptionAlgorithm

       KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

   EncryptedKey ::= OCTET STRING

   The fields of type RecipientInfo have the following meanings:

        o    version is the syntax version number. It shall be
             0 for this version of the document.

        o    issuerAndSerialNumber specifies the recipient's
             certificate (and thereby the recipient's
             distinguished name and public key) by issuer
             distinguished name and issuer-specific serial
             number.






Kaliski                      Informational                     [Page 20]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


        o    keyEncryptionAlgorithm identifies the key-
             encryption algorithm (and any associated
             parameters) under which the content-encryption key
             is encrypted with the recipient's public key. The
             key-encryption process is described in Section
             10.4.

        o    encryptedKey is the result of encrypting the
             content-encryption key with the recipient's public
             key (see below).

10.3 Content-encryption process

   The input to the content-encryption process is the "value" of the
   content being enveloped. Specifically, the input is the contents
   octets of a definite-length BER encoding of the content field of the
   ContentInfo value to which the enveloping process is applied. Only
   the contents octets of the BER encoding are encrypted, not the
   identifier octets or length octets; those other octets are not
   represented at all.

   When the content being enveloped has content type data, then just the
   value of the data (e.g., the contents of a file) is encrypted. This
   has the advantage that the length of the content being encrypted need
   not be known in advance of the encryption process. This method is
   compatible with Privacy-Enhanced Mail.

   The identifier octets and the length octets are not encrypted. The
   length octets may be protected implicitly by the encryption process,
   depending on the encryption algorithm. The identifier octets are not
   protected at all, although they can be recovered from the content
   type, assuming that the content type uniquely determines the
   identifier octets. Explicit protection of the identifier and length
   octets requires that the signed-and-enveloped-data content type be
   employed, or that the digested-data and enveloped-data content types
   be applied in succession.

   Notes.

        1.   The reason that a definite-length BER encoding is
             required is that the bit indicating whether the length is
             definite or indefinite is not recorded anywhere in the
             enveloped-data content type.  Definite-length encoding is
             more appropriate for simple types such as octet strings, so
             definite-length encoding is chosen.






Kaliski                      Informational                     [Page 21]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


        2.   Some content-encryption algorithms assume the
             input length is a multiple of k octets, where k > 1, and
             let the application define a method for handling inputs
             whose lengths are not a multiple of k octets. For such
             algorithms, the method shall be to pad the input at the
             trailing end with k - (l mod k) octets all having value k -
             (l mod k), where l 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 l mod k = k-1
                     02 02 -- if l mod k = k-2
                                 .
                                 .
                                 .
                   k k ... k k -- if l mod k = 0

             The padding can be removed unambiguously since all input is
             padded and no padding string is a suffix of another. This
             padding method is well-defined if and only if k < 256;
             methods for larger k are an open issue for further study.

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

11. Signed-and-enveloped-data content type

   This section defines the signed-and-enveloped-data content type. For
   brevity, much of this section is expressed in terms of material in
   Sections 9 and 10.

   The signed-and-enveloped-data content type consists of encrypted
   content of any type, encrypted content-encryption keys for one or
   more recipients, and doubly encrypted message digests for one or more
   signers. The "double encryption" consists of an encryption with a
   signer's private key followed by an encryption with the content-
   encryption key.

   The combination of encrypted content and encrypted content-encryption
   key for a recipient is a "digital envelope" for that recipient. The
   recovered singly encrypted message digest for a signer is a "digital
   signature" on the recovered content for that signer.  Any type of
   content can be enveloped for any number of recipients and signed by
   any number of signers in parallel.




Kaliski                      Informational                     [Page 22]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   It is expected that the typical application of the signed-and-
   enveloped-data content type will be to represent one signer's digital
   signature and one or more recipients' digital envelopes on content of
   the data content type.

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

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

        2.   For each recipient, the content-encryption key is
             encrypted with the recipient's public key.

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

        4.   For each signer, a message digest is computed on
             the content with a signer-specific message-digest
             algorithm. (If two signers employ the same message-
             digest algorithm, then the message digest need be
             computed for only one of them.)

        5.   For each signer, the message digest and associated
             information are encrypted with the signer's
             private key, and the result is encrypted with the
             content-encryption key. (The second encryption may
             require that the result of the first encryption be
             padded to a multiple of some block size; see
             Section 10.3 for discussion.)

        6.   For each signer, the doubly encrypted message
             digest and other signer-specific information are
             collected into a SignerInfo value, defined in
             Section 9.2.

        7.   The content is encrypted with the content-
             encryption key. (See Section 10.3 for discussion.)

        8.   The message-digest algorithms for all the signers,
             the SignerInfo values for all the signers and the
             RecipientInfo values for all the recipients are
             collected together with the encrypted content into
             a SignedAndEnvelopedData value, defined in Section
             11.1.




Kaliski                      Informational                     [Page 23]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   A recipient opens the envelope and verifies the signatures in two
   steps. First, the one of the encrypted content-encryption keys is
   decrypted with the recipient's private key, and the encrypted content
   is decrypted with the recovered content-encryption key. Second, the
   doubly encrypted message digest for each signer is decrypted with the
   recovered content-encryption key, the result is decrypted with the
   signer's public key, and the recovered message digest is compared to
   an independently computed message digest.

   Recipient private keys and signer public keys are contained or
   referenced as discussed in Sections 9 and 10.

   This section is divided into three parts. The first part describes
   the top-level type SignedAndEnvelopedData and the second part
   describes the digest-encryption process. Other types and processes
   are the same as in Sections 9 and 10.  The third part summarizes
   compatibility with Privacy-Enhanced Mail.

   Note. The signed-and-enveloped-data content type provides
   cryptographic enhancements similar to those resulting from the
   sequential combination of signed-data and enveloped-data content
   types. However, since the signed-and-enveloped-data content type does
   not have authenticated or unauthenticated attributes, nor does it
   provide enveloping of signer information other than the signature,
   the sequential combination of signed-data and enveloped-data content
   types is generally preferable to the SignedAndEnvelopedData content
   type, except when compatibility with the ENCRYPTED process type in
   Privacy-Enhanced Mail in intended.

11.1 SignedAndEnvelopedData type

   The signed-and-enveloped-data content type shall have ASN.1 type
   SignedAndEnvelopedData:

   SignedAndEnvelopedData ::= SEQUENCE {
     version Version,
     recipientInfos RecipientInfos,
     digestAlgorithms DigestAlgorithmIdentifiers,
     encryptedContentInfo EncryptedContentInfo,
     certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
          OPTIONAL,
     crls
       [1] IMPLICIT CertificateRevocationLists OPTIONAL,
     signerInfos SignerInfos }






Kaliski                      Informational                     [Page 24]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   The fields of type SignedAndEnvelopedData have the following
   meanings:

        o    version is the syntax version number. It shall be
             1 for this version of the document.

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

        o    digestAlgorithms is a collection of message-digest
             algorithm identifiers, as in Section 9. The
             message-digesting process is the same as in
             Section 9 in the case when there are no
             authenticated attributes.

        o    encryptedContentInfo is the encrypted content, as
             in Section 10. It can have any of the defined
             content types.

        o    certificates is a set of PKCS #6 extended
             certificates and X.509 certificates, as in Section
             9.

        o    crls is a set of certificate-revocation lists, as
             in Section 9.

        o    signerInfos is a collection of per-signer
             information. There must be at least one element in
             the collection. SignerInfo values have the same
             meaning as in Section 9 with the exception of the
             encryptedDigest field (see below).

   Notes.

        1.   The fact that the recipientInfos and
             digestAlgorithms fields come before the contentInfo field
             and the signerInfos field comes after it makes it possible
             to process a SignedAndEnvelopedData value in a single pass.
             (Single-pass processing is described in Section 5.)

        2.   The difference between version 1
             SignedAndEnvelopedData and version 0 SignedAndEnvelopedData
             (defined in PKCS #7, Version 1.4) is that the crls field is
             allowed in version 1, but not in version 0. Except for the
             difference in version number, version 0
             SignedAndEnvelopedData values are acceptable as version 1
             values. An implementation can therefore process



Kaliski                      Informational                     [Page 25]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


             SignedAndEnvelopedData values of either version as though
             they were version 1 values. It is suggested that PKCS
             implementations generate only version 1
             SignedAndEnvelopedData values, but be prepared to process
             SignedAndEnvelopedData values of either version.

11.2 Digest-encryption process

   The input to the digest-encryption process is the same as in Section
   9, but the process itself is different.  Specifically, the process
   involves two steps. First, the input to the process is supplied to
   the signer's digest-encryption algorithm, as in Section 9. Second,
   the result of the first step is encrypted with the content-encryption
   key.  There is no DER encoding between the two steps; the "value"
   output by the first step is input directly to the second step. (See
   Section 10.3 for discussion.)

   This process is compatible with the ENCRYPTED process type in
   Privacy-Enhanced Mail.

   Note. The purpose of the second step is to prevent an adversary from
   recovering the message digest of the content.  Otherwise, an
   adversary would be able to determine which of a list of candidate
   contents (e.g., "Yes" or "No") is the actual content by comparing the
   their message digests to the actual message digest.

11.3 Compatibility with Privacy-Enhanced Mail

   Compatibility with the ENCRYPTED process type of PEM occurs when the
   content type of the ContentInfo value being signed and enveloped is
   data, the message-digest algorithm is md2 or md5, the content-
   encryption algorithm is DES in CBC mode, the digest-encryption
   algorithm is PKCS #1's rsaEncryption, and the key-encryption
   algorithm is PKCS #1's rsaEncryption.  Under all those conditions,
   the doubly encrypted message digest and the encrypted content
   encryption key match the ones produced in PEM because of reasons
   similar to those given in Section 9.5, as well as the following:

        1.   The value input to the content-encryption
             algorithm in PEM is the same as in this document.
             DES in CBC mode is the same as desCBC.

        2.   The value input to the key-encryption algorithm in
             PEM is the same as in this document (see Section
             10.4). RSA public-key encryption in PEM is the
             same as PKCS #1's rsaEncryption.





Kaliski                      Informational                     [Page 26]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


        3.   The double-encryption process applied to the
             message digest in this document and in PEM are the
             same.

   The other parts of the signed-and-enveloped-data content type
   (certificates, CRLs, algorithm identifiers, etc.) are easily
   translated to and from their corresponding PEM components. (CRLs are
   carried in a separate PEM message.)

12. Digested-data content type

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

   It is expected that the typical application of the digested-data
   content type will be to add integrity to content of the data content
   type, and that the result would become the content input to the
   enveloped-data content type.

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

        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 digested-data content type shall have ASN.1 type DigestedData:

   DigestedData ::= SEQUENCE {
     version Version,
     digestAlgorithm DigestAlgorithmIdentifier,
     contentInfo ContentInfo,
     digest Digest }

   Digest ::= OCTET STRING

   The fields of type DigestedData have the following meanings:

        o    version is the syntax version number. It shall be
             0 for this version of the document.





Kaliski                      Informational                     [Page 27]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


        o    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 9 in the case when there are no
             authenticated attributes.)

        o    contentInfo is the content that is digested. It
             can have any of the defined content types.

        o    digest is the result of the message-digesting process.

   Note. The fact that the digestAlgorithm field comes before the
   contentInfo field and the digest field comes after it makes it
   possible to process a DigestedData value in a single pass.  (Single-
   pass processing is described in Section 5.)

13. 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 are assumed to be managed by other means.

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

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

   EncryptedData ::= SEQUENCE {
     version Version,
     encryptedContentInfo EncryptedContentInfo }

   The fields of type EncryptedData have the following meanings:

        o    version is the syntax version number. It shall be
             0 for this version of the document.

        o    encryptedContentInfo is the encrypted content
             information, as in Section 10.

14. Object identifiers

   This document defines seven object identifiers: pkcs-7, data,
   signedData, envelopedData, signedAndEnvelopedData, digestedData, and
   encryptedData.





Kaliski                      Informational                     [Page 28]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   The object identifier pkcs-7 identifies this document.

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

   The object identifiers data, signedData, envelopedData,
   signedAndEnvelopedData, digestedData, and encryptedData, identify,
   respectively, the data, signed-data, enveloped-data, signed-and-
   enveloped-data, digested-data, and encrypted-data content types
   defined in Sections 8-13.

   data OBJECT IDENTIFIER ::= { pkcs-7 1 }
   signedData OBJECT IDENTIFIER ::= { pkcs-7 2 }
   envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
   signedAndEnvelopedData OBJECT IDENTIFIER ::=
      { pkcs-7 4 }
   digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
   encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }

   These object identifiers are intended to be used in the contentType
   field of a value of type ContentInfo (see Section 5). The content
   field of that type, which has the content-type-specific syntax ANY
   DEFINED BY contentType, would have ASN.1 type Data, SignedData,
   EnvelopedData, SignedAndEnvelopedData, DigestedData, and
   EncryptedData, respectively. These object identifiers are also
   intended to be used in a PKCS #9 content-type attribute.

Security Considerations

   Security issues are discussed throughout this memo.

Revision history


   Versions 1.0-1.3

   Versions 1.0-1.3 were distributed to participants in RSA Data
   Security, Inc.'s Public-Key Cryptography Standards meetings in
   February and March 1991.


   Version 1.4

   Version 1.4 is part of the June 3, 1991 initial public release of
   PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop
   document SEC-SIG-91-22.




Kaliski                      Informational                     [Page 29]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   Version 1.5

   Version 1.5 incorporates several editorial changes, including updates
   to the references and the addition of a revision history. The
   following substantive changes were made:

        o    Section 6: CertificateRevocationLists type is
             added.

        o    Section 9.1: SignedData syntax is revised. The new
             version allows for the dissemination of
             certificate-revocation lists along with
             signatures. It also allows for the dissemination
             of certificates and certificate-revocation lists
             alone, without any signatures.

        o    Section 9.2: SignerInfo syntax is revised. The new
             version includes a message-digest encryption
             process compatible with Privacy-Enhanced Mail as
             specified in RFC 1423.

        o    Section 9.3: Meaning of "the DER encoding of the
             authenticatedAttributes field" is clarified as
             "the DER encoding of the Attributes value."

        o    Section 10.3: Padding method for content-
             encryption algorithms is described.

        o    Section 11.1: SignedAndEnvelopedData syntax is
             revised. The new version allows for the
             dissemination of certificate-revocation lists.

        o    Section 13: Encrypted-data content type is added.
             This content type consists of encrypted content of
             any type.

        o    Section 14: encryptedData object identifier is
             added.

   Supersedes June 3, 1991 version, which was also published as NIST/OSI
   Implementors' Workshop document SEC-SIG-91-22.










Kaliski                      Informational                     [Page 30]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


Acknowledgements

   This document is based on a contribution of RSA Laboratories, a
   division of RSA Data Security, Inc.  Any substantial use of the text
   from this document must acknowledge RSA Data Security, Inc. RSA Data
   Security, Inc.  requests that all material mentioning or referencing
   this document identify this as "RSA Data Security, Inc. PKCS #7".

Author's Address

   Burt Kaliski
   RSA Laboratories East
   20 Crosby Drive
   Bedford, MA  01730

   Phone: (617) 687-7000
   EMail: burt@rsa.com


































Kaliski                      Informational                     [Page 31]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Kaliski                      Informational                     [Page 32]