File: rfc3125.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 (2467 lines) | stat: -rw-r--r-- 95,505 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
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






Network Working Group                                            J. Ross
Request for Comments: 3125                          Security & Standards
Category: Experimental                                         D. Pinkas
                                                                Integris
                                                                 N. Pope
                                                    Security & Standards
                                                          September 2001


                     Electronic Signature Policies

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document defines signature policies for electronic signatures. A
   signature policy is a set of rules for the creation and validation of
   an electronic signature, under which the validity of signature can be
   determined.  A given legal/contractual context may recognize a
   particular signature policy as meeting its requirements.

   A signature policy has a globally unique reference, which is bound to
   an electronic signature by the signer as part of the signature
   calculation.

   The signature policy needs to be available in human readable form so
   that it can be assessed to meet the requirements of the legal and
   contractual context in which it is being applied.

   To allow for the automatic processing of an electronic signature
   another part of the signature policy specifies the electronic rules
   for the creation and validation of the electronic signature in a
   computer processable form.  In the current document the format of the
   signature policy is defined using ASN.1.

   The contents of this document is based on the signature policy
   defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).
   Individual copies of this ETSI deliverable can be downloaded from
   http://www.etsi.org.



Ross, et al.                  Experimental                      [Page 1]

RFC 3125             Electronic Signature Policies        September 2001


Table of Contents

   1.  Introduction                                                    3
   2.  Major Parties                                                   3
   3.  Signature Policy Specification                                  5
   3.1  Overall ASN.1 Structure                                        5
   3.2  Signature Validation Policy                                    6
   3.3  Common Rules                                                   7
   3.4  Commitment Rules                                               8
   3.5  Signer and Verifier Rules                                      9
   3.5.1  Signer Rules                                                 9
   3.5.2  Verifier Rules                                              11
   3.6  Certificate and Revocation Requirements                       11
   3.6.1  Certificate Requirements                                    11
   3.6.2  Revocation Requirements                                     13
   3.7  Signing Certificate Trust Conditions                          14
   3.8  Time-Stamp Trust Conditions                                   15
   3.9  Attribute Trust Conditions                                    16
   3.10  Algorithm Constraints                                        17
   3.11  Signature Policy Extensions                                  18
   4.  Security Considerations                                        18
   4.1  Protection of Private Key                                     18
   4.2  Choice of Algorithms                                          18
   5.  Conformance Requirements                                       19
   6.  References                                                     19
   7. Authors' Addresses                                              20
   Annex A (normative):                                               21
   A.1  Definitions Using X.208 (1988) ASN.1 Syntax                   21
   A.2  Definitions Using X.680 (1997) ASN.1 Syntax                   27
   Annex B (informative):                                             34
   B.1  Signature Policy and Signature Validation Policy              34
   B.2  Identification of Signature Policy                            36
   B.3  General Signature Policy Information                          36
   B.4  Recognized Commitment Types                                   37
   B.5  Rules for Use of Certification Authorities                    37
   B.5.1  Trust Points                                                38
   B.5.2  Certification Path                                          38
   B.6  Revocation Rules                                              39
   B.7  Rules for the Use of Roles                                    39
   B.7.1  Attribute Values                                            39
   B.7.2  Trust Points for Certified Attributes                       40
   B.7.3  Certification Path for Certified Attributes                 40
   B.8  Rules for the Use of Time-Stamping and Timing                 40
   B.8.1  Trust Points and Certificate Paths                          41
   B.8.2  Time-Stamping Authority Names                               41
   B.8.3  Timing Constraints - Caution Period                         41
   B.8.4  Timing Constraints - Time-Stamp Delay                       41
   B.9  Rules for Verification Data to be followed                    41



Ross, et al.                  Experimental                      [Page 2]

RFC 3125             Electronic Signature Policies        September 2001


   B.10  Rules for Algorithm Constraints and Key Lengths              42
   B.11  Other Signature Policy Rules                                 42
   B.12  Signature Policy Protection                                  42
   Full Copyright Statement                                           44

1.  Introduction

   This document is intended to cover signature policies which can be
   used with electronic signatures for various types of transactions,
   including business transactions (e.g., purchase requisition,
   contract, and invoice applications).  Electronic signatures can be
   used for any transaction between an individual and a company, between
   two companies, between an individual and a governmental body, etc.
   This document is independent of any environment.  It can be applied
   to any environment e.g., smart cards, GSM SIM cards, special programs
   for electronic signatures etc.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
   as shown) are to be interpreted as described in [RFC2119].

2.  Major Parties

   The document uses the following terms:

      *  the Signature Policy Issuer;
      *  the Signer;
      *  the Verifier;
      *  the Arbitrator;
      *  Trusted Service Providers (TSP);

   The Signature Policy Issuer (which is a Trusted Service Provider
   (TSP)) issues signatures policies that define the technical and
   procedural requirements for electronic signature creation, and
   validation/ verification, in order to meet a particular business
   need.

   The Signer is the entity that creates the electronic signature.  When
   the signer digitally signs over an signature policy identifier, it
   represents a commitment on behalf of the signing entity that the data
   being signed is signed under the rules defined by the signature
   policy.

   The Verifier is the entity that validates the electronic signature,
   it may be a single entity or multiple entities.  The verifier MUST
   validate the electronic signature under the rules defined by the
   electronic signature policy for the signature to be valid.




Ross, et al.                  Experimental                      [Page 3]

RFC 3125             Electronic Signature Policies        September 2001


   An arbitrator, is an entity which arbitrates disputes between a
   signer and a verifier.  It acts as verifier when it verifies the
   electronic signature after it has been previously validated.

   The Trusted Service Providers (TSPs) are one or more entities that
   help to build trust relationships between the signer and verifier.
   Use of TSP specific services MAY be mandated by signature policy.
   TSP supporting services include: user certificates, cross-
   certificates, time-stamping tokens,CRLs, ARLs, OCSP responses.

   A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer,
   as Such, the TSP MUST define the technical and procedural
   requirements for electronic signature creation and validation, in
   order to meet a particular business need.

   The following other TSPs are used to support the functions defined in
   this document:

      *  Certification Authorities;
      *  Registration Authorities;
      *  Repository Authorities (e.g., a Directory);
      *  Time-Stamping Authorities;
      *  One-line Certificate Status Protocol responders;
      *  Attribute Authorities.

   Certification Authorities provide users with public key certificates.

   Registration Authorities allows the registration of entities before a
   CA generates certificates.

   Repository Authorities publish CRLs issued by CAs, , cross-
   certificates (i.e., CA certificates) issued by CAs, signature
   policies issued by Signature Policy Issuers and optionally public key
   certificates (i.e., leaf certificates) issued by CAs.

   Time-Stamping Authorities attest that some data was formed before a
   given trusted time.

   One-line Certificate Status Protocol responders (OSCP responders)
   provide information about the status (i.e., revoked, not revoked,
   unknown) of a particular certificate.

   Attributes Authorities provide users with attributes linked to public
   key certificates

   An Arbitrator is an entity that arbitrates disputes between a signer
   and a verifier.




Ross, et al.                  Experimental                      [Page 4]

RFC 3125             Electronic Signature Policies        September 2001


3.  Signature Policy Specification

   A signature policy specification includes general information about
   the policy, the validation policy rules and other signature policy
   information.

   This document mandates that:

      *  an electronic signature must be processed by the signer and
         verifier in accordance with the signature policy referenced by
         the signer;
      *  the signature policy referenced by the signer must be
         identifiable by an Object Identifier;
      *  there must exist a specification of the signature policy;
      *  for a given signature policy there must be one definitive form
         of the specification which has a unique binary encoding;
      *  a hash of the definitive specification, using an agreed
         algorithm, must be provided by the signer and checked by the
         verifier.

   This document defines but does not mandate the form of the signature
   policy specification.  The signature policy may be specified either:

      *  in a free form document for human interpretation; or
      *  in a structured form using an agreed syntax and encoding.

   This document defines an ASN.1 based syntax that may be used to
   define a structured signature policy.  Future versions of this
   document may include structured a signature policy specification
   using XML.

3.1  Overall ASN.1 Structure

   The overall structure of a signature policy defined using ASN.1 is
   given in this section.  Use of this ASN.1 structure is optional.

   This ASN.1 syntax is encoded using the Distinguished Encoding Rules
   (DER).

   In this structure the policy information is preceded by an identifier
   for the hashing algorithm used to protect the signature policy and
   followed by the hash value which must be re-calculated and checked
   whenever the signature policy is passed between the issuer and
   signer/verifier.

   The hash is calculated without the outer type and length fields.





Ross, et al.                  Experimental                      [Page 5]

RFC 3125             Electronic Signature Policies        September 2001


SignaturePolicy ::= SEQUENCE {
        signPolicyHashAlg      AlgorithmIdentifier,
        signPolicyInfo         SignPolicyInfo,
        signPolicyHash         SignPolicyHash     OPTIONAL }

SignPolicyHash ::= OCTET STRING

SignPolicyInfo ::= SEQUENCE {
        signPolicyIdentifier            SignPolicyId,
        dateOfIssue                     GeneralizedTime,
        policyIssuerName                PolicyIssuerName,
        fieldOfApplication              FieldOfApplication,
        signatureValidationPolicy       SignatureValidationPolicy,
        signPolExtensions               SignPolExtensions
                                                   OPTIONAL
                                                         }

SignPolicyId ::= OBJECT IDENTIFIER

PolicyIssuerName ::= GeneralNames

FieldOfApplication ::= DirectoryString

   The policyIssuerName field identifies the policy issuer in one or
   more of the general name forms.

   The fieldofApplication is a description of the expected application
   of this policy.

   The signature validation policy rules are fully processable to allow
   the validation of electronic signatures issued under that form of
   signature policy.  They are described in the rest of this section.

   The signPolExtensions is a generic way to extend the definition of
   any sub-component of a signature policy.

3.2  Signature Validation Policy

   The signature validation policy defines for the signer which data
   elements must be present in the electronic signature he provides and
   for the verifier which data elements must be present under that
   signature policy for an electronic signature to be potentially valid.

   The signature validation policy is described as follows:







Ross, et al.                  Experimental                      [Page 6]

RFC 3125             Electronic Signature Policies        September 2001


SignatureValidationPolicy ::= SEQUENCE {
        signingPeriod          SigningPeriod,
        commonRules            CommonRules,
        commitmentRules        CommitmentRules,
        signPolExtensions      SignPolExtensions        OPTIONAL
                                                }

   The signingPeriod identifies the date and time before which the
   signature policy SHOULD NOT be used for creating signatures, and an
   optional date after which it should not be used for creating
   signatures.

SigningPeriod ::= SEQUENCE {
        notBefore       GeneralizedTime,
        notAfter        GeneralizedTime OPTIONAL }

3.3  Common Rules

   The CommonRules define rules that are common to all commitment types.
   These rules are defined in terms of trust conditions for
   certificates, time-stamps and attributes, along with any constraints
   on attributes that may be included in the electronic signature.

CommonRules  ::= SEQUENCE {
        signerAndVeriferRules          [0]  SignerAndVerifierRules
                                                        OPTIONAL,
        signingCertTrustCondition      [1]  SigningCertTrustCondition
                                                        OPTIONAL,
        timeStampTrustCondition        [2]  TimestampTrustCondition
                                                        OPTIONAL,
        attributeTrustCondition        [3]  AttributeTrustCondition
                                                        OPTIONAL,
        algorithmConstraintSet         [4]  AlgorithmConstraintSet
                                                        OPTIONAL,
        signPolExtensions              [5]  SignPolExtensions
                                                         OPTIONAL
                                                       }

   If a field is present in CommonRules then the equivalent field must
   not be present in any of the CommitmentRules (see below).  If any of
   the following fields are not present in CommonRules then it must be
   present in each CommitmentRule:

      *  signerAndVeriferRules;
      *  signingCertTrustCondition;
      *  timeStampTrustCondition.





Ross, et al.                  Experimental                      [Page 7]

RFC 3125             Electronic Signature Policies        September 2001


3.4  Commitment Rules

   The CommitmentRules consists of the validation rules which apply to
   given commitment types:

   CommitmentRules ::= SEQUENCE OF CommitmentRule

   The CommitmentRule for given commitment types are defined in terms of
   trust conditions for certificates, time-stamps and attributes, along
   with any constraints on attributes that may be included in the
   electronic signature.

CommitmentRule  ::= SEQUENCE {
        selCommitmentTypes                  SelectedCommitmentTypes,
        signerAndVeriferRules          [0]  SignerAndVerifierRules
                                                          OPTIONAL,
        signingCertTrustCondition      [1]  SigningCertTrustCondition
                                                          OPTIONAL,
        timeStampTrustCondition        [2]  TimestampTrustCondition
                                                          OPTIONAL,
        attributeTrustCondition        [3]  AttributeTrustCondition
                                                          OPTIONAL,
        algorithmConstraintSet         [4]  AlgorithmConstraintSet
                                                          OPTIONAL,
        signPolExtensions              [5]  SignPolExtensions
                                                          OPTIONAL
                                                       }

SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
        empty                        NULL,
        recognizedCommitmentType     CommitmentType }


   If the SelectedCommitmentTypes indicates "empty" then this rule
   applied when a commitment type is not present  (i.e., the type of
   commitment is indicated in the semantics of the message).  Otherwise,
   the electronic signature must contain a commitment type indication
   that must fit one of the commitments types that are mentioned in
   CommitmentType.

   A specific commitment type identifier must not appear in more than
   one commitment rule.

CommitmentType ::= SEQUENCE {
        identifier                      CommitmentTypeIdentifier,
        fieldOfApplication      [0] FieldOfApplication OPTIONAL,
        semantics               [1] DirectoryString OPTIONAL }




Ross, et al.                  Experimental                      [Page 8]

RFC 3125             Electronic Signature Policies        September 2001


   The fieldOfApplication and semantics fields define the specific use
   and meaning of the commitment within the overall field of application
   defined for the policy.

3.5  Signer and Verifier Rules

   The following rules apply to the format of electronic signatures
   defined using [ES-FORMATS].

   The SignerAndVerifierRules consists of signer rule and verification
   rules as defined below:

SignerAndVerifierRules ::= SEQUENCE {
        signerRules      SignerRules,
        verifierRules    VerifierRules }

3.5.1  Signer Rules

   The signer rules identify:

      *  if the eContent is empty and the signature is calculated using
         a hash of signed data external to CMS structure.

      *  the CMS signed attributes that must be provided by the signer
         under this policy;

      *  the CMS unsigned attribute that must be provided by the signer
         under this policy;

      *  whether the certificate identifiers from the full certification
         path up to the trust point must be provided by the signer in
         the SigningCertificate attribute;

      *  whether a signer's certificate, or all certificates in the
         certification path to the trust point must be by the signer in
         the *  certificates field of SignedData.

SignerRules ::= SEQUENCE {
        externalSignedData         BOOLEAN      OPTIONAL,
                   -- True if signed data is external to CMS structure
                        -- False if signed data part of CMS structure
                        -- Not present if either allowed
        mandatedSignedAttr         CMSAttrs,
                                 -- Mandated CMS signed attributes
        mandatedUnsignedAttr       CMSAttrs,
                                 -- Mandated CMS unsigned attributed
        mandatedCertificateRef     [0] CertRefReq DEFAULT signerOnly,
                                 -- Mandated Certificate Reference



Ross, et al.                  Experimental                      [Page 9]

RFC 3125             Electronic Signature Policies        September 2001


        mandatedCertificateInfo    [1] CertInfoReq DEFAULT none,
                                 -- Mandated Certificate Info
        signPolExtensions          [2] SignPolExtensions        OPTIONAL
                                                }

CMSattrs ::= SEQUENCE OF OBJECT IDENTIFIER

   The mandated SignedAttr field must include the object identifier for
   all those signed attributes required by this document as well as
   additional attributes required by this policy.

   The mandatedUnsignedAttr field must include the object identifier for
   all those unsigned attributes required by this document as well as
   additional attributes required by this policy.  For example, if a
   signature time-stamp <see section 1.1) is required by the signer the
   object identifier for this attribute must be included.

   The mandatedCertificateRef identifies whether just the signer's
   certificate, or all the full certificate path must be provided by the
   signer.

CertRefReq ::= ENUMERATED {
                                signerOnly (1),
           -- Only reference to signer cert mandated
                                fullpath (2)

           -- References for full cert path up to a trust point required
                                        }

   The mandatedCertificateInfo field identifies whether a signer's
   certificate, or all certificates in the certification path to the
   trust point must be provided by the signer in the certificates field
   of SignedData.

CertInfoReq ::= ENUMERATED {
                                none (0)        ,
                        -- No mandatory requirements
                                signerOnly (1)  ,
                        -- Only reference to signer cert mandated
                                fullpath (2)
                        -- References for full cert path up to a
                        -- trust point mandated
                                                   }








Ross, et al.                  Experimental                     [Page 10]

RFC 3125             Electronic Signature Policies        September 2001


3.5.2  Verifier Rules

   The verifier rules identify:

      *  The CMS unsigned attributes that must be present under this
         policy and must be added by the verifier if not added by the
         signer.

VerifierRules ::= SEQUENCE {
                mandatedUnsignedAttr    MandatedUnsignedAttr,
                signPolExtensions           SignPolExtensions  OPTIONAL
                                                                   }

MandatedUnsignedAttr ::=  CMSAttrs
                                   -- Mandated CMS unsigned attributed

3.6  Certificate and Revocation Requirement

   The SigningCertTrustCondition, TimestampTrustCondition and
   AttributeTrustCondition (defined in subsequent sub-sections) make use
   of two ASN1 structures which are defined below: CertificateTrustTrees
   and CertRevReq.

3.6.1  Certificate Requirements

   The certificateTrustTrees identifies a set of self signed
   certificates for the trust points used to start (or end) certificate
   path processing and the initial conditions for certificate path
   validation as defined RFC 2459 [7] section 4.  This ASN1 structure is
   used to define policy for validating the signing certificate, the
   TSA's certificate and attribute certificates.

CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
        trustpoint                              Certificate,
                               -- self-signed certificate
        pathLenConstraint       [0] PathLenConstraint   OPTIONAL,
        acceptablePolicySet     [1] AcceptablePolicySet OPTIONAL,
                                -- If not present "any policy"
        nameConstraints         [2] NameConstraints     OPTIONAL,
        policyConstraints       [3] PolicyConstraints   OPTIONAL }


   The trustPoint field gives the self signed certificate for the CA
   that is used as the trust point for the start of certificate path
   processing.




Ross, et al.                  Experimental                     [Page 11]

RFC 3125             Electronic Signature Policies        September 2001


   The pathLenConstraint field gives the maximum number of CA
   certificates that may be in a certification path following the
   trustpoint.  A value of zero indicates that only the given trustpoint
   certificate and an end-entity certificate may be used.  If present,
   the pathLenConstraint field must be greater than or equal to zero.
   Where pathLenConstraint is not present, there is no limit to the
   allowed length of the certification path.

   PathLenConstraint    ::=   INTEGER (0..MAX)

   The acceptablePolicySet field identifies the initial set of
   certificate policies, any of which are acceptable under the signature
   policy.  AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

   CertPolicyId ::= OBJECT IDENTIFIER

   The nameConstraints field indicates a name space within which all
   subject names in subsequent certificates in a certification path must
   be located.  Restrictions may apply to the subject distinguished name
   or subject alternative names.  Restrictions apply only when the
   specified name form is present.  If no name of the type is in the
   certificate, the certificate is acceptable.

   Restrictions are defined in terms of permitted or excluded name
   subtrees.  Any name matching a restriction in the excludedSubtrees
   field is invalid regardless of information appearing in the
   permittedSubtrees.

NameConstraints ::= SEQUENCE {
          permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
          excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

     GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

     GeneralSubtree ::= SEQUENCE {
          base                    GeneralName,
          minimum         [0]     BaseDistance DEFAULT 0,
          maximum         [1]     BaseDistance OPTIONAL }

     BaseDistance ::= INTEGER (0..MAX)

   The policyConstraints extension constrains path processing in two
   ways. It can be used to prohibit policy mapping or require that each
   certificate in a path contain an acceptable policy identifier.

   The policyConstraints field, if present specifies requirement for
   explicit indication of the certificate policy and/or the constraints
   on policy mapping.



Ross, et al.                  Experimental                     [Page 12]

RFC 3125             Electronic Signature Policies        September 2001


PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

   If the inhibitPolicyMapping field is present, the value indicates the
   number of additional certificates that may appear in the path
   (including the trustpoint's self certificate) before policy mapping
   is no longer permitted.  For example, a value of one indicates that
   policy mapping may be processed in certificates issued by the subject
   of this certificate, but not in additional certificates in the path.

   If the requireExplicitPolicy field is present, subsequent
   certificates must include an acceptable policy identifier.  The value
   of requireExplicitPolicy indicates the number of additional
   certificates that may appear in the path (including the trustpoint's
   self certificate) before an explicit policy is required.  An
   acceptable policy identifier is the identifier of a policy required
   by the user of the certification path or the identifier of a policy
   which has been declared equivalent through policy mapping.

3.6.2  Revocation Requirements

   The RevocRequirements field specifies minimum requirements for
   revocation information, obtained through CRLs and/or OCSP responses,
   to be used in checking the revocation status of certificates.  This
   ASN1 structure is used to define policy for validating the signing
   certificate, the TSA's certificate and attribute certificates.

CertRevReq ::= SEQUENCE {
        endCertRevReq   RevReq,
        caCerts     [0] RevReq
                                            }

   Certificate revocation requirements are specified in terms of checks
   required on:

      *  endCertRevReq: end certificates (i.e., the signers certificate,
         the attribute certificate or the time-stamping authority
         certificate).

      *  caCerts: CA certificates.

            RevReq ::= SEQUENCE  {
             enuRevReq  EnuRevReq,
             exRevReq    SignPolExtensions OPTIONAL}




Ross, et al.                  Experimental                     [Page 13]

RFC 3125             Electronic Signature Policies        September 2001


   An authority certificate is certificate issued to an authority (e.g.,
   either to a certification authority or to an attribute authority
   (AA)).

   A Time-Stamping Authority (TSA) is a trusted third party that creates
   time-stamp tokens in order to indicate that a datum existed at a
   particular point in time.  See [TSP].

EnuRevReq  ::= ENUMERATED {
        clrCheck        (0),
                   --Checks must be made against current CRLs
                   -- (or authority revocation lists (ARL))
        ocspCheck       (1), -- The revocation status must be checked
                  -- using the Online Certificate Status Protocol
                  -- (OCSP),RFC 2450.
        bothCheck       (2),
                  -- Both CRL and OCSP checks must be carried out
        eitherCheck     (3),
                  -- At least one of CRL or OCSP checks must be
                  -- carried out
        noCheck         (4),
                  -- no check is mandated
        other           (5)
                  -- Other mechanism as defined by signature policy
                  -- extension
          }

   Revocation requirements are specified in terms of:

      *  clrCheck: Checks must be made against current CRLs (or
         authority revocation lists);
      *  ocspCheck: The revocation status must be checked using the
         Online Certificate Status Protocol (RFC 2450);
      *  bothCheck: Both OCSP and CRL checks must be carried out;
      *  eitherCheck: Either OCSP or CRL checks must be carried out;
      *  noCheck: No check is mandated.

3.7  Signing Certificate Trust Conditions

   The SigningCertTrustCondition field identifies trust conditions for
   certificate path processing used to validate the signing certificate.

SigningCertTrustCondition ::=   SEQUENCE {
     signerTrustTrees              CertificateTrustTrees,
     signerRevReq                  CertRevReq
                                             }





Ross, et al.                  Experimental                     [Page 14]

RFC 3125             Electronic Signature Policies        September 2001


3.8  Time-Stamp Trust Conditions

   The TimeStampTrustCondition field identifies trust conditions for
   certificate path processing used to authenticate the timstamping
   authority and constraints on the name of the time-stamping authority.
   This applies to the time-stamp that must be present in every ES-T.

TimestampTrustCondition ::= SEQUENCE {
    ttsCertificateTrustTrees    [0]     CertificateTrustTrees
                                           OPTIONAL,
    ttsRevReq                   [1]             CertRevReq
                                           OPTIONAL,
    ttsNameConstraints          [2]             NameConstraints
                                           OPTIONAL,
    cautionPeriod               [3]             DeltaTime
                                           OPTIONAL,
    signatureTimestampDelay     [4]             DeltaTime
                                           OPTIONAL }

DeltaTime ::= SEQUENCE {
        deltaSeconds    INTEGER,
        deltaMinutes    INTEGER,
        deltaHours      INTEGER,
        deltaDays       INTEGER }

   If ttsCertificateTrustTrees is not present then the same rule as
   defined in certificateTrustCondition applies to certification of the
   time-stamping authorities public key.

   The tstrRevReq specifies minimum requirements for revocation
   information, obtained through CRLs and/or OCSP responses, to be used
   in checking the revocation status of the time-stamp that must be
   present in the ES-T.

   If ttsNameConstraints is not present then there are no additional
   naming constraints on the trusted time-stamping authority other than
   those implied by the ttsCertificateTrustTrees.

   The cautionPeriod field specifies a caution period after the signing
   time that it is mandated the verifier must wait to get high assurance
   of the validity of the signer's key and that any relevant revocation
   has been notified.  The revocation status information forming the ES
   with Complete validation data must not be collected and used to
   validate the electronic signature until after this caution period.

   The signatureTimestampDelay field specifies a maximum acceptable time
   between the signing time and the time at which the signature time-
   stamp, as used to form the ES Time-Stamped, is created for the



Ross, et al.                  Experimental                     [Page 15]

RFC 3125             Electronic Signature Policies        September 2001


   verifier.  If the signature time-stamp is later that the time in the
   signing-time attribute by more than the value given in
   signatureTimestampDelay, the signature must be considered invalid.

3.9  Attribute Trust Conditions

   If the attributeTrustCondition field is not present then any
   certified attributes may not considered to be valid under this
   validation policy.  The AttributeTrustCondition field is defined as
   follows:

AttributeTrustCondition ::= SEQUENCE {
      attributeMandated            BOOLEAN,
                                   -- Attribute must be present
      howCertAttribute             HowCertAttribute,
      attrCertificateTrustTrees   [0] CertificateTrustTrees  OPTIONAL,
      attrRevReq                  [1] CertRevReq             OPTIONAL,
      attributeConstraints        [2] AttributeConstraints   OPTIONAL }

   If attributeMandated is true then an attribute, certified within the
   following constraints, must be present.  If false, then the signature
   is still valid if no attribute is specified.

   The howCertAttribute field specifies whether attributes uncertified
   attributes "claimed" by the signer, or certified attributes (i.e.,
   Attribute Certificates) or either using the signer attributes
   attribute defined in [ES-FORMATS] section 3.12.3.

HowCertAttribute ::= ENUMERATED {
        claimedAttribute       (0),
        certifiedAttribtes     (1),
        either                 (2) }

   The attrCertificateTrustTrees specifies certificate path conditions
   for any attribute certificate.  If not present the same rules apply
   as in certificateTrustCondition.

   The attrRevReq specifies minimum requirements for revocation
   information, obtained through CRLs and/or OCSP responses, to be used
   in checking the revocation status of Attribute Certificates, if any
   are present.

   If the attributeConstraints field is not present then there are no
   constraints on the attributes that may be validated under this
   policy. The attributeConstraints field is defined as follows:






Ross, et al.                  Experimental                     [Page 16]

RFC 3125             Electronic Signature Policies        September 2001


AttributeConstraints ::= SEQUENCE {
        attributeTypeConstarints        [0] AttributeTypeConstraints
                                                 OPTIONAL,
        attributeValueConstarints       [1] AttributeValueConstraints
                                                 OPTIONAL }

   If present, the attributeTypeConstarints field specifies the
   attribute types which are considered valid under the signature
   policy.  Any value for that attribute is considered valid.

   AttributeTypeConstraints ::= SEQUENCE OF AttributeType

   If present, the attributeTypeConstraints field specifies the specific
   attribute values which are considered valid under the signature
   policy.

   AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue

3.10  Algorithm Constraints

   The algorithmConstrains fields, if present, identifies the signing
   algorithms (hash, public key cryptography, combined hash and public
   key cryptography) that may be used for specific purposes and any
   minimum length.  If this field is not present then the policy applies
   no constraints.

AlgorithmConstraintSet ::= SEQUENCE {   -- Algorithm constrains on:
signerAlgorithmConstraints      [0]     AlgorithmConstraints OPTIONAL,
                                -- signer
eeCertAlgorithmConstraints      [1]     AlgorithmConstraints OPTIONAL,
                                -- issuer of end entity certs.
caCertAlgorithmConstraints      [2]     AlgorithmConstraints OPTIONAL,
                                -- issuer of CA certificates
aaCertAlgorithmConstraints      [3]     AlgorithmConstraints OPTIONAL,
                                -- Attribute Authority
tsaCertAlgorithmConstraints     [4]     AlgorithmConstraints OPTIONAL
                                -- Time-Stamping Authority
                                                            }

AlgorithmConstraints ::= SEQUENCE OF AlgAndLength

AlgAndLength ::= SEQUENCE {
        algID                   OBJECT IDENTIFIER,
        minKeyLength    INTEGER         OPTIONAL,
       -- Minimum key length in bits
        other           SignPolExtensions OPTIONAL
                 }




Ross, et al.                  Experimental                     [Page 17]

RFC 3125             Electronic Signature Policies        September 2001


   An Attribute Authority (AA)is authority which assigns privileges by
   issuing attribute certificates

3.11  Signature Policy Extensions

   Additional signature policy rules may be added to:

      *  the overall signature policy structure, as defined in section
         3.1;
      *  the signature validation policy structure, as defined in
         section 3.2;
      *  the common rules, as defined in section 3.3;
      *  the commitment rules, as defined in section 3.4;
      *  the signer rules, as defined in section 3.5.1;
      *  the verifier rules, as defined in section 3.5.2;
      * the revocation requirements in section 3.6.2;
      *  the algorithm constraints in section 3.10.

   These extensions to the signature policy rules must be defined using
   an ASN.1 syntax with an associated object identifier carried in the
   SignPolExtn as defined below:

SignPolExtensions ::= SEQUENCE OF SignPolExtn

SignPolExtn ::= SEQUENCE {
                extnID      OBJECT IDENTIFIER,
                extnValue   OCTET STRING  }

   The extnID field must contain the object identifier for the
   extension. The extnValue field must contain the DER (see ITU-T
   Recommendation X.690 [4]) encoded value of the extension.  The
   definition of an extension, as identified by extnID must include a
   definition of the syntax and semantics of the extension.

4.  Security Considerations

4.1  Protection of Private Key

   The security of the electronic signature mechanism defined in this
   document depends on the privacy of the signer's private key.
   Implementations must take steps to ensure that private keys cannot be
   compromised.

4.2  Choice of Algorithms

   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



Ross, et al.                  Experimental                     [Page 18]

RFC 3125             Electronic Signature Policies        September 2001


   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.

5.  Conformance Requirements

   Signer and verifier systems shall be able to process an electronic
   signature in accordance with the specification of the signature
   policy signature policy referenced identifiable by an Object
   Identifier, see section 3.

6.  References

   [TS101733]   ETSI Standard TS 101 733 V.1.2.2 (2000-12) Electronic
                Signature Formats. Note: copies of ETSI TS 101 733 can
                be freely download from the ETSI web site www.etsi.org.

   [ES-FORMATS] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
                Formats for Long Term Electronic Signatures", RFC 3126,
                June 2001.

   [TSP]        Adams, C, Pinkas, D., Zuccherato, R. and P. Cain,
                "Internet X.509 Public Key Infrastructure Time-Stamp
                Protocol (TSP)", RFC 3161, August 2001.

   [OCSP]       Myers, M., Ankney, R., Malpani, R., Galperin, S. and C.
                Adams, "On-line Status Certificate Protocol", RFC 2560,
                June 1999.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
                June 1999.

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

   [PKCS9]      RSA Laboratories, "The Public-Key Cryptography Standards
                (PKCS)", RSA Data Security Inc., Redwood City,
                California, November 1993 Release.





Ross, et al.                  Experimental                     [Page 19]

RFC 3125             Electronic Signature Policies        September 2001


   [ISONR]      ISO/IEC 10181-5:  Security Frameworks in Open Systems.
                Non-Repudiation Framework. April 1997.

7.  Authors' Addresses

   This Experimental RFC has been produced in ETSI TC-SEC.

      ETSI
      F-06921 Sophia Antipolis, Cedex - FRANCE
      650 Route des Lucioles - Sophia Antipolis
      Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
      secretariat@etsi.fr
      http://www.etsi.org

   Contact Point

      Harri Rasilainen
      ETSI
      650 Route des Lucioles
      F-06921 Sophia Antipolis Cedex
      FRANCE

      EMail: harri.rasilainen@etsi.fr

      John Ross
      Security & Standards
      192 Moulsham Street
      Chelmsford, Essex
      CM2 0LG
      United Kingdom

      EMail: ross@secstan.com

      Denis Pinkas
      Integris, Bull.
      68, Route de Versailles
      78434 Louveciennes CEDEX
      FRANCE

      EMail: Denis.Pinkas@bull.net

      Nick Pope
      Security & Standards
      192 Moulsham Street
      Chelmsford, Essex
      CM2 0LG
      United Kingdom
      EMail: pope@secstan.com



Ross, et al.                  Experimental                     [Page 20]

RFC 3125             Electronic Signature Policies        September 2001


Annex A (normative):

   ASN.1 Definitions This annex provides the reference definition of the
   ASN.1 syntax signature policies definitions for new syntax defined in
   this document.

A.1  Definitions Using X.208 (1988) ASN.1 Syntax

   NOTE: The ASN.1 Module defined in section A.1 has precedence over
   that defined in Annex A-2 in the case of any conflict.

   ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0)
       7}

DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All

IMPORTS

-- Internet X.509 Public Key Infrastructure
 - Certificate and CRL Profile: RFC 2560
        Certificate, AlgorithmIdentifier, CertificateList, Name,
        GeneralNames, GeneralName, DirectoryString,Attribute,
        AttributeTypeAndValue, AttributeType, AttributeValue,
         PolicyInformation, BMPString, UTF8String

  FROM PKIX1Explicit88
        {iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-pkix1-explicit-88(1)}
                                                ;

-- Signature Policy Specification
-- ==============================

SignaturePolicy ::= SEQUENCE {
        signPolicyHashAlg      AlgorithmIdentifier,
        signPolicyInfo         SignPolicyInfo,
        signPolicyHash         SignPolicyHash     OPTIONAL }

SignPolicyHash ::= OCTET STRING

SignPolicyInfo ::= SEQUENCE {
        signPolicyIdentifier            SignPolicyId,
        dateOfIssue                     GeneralizedTime,
        policyIssuerName                PolicyIssuerName,



Ross, et al.                  Experimental                     [Page 21]

RFC 3125             Electronic Signature Policies        September 2001


        fieldOfApplication              FieldOfApplication,
        signatureValidationPolicy       SignatureValidationPolicy,
        signPolExtensions               SignPolExtensions
                                              OPTIONAL
                                                      }

PolicyIssuerName ::= GeneralNames

FieldOfApplication ::= DirectoryString

SignatureValidationPolicy ::= SEQUENCE {
        signingPeriod          SigningPeriod,
        commonRules            CommonRules,
        commitmentRules        CommitmentRules,
        signPolExtensions       SignPolExtensions
                                        OPTIONAL
                                                }

SigningPeriod ::= SEQUENCE {
        notBefore       GeneralizedTime,
        notAfter        GeneralizedTime OPTIONAL }


CommonRules  ::= SEQUENCE {
        signerAndVeriferRules          [0]  SignerAndVerifierRules
                                                          OPTIONAL,
        signingCertTrustCondition      [1]  SigningCertTrustCondition
                                                          OPTIONAL,
        timeStampTrustCondition        [2]  TimestampTrustCondition
                                                        OPTIONAL,
        attributeTrustCondition        [3]  AttributeTrustCondition
                                                        OPTIONAL,
        algorithmConstraintSet         [4]  AlgorithmConstraintSet
                                                         OPTIONAL,
        signPolExtensions              [5]  SignPolExtensions
                                                         OPTIONAL
                                                                 }

CommitmentRules ::= SEQUENCE OF CommitmentRule

CommitmentRule  ::= SEQUENCE {
        selCommitmentTypes                  SelectedCommitmentTypes,
        signerAndVeriferRules          [0]  SignerAndVerifierRules
                                                           OPTIONAL,
        signingCertTrustCondition      [1]  SigningCertTrustCondition
                                                           OPTIONAL,
        timeStampTrustCondition        [2]  TimestampTrustCondition
                                                           OPTIONAL,



Ross, et al.                  Experimental                     [Page 22]

RFC 3125             Electronic Signature Policies        September 2001


        attributeTrustCondition        [3]  AttributeTrustCondition
                                                           OPTIONAL,
        algorithmConstraintSet         [4]  AlgorithmConstraintSet
                                                           OPTIONAL,
        signPolExtensions              [5]  SignPolExtensions
                                                            OPTIONAL
                                                                  }
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
        empty                        NULL,
        recognizedCommitmentType     CommitmentType }

CommitmentType ::= SEQUENCE {
        identifier                      CommitmentTypeIdentifier,
        fieldOfApplication      [0] FieldOfApplication OPTIONAL,
        semantics                       [1] DirectoryString OPTIONAL }

SignerAndVerifierRules ::= SEQUENCE {
        signerRules      SignerRules,
        verifierRules    VerifierRules }


SignerRules ::= SEQUENCE {
        externalSignedData         BOOLEAN      OPTIONAL,
                     -- True if signed data is external to CMS structure
                      -- False if signed data part of CMS structure
                      -- not present if either allowed
        mandatedSignedAttr         CMSAttrs,
                      -- Mandated CMS signed attributes
        mandatedUnsignedAttr       CMSAttrs,
                      -- Mandated CMS unsigned attributed
        mandatedCertificateRef     [0] CertRefReq DEFAULT signerOnly,
                      -- Mandated Certificate Reference
        mandatedCertificateInfo    [1] CertInfoReq DEFAULT none,
                      -- Mandated Certificate Info
        signPolExtensions                [2] SignPolExtensions
                                                OPTIONAL}

CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER

CertRefReq ::= ENUMERATED {
                                signerOnly (1),
-- Only reference to signer cert mandated
                                fullPath (2)
-- References for full cert path up to a trust point required

                                                  }

CertInfoReq ::= ENUMERATED {



Ross, et al.                  Experimental                     [Page 23]

RFC 3125             Electronic Signature Policies        September 2001


                                none (0),
-- No mandatory requirements
                                signerOnly (1),
-- Only reference to signer cert mandated
                                fullPath (2)
-- References for full cert path up to a trust point mandated
                                                  }

VerifierRules ::= SEQUENCE {
                mandatedUnsignedAttr    MandatedUnsignedAttr,
                signPolExtensions       SignPolExtensions   OPTIONAL
                                                  }

MandatedUnsignedAttr ::=  CMSAttrs
-- Mandated CMS unsigned attributed

CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
        trustpoint                              Certificate,
                            -- self-signed certificate
        pathLenConstraint       [0] PathLenConstraint   OPTIONAL,
        acceptablePolicySet     [1] AcceptablePolicySet OPTIONAL,
                            -- If not present "any policy"
        nameConstraints         [2] NameConstraints     OPTIONAL,
        policyConstraints       [3] PolicyConstraints   OPTIONAL }

PathLenConstraint    ::=   INTEGER (0..MAX)

AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

CertPolicyId ::= OBJECT IDENTIFIER

NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,



Ross, et al.                  Experimental                     [Page 24]

RFC 3125             Electronic Signature Policies        September 2001


        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

CertRevReq ::= SEQUENCE {
        endCertRevReq   RevReq,
        caCerts   [0] RevReq
                             }

RevReq ::= SEQUENCE  {
    enuRevReq  EnuRevReq,
    exRevReq    SignPolExtensions OPTIONAL}

EnuRevReq  ::= ENUMERATED {
        clrCheck        (0), --Checks must be made against current CRLs
        -- (or authority revocation lists)
        ocspCheck       (1), -- The revocation status must be checked
        -- using the Online Certificate Status Protocol (RFC 2450)
        bothCheck       (2),
      -- Both CRL and OCSP checks must be carried out
        eitherCheck     (3),
      -- At least one of CRL or OCSP checks must be carried out
        noCheck         (4),
      -- no check is mandated
        other           (5)
      -- Other mechanism as defined by signature policy extension
                                                }

SigningCertTrustCondition ::=   SEQUENCE {
     signerTrustTrees              CertificateTrustTrees,
     signerRevReq                  CertRevReq
                                               }

TimestampTrustCondition ::= SEQUENCE {
    ttsCertificateTrustTrees    [0]             CertificateTrustTrees
                                                        OPTIONAL,
    ttsRevReq                   [1]             CertRevReq
                                                        OPTIONAL,
    ttsNameConstraints          [2]             NameConstraints
                                                        OPTIONAL,
    cautionPeriod               [3]             DeltaTime
                                                        OPTIONAL,
    signatureTimestampDelay     [4]             DeltaTime
                                                       OPTIONAL }

DeltaTime ::= SEQUENCE {
        deltaSeconds    INTEGER,
        deltaMinutes    INTEGER,



Ross, et al.                  Experimental                     [Page 25]

RFC 3125             Electronic Signature Policies        September 2001


        deltaHours      INTEGER,
        deltaDays       INTEGER }

AttributeTrustCondition ::= SEQUENCE {
        attributeMandated            BOOLEAN,
                                -- Attribute must be present
        howCertAttribute             HowCertAttribute,
        attrCertificateTrustTrees   [0] CertificateTrustTrees OPTIONAL,
        attrRevReq                  [1] CertRevReq            OPTIONAL,
        attributeConstraints        [2] AttributeConstraints  OPTIONAL }

HowCertAttribute ::= ENUMERATED {
        claimedAttribute    (0),
        certifiedAttribtes  (1),
        either              (2) }

AttributeConstraints ::= SEQUENCE {
        attributeTypeConstarints        [0] AttributeTypeConstraints
                                                        OPTIONAL,
        attributeValueConstarints       [1] AttributeValueConstraints
                                                       OPTIONAL }


AttributeTypeConstraints ::= SEQUENCE OF AttributeType

AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue


AlgorithmConstraintSet ::= SEQUENCE {   -- Algorithm constrains on:
signerAlgorithmConstraints      [0]     AlgorithmConstraints OPTIONAL,
                                 -- signer
eeCertAlgorithmConstraints      [1]     AlgorithmConstraints OPTIONAL,
                                 -- issuer of end entity certs.
caCertAlgorithmConstraints      [2]     AlgorithmConstraints OPTIONAL,
                                 -- issuer of CA certificates
aaCertAlgorithmConstraints      [3]     AlgorithmConstraints OPTIONAL,
                                 -- Attribute Authority
tsaCertAlgorithmConstraints     [4]     AlgorithmConstraints OPTIONAL
                                 -- Time-Stamping Authority
                                                    }

AlgorithmConstraints ::= SEQUENCE OF AlgAndLength

AlgAndLength ::= SEQUENCE {
        algID                   OBJECT IDENTIFIER,
        minKeyLength    INTEGER         OPTIONAL,
                             -- Minimum key length in bits other
                SignPolExtensions OPTIONAL



Ross, et al.                  Experimental                     [Page 26]

RFC 3125             Electronic Signature Policies        September 2001


                 }

SignPolExtensions ::= SEQUENCE OF SignPolExtn

SignPolExtn ::= SEQUENCE {
        extnID      OBJECT IDENTIFIER,
                extnValue   OCTET STRING  }


END -- ETS-ElectronicSignaturePolicies-88syntax --

A.2  Definitions Using X.680 1997 ASN.1 Syntax

   NOTE:   The ASN.1 module defined in section A.1 has precedence over
   that defined in section A.2 in the case of any conflict.

ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8}

DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All -

IMPORTS

-- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC 2560
        Certificate, AlgorithmIdentifier, CertificateList, Name,
        GeneralNames, GeneralName, DirectoryString, Attribute,
        AttributeTypeAndValue, AttributeType, AttributeValue,
        PolicyInformation

  FROM PKIX1Explicit93
        {iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        nid-pkix1-explicit-88(1)}
;

-- S/MIME Object Identifier arcs used in the present document
-- ==================================================================

-- S/MIME  OID arc used in the present document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
--             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

-- S/MIME Arcs
-- id-mod  OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules



Ross, et al.                  Experimental                     [Page 27]

RFC 3125             Electronic Signature Policies        September 2001


-- id-ct   OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types
-- id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes
-- id-spq  OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier
-- id-cti  OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier
-- Signature Policy Specification
-- ==============================

SignaturePolicy ::= SEQUENCE {
        signPolicyHashAlg      AlgorithmIdentifier,
        signPolicyInfo         SignPolicyInfo,
        signPolicyHash         SignPolicyHash     OPTIONAL }

SignPolicyHash ::= OCTET STRING

SignPolicyInfo ::= SEQUENCE {
        signPolicyIdentifier            SignPolicyId,
        dateOfIssue                     GeneralizedTime,
        policyIssuerName                PolicyIssuerName,
        fieldOfApplication              FieldOfApplication,
        signatureValidationPolicy       SignatureValidationPolicy,
        signPolExtensions               SignPolExtensions
                                                        OPTIONAL
                                                               }

SignPolicyId ::= OBJECT IDENTIFIER

PolicyIssuerName ::= GeneralNames

FieldOfApplication ::= DirectoryString

SignatureValidationPolicy ::= SEQUENCE {
        signingPeriod          SigningPeriod,
        commonRules            CommonRules,
        commitmentRules        CommitmentRules,
        signPolExtensions      SignPolExtensions   OPTIONAL
                                                       }

SigningPeriod ::= SEQUENCE {
        notBefore       GeneralizedTime,
        notAfter        GeneralizedTime OPTIONAL }

CommonRules  ::= SEQUENCE {
        signerAndVeriferRules          [0]  SignerAndVerifierRules
                                                         OPTIONAL,



Ross, et al.                  Experimental                     [Page 28]

RFC 3125             Electronic Signature Policies        September 2001


        signingCertTrustCondition      [1]  SigningCertTrustCondition
                                                         OPTIONAL,
        timeStampTrustCondition        [2]  TimestampTrustCondition
                                                         OPTIONAL,
        attributeTrustCondition        [3]  AttributeTrustCondition
                                                         OPTIONAL,
        algorithmConstraintSet         [4]  AlgorithmConstraintSet
                                                         OPTIONAL,
        signPolExtensions              [5]  SignPolExtensions
                                                         OPTIONAL
                                                        }

CommitmentRules ::= SEQUENCE OF CommitmentRule

CommitmentRule  ::= SEQUENCE {
        selCommitmentTypes                  SelectedCommitmentTypes,
        signerAndVeriferRules          [0]  SignerAndVerifierRules
                                                         OPTIONAL,
        signingCertTrustCondition      [1]  SigningCertTrustCondition
                                                         OPTIONAL,
        timeStampTrustCondition        [2]  TimestampTrustCondition
                                                         OPTIONAL,
        attributeTrustCondition        [3]  AttributeTrustCondition
                                                         OPTIONAL,
        algorithmConstraintSet         [4]  AlgorithmConstraintSet
                                                         OPTIONAL,
        signPolExtensions                    [5]  SignPolExtensions
                                                         OPTIONAL
                                                              }

SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
        empty                        NULL,
        recognizedCommitmentType     CommitmentType }

CommitmentType ::= SEQUENCE {
        identifier                      CommitmentTypeIdentifier,
        fieldOfApplication      [0] FieldOfApplication OPTIONAL,
        semantics               [1] DirectoryString OPTIONAL }

SignerAndVerifierRules ::= SEQUENCE {
        signerRules      SignerRules,
        verifierRules    VerifierRules }

SignerRules ::= SEQUENCE {
        externalSignedData         BOOLEAN      OPTIONAL,
                     -- True if signed data is external to CMS structure
                        -- False if signed data part of CMS structure
                        -- not present if either allowed



Ross, et al.                  Experimental                     [Page 29]

RFC 3125             Electronic Signature Policies        September 2001


        mandatedSignedAttr         CMSAttrs,
                  -- Mandated CMS signed attributes
        mandatedUnsignedAttr       CMSAttrs,
                  -- Mandated CMS unsigned attributed
        mandatedCertificateRef     [0] CertRefReq DEFAULT signerOnly,
                        -- Mandated Certificate Reference
        mandatedCertificateInfo    [1] CertInfoReq DEFAULT none,
                        -- Mandated Certificate Info
        signPolExtensions                [2] SignPolExtensions  OPTIONAL
                                                      }

CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER

CertRefReq ::= ENUMERATED {
                                signerOnly (1),
                   -- Only reference to signer cert mandated
                                fullPath (2)
                   -- References for full cert path up to a trust
                   -- point required
                                                                       }

CertInfoReq ::= ENUMERATED {
                                none (0)        ,
                   -- No mandatory requirements
                                signerOnly (1)  ,
                   -- Only reference to signer cert mandated
                                fullPath (2)
                         -- References for full cert path up to a
                   -- trust point mandated
                                                          }

VerifierRules ::= SEQUENCE {
                mandatedUnsignedAttr    MandatedUnsignedAttr,
                signPolExtensions       SignPolExtensions  OPTIONAL
                }
MandatedUnsignedAttr ::=  CMSAttrs
                          -- Mandated CMS unsigned attributed

CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
        trustpoint                              Certificate,
                          -- self-signed certificate
        pathLenConstraint               [0] PathLenConstraint  OPTIONAL,
        acceptablePolicySet     [1] AcceptablePolicySet OPTIONAL,
                          -- If not present "any policy"
        nameConstraints         [2] NameConstraints     OPTIONAL,
        policyConstraints               [3] PolicyConstraints OPTIONAL }



Ross, et al.                  Experimental                     [Page 30]

RFC 3125             Electronic Signature Policies        September 2001


PathLenConstraint    ::=   INTEGER (0..MAX)

AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

CertPolicyId ::= OBJECT IDENTIFIER

NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

CertRevReq ::= SEQUENCE {
        endCertRevReq   RevReq,
        caCerts      [0] RevReq
                                          }

RevReq ::= SEQUENCE  {
    enuRevReq  EnuRevReq,
    exRevReq    SignPolExtensions OPTIONAL}

EnuRevReq  ::= ENUMERATED {
        clrCheck        (0),
                   -- Checks must be made against current CRLs
                   -- (or authority revocation lists)
        ocspCheck       (1),
                   -- The revocation status must be checked using
                   -- the Online Certificate Status Protocol (RFC 2450)
        bothCheck       (2),
                   -- Both CRL and OCSP checks must be carried out
        eitherCheck     (3),
                   -- At least one of CRL or OCSP checks must be
                   -- carried out
        noCheck         (4),
                   -- no check is mandated



Ross, et al.                  Experimental                     [Page 31]

RFC 3125             Electronic Signature Policies        September 2001


        other           (5)
                   -- Other mechanism as defined by signature policy
                   -- extension
                                              }

SigningCertTrustCondition ::=   SEQUENCE {
     signerTrustTrees              CertificateTrustTrees,
     signerRevReq                  CertRevReq
                                              }


TimestampTrustCondition ::= SEQUENCE {
    ttsCertificateTrustTrees    [0]             CertificateTrustTrees
                                                       OPTIONAL,
    ttsRevReq                   [1]             CertRevReq
                                                       OPTIONAL,
    ttsNameConstraints          [2]             NameConstraints
                                                       OPTIONAL,
    cautionPeriod                       [3]             DeltaTime
                                                       OPTIONAL,
    signatureTimestampDelay     [4]             DeltaTime
                                                      OPTIONAL }

DeltaTime ::= SEQUENCE {
        deltaSeconds    INTEGER,
        deltaMinutes    INTEGER,
        deltaHours      INTEGER,
        deltaDays       INTEGER }

AttributeTrustCondition ::= SEQUENCE {
        attributeMandated            BOOLEAN,
                               -- Attribute must be present
        howCertAttribute             HowCertAttribute,
        attrCertificateTrustTrees   [0] CertificateTrustTrees OPTIONAL,
        attrRevReq                  [1] CertRevReq            OPTIONAL,
        attributeConstraints        [2] AttributeConstraints  OPTIONAL }

HowCertAttribute ::= ENUMERATED {
        claimedAttribute        (0),
        certifiedAttribtes      (1),
        either                  (2) }

AttributeConstraints ::= SEQUENCE {
        attributeTypeConstarints        [0] AttributeTypeConstraints
                                                       OPTIONAL,
        attributeValueConstarints       [1] AttributeValueConstraints
                                                       OPTIONAL }




Ross, et al.                  Experimental                     [Page 32]

RFC 3125             Electronic Signature Policies        September 2001


AttributeTypeConstraints ::= SEQUENCE OF AttributeType

AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue

AlgorithmConstraintSet ::= SEQUENCE {
                               -- Algorithm constrains on:
signerAlgorithmConstraints      [0]     AlgorithmConstraints OPTIONAL,
                                -- signer
eeCertAlgorithmConstraints      [1]     AlgorithmConstraints OPTIONAL,
                                -- issuer of end entity certs.
caCertAlgorithmConstraints      [2]     AlgorithmConstraints OPTIONAL,
                                -- issuer of CA certificates
aaCertAlgorithmConstraints      [3]     AlgorithmConstraints OPTIONAL,
                                -- Attribute Authority
tsaCertAlgorithmConstraints     [4]     AlgorithmConstraints OPTIONAL
                                -- Time-Stamping Authority
                                                         }

AlgorithmConstraints ::= SEQUENCE OF AlgAndLength

AlgAndLength ::= SEQUENCE {
        algID           OBJECT IDENTIFIER,
        minKeyLength    INTEGER         OPTIONAL,
                               -- Minimum key length in bits
        other           SignPolExtensions OPTIONAL
                                                         }

SignPolExtensions ::= SEQUENCE OF SignPolExtn

SignPolExtn ::= SEQUENCE {
        extnID      OBJECT IDENTIFIER,
        extnValue   OCTET STRING  }

END                           -- ETS-ElectronicPolicies-97Syntax

















Ross, et al.                  Experimental                     [Page 33]

RFC 3125             Electronic Signature Policies        September 2001


Annex B (informative):

B.1  Signature Policy and Signature Validation Policy

   The definition of electronic signature mentions: "a commitment has
   been explicitly endorsed under a "Signature Policy", at a given time,
   by a signer under an identifier, e.g., a name or a pseudonym, and
   optionally a role."

   Electronic signatures are commonly applied within the context of a
   legal or contractual framework.  This establishes the requirements on
   the electronic signatures and any special semantics (e.g., agreement,
   intent).  These requirements may be defined in very general abstract
   terms or in terms of detailed rules.  The specific semantics
   associated with an electronic signature implied by a legal or
   contractual framework are outside the scope of this document.

   If the signature policy is recognized, within the legal/contractual
   context, as providing commitment, then the signer explicitly agrees
   with terms and conditions which are implicitly or explicitly part of
   the signed data.

   When two independent parties want to evaluate an electronic
   signature, it is fundamental that they get the same result.  It is
   therefore important that the conditions agreed by the signer at the
   time of signing are indicated to the verifier and any arbitrator.  An
   aspect that enables this to be known by all parties is the signature
   policy. The technical implications of the signature policy on the
   electronic signature with all the validation data are called the
   "Signature Validation Policy".  The signature validation policy
   specifies the rules used to validate the signature.

   This document does not mandate the form and encoding of the
   specification of the signature policy.  However, for a given
   signature policy there must be one definitive form that has a unique
   binary encoded value.

   This document includes, as an option, a formal structure for
   signature validation policy based on the use of Abstract Syntax
   Notation 1 (ASN.1).

   Given the specification of the signature policy and its hash value an
   implementation of a verification process must obey the rules defined
   in the specification.

   This document places no restriction on how it should be implemented.
   Provide the implementation conforms to the conformance requirements
   as define in section 5 implementation options include:



Ross, et al.                  Experimental                     [Page 34]

RFC 3125             Electronic Signature Policies        September 2001


   A validation process that supports a specific signature policy as
   identified by the signature policy OID.  Such an implementation
   should conform to a human readable description provided all the
   processing rules of the signature policy are clearly defined.
   However, if additional policies need to be supported, then such an
   implementation would need to be customized for each additional
   policy.  This type of implementation may be simpler to implement
   initially, but can be difficult to enhance to support numerous
   additional signature policies.

   A validation process that is dynamically programmable and able to
   adapt its validation rules in accordance with a description of the
   signature policy provided in a computer-processable language.  This
   present document defines such a policy using an ASN.1 structure (see
   6.1).  This type of implementation could support multiple signature
   policies without being modified every time, provided all the
   validation rules specified as part of the signature policy are known
   by the implementation.  (i.e., only requires modification if there
   are additional rules specified).

   The precise content of a signature policy is not mandated by the
   current document.  However, a signature policy must be sufficiently
   definitive to avoid any ambiguity as to its implementation
   requirements.  It must be absolutely clear under which conditions an
   electronic signature should be accepted.  For this reason, it should
   contain the following information:

   *  General information about the signature policy which includes:
      -  a unique identifier of the policy;
      -  the name of the issuer of the policy;
      -  the date the policy was issued;
      -  the field of application of the policy.

   *  The signature verification policy which includes:
      -  the signing period,
      -  a list of recognized commitment types;
      -  rules for Use of Certification Authorities;
      -  rules for Use of Revocation Status Information;
      -  rules for Use of Roles;
      -  rules for use of Time-Stamping and Timing;
      -  signature verification data to be provided by the
         signer/collected by verifier;
      -  any constraints on signature algorithms and key lengths.
   *  Other signature policy rules required to meet the objectives of
      the signature.

   Variations of the validation policy rules may apply to different
   commitment types.



Ross, et al.                  Experimental                     [Page 35]

RFC 3125             Electronic Signature Policies        September 2001


B.2  Identification of Signature Policy

   When data is signed the signer indicates the signature policy
   applicable to that electronic signature by including an object
   identifier for the signature policy with the signature.  The signer
   and verifier must apply the rules specified by the identified policy.
   In addition to the identifier of the signature policy the signer must
   include the hash of the signature policy, so it can be verified that
   the policy selected by the signer is the identical to the one being
   used the verifier.

   A signature policy may be qualified by additional information.  This
   can includes:

      *  A URL where a copy of the Signature Policy may be obtained;
      *  A user notice that should be displayed when the signature is
         verified;

   If no signature policy is identified then the signature may be
   assumed to have been generated/verified without any policy
   constraints, and hence may be given no specific legal or contractual
   significance through the context of a signature policy.

   A "Signature Policy" will be identifiable by an OID (Object
   Identifier) and verifiable using a hash of the signature policy.

B.3  General Signature Policy Information

   General information should be recorded about the signature policy
   along with the definition of the rules which form the signature
   policy as described in subsequent subsections.  This should include:

      *  Policy Object Identifier: The "Signature Policy" will be
         identifiable by an OID (Object Identifier) whose last component
         (i.e., right most) is an integer that is specific to a
         particular version issued on the given date.
      *  Date of issue: When the "Signature Policy" was issued.
      *  Signature Policy Issuer name: An identifier for the body
         responsible for issuing the Signature Policy.  This may be used
         by the signer or verifying in deciding if a policy is to be
         trusted, in which case the signer/verifier must authenticate
         the origin of the signature policy as coming from the
         identified issuer.
      *  Signing period: The start time and date, optionally with an end
         time and date, for the period over which the signature policy
         may be used to generate electronic signatures.





Ross, et al.                  Experimental                     [Page 36]

RFC 3125             Electronic Signature Policies        September 2001


      *  Field of application: This defines in general terms the general
         legal/contract/application contexts in which the signature
         policy is to be used and the specific purposes for which the
         electronic signature is to be applied.

B.4  Recognized Commitment Types

   The signature validation policy may recognize one or more types of
   commitment as being supported by electronic signatures produced under
   the security policy.  If an electronic signature does not contain a
   recognized commitment type then the semantics of the electronic
   signature is dependent on the data being signed and the context in
   which it is being used.

   Only recognized commitment types are allowed in an electronic
   signature.

   The definition of a commitment type includes:

      *  the object identifier for the commitment;
      *  the contractual/legal/application context in which the
         signature may be used (e.g., submission of messages);
      *  a description of the support provided within the terms of the
         context (e.g., proof that the identified source submitted the
         message if the signature is created when message submission is
         initiated).

   The definition of a commitment type can be registered:

      *  as part of the validation policy;
      *  as part of the application/contract/legal environment;
      *  as part of generic register of definitions.

   The legal/contractual context will determine the rules applied to the
   signature, as defined by the signature policy and its recognized
   commitment types, make it fit for purpose intended.

B.5  Rules for Use of Certification Authorities

   The certificate validation process of the verifier, and hence the
   certificates that may be used by the signer for a valid electronic
   signature, may be constrained by the combination of the trust point
   and certificate path constraints in the signature validation policy.








Ross, et al.                  Experimental                     [Page 37]

RFC 3125             Electronic Signature Policies        September 2001


B.5.1  Trust Points

   The signature validation policy defines the certification authority
   trust points that are to be used for signature verification.  Several
   trust points may be specified under one signature policy.  Specific
   trust points may be specified for a particular type of commitment
   defined under the signature policy.  For a signature to be valid a
   certification path must exists between the Certification Authority
   that has granted the certificate selected by the signer (i.e., the
   used user-certificate) and one of the trust point of the "Signature
   Validation Policy".

B.5.2  Certification Path

   There may be constraints on the use of certificates issued by one or
   more CA(s) in the certificate chain and trust points.  The two prime
   constraints are certificate policy constraints and naming
   constraints:

      *  Certificate policy constraints limit the certification chain
         between the user certificate and the certificate of the trusted
         point to a given set of certificate policies, or equivalents
         identified through certificate policy mapping.
      *  The naming constraints limit the forms of names that the CA is
         allowed to certify.

   Name constraints are particularly important when a "Signature policy"
   identifies more than one trust point.  In this case, a certificate of
   a particular trusted point may only be used to verify signatures from
   users with names permitted under the name constraint.

   Certificate Authorities may be organized in a tree structure, this
   tree structure may represent the trust relationship between various
   CA(s) and the users CA.  Alternatively, a mesh relationship may exist
   where a combination of tree and peer cross-certificates may be used.
   The requirement of the certificate path in this document is that it
   provides the trust relationship between all the CAs and the signers
   user certificate.  The starting point from a verification point of
   view, is the "trust point".  A trust point is usually a CA that
   publishes self-certified certificates, is the starting point from
   which the verifier verifies the certificate chain.  Naming
   constraints may apply from the trust point, in which case they apply
   throughout the set of certificates that make up the certificate path
   down to the signer's user certificate.

   Policy constraints can be easier to process but to be effective
   require the presence of a certificate policy identifier in the
   certificates used in a certification path.



Ross, et al.                  Experimental                     [Page 38]

RFC 3125             Electronic Signature Policies        September 2001


   Certificate path processing, thus generally starts with one of the
   trust point from the signature policy and ends with the user
   certificate.  The certificate path processing procedures defined in
   RFC 2459 section 6 identifies the following initial parameters that
   are selected by the verifier in certificate path processing:

      *  acceptable certificate policies;
      *  naming constraints in terms of constrained and excluded naming
         subtree;
      *  requirements for explicit certificate policy indication and
         whether certificate policy mapping are allowed;
      *  restrictions on the certificate path length.

   The signature validation policy identifies constraints on these
   parameters.

B.6  Revocation Rules

   The signature policy should defines rules specifying requirements for
   the use of certificate revocation lists (CRLs) and/or on-line
   certificate status check service to check the validity of a
   certificate. These rules specify the mandated minimum checks that
   must be carried out.

   It is expected that in many cases either check may be selected with
   CRLs checks being carried out for certificate status that are
   unavailable from OCSP servers.  The verifier may take into account
   information in the certificate in deciding how best to check the
   revocation status (e.g., a certificate extension field about
   authority information access or a CRL distribution point) provided
   that it does not conflict with the signature policy revocation rules.

B.7  Rules for the Use of Roles

   Roles can be supported as claimed roles or as certified roles using
   Attribute Certificates.

B.7.1  Attribute Values

   When signature under a role is mandated by the signature policy, then
   either Attribute Certificates may be used or the signer may provide a
   claimed role attribute.  The acceptable attribute types or values may
   be dependent on the type of commitment.  For example, a user may have
   several roles that allow the user to sign data that imply commitments
   based on one or more of his roles.






Ross, et al.                  Experimental                     [Page 39]

RFC 3125             Electronic Signature Policies        September 2001


B.7.2  Trust Points for Certified Attributes

   When a signature under a certified role is mandated by the signature
   policy, Attribute Authorities are used and need to be validated as
   part of the overall validation of the electronic signature.  The
   trust points for Attribute Authorities do not need to be the same as
   the trust points to evaluate a certificate from the CA of the signer.
   Thus the trust point for verifying roles need not be the same as
   trust point used to validate the certificate path of the user's key.

   Naming and certification policy constraints may apply to the AA in
   similar circumstance to when they apply to CA.  Constraints on the AA
   and CA need not be exactly the same.

   AA(s) may be used when a signer is creating a signature on behalf of
   an organization, they can be particularly useful when the signature
   represents an organizational role.  AA(s) may or may not be the same
   authority as CA(s).

   Thus, the Signature Policy identifies trust points that can be used
   for Attribute Authorities, either by reference to the same trust
   points as used for Certification Authorities, or by an independent
   list.

B.7.3  Certification Path for Certified Attributes

   Attribute Authorities may be organized in a tree structure in similar
   way to CA where the AAs are the leafs of such a tree.  Naming and
   other constraints may be required on attribute certificate paths in a
   similar manner to other electronic signature certificate paths.

   Thus, the Signature Policy identify constraints on the following
   parameters used as input to the certificate path processing:

      *  acceptable certificate policies, including requirements for
         explicit certificate policy indication and whether certificate
         policy mapping is allowed;
      *  naming constraints in terms of constrained and excluded naming
         subtrees;
      *  restrictions on the certificate path length.

B.8  Rules for the Use of Time-Stamping and Timing

   The following rules should be used when specifying, constraints on
   the certificate paths for time-stamping authorities, constraints on
   the time-stamping authority names and general timing constraints.





Ross, et al.                  Experimental                     [Page 40]

RFC 3125             Electronic Signature Policies        September 2001


B.8.1  Trust Points and Certificate Paths

   Signature keys from time-stamping authorities will need to be
   supported by a certification path.  The certification path used for
   time-stamping authorities requires a trustpoint and possibly path
   constraints in the same way that the certificate path for the
   signer's key.

B.8.2  Time-Stamping Authority Names

   Restrictions may need to be placed by the validation policy on the
   named entities that may act a time-stamping authorities.

B.8.3  Timing Constraints - Caution Period

   Before an electronic signature may really be valid, the verifier has
   to be sure that the holder of the private key was really the only one
   in possession of key at the time of signing.  However, there is an
   inevitable delay between a compromise or loss of key being noted, and
   a report of revocation being distributed.  To allow greater
   confidence in the validity of a signature, a "cautionary period" may
   be identified before a signature may be said to be valid with high
   confidence.  A verifier may revalidate a signature after this
   cautionary signature, or wait for this period before validating a
   signature.

   The validation policy may specify such a cautionary period.

B.8.4  Timing Constraints - Time-Stamp Delay

   There will be some delay between the time that a signature is created
   and the time the signer's digital signature is time-stamped.
   However, the longer this elapsed period the greater the risk of the
   signature being invalidated due to compromise or deliberate
   revocation of its private signing key by the signer.  Thus the
   signature policy should specify a maximum acceptable delay between
   the signing time as claimed by the signer and the time included
   within the time-stamp.

B.9  Rules for Verification Data to be followed

   By specifying the requirements on the signer and verifier the
   responsibilities of the two parties can be clearly defined to
   establish all the necessary information.







Ross, et al.                  Experimental                     [Page 41]

RFC 3125             Electronic Signature Policies        September 2001


   These verification data rules should include:

      *  requirements on the signer to provide given signed attributes;
      *  requirements on the verifier to obtain additional certificates,
         CRLs, results of on line certificate status checks and to use
         time-stamps (if no already provided by the signer).

B.10  Rules for Algorithm Constraints and Key Lengths

   The signature validation policy may identify a set of signing
   algorithms (hashing, public key, combinations) and minimum key
   lengths that may be used:

      *  by the signer in creating the signature;
      *  in end entity public key Certificates;
      *  CA Certificates;
      *  attribute Certificates;
      *  by the time-stamping authority.

B.11  Other Signature Policy Rules

   The signature policy may specify additional policy rules, for example
   rules that relate to the environment used by the signer.  These
   additional rules may be defined in computer processable and/or human
   readable form.

B.12  Signature Policy Protection

   When signer or verifier obtains a copy of the Signature Policy from
   an issuer, the source should be authenticated (for example by using
   electronic signatures).  When the signer references a signature
   policy the Object Identifier (OID) of the policy, the hash value and
   the hash algorithm OID of that policy must be included in the
   Electronic Signature.

   It is a mandatory requirement of this present document that the
   signature policy value computes to one, and only one hash value using
   the specified hash algorithm.  This means that there must be a single
   binary value of the encoded form of the signature policy for the
   unique hash value to be calculated.  For example, there may exist a
   particular file type, length and format on which the hash value is
   calculated which is fixed and definitive for a particular signature
   policy.








Ross, et al.                  Experimental                     [Page 42]

RFC 3125             Electronic Signature Policies        September 2001


   The hash value may be obtained by:

      the signer performing his own computation of the hash over the
      signature policy using his preferred hash algorithm permitted by
      the signature policy, and the definitive binary encoded form.

      the signer, having verified the source of the policy, may use both
      the hash algorithm and the hash value included in the computer
      processable form of the policy (see section 6.1).










































Ross, et al.                  Experimental                     [Page 43]

RFC 3125             Electronic Signature Policies        September 2001


Full Copyright Statement

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



















Ross, et al.                  Experimental                     [Page 44]