File: rfc2527.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 (2523 lines) | stat: -rw-r--r-- 91,860 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
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523






Network Working Group                                        S. Chokhani
Request for Comments: 2527                      CygnaCom Solutions, Inc.
Category: Informational                                          W. Ford
                                                          VeriSign, Inc.
                                                              March 1999


                Internet X.509 Public Key Infrastructure
        Certificate Policy and Certification Practices Framework

Status of this Memo

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

Copyright Notice

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

Abstract

   This document presents a framework to assist the writers of
   certificate policies or certification practice statements for
   certification authorities and public key infrastructures.  In
   particular, the framework provides a comprehensive list of topics
   that potentially (at the writer's discretion) need to be covered in a
   certificate policy definition or a certification practice statement.

1. INTRODUCTION

1.1  BACKGROUND

   A public-key certificate (hereinafter "certificate") binds a public-
   key value to a set of information that identifies the entity (such as
   person, organization, account, or site) associated with use of the
   corresponding private key (this entity is known as the "subject" of
   the certificate).  A certificate is used by a "certificate user" or
   "relying party" that needs to use, and rely upon the accuracy of, the
   public key distributed via that certificate (a certificate user is
   typically an entity that is verifying a digital signature from the
   certificate's subject or an entity sending encrypted data to the
   subject).  The degree to which a certificate user can trust the
   binding embodied in a certificate depends on several factors. These
   factors include the practices followed by the certification authority
   (CA) in authenticating the subject; the CA's operating policy,
   procedures, and security controls; the subject's obligations (for
   example, in protecting the private key); and the stated undertakings



Chokhani & Ford              Informational                      [Page 1]

RFC 2527                          PKIX                        March 1999


   and legal obligations of the CA (for example, warranties and
   limitations on liability).

   A Version 3 X.509 certificate may contain a field declaring that one
   or more specific certificate policies applies to that certificate
   [ISO1].  According to X.509, a certificate policy is "a named set of
   rules that indicates the applicability of a certificate to a
   particular community and/or class of application with common security
   requirements." A certificate policy may be used by a certificate user
   to help in deciding whether a certificate, and the binding therein,
   is sufficiently trustworthy for a particular application.  The
   certificate policy concept is an outgrowth of the policy statement
   concept developed for Internet Privacy Enhanced Mail [PEM1] and
   expanded upon in [BAU1].

   A more detailed description of the practices followed by a CA in
   issuing and otherwise managing certificates may be contained in a
   certification practice statement (CPS) published by or referenced by
   the CA.  According to the American Bar Association Digital Signature
   Guidelines (hereinafter "ABA Guidelines"), "a CPS is a statement of
   the practices which a certification authority employs in issuing
   certificates." [ABA1]

1.2  PURPOSE

   The purpose of this document is to establish a clear relationship
   between certificate policies and CPSs, and to present a framework to
   assist the writers of certificate policies or CPSs with their tasks.
   In particular, the framework identifies the elements that may need to
   be considered in formulating a certificate policy or a CPS.  The
   purpose is not to define particular certificate policies or CPSs, per
   se.

1.3  SCOPE

   The scope of this document is limited to discussion of the contents
   of a certificate policy (as defined in X.509) or CPS (as defined in
   the ABA Guidelines).  In particular, this document describes the
   types of information that should be considered for inclusion in a
   certificate policy definition or a CPS.  While the framework as
   presented generally assumes use of the X.509 version 3 certificate
   format, it is not intended that the material be restricted to use of
   that certificate format.  Rather, it is intended that this framework
   be adaptable to other certificate formats that may come into use.

   The scope does not extend to defining security policies generally
   (such as organization security policy, system security policy, or
   data labeling policy) beyond the policy elements that are considered



Chokhani & Ford              Informational                      [Page 2]

RFC 2527                          PKIX                        March 1999


   of particular relevance to certificate policies or CPSs.

   This document does not define a specific certificate policy or CPS.

   It is assumed that the reader is familiar with the general concepts
   of digital signatures, certificates, and public-key infrastructure,
   as used in X.509 and the ABA Guidelines.

2.  DEFINITIONS

   This document makes use of the following defined terms:

      Activation data - Data values, other than keys, that are required
      to operate cryptographic modules and that need to be protected
      (e.g., a PIN, a passphrase, or a manually-held key share).

      CA-certificate - A certificate for one CA's public key issued by
      another CA.

      Certificate policy - A named set of rules that indicates the
      applicability of a certificate to a particular community and/or
      class of application with common security requirements.  For
      example, a particular certificate policy might indicate
      applicability of a type of certificate to the authentication of
      electronic data interchange transactions for the trading of goods
      within a given price range.

      Certification path - An ordered sequence of certificates which,
      together with the public key of the initial object in the path,
      can be processed to obtain that of the final object in the path.

      Certification Practice Statement (CPS) - A statement of the
      practices which a certification authority employs in issuing
      certificates.

      Issuing certification authority (issuing CA) - In the context of a
      particular certificate, the issuing CA is the CA that issued the
      certificate (see also Subject certification authority).

      Policy qualifier - Policy-dependent information that accompanies a
      certificate policy identifier in an X.509 certificate.

      Registration authority (RA) - An entity that is responsible for
      identification and authentication of certificate subjects, but
      that does not sign or issue certificates (i.e., an RA is delegated
      certain tasks on behalf of a CA).  [Note: The term Local
      Registration Authority (LRA) is used elsewhere for the same
      concept.]



Chokhani & Ford              Informational                      [Page 3]

RFC 2527                          PKIX                        March 1999


      Relying party - A recipient of a certificate who acts in reliance
      on that certificate and/or digital signatures verified using that
      certificate.  In this document, the terms "certificate user" and
      "relying party" are used interchangeably.

      Set of provisions - A collection of practice and/or policy
      statements, spanning a range of standard topics, for use in
      expressing a certificate policy definition or CPS employing the
      approach described in this framework.

      Subject certification authority (subject CA) - In the context of a
      particular CA-certificate, the subject CA is the CA whose public
      key is certified in the certificate (see also Issuing
      certification authority).

3.  CONCEPTS

   This section explains the concepts of certificate policy and CPS, and
   describes their relationship.  Other related concepts are also
   described.  Some of the material covered in this section and in some
   other sections is specific to certificate policies extensions as
   defined X.509 version 3.  Except for those sections, this framework
   is intended to be adaptable to other certificate formats that may
   come into use.

3.1  CERTIFICATE POLICY

   When a certification authority issues a certificate, it is providing
   a statement to a certificate user (i.e., a relying party) that a
   particular public key is bound to a particular entity (the
   certificate subject).  However, the extent to which the certificate
   user should rely on that statement by the CA needs to be assessed by
   the certificate user.  Different certificates are issued following
   different practices and procedures, and may be suitable for different
   applications and/or purposes.

   The X.509 standard defines a certificate policy as "a named set of
   rules that indicates the applicability of a certificate to a
   particular community and/or class of application with common security
   requirements"[ISO1].  An X.509 Version 3 certificate may contain an
   indication of certificate policy, which may be used by a certificate
   user to decide whether or not to trust a certificate for a particular
   purpose.

   A certificate policy, which needs to be recognized by both the issuer
   and user of a certificate, is represented in a certificate by a
   unique, registered Object Identifier.  The registration process
   follows the procedures specified in ISO/IEC and ITU standards.  The



Chokhani & Ford              Informational                      [Page 4]

RFC 2527                          PKIX                        March 1999


   party that registers the Object Identifier also publishes a textual
   specification of the certificate policy, for examination by
   certificate users.  Any one certificate will typically declare a
   single certificate policy or, possibly, be issued consistent with a
   small number of different policies.

   Certificate policies also constitute a basis for accreditation of
   CAs.  Each CA is accredited against one or more certificate policies
   which it is recognized as implementing.  When one CA issues a CA-
   certificate for another CA, the issuing CA must assess the set of
   certificate policies for which it trusts the subject CA (such
   assessment may be based upon accreditation with respect to the
   certificate policies involved).  The assessed set of certificate
   policies is then indicated by the issuing CA in the CA-certificate.
   The X.509 certification path processing logic employs these
   certificate policy indications in its well-defined trust model.

3.2  CERTIFICATE POLICY EXAMPLES

   For example purposes, suppose that IATA undertakes to define some
   certificate policies for use throughout the airline industry, in a
   public-key infrastructure operated by IATA in combination with
   public-key infrastructures operated by individual airlines.  Two
   certificate policies are defined - the IATA General-Purpose policy,
   and the IATA Commercial-Grade policy.

   The IATA General-Purpose policy is intended for use by industry
   personnel for protecting routine information (e.g., casual electronic
   mail) and for authenticating connections from World Wide Web browsers
   to servers for general information retrieval purposes.  The key pairs
   may be generated, stored, and managed using low-cost, software-based
   systems, such as commercial browsers.  Under this policy, a
   certificate may be automatically issued to anybody listed as an
   employee in the corporate directory of IATA or any member airline who
   submits a signed certificate request form to a network administrator
   in his or her organization.

   The IATA Commercial-Grade policy is used to protect financial
   transactions or binding contractual exchanges between airlines.
   Under this policy, IATA requires that certified key pairs be
   generated and stored in approved cryptographic hardware tokens.
   Certificates and tokens are provided to airline employees with
   disbursement authority. These authorized individuals are required to
   present themselves to the corporate security office, show a valid
   identification badge, and sign an undertaking to protect the token
   and use it only for authorized purposes, before a token and a
   certificate are issued.




Chokhani & Ford              Informational                      [Page 5]

RFC 2527                          PKIX                        March 1999


3.3 X.509 CERTIFICATE FIELDS

   The following extension fields in an X.509 certificate are used to
   support certificate policies:

      * Certificate Policies extension;
      * Policy Mappings extension; and
      * Policy Constraints extension.

3.3.1 Certificate Policies Extension

   The Certificate Policies extension has two variants - one with the
   field flagged non-critical and one with the field flagged critical.
   The purpose of the field is different in the two cases.

   A non-critical Certificate Policies field lists certificate policies
   that the certification authority declares are applicable.  However,
   use of the certificate is not restricted to the purposes indicated by
   the applicable policies.  Using the example of the IATA General-
   Purpose and Commercial-Grade policies defined in Section 3.2, the
   certificates issued to regular airline employees will contain the
   object identifier for certificate policy for the General-Purpose
   policy.  The certificates issued to the employees with disbursement
   authority will contain the object identifiers for both the General-
   Purpose policy and the Commercial-Grade policy.  The Certificate
   Policies field may also optionally convey qualifier values for each
   identified policy; use of qualifiers is discussed in Section 3.4.

   The non-critical Certificate Policies field is designed to be used by
   applications as follows.  Each application is pre-configured to know
   what policy it requires.  Using the example in Section 3.2,
   electronic mail applications and Web servers will be configured to
   require the General-Purpose policy.  However, an airline's financial
   applications will be configured to require the Commercial-Grade
   policy for validating financial transactions over a certain dollar
   value.

   When processing a certification path, a certificate policy that is
   acceptable to the certificate-using application must be present in
   every certificate in the path, i.e., in CA-certificates as well as
   end entity certificates.

   If the Certificate Policies field is flagged critical, it serves the
   same purpose as described above but also has an additional role.  It
   indicates that the use of the certificate is restricted to one of the
   identified policies, i.e., the certification authority is declaring
   that the certificate must only be used in accordance with the
   provisions of one of the listed certificate policies. This field is



Chokhani & Ford              Informational                      [Page 6]

RFC 2527                          PKIX                        March 1999


   intended to protect the certification authority against damage claims
   by a relying party who has used the certificate for an inappropriate
   purpose or in an inappropriate manner, as stipulated in the
   applicable certificate policy definition.

   For example, the Internal Revenue Service might issue certificates to
   taxpayers for the purpose of protecting tax filings.  The Internal
   Revenue Service understands and can accommodate the risks of
   accidentally issuing a bad certificate, e.g., to a wrongly-
   authenticated person.  However, suppose someone used an Internal
   Revenue Service tax-filing certificate as the basis for encrypting
   multi-million-dollar-value proprietary secrets which subsequently
   fell into the wrong hands because of an error in issuing the Internal
   Revenue Service certificate.  The Internal Revenue Service may want
   to protect itself against claims for damages in such circumstances.
   The critical-flagged Certificate Policies extension is intended to
   mitigate the risk to the certificate issuer in such situations.

3.3.2  Policy Mappings Extension

   The Policy Mappings extension may only be used in CA-certificates.
   This field allows a certification authority to indicate that certain
   policies in its own domain can be considered equivalent to certain
   other policies in the subject certification authority's domain.

   For example, suppose the ACE Corporation establishes an agreement
   with the ABC Corporation to cross-certify each others' public-key
   infrastructures for the purposes of mutually protecting electronic
   data interchange (EDI). Further, suppose that both companies have
   pre-existing financial transaction protection policies called ace-e-
   commerce and abc-e-commerce, respectively.  One can see that simply
   generating cross certificates between the two domains will not
   provide the necessary interoperability, as the two companies'
   applications are configured with and employee certificates are
   populated with their respective certificate policies.  One possible
   solution is to reconfigure all of the financial applications to
   require either policy and to reissue all the certificates with both
   policies.  Another solution, which may be easier to administer, uses
   the Policy Mapping field.  If this field is included in a cross-
   certificate for the ABC Corporation certification authority issued by
   the ACE Corporation certification authority, it can provide a
   statement that the ABC's financial transaction protection policy
   (i.e., abc-e-commerce) can be considered equivalent to that of the
   ACE Corporation (i.e., ace-e-commerce).







Chokhani & Ford              Informational                      [Page 7]

RFC 2527                          PKIX                        March 1999


3.3.3  Policy Constraints Extension

   The Policy Constraints extension supports two optional features.  The
   first is the ability for a certification authority to require that
   explicit certificate policy indications be present in all subsequent
   certificates in a certification path.  Certificates at the start of a
   certification path may be considered by a certificate user to be part
   of a trusted domain, i.e., certification authorities are trusted for
   all purposes so no particular certificate policy is needed in the
   Certificate Policies extension.  Such certificates need not contain
   explicit indications of certificate policy.  However, when a
   certification authority in the trusted domain certifies outside the
   domain, it can activate the requirement for explicit certificate
   policy in subsequent certificates in the certification path.

   The other optional feature in the Policy Constraints field is the
   ability for a certification authority to disable policy mapping by
   subsequent certification authorities in a certification path.  It may
   be prudent to disable policy mapping when certifying outside the
   domain.  This can assist in controlling risks due to transitive
   trust, e.g., a domain A trusts domain B, domain B trusts domain C,
   but domain A does not want to be forced to trust domain C.

3.4  POLICY QUALIFIERS

   The Certificate Policies extension field has a provision for
   conveying, along with each certificate policy identifier, additional
   policy-dependent information in a qualifier field.  The X.509
   standard does not mandate the purpose for which this field is to be
   used, nor does it prescribe the syntax for this field.  Policy
   qualifier types can be registered by any organization.

   The following policy qualifier types are defined in PKIX Part I
   [PKI1]:

      (a) The CPS Pointer qualifier contains a pointer to a
          Certification Practice Statement (CPS) published by the CA.
          The pointer is in the form of a uniform resource identifier
          (URI).

      (b) The User Notice qualifier contains a text string that is to be
          displayed to a certificate user (including subscribers and
          relying parties) prior to the use of the certificate.  The
          text string may be an IA5String or a BMPString - a subset of
          the ISO 100646-1 multiple octet coded character set.  A CA may
          invoke a procedure that requires that the certficate user
          acknowledge that the applicable terms and conditions have been
          disclosed or accepted.



Chokhani & Ford              Informational                      [Page 8]

RFC 2527                          PKIX                        March 1999


   Policy qualifiers can be used to support the definition of generic,
   or parameterized, certificate policy definitions.  Provided the base
   certificate policy definition so provides, policy qualifier types can
   be defined to convey, on a per-certificate basis, additional specific
   policy details that fill in the generic definition.

3.5  CERTIFICATION PRACTICE STATEMENT

   The term certification practice statement (CPS) is defined by the ABA
   Guidelines as: "A statement of the practices which a certification
   authority employs in issuing certificates." [ABA1] In the 1995 draft
   of the ABA guidelines, the ABA expands this definition with the
   following comments:

      A certification practice statement may take the form of a
      declaration by the certification authority of the details of its
      trustworthy system and the practices it employs in its operations
      and in support of issuance of a certificate, or it may be a
      statute or regulation applicable to the certification authority
      and covering similar subject matter. It may also be part of the
      contract between the certification authority and the subscriber. A
      certification practice statement may also be comprised of multiple
      documents, a combination of public law, private contract, and/or
      declaration.

      Certain forms for legally implementing certification practice
      statements lend themselves to particular relationships. For
      example, when the legal relationship between a certification
      authority and subscriber is consensual, a contract would
      ordinarily be the means of giving effect to a certification
      practice statement.  The certification authority's duties to a
      relying person are generally based on the certification
      authority's representations, which may include a certification
      practice statement.

      Whether a certification practice statement is binding on a relying
      person depends on whether the relying person has knowledge or
      notice of the certification practice statement.  A relying person
      has knowledge or at least notice of the contents of the
      certificate used by the relying person to verify a digital
      signature, including documents incorporated into the certificate
      by reference.  It is therefore advisable to incorporate a
      certification practice statement into a certificate by reference.

      As much as possible, a certification practice statement should
      indicate any of the widely recognized standards to which the
      certification authority's practices conform.  Reference to widely
      recognized standards may indicate concisely the suitability of the



Chokhani & Ford              Informational                      [Page 9]

RFC 2527                          PKIX                        March 1999


      certification authority's practices for another person's purposes,
      as well as the potential technological compatibility of the
      certificates issued by the certification authority with
      repositories and other systems.

3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION PRACTICE
    STATEMENT

   The concepts of certificate policy and CPS come from different
   sources and were developed for different reasons.  However, their
   interrelationship is important.

   A certification practice statement is a detailed statement by a
   certification authority as to its practices, that potentially needs
   to be understood and consulted by subscribers and certificate users
   (relying parties).  Although the level of detail may vary among CPSs,
   they will generally be more detailed than certificate policy
   definitions.  Indeed, CPSs may be quite comprehensive, robust
   documents providing a description of the precise service offerings,
   detailed procedures of the life-cycle management of certificates, and
   more - a level of detail which weds the CPS to a particular
   (proprietary) implementation of a service offering.

   Although such detail may be indispensable to adequately disclose, and
   to make a full assessment of trustworthiness in the absence of
   accreditation or other recognized quality metrics, a detailed CPS
   does not form a suitable basis for interoperability between CAs
   operated by different organizations.  Rather, certificate policies
   best serve as the vehicle on which to base common interoperability
   standards and common assurance criteria on an industry-wide (or
   possibly more global) basis.  A CA with a single CPS may support
   multiple certificate policies (used for different application
   purposes and/or by different certificate user communities).  Also,
   multiple different CAs, with non-identical certification practice
   statements, may support the same certificate policy.

   For example, the Federal Government might define a government-wide
   certificate policy for handling confidential human resources
   information.  The certificate policy definition will be a broad
   statement of the general characteristics of that certificate policy,
   and an indication of the types of applications for which it is
   suitable for use.  Different departments or agencies that operate
   certification authorities with different certification practice
   statements might support this certificate policy.  At the same time,
   such certification authorities may support other certificate
   policies.





Chokhani & Ford              Informational                     [Page 10]

RFC 2527                          PKIX                        March 1999


   The main difference between certificate policy and CPS can therefore
   be summarized as follows:

      (a) Most organizations that operate public or inter-
          organizational certification authorities will document their
          own practices in CPSs or similar statements.  The CPS is one
          of the organization's means of protecting itself and
          positioning its business relationships with subscribers and
          other entities.

      (b) There is strong incentive, on the other hand, for a
          certificate policy to apply more broadly than to just a single
          organization.  If a particular certificate policy is widely
          recognized and imitated, it has great potential as the basis
          of automated certificate acceptance in many systems, including
          unmanned systems and systems that are manned by people not
          independently empowered to determine the acceptability of
          different presented certificates.

   In addition to populating the certificate policies field with the
   certificate policy identifier, a certification authority may include,
   in certificates it issues, a reference to its certification practice
   statement.  A standard way to do this, using a certificate policy
   qualifier, is described in Section 3.4.

3.7  SET OF PROVISIONS

   A set of provisions is a collection of practice and/or policy
   statements, spanning a range of standard topics, for use in
   expressing a certificate policy definition or CPS employing the
   approach described in this framework.

   A certificate policy can be expressed as a single set of provisions.

   A CPS can be expressed as a single set of provisions with each
   component addressing the requirements of one or more certificate
   policies, or, alternatively, as an organized collection of sets of
   provisions.  For example, a CPS could be expressed as a combination
   of the following:

      (a) a list of certificate policies supported by the CPS;

      (b) for each certificate policy in (a), a set of provisions which
          contains statements that refine that certificate policy by
          filling in details not stipulated in that policy or expressly
          left to the discretion of the CPS by that certificate policy;
          such statements serve to state how this particular CPS
          implements the requirements of the particular certificate



Chokhani & Ford              Informational                     [Page 11]

RFC 2527                          PKIX                        March 1999


          policy;

      (c) a set of provisions that contains statements regarding the
          certification practices on the CA, regardless of certificate
          policy.

   The statements provided in (b) and (c) may augment or refine the
   stipulations of the applicable certificate policy definition, but
   must not conflict with any of the stipulations of such certificate
   policy definition.

   This framework outlines the contents of a set of provisions, in terms
   of eight primary components, as follows:

      * Introduction;

      * General Provisions;

      * Identification and Authentication;

      * Operational Requirements;

      * Physical, Procedural, and Personnel Security Controls;

      * Technical Security Controls;

      * Certificate and CRL Profile; and

      * Specification Administration.

   Components can be further divided into subcomponents, and a
   subcomponent may comprise multiple elements.  Section 4 provides a
   more detailed description of the contents of the above components,
   and their subcomponents.

4.  CONTENTS OF A SET OF PROVISIONS

   This section expands upon the contents of a set of provisions, as
   introduced in Section 3.7.  The topics identified in this section
   are, consequently, candidate topics for inclusion in a certificate
   policy definition or CPS.

   While many topics are identified, it is not necessary for a
   certificate policy or a CPS to include a concrete statement for every
   such topic.  Rather, a particular certificate policy or CPS may state
   "no stipulation" for a component, subcomponent, or element on which
   the particular certificate policy or CPS imposes no requirements.  In
   this sense, the list of topics can be considered a checklist of



Chokhani & Ford              Informational                     [Page 12]

RFC 2527                          PKIX                        March 1999


   topics for consideration by the certificate policy or CPS writer.  It
   is recommended that each and every component and subcomponent be
   included in a certificate policy or CPS, even if there is "no
   stipulation"; this will indicate to the reader that a conscious
   decision was made to include or exclude that topic.  This protects
   against inadvertent omission of a topic, while facilitating
   comparison of different certificate policies or CPSs, e.g., when
   making policy mapping decisions.

   In a certificate policy definition, it is possible to leave certain
   components, subcomponents, and/or elements unspecified, and to
   stipulate that the required information will be indicated in a policy
   qualifier.  Such certificate policy definitions can be considered
   parameterized definitions.  The set of provisions should reference or
   define the required policy qualifier types and should specify any
   applicable default values.

4.1 INTRODUCTION

   This component identifies and introduces the set of provisions, and
   indicates the types of entities and applications for which the
   specification is targeted.

   This component has the following subcomponents:

      * Overview;

      * Identification;

      * Community and Applicability; and

      * Contact Details.

4.1.1  Overview

   This subcomponent provides a general introduction to the
   specification.

4.1.2  Identification

   This subcomponent provides any applicable names or other identifiers,
   including ASN.1 object identifiers, for the set of provisions.

4.1.3  Community and Applicability

   This subcomponent describes the types of entities that issue
   certificates or that are certified as subject CAs (2, 3), the types
   of entities that perform RA functions (4), and the types of entities



Chokhani & Ford              Informational                     [Page 13]

RFC 2527                          PKIX                        March 1999


   that are certified as subject end entities or subscribers. (5, 6)

   This subcomponent also contains:

      * A list of applications for which the issued certificates are
        suitable.  (Examples of application in this case are: electronic
        mail, retail transactions, contracts, travel order, etc.)

      * A list of applications for which use of the issued certificates
        is restricted.  (This list implicitly prohibits all other uses
        for the certificates.)

      * A list of applications for which use of the issued certificates
        is prohibited.

4.1.4  Contact Details

   This subcomponent includes the name and mailing address of the
   authority that is responsible for the registration, maintenance, and
   interpretation of this certificate policy or CPS.  It also includes
   the name, electronic mail address, telephone number, and fax number
   of a contact person.

4.2  GENERAL PROVISIONS

   This component specifies any applicable presumptions on a range of
   legal and general practices topics.

   This component contains the following subcomponents:

      * Obligations;

      * Liability;

      * Financial Responsibility;

      * Interpretation and Enforcement;

      * Fees;

      * Publication and Repositories;

      * Compliance Audit;

      * Confidentiality; and

      * Intellectual Property Rights.




Chokhani & Ford              Informational                     [Page 14]

RFC 2527                          PKIX                        March 1999


   Each subcomponent may need to separately state provisions applying to
   the entity types: CA, repository, RA, subscriber, and relying party.
   (Specific provisions regarding subscribers and relying parties are
   only applicable in the Liability and Obligations subcomponents.)

4.2.1  Obligations

   This subcomponent contains, for each entity type, any applicable
   provisions regarding the entity's obligations to other entities.
   Such provisions may include:

      * CA and/or RA obligations:
         *  Notification of issuance of a certificate to the
            subscriber who is the subject of the certificate being
            issued;
         *  Notification of issuance of a certificate to others
            than the subject of the certificate;
         *  Notification of revocation or suspension of a
            certificate to the subscriber whose certificate is being
            revoked or suspended; and
         *  Notification of revocation or suspension of a
            certificate to others than the subject whose certificate
            is being revoked or suspended.

      * Subscriber obligations:

         *  Accuracy of representations in certificate application;
         *  Protection of the entity's private key;
         *  Restrictions on private key and certificate use; and
         *  Notification upon private key compromise.

      * Relying party obligations:

         *  Purposes for which certificate is used;
         *  Digital signature verification responsibilities;
         *  Revocation and suspension checking responsibilities;
            and
         *  Acknowledgment of applicable liability caps and
            warranties.

      * Repository obligations

         *  Timely publication of certificates and revocation
            information







Chokhani & Ford              Informational                     [Page 15]

RFC 2527                          PKIX                        March 1999


4.2.2  Liability

   This subcomponent contains, for each entity type, any applicable
   provisions regarding apportionment of liability, such as:

      * Warranties and limitations on warranties;

      * Kinds of damages covered (e.g., indirect, special,
        consequential, incidental, punitive, liquidated damages,
        negligence and fraud) and disclaimers;

      * Loss limitations (caps) per certificate or per transaction; and

      * Other exclusions (e.g., Acts of God, other party
        responsibilities).

4.2.3  Financial Responsibility

   This subcomponent contains, for CAs, repository, and RAs, any
   applicable provisions regarding financial responsibilities, such as:

      * Indemnification of CA and/or RA by relying parties;

      * Fiduciary relationships (or lack thereof) between the various
        entities; and

      * Administrative processes (e.g., accounting, audit).

4.2.4  Interpretation and Enforcement

   This subcomponent contains any applicable provisions regarding
   interpretation and enforcement of the certificate policy or CPS,
   addressing such topics as:

      * Governing law;

      * Severability of provisions, survival, merger, and notice; and

      * Dispute resolution procedures.

4.2.5  Fees

   This subcomponent contains any applicable provisions regarding fees
   charged by CAs, repositories, or RAs, such as:

      * Certificate issuance or renewal fees;

      * Certificate access fee;



Chokhani & Ford              Informational                     [Page 16]

RFC 2527                          PKIX                        March 1999


      * Revocation or status information access fee;

      * Fees for other services such as policy information; and

      * Refund policy.

4.2.6  Publication and Repositories

   This subcomponent contains any applicable provisions regarding:

      * A CA's obligations to publish information regarding its
        practices, its certificates, and the current status of such
        certificates;

      * Frequency of publication;

      * Access control on published information objects including
        certificate policy definitions, CPS, certificates, certificate
        status, and CRLs; and

      * Requirements pertaining to the use of repositories operated by
        CAs or by other independent parties.

4.2.7  Compliance Audit

   This subcomponent addresses the following:

      * Frequency of compliance audit for each entity;

      * Identity/qualifictions of the auditor;

      * Auditor's relationship to the entity being audited; (30)

      * List of topics covered under the compliance audit; (31)

      * Actions taken as a result of a deficiency found during
        compliance audit; (32)

      * Compliance audit results: who they are shared with (e.g.,
        subject CA, RA, and/or end entities), who provides them (e.g.,
        entity being audited or auditor), how they are communicated.










Chokhani & Ford              Informational                     [Page 17]

RFC 2527                          PKIX                        March 1999


4.2.8  Confidentiality Policy

   This subcomponent addresses the following:

      * Types of information that must be kept confidential by CA or RA;

      * Types of information that are not considered confidential;

      * Who is entitled to be informed of reasons for revocation and
        suspension of certificates;

      * Policy on release of information to law enforcement officials;

      * Information that can be revealed as part of civil discovery;

      * Conditions upon which CA or RA may disclose upon owner's
        request; and

      * Any other circumstances under which confidential information may
        be disclosed.

4.2.9  Intellectual Property Rights

   This subcomponent addresses ownership rights of certificates,
   practice/policy specifications, names, and keys.

4.3  IDENTIFICATION AND AUTHENTICATION

   This component describes the procedures used to authenticate a
   certificate applicant to a CA or RA prior to certificate issuance.
   It also describes how parties requesting rekey or revocation are
   authenticated.  This component also addresses naming practices,
   including name ownership recognition and name dispute resolution.

   This component has the following subcomponents:

      * Initial Registration;

      * Routine Rekey;

      * Rekey After Revocation; and

      * Revocation Request.








Chokhani & Ford              Informational                     [Page 18]

RFC 2527                          PKIX                        March 1999


4.3.1  Initial Registration

   This subcomponent includes the following elements regarding
   identification and authentication procedures during entity
   registration or certificate issuance:

      * Types of names assigned to the subject (7);

      * Whether names have to be meaningful or not (8);

      * Rules for interpreting various name forms;

      * Whether names have to be unique;

      * How name claim disputes are resolved;

      * Recognition, authentication, and role of trademarks;

      * If and how the subject must prove possession of the companion
        private key for the public key being registered (9);

      * Authentication requirements for organizational identity of
        subject (CA, RA, or end entity) (10);

      * Authentication requirements for a person acting on behalf of a
        subject (CA, RA, or end entity) (11), including:

         * Number of pieces of identification required;
         * How a CA or RA validates the pieces of identification
           provided;
         * If the individual must present personally to the
           authenticating CA or RA;
         * How an individual as an organizational person is
           authenticated (12).

4.3.2 Routine Rekey

   This subcomponent describes the identification and authentication
   procedures for routine rekey for each subject type (CA, RA, and end
   entity). (13)

4.3.3 Rekey After Revocation -- No Key Compromise

   This subcomponent describes the identification and authentication
   procedures for rekey for each subject type (CA, RA, and end entity)
   after the subject certificate has been revoked.  (14)





Chokhani & Ford              Informational                     [Page 19]

RFC 2527                          PKIX                        March 1999


4.3.4 Revocation Request

   This subcomponent describes the identification and authentication
   procedures for a revocation request by each subject type (CA, RA, and
   end entity). (16)

4.4 OPERATIONAL REQUIREMENTS

   This component is used to specify requirements imposed upon issuing
   CA, subject CAs, RAs, or end entities with respect to various
   operational activities.

   This component consists of the following subcomponents:

      * Certificate Application;

      * Certificate Issuance;

      * Certificate Acceptance;

      * Certificate Suspension and Revocation;

      * Security Audit Procedures;

      * Records Archival;

      * Key Changeover;

      * Compromise and Disaster Recovery; and

      * CA Termination.

   Within each subcomponent, separate consideration may need to be given
   to issuing CA, repository, subject CAs, RAs, and end entities.

4.4.1 Certificate Application

   This subcomponent is used to state requirements regarding subject
   enrollment and request for certificate issuance.

4.4.2 Certificate Issuance

   This subcomponent is used to state requirements regarding issuance of
   a certificate and notification to the applicant of such issuance.







Chokhani & Ford              Informational                     [Page 20]

RFC 2527                          PKIX                        March 1999


4.4.3 Certificate Acceptance

   This subcomponent is used to state requirements regarding acceptance
   of an issued certificate and for consequent publication of
   certificates.

4.4.4 Certificate Suspension and Revocation

   This subcomponent addresses the following:

      * Circumstances under which a certificate may be revoked;

      * Who can request the revocation of the entity certificate;

      * Procedures used for certificate revocation request;

      * Revocation request grace period available to the subject;

      * Circumstances under which a certificate may be suspended;

      * Who can request the suspension of a certificate;

      * Procedures to request certificate suspension;

      * How long the suspension may last;

      * If a CRL mechanism is used, the issuance frequency;

      * Requirements on relying parties to check CRLs;

      * On-line revocation/status checking availability;

      * Requirements on relying parties to perform on-line
        revocation/status checks;

      * Other forms of revocation advertisements available; and

      * Requirements on relying parties to check other forms of
        revocation advertisements.

      * Any variations on the above stipulations when the suspension or
        revocation is the result of private key compromise (as opposed
        to other reasons for suspension or revocation).








Chokhani & Ford              Informational                     [Page 21]

RFC 2527                          PKIX                        March 1999


4.4.5  Security Audit Procedures

   This subcomponent is used to describe event logging and audit
   systems, implemented for the purpose of maintaining a secure
   environment.  Elements include the following:

      * Types of events recorded; (28)

      * Frequency with which audit logs are processed or audited;

      * Period for which audit logs are kept;

      * Protection of audit logs:

         - Who can view audit logs;
         - Protection against modification of audit log; and
         - Protection against deletion of audit log.

      * Audit log back up procedures;

      * Whether the audit log accumulation system is internal or
        external to the entity;

      * Whether the subject who caused an audit event to occur is
        notified of the audit action; and

      * Vulnerability assessments.

4.4.6  Records Archival

   This subcomponent is used to describe general records archival (or
   records retention) policies, including the following:

      * Types of events recorded; (29)

      * Retention period for archive;

      * Protection of archive:

         - Who can view the archive;
         - Protection against modification of archive; and
         - Protection against deletion of archive.

      * Archive backup procedures;

      * Requirements for time-stamping of records;

      * Whether the archive collection system is internal or external;



Chokhani & Ford              Informational                     [Page 22]

RFC 2527                          PKIX                        March 1999


        and

      * Procedures to obtain and verify archive information.

4.4.7  Key Changeover

   This subcomponent describes the procedures to provide a new public
   key to a CA's users.

4.4.8  Compromise and Disaster Recovery

   This subcomponent describes requirements relating to notification and
   recovery procedures in the event of compromise or disaster.  Each of
   the following circumstances may need to be addressed separately:

      * The recovery procedures used if computing resources, software,
        and/or data are corrupted or suspected to be corrupted.  These
        procedures describe how a secure environment is reestablished,

        which certificates are revoked, whether the entity key is
        revoked, how the new entity public key is provided to the users,
        and how the subjects are recertified.

      * The recovery procedures used if the entity public key is
        revoked.  These procedures describe how a secure environment is
        reestablished, how the new entity public key is provided to the
        users, and how the subjects are recertified.

      * The recovery procedures used if the entity key is compromised.
        These procedures describe how a secure environment is
        reestablished, how the new entity public key is provided to the
        users, and how the subjects are recertified.

      * The CA's procedures for securing its facility during the period
        of time following a natural or other disaster and before a
        secure environment is reestablished either at the original site
        or a remote hot-site.  For example, procedures to protect
        against theft of sensitive materials from an earthquake-damaged
        site.

4.4.9 CA Termination

   This subcomponent describes requirements relating to procedures for
   termination and for termination notification of a CA or RA, including
   the identity of the custodian of CA and RA archival records.






Chokhani & Ford              Informational                     [Page 23]

RFC 2527                          PKIX                        March 1999


4.5 PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS

   This component describes non-technical security controls (that is,
   physical, procedural, and personnel controls) used by the issuing CA
   to perform securely the functions of key generation, subject
   authentication, certificate issuance, certificate revocation, audit,
   and archival.

   This component can also be used to define non-technical security
   controls on repository, subject CAs, RAs, and end entities.  The non
   technical security controls for the subject CAs, RAs, and end
   entities could be the same, similar, or very different.

   These non-technical security controls are critical to trusting the
   certificates since lack of security may compromise CA operations
   resulting, for example, in the creation of certificates or CRLs with
   erroneous information or the compromise of the CA private key.

   This component consists of three subcomponents:

      * Physical Security Controls;

      * Procedural Controls; and

      * Personnel Security Controls.

   Within each subcomponent, separate consideration will, in general,
   need to be given to each entity type, that is, issuing CA,
   repository, subject CAs, RAs, and end entities.

4.5.1 Physical Security Controls

   In this subcomponent, the physical controls on the facility housing
   the entity systems are described.(21) Topics addressed may include:

      * Site location and construction;

      * Physical access;

      * Power and air conditioning;

      * Water exposures;

      * Fire prevention and protection;

      * Media storage;

      * Waste disposal; and



Chokhani & Ford              Informational                     [Page 24]

RFC 2527                          PKIX                        March 1999


      * Off-site backup.

4.5.2 Procedural Controls

   In this subcomponent, requirements for recognizing trusted roles are
   described, together with the responsibilities for each role.(22)

   For each task identified for each role, it should also be stated how
   many individuals are required to perform the task (n out m rule).
   Identification and authentication requirements for each role may also
   be defined.

4.5.3 Personnel Security Controls

   This subcomponent addresses the following:

      * Background checks and clearance procedures required for the
        personnel filling the trusted roles; (23)

      * Background checks and clearance procedures requirements for
        other personnel, including janitorial staff; (24)

      * Training requirements and training procedures for each role;

      * Any retraining period and retraining procedures for each role;

      * Frequency and sequence for job rotation among various roles;

      * Sanctions against personnel for unauthorized actions,
        unauthorized use of authority, and unauthorized use of entity
        systems; (25)

        * Controls on contracting personnel, including:

         - Bonding requirements on contract personnel;
         - Contractual requirements including indemnification  for
           damages due to the actions of the contractor personnel;
         - Audit and monitoring of contractor personnel; and
         - Other controls on contracting personnel.

      * Documentation to be supplied to personnel.

4.6 TECHNICAL SECURITY CONTROLS

   This component is used to define the security measures taken by the
   issuing CA to protect its cryptographic keys and activation data
   (e.g., PINs, passwords, or manually-held key shares).  This component
   may also be used to impose constraints on repositories, subject CAs



Chokhani & Ford              Informational                     [Page 25]

RFC 2527                          PKIX                        March 1999


   and end entities to protect their cryptographic keys and critical
   security parameters.  Secure key management is critical to ensure
   that all secret and private keys and activation data are protected
   and used only by authorized personnel.

   This component also describes other technical security controls used
   by the issuing CA to perform securely the functions of key
   generation, user authentication, certificate registration,
   certificate revocation, audit, and archival.  Technical controls
   include life-cycle security controls (including software development
   environment security, trusted software development methodology) and
   operational security controls.

   This component can also be used to define other technical security
   controls on repositories, subject CAs, RAs, and end entities.

   This component has the following subcomponents:

      * Key Pair Generation and Installation;

      * Private Key Protection;

      * Other Aspects of Key Pair Management;

      * Activation Data;

      * Computer Security Controls;

      * Life-Cycle Security Controls;

      * Network Security Controls; and

      * Cryptographic Module Engineering Controls.

4.6.1 Key Pair Generation and Installation

   Key pair generation and installation need to be considered for the
   issuing CA, repositories, subject CAs, RAs, and subject end entities.
   For each of these types of entities, the following questions
   potentially need to be answered:

      1. Who generates the entity public, private key pair?

      2. How is the private key provided securely to the entity?

      3. How is the entity's public key provided securely to the
         certificate issuer?




Chokhani & Ford              Informational                     [Page 26]

RFC 2527                          PKIX                        March 1999


      4. If the entity is a CA (issuing or subject) how is the entity's
         public key provided securely to the users?

      5. What are the key sizes?

      6. Who generates the public key parameters?

      7. Is the quality of the parameters checked during key generation?

      8. Is the key generation performed in hardware or software?

      9. For what purposes may the key be used, or for what purposes
         should usage of the key be restricted (for X.509 certificates,
         these purposes should map to the key usage flags in the Version
         3, X.509 certificates)?

4.6.2 Private Key Protection

   Requirements for private key protection need to be considered for the
   issuing CA, repositories, subject CAs, RAs, and subject end entities.
   For each of these types of entity, the following questions
   potentially need to be answered:

      1. What standards, if any, are required for the module used to
         generate the keys?  For example, are the keys certified by the
         infrastructure required to be generated using modules complaint
         with the US FIPS 140-1?  If so, what is the required FIPS 140-1
         level of the module?

      2. Is the private key under n out of m multi-person control?(18)
         If yes, provide n and m (two person control is a special case
         of n out of m, where n = m = 2)?

      3. Is the private key escrowed?  (19) If so, who is the escrow
         agent, what form is the key escrowed in (examples include
         plaintext, encrypted, split key), and what are the security
         controls on the escrow system?

      4. Is the private key backed up?  If so, who is the backup agent,
         what form is the key backed up in (examples include plaintext,
         encrypted, split key), and what are the security controls on
         the backup system?

      5. Is the private key archived?  If so, who is the archival agent,
         what form is the key archived in (examples include plaintext,
         encrypted, split key), and what are the security controls on
         the archival system?




Chokhani & Ford              Informational                     [Page 27]

RFC 2527                          PKIX                        March 1999


      6. Who enters the private key in the cryptographic module?  In
         what form (i.e., plaintext, encrypted, or split key)?  How is
         the private key stored in the module (i.e., plaintext,
         encrypted, or split key)?

      7. Who can activate (use) the private key?  What actions must be
         performed to activate the private key (e.g., login, power on,
         supply PIN, insert token/key, automatic, etc.)?  Once the key
         is activated, is the key active for an indefinite period,
         active for one time, or active for a defined time period?

      8. Who can deactivate the private key and how? Example of how
         might include, logout, power off, remove token/key, automatic,
         or time expiration.

      9. Who can destroy the private key and how?  Examples of how might
         include token surrender, token destruction, or key overwrite.

4.6.3 Other Aspects of Key Pair Management

   Other aspects of key management need to be considered for the issuing
   CA, repositories, subject CAs, RAs, and subject end entities.  For
   each of these types of entity, the following questions potentially
   need to be answered:

      1. Is the public key archived?  If so, who is the archival agent
         and what are the security controls on the archival system?  The
         archival system should provide integrity controls other than
         digital signatures since: the archival period may be greater
         than the cryptanalysis period for the key and the archive
         requires tamper protection, which is not provided by digital
         signatures.

      2. What are the usage periods, or active lifetimes, for the public
         and the private key respectively?

4.6.4 Activation Data

   Activation data refers to data values other than keys that are
   required to operate cryptographic modules and that need to be
   protected.  (20) Protection of activation data potentially needs to
   be considered for the issuing CA, subject CAs, RAs, and end entities.
   Such consideration potentially needs to address the entire life-cycle
   of the activation data from generation through archival and
   destruction.  For each of the entity types (issuing CA, repository,
   subject CA, RA, and end entity) all of the questions listed in 4.6.1
   through 4.6.3 potentially need to be answered with respect to
   activation data rather than with respect to keys.



Chokhani & Ford              Informational                     [Page 28]

RFC 2527                          PKIX                        March 1999


4.6.5 Computer Security Controls

   This subcomponent is used to describe computer security controls such
   as: use of the trusted computing base concept, discretionary access
   control, labels, mandatory access controls, object reuse, audit,
   identification and authentication, trusted path, security testing,
   and penetration testing.  Product assurance may also be addressed.

   A computer security rating for computer systems may be required.  The
   rating could be based, for example, on the Trusted System Evaluation
   Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria,
   European Information Technology Security Evaluation Criteria (ITSEC),
   or the Common Criteria.  This subcomponent can also address
   requirements for product evaluation analysis, testing, profiling,
   product certification, and/or product accreditation related activity
   undertaken.

4.6.6 Life Cycle Security Controls

   This subcomponent addresses system development controls and security
   management controls.

   System development controls include development environment security,
   development personnel security, configuration management security
   during product maintenance, software engineering practices, software
   development methodology, modularity, layering, use of failsafe design
   and implementation techniques (e.g., defensive programming) and
   development facility security.

   Security management controls include execution of tools and
   procedures to ensure that the operational systems and networks adhere
   to configured security.  These tools and procedures include checking
   the integrity of the security software, firmware, and hardware to
   ensure their correct operation.

   This subcomponent can also address life-cycle security ratings based,
   for example, on the Trusted Software Development Methodology (TSDM)
   level IV and V, independent life-cycle security controls audit, and
   the Software Engineering Institute's Capability Maturity Model (SEI-
   CMM).

4.6.7 Network Security Controls

   This subcomponent addresses network security related controls,
   including firewalls.






Chokhani & Ford              Informational                     [Page 29]

RFC 2527                          PKIX                        March 1999


4.6.8 Cryptographic Module Engineering Controls (26)

   This subcomponent addresses the following aspects of a cryptographic
   module: identification of the cryptographic module boundary,
   input/output, roles and services, finite state machine, physical
   security, software security, operating system security, algorithm
   compliance, electromagnetic compatibility, and self tests.
   Requirements may be expressed through reference to a standard such as
   U.S. FIPS 140-1. (27)

4.7 CERTIFICATE AND CRL PROFILES

   This component is used to specify the certificate format and, if CRLs
   are used, the CRL format.  Assuming use of the X.509 certificate and
   CRL formats, this includes information on profiles, versions, and
   extensions used.

   This component has two subcomponents:

      * Certificate Profile; and

      * CRL Profile.

4.7.1 Certificate Profile

   This subcomponent addresses such topics as the following (potentially
   by reference to a separate profile definition, such as the PKIX Part
   I profile):

      * Version number(s) supported;

      * Certificate extensions populated and their criticality;

      * Cryptographic algorithm object identifiers;

      * Name forms used for the CA, RA, and end entity names;

      * Name constraints used and the name forms used in the  name
        constraints;

      * Applicable certificate policy Object Identifier(s);

      * Usage of the policy constraints extension;

      * Policy qualifiers syntax and semantics; and

      * Processing semantics for the critical certificate policy
        extension.



Chokhani & Ford              Informational                     [Page 30]

RFC 2527                          PKIX                        March 1999


4.7.2 CRL Profile

   This subcomponent addresses such topics as the following (potentially
   by reference to a separate profile definition, such as the PKIX Part
   I profile):

      * Version numbers supported for CRLs; and

      * CRL and CRL entry extensions populated and their criticality.

4.8 SPECIFICATION ADMINISTRATION

   This component is used to specify how this particular certificate
   policy definition or CPS will be maintained.

   It contains the following subcomponents:

      * Specification Change Procedures;

      * Publication and Notification Procedures; and

      * CPS Approval Procedures.

4.8.1 Specification Change Procedures

   It will occasionally be necessary to change certificate policies and
   Certification Practice Statements.  Some of these changes will not
   materially reduce the assurance that a certificate policy or its
   implementation provides, and will be judged by the policy
   administrator as not changing the acceptability of certificates
   asserting the policy for the purposes for which they have been used.
   Such changes to certificate policies and Certification Practice
   Statements need not require a change in the certificate policy Object
   Identifier or the CPS pointer (URL).  Other changes to a
   specification will change the acceptability of certificates for
   specific purposes, and these changes will require changes to the
   certificate policy Object Identifier or CPS pointer (URL).

   This subcomponent contains the following information:

      * A list of specification components, subcomponents, and/or
        elements thereof that can be changed without notification and
        without changes to the certificate policy Object Identifier or
        CPS pointer (URL).

      * A list of specification components, subcomponents, and/or
        elements thereof that may change following a notification period
        without changing the certificate policy Object Identifier or CPS



Chokhani & Ford              Informational                     [Page 31]

RFC 2527                          PKIX                        March 1999


        pointer (URL).  The procedures to be used to notify interested
        parties (relying parties, certification authorities, etc.) of
        the certificate policy or CPS changes are described.  The
        description of notification procedures includes the notification
        mechanism, notification period for comments, mechanism to
        receive, review and incorporate the comments, mechanism for
        final changes to the policy, and the period before final changes
        become effective.

      * A list of specification components, subcomponents, and/or
        elements, changes to which require a change in certificate
        policy Object Identifier or CPS pointer (URL)..

4.8.2 Publication and Notification Procedures

   This subcomponent contains the following elements:

      * A list of components, subcomponents, and elements thereof that
        exist but that are not made publicly available; (33)

      * Descriptions of mechanisms used to distribute the certificate
        policy definition or CPS, including access controls on such
        distribution.

4.8.3 CPS Approval Procedures

   In a certificate policy definition, this subcomponent describes how
   the compliance of a specific CPS with the certificate policy can be
   determined.

5. OUTLINE OF A SET OF PROVISIONS

   This section contains a possible outline for a set of provisions,
   intended to serve as a checklist or (with some further development) a
   standard template for use by certificate policy or CPS writers.  Such
   a common outline will facilitate:

      (a) Comparison of two certificate policies during cross-
          certification (for the purpose of equivalency mapping).

      (b) Comparison of a CPS with a certificate policy definition to
          ensure that the CPS faithfully implements the policy.

      (c) Comparison of two CPSs.







Chokhani & Ford              Informational                     [Page 32]

RFC 2527                          PKIX                        March 1999


   1.   INTRODUCTION

   1.1  Overview

   1.2  Identification

   1.3  Community and Applicability
      1.3.1  Certification authorities
      1.3.2  Registration authorities
      1.3.3  End entities
      1.3.4  Applicability

   1.4  Contact Details
      1.4.1  Specification administration organization
      1.4.2  Contact person
      1.4.3  Person determining CPS suitability for the policy

   2.  GENERAL PROVISIONS

   2.1  Obligations

      2.1.1  CA obligations
      2.1.2  RA obligations
      2.1.3  Subscriber obligations
      2.1.4  Relying party obligations
      2.1.5  Repository obligations

   2.2  Liability

      2.2.1  CA liability
      2.2.2  RA liability

   2.3  Financial responsibility

      2.3.1  Indemnification by relying parties
      2.3.2  Fiduciary relationships
      2.3.3  Administrative processes

   2.4  Interpretation and Enforcement

      2.4.1  Governing law
      2.4.2  Severability, survival, merger, notice
      2.4.3  Dispute resolution procedures

   2.5  Fees

      2.5.1  Certificate issuance or renewal fees
      2.5.2  Certificate access fees



Chokhani & Ford              Informational                     [Page 33]

RFC 2527                          PKIX                        March 1999


      2.5.3  Revocation or status information access fees
      2.5.4  Fees for other services such as policy information
      2.5.5  Refund policy

   2.6  Publication and Repository

      2.6.1  Publication of CA information
      2.6.2  Frequency of publication
      2.6.3  Access controls
      2.6.4  Repositories

   2.7  Compliance audit

      2.7.1  Frequency of entity compliance audit
      2.7.2  Identity/qualifications of auditor
      2.7.3  Auditor's relationship to audited party
      2.7.4  Topics covered by audit
      2.7.5  Actions taken as a result of deficiency
      2.7.6  Communication of results

   2.8  Confidentiality

      2.8.1  Types of information to be kept confidential
      2.8.2  Types of information not considered confidential
      2.8.3  Disclosure of certificate revocation/suspension information
      2.8.4  Release to law enforcement officials
      2.8.5  Release as part of civil discovery
      2.8.6  Disclosure upon owner's request
      2.8.7  Other information release circumstances

   2.9  Intellectual Property Rights

   3.   IDENTIFICATION AND AUTHENTICATION (34)

   3.1  Initial Registration
      3.1.1  Types of names
      3.1.2  Need for names to be meaningful
      3.1.3  Rules for interpreting various name forms
      3.1.4  Uniqueness of names
      3.1.5  Name claim dispute resolution procedure
      3.1.6  Recognition, authentication and role of trademarks
      3.1.7  Method to prove possession of private key
      3.1.8  Authentication of organization identity
      3.1.9  Authentication of individual identity

   3.2  Routine Rekey

   3.3  Rekey after Revocation



Chokhani & Ford              Informational                     [Page 34]

RFC 2527                          PKIX                        March 1999


   3.4  Revocation Request

   4.  OPERATIONAL REQUIREMENTS (34)

   4.1  Certificate Application

   4.2  Certificate Issuance

   4.3  Certificate Acceptance

   4.4  Certificate Suspension and Revocation
      4.4.1  Circumstances for revocation
      4.4.2  Who can request revocation
      4.4.3  Procedure for revocation request
      4.4.4  Revocation request grace period
      4.4.5  Circumstances for suspension
      4.4.6  Who can request suspension
      4.4.7  Procedure for suspension request
      4.4.8  Limits on suspension period
      4.4.9  CRL issuance frequency (if applicable)
      4.4.10  CRL checking requirements
      4.4.11  On-line revocation/status checking availability
      4.4.12  On-line revocation checking requirements
      4.4.13  Other forms of revocation advertisements available
      4.4.14  Checking  requirements  for  other  forms  of  revocation
              advertisements
      4.4.15  Special requirements re key compromise

   4.5  Security Audit Procedures
      4.5.1  Types of event recorded
      4.5.2  Frequency of processing log
      4.5.3  Retention period for audit log
      4.5.4  Protection of audit log
      4.5.5  Audit log backup procedures
      4.5.6  Audit collection system (internal vs external)
      4.5.7  Notification to event-causing subject
      4.5.8  Vulnerability assessments

   4.6  Records Archival

      4.6.1  Types of event recorded
      4.6.2  Retention period for archive
      4.6.3  Protection of archive
      4.6.4  Archive backup procedures
      4.6.5  Requirements for time-stamping of records
      4.6.6  Archive collection system (internal or external)
      4.6.7  Procedures to obtain and verify archive information




Chokhani & Ford              Informational                     [Page 35]

RFC 2527                          PKIX                        March 1999


   4.7  Key changeover

   4.8  Compromise and Disaster Recovery
      4.8.1 Computing resources, software, and/or data are corrupted
      4.8.2 Entity public key is revoked
      4.8.3 Entity key is compromised
      4.8.4 Secure facility after a natural or other type of disaster

   4.9  CA Termination

   5.  PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34)

   5.1  Physical Controls
      5.1.1  Site location and construction
      5.1.2  Physical access
      5.1.3  Power and air conditioning
      5.1.4  Water exposures
      5.1.5  Fire prevention and protection
      5.1.6  Media storage
      5.1.7  Waste disposal
      5.1.8  Off-site backup

   5.2  Procedural Controls
      5.2.1  Trusted roles
      5.2.2  Number of persons required per task
      5.2.3  Identification and authentication for each role

   5.3  Personnel Controls
      5.3.1  Background, qualifications, experience, and  clearance
             requirements
      5.3.2  Background check procedures
      5.3.3  Training requirements
      5.3.4  Retraining frequency and requirements
      5.3.5  Job rotation frequency and sequence
      5.3.6  Sanctions for unauthorized actions
      5.3.7  Contracting personnel requirements
      5.3.8  Documentation supplied to personnel

   6.  TECHNICAL SECURITY CONTROLS (34)

   6.1  Key Pair Generation and Installation
      6.1.1  Key pair generation
      6.1.2  Private key delivery to entity
      6.1.3  Public key delivery to certificate issuer
      6.1.4  CA public key delivery to users
      6.1.5  Key sizes
      6.1.6  Public key parameters generation
      6.1.7  Parameter quality checking



Chokhani & Ford              Informational                     [Page 36]

RFC 2527                          PKIX                        March 1999


      6.1.8  Hardware/software key generation
      6.1.9  Key usage purposes (as per X.509 v3 key usage field)

   6.2  Private Key Protection
      6.2.1  Standards for cryptographic module
      6.2.2  Private key (n out of m) multi-person control
      6.2.3  Private key escrow
      6.2.4  Private key backup
      6.2.5  Private key archival
      6.2.6  Private key entry into cryptographic module
      6.2.7  Method of activating private key
      6.2.8  Method of deactivating private key
      6.2.9  Method of destroying private key

   6.3  Other Aspects of Key Pair Management
      6.3.1  Public key archival
      6.3.2  Usage periods for the public and private keys

   6.4  Activation Data
      6.4.1  Activation data generation and installation
      6.4.2  Activation data protection
      6.4.3  Other aspects of activation data

   6.5  Computer Security Controls
      6.5.1  Specific computer security technical requirements
      6.5.2  Computer security rating

   6.6  Life Cycle Technical Controls
      6.6.1  System development controls
      6.6.2  Security management controls
      6.6.3  Life cycle security ratings

   6.7  Network Security Controls

   6.8  Cryptographic Module Engineering Controls

   7.  CERTIFICATE AND CRL PROFILES

   7.1  Certificate Profile

      7.1.1  Version number(s)
      7.1.2  Certificate extensions
      7.1.3  Algorithm object identifiers
      7.1.4  Name forms
      7.1.5  Name constraints
      7.1.6  Certificate policy Object Identifier
      7.1.7  Usage of Policy Constraints extension
      7.1.8  Policy qualifiers syntax and semantics



Chokhani & Ford              Informational                     [Page 37]

RFC 2527                          PKIX                        March 1999


      7.1.9  Processing  semantics  for  the critical certificate policy
             extension

   7.2  CRL Profile

      7.2.1  Version number(s)
      7.2.2  CRL and CRL entry extensions

   8.  SPECIFICATION ADMINISTRATION

   8.1  Specification change procedures

   8.2  Publication and notification policies

   8.3  CPS approval procedures




































Chokhani & Ford              Informational                     [Page 38]

RFC 2527                          PKIX                        March 1999


6.  ACKNOWLEDGMENTS

   The development of this document was supported by the Government of
   Canada's Policy Management Authority (PMA) Committee, the National
   Security Agency, the National Institute of Standards and Technology
   (NIST), and the American Bar Association Information Security
   Committee Accreditation Technical Working Group. Special thanks are
   due to Dave Fillingham, Jim Brandt, and Edmond Van Hees for their
   inspiration, support, and valuable inputs.

   The following individuals also deserve credit for their review and
   input:

      Teresa Acevedo, A&N Associates;
      Michael Baum; VeriSign;
      Sharon Boeyen, Entrust;
      Bob Burger, McCarter & English;
      Bill Burr, NIST;
      Patrick Cain, BBN;
      Michael Harrop, Government of Canada Treasury Board;
      Rick Hornbeck, Digital Commerce Services;
      Francois Marinier, Domus Software;
      John Morris, CygnaCom Solutions;
      Tim Moses, Entrust;
      Noel Nazario, NIST;
      John Nicolletos, A&N Associates;
      Jean Petty, CygnaCom Solutions;
      Denis Pinkas, Bull;
      J.-F. Sauriol, Domus Software;
      Robert Shirey, BBN;
      Mark Silvern, VeriSign;
      David Simonetti, Booz, Allen and Hamilton; and
      Darryl Stal, Entrust.

   Johnny Hsiung, and Chris Miller assisted in the preparation of the
   manuscript.















Chokhani & Ford              Informational                     [Page 39]

RFC 2527                          PKIX                        March 1999


7.  REFERENCES

   [ABA1] American Bar Association, Digital Signature Guidelines: Legal
          Infrastructure for Certification Authorities and Electronic
          Commerce, 1995.

   [BAU1] Michael. S. Baum, Federal Certification Authority Liability
          and Policy, NIST-GCR- 94-654, June 1994.

   [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
          Technology - Open Systems Interconnection: The Directory:
          Authentication Framework," 1997 edition. (Pending publication
          of 1997 edition, use 1993 edition with the following amendment
          applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8
          on Certificate Extensions, June 1996.)

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

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

8.  AUTHORS' ADDRESSES

   Santosh Chokhani
   CygnaCom Solutions, Inc.
   Suite 100 West
   7927 Jones Branch Drive
   McLean, VA 22102

   Phone: (703) 848-0883
   Fax: (703) 848-0960
   EMail: chokhani@cygnacom.com


   Warwick Ford
   VeriSign, Inc.
   301 Edgewater Place, Suite 210
   Wakefield, MA 01880

   Phone: (781) 245-6996 x225
   Fax: (781) 245-6006
   EMail: wford@verisign.com






Chokhani & Ford              Informational                     [Page 40]

RFC 2527                          PKIX                        March 1999


NOTES

   1 The ABA Digital Signature Guidelines can be purchased from the ABA.
     See http://www.abanet.com for ordering details.

   2 Examples of types of entity for subject CAs are a subordinate
     organization (e.g., branch or division), a federal government
     agency, or a state or provincial government department.

   3 This statement can have significant implications.  For example,
     suppose a bank claims that it issues CA certificates to its
     branches only.  Now, the user of a CA certificate issued by the
     bank can assume that the subject CA in the certificate is a branch
     of the bank

   4 Examples of the types of subject RA entities are branch and
     division of an organization.

   5 Examples of types of subject end entities are bank customers,
     telephone company subscribers, and employees of a government
     department

   6 This statement can have significant implications.  For example,
     suppose Government CA claims that it issues certificates to
     Government employees only.  Now, the user of a certificate issued
     by the Government CA can assume that the subject of the certificate
     is a Government employee.

   7 Examples include X.500 distinguished name, Internet e-mail address,
     and URL.

   8 The term "meaningful" means that the name form has commonly
     understood semantics to determine identity of the person and/or
     organization.  Directory names and RFC 822 names may be more or
     less meaningful.

   9 Examples of proof include the issuing CA generating the key, or
     requiring the subject to send an electronically signed request or
     to sign a challenge.

   10 Examples of organization identity authentication are: articles of
      incorporation, duly signed corporate resolutions, company seal,
      and notarized documents.

   11 Examples of individual identity authentication are: biometrics
      (thumb print, ten finger print, face, palm, and retina scan),
      driver's license, passport, credit card, company badge, and
      government badge.



Chokhani & Ford              Informational                     [Page 41]

RFC 2527                          PKIX                        March 1999


   12 Examples include duly signed authorization papers or corporate ID
      badge.

   13 The identification policy for routine rekey should be the same as
      the one for initial registration since the same subject needs
      rekeying.  The rekey authentication may be accomplished using the
      techniques for initial I&A or using digitally signed requests.

   14 This identification and authentication policy could be the same as
      that for initial registration.

   15 This policy could be the same as the one for initial registration.

   16 The identification policy for Revocation request could be the same
      as that for initial registration since the same subject
      certificate needs to be revoked.  The authentication policy could
      accept a Revocation request digitally signed by subject.  The
      authentication information used during initial registration could
      be acceptable for Revocation request. Other less stringent
      authentication policy could be defined.

   17 The identification policy for key compromise notification could be
      the same as the one for initial registration since the same
      subject certificate needs to be revoked.  The authentication
      policy could accept a Revocation request digitally signed by
      subject.  The authentication information used during initial
      registration could be acceptable for key compromise notification.
      Other less stringent authentication policy could be defined.

   18 The n out of m rule allows a key to be split in m parts.  The m
      parts may be given to m different individuals.  Any n parts out of
      the m parts may be used to fully reconstitute the key, but having
      any n- 1 parts provides one with no information about the key.

   19 A key may be escrowed, backed up or archived.  Each of these
      functions have different purpose.  Thus, a key may go through any
      subset of these functions depending on the requirements.  The
      purpose of escrow is to allow a third party (such as an
      organization or government) to legally obtain the key without the
      cooperation of the subject.  The purpose of back up is to allow
      the subject to reconstitute the key in case of the destruction of
      the key.  The purpose of archive is to provide for reuse of the
      key in future, e.g., use the private key to decrypt a document.

   20 An example of activation data is a PIN or passphrase.

   21 Examples of physical access controls are: monitored facility ,
      guarded facility, locked facility, access controlled using tokens,



Chokhani & Ford              Informational                     [Page 42]

RFC 2527                          PKIX                        March 1999


      access controlled using biometrics, and access controlled through
      an access list.

   22 Examples of the roles include system administrator, system
      security officer, and system auditor.  The duties of the system
      administrator are to configure, generate, boot, and operate the
      system.  The duties of the system security officer are to assign
      accounts and privileges.  The duties of the system auditor are to
      set up system audit profile, perform audit file management, and
      audit review.

   23 The background checks may include clearance level (e.g., none,
      sensitive, confidential, secret, top secret, etc.) and the
      clearance granting authority name.  In lieu of or in addition to a
      defined clearance, the background checks may include types of
      background information (e.g., name, place of birth, date of birth,
      home address, previous residences, previous employment, and any
      other information that may help determine trustworthiness).  The
      description should also include which information was verified and
      how.

   24 For example, the certificate policy may impose personnel security
      requirements on the network system administrator responsible for a
      CA's network access.

   25 Regardless of whether authorized persons are employees, practices
      should be implemented to ensure that each authorized person is
      held accountable for his/her actions.

   26 A cryptographic module is hardware, software, or firmware or any
      combination of them.

   27 The compliance description should be specific and detailed.  For
      example, for each FIPS 140-1 requirement, describe the level and
      whether the level has been certified by an accredited laboratory.

   28 Example of audit events are: request to create a certificate,
      request to revoke a certificate, key compromise notification,
      creation of a certificate, revocation of a certificate, issuance
      of a certificate, issuance of a CRL, issuance of key compromise
      CRL, establishment of trusted roles on the CA, actions of truste
      personnel, changes to CA keys, etc.

   29 Example of archive events are: request to create a certificate,
      request to revoke a certificate, key compromise notification,
      creation of a certificate, revocation of a certificate, issuance
      of a certificate, issuance of a CRL, issuance of key compromise
      CRL, and changes to CA keys.



Chokhani & Ford              Informational                     [Page 43]

RFC 2527                          PKIX                        March 1999


   30 A parent CA is an example of audit relationship.

   31 Example of compliance audit topics: sample check on the various
      I&A policies, comprehensive checks on key management policies,
      comprehensive checks on system security controls, comprehensive
      checks on operations policy, and comprehensive checks on
      certificate profiles.

   32 The examples include, temporary suspension of operations until
      deficiencies are corrected, revocation of entity certificate,
      change in personnel, invocation of liability policy, more frequent
      compliance audit, etc.

   33 An organization may choose not to make public some of its security
      controls, clearance procedures, or some others elements due to
      their sensitivity.

   34 All or some of the following items may be different for the
      various types of entities, i.e., CA, RA, and end entities.

LIST OF ACRONYMS

   ABA - American Bar Association
   CA - Certification Authority
   CPS - Certification Practice Statement
   CRL - Certificate Revocation List
   DAM - Draft Amendment
   FIPS - Federal Information Processing Standard
   I&A - Identification and Authentication
   IEC - International Electrotechnical Commission
   IETF - Internet Engineering Task Force
   IP - Internet Protocol
   ISO - International Organization for Standardization
   ITU - International Telecommunications Union
   NIST - National Institute of Standards and Technology
   OID - Object Identifier
   PIN - Personal Identification Number
   PKI - Public Key Infrastructure
   PKIX - Public Key Infrastructure (X.509) (IETF Working Group)
   RA - Registration Authority
   RFC - Request For Comment
   URL - Uniform Resource Locator
   US - United States








Chokhani & Ford              Informational                     [Page 44]

RFC 2527                          PKIX                        March 1999


Full Copyright Statement

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

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

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

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
























Chokhani & Ford              Informational                     [Page 45]