File: rfc3281.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 (2243 lines) | stat: -rw-r--r-- 90,580 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






Network Working Group                                         S. Farrell
Request for Comments: 3281                        Baltimore Technologies
Category: Standards Track                                     R. Housley
                                                        RSA Laboratories
                                                              April 2002


                   An Internet Attribute Certificate
                       Profile for Authorization

Status of this Memo

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

Copyright Notice

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

Abstract

   This specification defines a profile for the use of X.509 Attribute
   Certificates in Internet Protocols.  Attribute certificates may be
   used in a wide range of applications and environments covering a
   broad spectrum of interoperability goals and a broader spectrum of
   operational and assurance requirements.  The goal of this document is
   to establish a common baseline for generic applications requiring
   broad interoperability as well as limited special purpose
   requirements.  The profile places emphasis on attribute certificate
   support for Internet electronic mail, IPSec, and WWW security
   applications.

Table of Contents

   1. Introduction.................................................  2
       1.1  Delegation and AC chains...............................  4
       1.2  Attribute Certificate Distribution ("push" vs. "pull").  4
       1.3  Document Structure.....................................  6
   2. Terminology..................................................  6
   3. Requirements.................................................  7
   4. Attribute Certificate Profile................................  7
       4.1  X.509 Attribute Certificate Definition.................  8
       4.2  Profile of Standard Fields............................. 10
           4.2.1  Version.......................................... 10
           4.2.2  Holder........................................... 11



Farrell & Housley           Standards Track                     [Page 1]

RFC 3281           An Internet Attribute Certificate          April 2002


           4.2.3  Issuer........................................... 12
           4.2.4  Signature........................................ 12
           4.2.5  Serial Number.................................... 12
           4.2.6  Validity Period.................................. 13
           4.2.7  Attributes....................................... 13
           4.2.8  Issuer Unique Identifier......................... 14
           4.2.9  Extensions....................................... 14
       4.3  Extensions............................................. 14
           4.3.1  Audit Identity................................... 14
           4.3.2  AC Targeting..................................... 15
           4.3.3  Authority Key Identifier......................... 17
           4.3.4  Authority Information Access..................... 17
           4.3.5  CRL Distribution Points.......................... 17
           4.3.6  No Revocation Available.......................... 18
       4.4  Attribute Types........................................ 18
           4.4.1  Service Authentication Information............... 19
           4.4.2  Access Identity.................................. 19
           4.4.3  Charging Identity................................ 20
           4.4.4  Group............................................ 20
           4.4.5  Role............................................. 20
           4.4.6  Clearance........................................ 21
       4.5  Profile of AC issuer's PKC............................. 22
   5. Attribute Certificate Validation............................. 23
   6. Revocation................................................... 24
   7. Optional Features............................................ 25
       7.1  Attribute Encryption................................... 25
       7.2  Proxying............................................... 27
       7.3  Use of ObjectDigestInfo................................ 28
       7.4  AA Controls............................................ 29
   8. Security Considerations...................................... 30
   9. IANA Considerations.......................................... 32
   10. References.................................................. 32
   Appendix A: Object Identifiers.................................. 34
   Appendix B: ASN.1 Module........................................ 35
   Author's Addresses.............................................. 39
   Acknowledgements................................................ 39
   Full Copyright Statement........................................ 40

1. Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119.

   X.509 public key certificates (PKCs) [X.509-1997, X.509-2000,
   PKIXPROF] bind an identity and a public key.  An attribute
   certificate (AC) is a structure similar to a PKC; the main difference
   being that the AC contains no public key.  An AC may contain



Farrell & Housley           Standards Track                     [Page 2]

RFC 3281           An Internet Attribute Certificate          April 2002


   attributes that specify group membership, role, security clearance,
   or other authorization information associated with the AC holder.
   The syntax for the AC is defined in Recommendation X.509, making the
   term "X.509 certificate" ambiguous.

   Some people constantly confuse PKCs and ACs.  An analogy may make the
   distinction clear.  A PKC can be considered to be like a passport: it
   identifies the holder, tends to last for a long time, and should not
   be trivial to obtain.  An AC is more like an entry visa: it is
   typically issued by a different authority and does not last for as
   long a time.  As acquiring an entry visa typically requires
   presenting a passport, getting a visa can be a simpler process.

   Authorization information may be placed in a PKC extension or placed
   in a separate attribute certificate (AC).  The placement of
   authorization information in PKCs is usually undesirable for two
   reasons.  First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime.  Second,
   the PKC issuer is not usually authoritative for the authorization
   information.  This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source.

   For these reasons, it is often better to separate authorization
   information from the PKC.  Yet, authorization information also needs
   to be bound to an identity.  An AC provides this binding; it is
   simply a digitally signed (or certified) identity and set of
   attributes.

   An AC may be used with various security services, including access
   control, data origin authentication, and non-repudiation.

   PKCs can provide an identity to access control decision functions.
   However, in many contexts the identity is not the criterion that is
   used for access control decisions, rather the role or group-
   membership of the accessor is the criterion used.  Such access
   control schemes are called role-based access control.

   When making an access control decision based on an AC, an access
   control decision function may need to ensure that the appropriate AC
   holder is the entity that has requested access.  One way in which the
   linkage between the request or identity and the AC can be achieved is
   the inclusion of a reference to a PKC within the AC and the use of
   the private key corresponding to the PKC for authentication within
   the access request.





Farrell & Housley           Standards Track                     [Page 3]

RFC 3281           An Internet Attribute Certificate          April 2002


   ACs may also be used in the context of a data origin authentication
   service and a non-repudiation service.  In these contexts, the
   attributes contained in the AC provide additional information about
   the signing entity.  This information can be used to make sure that
   the entity is authorized to sign the data.  This kind of checking
   depends either on the context in which the data is exchanged or on
   the data that has been digitally signed.

1.1 Delegation and AC chains

   The X.509 standard [X.509-2000] defines authorization as the
   "conveyance of privilege from one entity that holds such privilege,
   to another entity".  An AC is one authorization mechanism.

   An ordered sequence of ACs could be used to verify the authenticity
   of a privilege asserter's privilege.  In this way, chains or paths of
   ACs could be employed to delegate authorization.

   Since the administration and processing associated with such AC
   chains is complex and the use of ACs in the Internet today is quite
   limited, this specification does NOT RECOMMEND the use of AC chains.
   Other (future) specifications may address the use of AC chains.  This
   specification deals with the simple cases, where one authority issues
   all of the ACs for a particular set of attributes.  However, this
   simplification does not preclude the use of several different
   authorities, each of which manages a different set of attributes.
   For example, group membership may be included in one AC issued by one
   authority, and security clearance may be included in another AC
   issued by another authority.

   This means that conformant implementations are only REQUIRED to be
   able to process a single AC at a time.  Processing of more than one
   AC, one after another, may be necessary.  Note however, that
   validation of an AC MAY require validation of a chain of PKCs, as
   specified in [PKIXPROF].

1.2 Attribute Certificate Distribution ("push" vs. "pull")

   As discussed above, ACs provide a mechanism to securely provide
   authorization information to, for example, access control decision
   functions.  However, there are a number of possible communication
   paths for ACs.

   In some environments, it is suitable for a client to "push" an AC to
   a server.  This means that no new connections between the client and
   server are required.  It also means that no search burden is imposed
   on servers, which improves performance and that the AC verifier is




Farrell & Housley           Standards Track                     [Page 4]

RFC 3281           An Internet Attribute Certificate          April 2002


   only presented with what it "needs to know."  The "push" model is
   especially suitable in inter-domain cases where the client's rights
   should be assigned within the client's "home" domain.

   In other cases, it is more suitable for a client to simply
   authenticate to the server and for the server to request or "pull"
   the client's AC from an AC issuer or a repository.  A major benefit
   of the "pull" model is that it can be implemented without changes to
   the client or to the client-server protocol.  The "pull" model is
   especially suitable for inter-domain cases where the client's rights
   should be assigned within the server's domain, rather than within the
   client's domain.

   There are a number of possible exchanges involving three entities:
   the client, the server, and the AC issuer.  In addition, a directory
   service or other repository for AC retrieval MAY be supported.

   Figure 1 shows an abstract view of the exchanges that may involve
   ACs.  This profile does not specify a protocol for these exchanges.

      +--------------+
      |              |        Server Acquisition
      |  AC issuer   +----------------------------+
      |              |                            |
      +--+-----------+                            |
         |                                        |
         | Client                                 |
         | Acquisition                            |
         |                                        |
      +--+-----------+                         +--+------------+
      |              |       AC "push"         |               |
      |   Client     +-------------------------+    Server     |
      |              | (part of app. protocol) |               |
      +--+-----------+                         +--+------------+
         |                                        |
         | Client                                 | Server
         | Lookup        +--------------+         | Lookup
         |               |              |         |
         +---------------+  Repository  +---------+
                         |              |
                         +--------------+

                     Figure 1: AC Exchanges








Farrell & Housley           Standards Track                     [Page 5]

RFC 3281           An Internet Attribute Certificate          April 2002


1.3 Document Structure

   Section 2 defines some terminology.  Section 3 specifies the
   requirements that this profile is intended to meet.  Section 4
   contains the profile of the X.509 AC.  Section 5 specifies rules for
   AC validation.  Section 6 specifies rules for AC revocation checks.
   Section 7 specifies optional features which MAY be supported;
   however, support for these features is not required for conformance
   to this profile.  Finally, appendices contain the list of OIDs
   required to support this specification and an ASN.1 module.

2. Terminology

   For simplicity, we use the terms client and server in this
   specification.  This is not intended to indicate that ACs are only to
   be used in client-server environments.  For example, ACs may be used
   in the S/MIME v3 context, where the mail user agent would be both a
   "client" and a "server" in the sense the terms are used here.

   Term          Meaning

   AA            Attribute Authority, the entity that issues the
                 AC, synonymous in this specification with "AC
                 issuer"
   AC            Attribute Certificate
   AC user       any entity that parses or processes an AC
   AC verifier   any entity that checks the validity of an AC and
                 then makes use of the result
   AC issuer     the entity which signs the AC, synonymous in this
                 specification with "AA"
   AC holder     the entity indicated (perhaps indirectly) in the
                 holder field of the AC
   Client        the entity which is requesting the action for
                 which authorization checks are to be made
   Proxying      In this specification, Proxying is used to mean
                 the situation where an application server acts as
                 an application client on behalf of a user.
                 Proxying here does not mean granting of authority.
   PKC           Public Key Certificate - uses the type ASN.1
                 Certificate defined in X.509 and profiled in RFC
                 2459.  This (non-standard) acronym is used in order
                 to avoid confusion about the term "X.509
                 certificate".
   Server        the entity which requires that the authorization
                 checks are made






Farrell & Housley           Standards Track                     [Page 6]

RFC 3281           An Internet Attribute Certificate          April 2002


3. Requirements

   This AC profile meets the following requirements.

   Time/Validity requirements:

   1. Support for short-lived as well as long-lived ACs.  Typical
      short-lived validity periods might be measured in hours, as
      opposed to months for PKCs.  Short validity periods allow ACs to
      be useful without a revocation mechanism.

   Attribute Types:

   2. Issuers of ACs should be able to define their own attribute types
      for use within closed domains.

   3. Some standard attribute types, which can be contained within ACs,
      should be defined.  Examples include "access identity," "group,"
      "role," "clearance," "audit identity," and "charging identity."

   4. Standard attribute types should be defined in a manner that
      permits an AC verifier to distinguish between uses of the same
      attribute in different domains.  For example, the "Administrators
      group" as defined by Baltimore and the "Administrators group" as
      defined by SPYRUS should be easily distinguished.

   Targeting of ACs:

   5. It should be possible to "target" an AC at one, or a small number
      of, servers.  This means that a trustworthy non-target server will
      reject the AC for authorization decisions.

   Push vs. Pull

   6. ACs should be defined so that they can either be "pushed" by the
      client to the server, or "pulled" by the server from a repository
      or other network service, including an online AC issuer.

4. Attribute Certificate Profile

   ACs may be used in a wide range of applications and environments
   covering a broad spectrum of interoperability goals and a broader
   spectrum of operational and assurance requirements.  The goal of this
   document is to establish a common baseline for generic applications
   requiring broad interoperability and limited special purpose






Farrell & Housley           Standards Track                     [Page 7]

RFC 3281           An Internet Attribute Certificate          April 2002


   requirements.  In particular, the emphasis will be on supporting the
   use of attribute certificates for informal Internet electronic mail,
   IPSec, and WWW applications.

   This section presents a profile for ACs that will foster
   interoperability.  This section also defines some private extensions
   for the Internet community.

   While the ISO/IEC/ITU documents use the 1993 (or later) version of
   ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for
   PKCs [PKIXPROF].  The encoded certificates and extensions from either
   ASN.1 version are bit-wise identical.

   Where maximum lengths for fields are specified, these lengths refer
   to the DER encoding and do not include the ASN.1 tag or length
   fields.

   Conforming implementations MUST support the profile specified in this
   section.

4.1 X.509 Attribute Certificate Definition

   X.509 contains the definition of an AC given below.  All types that
   are not defined in this document can be found in [PKIXPROF].

            AttributeCertificate ::= SEQUENCE {
                 acinfo               AttributeCertificateInfo,
                 signatureAlgorithm   AlgorithmIdentifier,
                 signatureValue       BIT STRING
            }

            AttributeCertificateInfo ::= SEQUENCE {
                 version              AttCertVersion -- version is v2,
                 holder               Holder,
                 issuer               AttCertIssuer,
                 signature            AlgorithmIdentifier,
                 serialNumber         CertificateSerialNumber,
                 attrCertValidityPeriod   AttCertValidityPeriod,
                 attributes           SEQUENCE OF Attribute,
                 issuerUniqueID       UniqueIdentifier OPTIONAL,
                 extensions           Extensions OPTIONAL
            }

            AttCertVersion ::= INTEGER { v2(1) }
            Holder ::= SEQUENCE {
                  baseCertificateID   [0] IssuerSerial OPTIONAL,
                           -- the issuer and serial number of
                           -- the holder's Public Key Certificate



Farrell & Housley           Standards Track                     [Page 8]

RFC 3281           An Internet Attribute Certificate          April 2002


                  entityName          [1] GeneralNames OPTIONAL,
                           -- the name of the claimant or role
                  objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
                           -- used to directly authenticate the holder,
                           -- for example, an executable
            }

            ObjectDigestInfo ::= SEQUENCE {
                 digestedObjectType  ENUMERATED {
                         publicKey            (0),
                         publicKeyCert        (1),
                         otherObjectTypes     (2) },
                                 -- otherObjectTypes MUST NOT
                                 -- be used in this profile
                 otherObjectTypeID   OBJECT IDENTIFIER OPTIONAL,
                 digestAlgorithm     AlgorithmIdentifier,
                 objectDigest        BIT STRING
            }

            AttCertIssuer ::= CHOICE {
                 v1Form   GeneralNames,  -- MUST NOT be used in this
                                         -- profile
                 v2Form   [0] V2Form     -- v2 only
            }

            V2Form ::= SEQUENCE {
                 issuerName            GeneralNames  OPTIONAL,
                 baseCertificateID     [0] IssuerSerial  OPTIONAL,
                 objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
                   -- issuerName MUST be present in this profile
                   -- baseCertificateID and objectDigestInfo MUST NOT
                   -- be present in this profile
            }

            IssuerSerial  ::=  SEQUENCE {
                 issuer         GeneralNames,
                 serial         CertificateSerialNumber,
                 issuerUID      UniqueIdentifier OPTIONAL
            }

            AttCertValidityPeriod  ::= SEQUENCE {
                 notBeforeTime  GeneralizedTime,
                 notAfterTime   GeneralizedTime
            }







Farrell & Housley           Standards Track                     [Page 9]

RFC 3281           An Internet Attribute Certificate          April 2002


   Although the Attribute syntax is defined in [PKIXPROF], we repeat
   the definition here for convenience.

            Attribute ::= SEQUENCE {
                  type      AttributeType,
                  values    SET OF AttributeValue
                    -- at least one value is required
            }

            AttributeType ::= OBJECT IDENTIFIER

            AttributeValue ::= ANY DEFINED BY AttributeType

   Implementers should note that the DER encoding (see [X.509-
   1988],[X.208-1988]) of the SET OF values requires ordering of the
   encodings of the values.  Though this issue arises with respect to
   distinguished names, and has to be handled by [PKIXPROF]
   implementations, it is much more significant in this context, since
   the inclusion of multiple values is much more common in ACs.

4.2 Profile of Standard Fields

   GeneralName offers great flexibility.  To achieve interoperability,
   in spite of this flexibility, this profile imposes constraints on the
   use of GeneralName.

   Conforming implementations MUST be able to support the dNSName,
   directoryName, uniformResourceIdentifier, and iPAddress options.
   This is compatible with the GeneralName requirements in [PKIXPROF]
   (mainly in section 4.2.1.7).

   Conforming implementations MUST NOT use the x400Address,
   ediPartyName, or registeredID options.

   Conforming implementations MAY use the otherName option to convey
   name forms defined in Internet Standards.  For example, Kerberos
   [KRB] format names can be encoded into the otherName, using a
   Kerberos 5 principal name OID and a SEQUENCE of the Realm and the
   PrincipalName.

4.2.1   Version

   The version field MUST have the value of v2.  That is, the version
   field is present in the DER encoding.







Farrell & Housley           Standards Track                    [Page 10]

RFC 3281           An Internet Attribute Certificate          April 2002


   Note: This version (v2) is not backwards compatible with the previous
   attribute certificate definition (v1) from the 1997 X.509 standard
   [X.509-1997], but is compatible with the v2 definition from X.509
   (2000) [X.509-2000].

4.2.2   Holder

   The Holder field is a SEQUENCE allowing three different (optional)
   syntaxes: baseCertificateID, entityName and objectDigestInfo.  Where
   only one option is present, the meaning of the Holder field is clear.
   However, where more than one option is used, there is a potential for
   confusion as to which option is "normative", which is a "hint" etc.
   Since the correct position is not clear from [X.509-2000], this
   specification RECOMMENDS that only one of the options be used in any
   given AC.

   For any environment where the AC is passed in an authenticated
   message or session and where the authentication is based on the use
   of an X.509 PKC, the holder field SHOULD use the baseCertificateID.

   With the baseCertificateID option, the holder's PKC serialNumber and
   issuer MUST be identical to the AC holder field.  The PKC issuer MUST
   have a non-empty distinguished name which is to be present as the
   single value of the holder.baseCertificateID.issuer construct in the
   directoryName field.  The AC holder.baseCertificateID.issuerUID field
   MUST only be used if the holder's PKC contains an issuerUniqueID
   field.  If both the AC holder.baseCertificateID.issuerUID and the PKC
   issuerUniqueID fields are present, the same value MUST be present in
   both fields.  Thus, the baseCertificateID is only usable with PKC
   profiles (like [PKIXPROF]) which mandate that the PKC issuer field
   contain a non-empty distinguished name value.

   Note: An empty distinguished name is a distinguished name where the
   SEQUENCE OF relative distinguished names is of zero length.  In a DER
   encoding, this has the value '3000'H.

   If the holder field uses the entityName option and the underlying
   authentication is based on a PKC, the entityName MUST be the same as
   the PKC subject field or one of the values of the PKC subjectAltName
   field extension (if present).  Note that [PKIXPROF] mandates that the
   subjectAltName extension be present if the PKC subject is an empty
   distinguished name.  See the security considerations section which
   mentions some name collision problems that may arise when using the
   entityName option.

   In any other case where the holder field uses the entityName option,
   only one name SHOULD be present.




Farrell & Housley           Standards Track                    [Page 11]

RFC 3281           An Internet Attribute Certificate          April 2002


   Implementations conforming to this profile are not required to
   support the use of the objectDigest field.  However, section 7.3
   specifies how this optional feature MAY be used.

   Any protocol conforming to this profile SHOULD specify which AC
   holder option is to be used and how this fits with the supported
   authentication schemes defined in that protocol.

4.2.3   Issuer

   ACs conforming to this profile MUST use the v2Form choice, which MUST
   contain one and only one GeneralName in the issuerName, which MUST
   contain a non-empty distinguished name in the directoryName field.
   This means that all AC issuers MUST have non-empty distinguished
   names.  ACs conforming to this profile MUST omit the
   baseCertificateID and objectDigestInfo fields.

   Part of the reason for the use of the v2Form containing only an
   issuerName is that it means that the AC issuer does not have to know
   which PKC the AC verifier will use for it (the AC issuer).  Using the
   baseCertificateID field to reference the AC issuer would mean that
   the AC verifier would have to trust the PKC that the AC issuer chose
   (for itself) at AC creation time.

4.2.4   Signature

   Contains the algorithm identifier used to validate the AC signature.

   This MUST be one of the signing algorithms defined in [PKIXALGS].
   Conforming implementations MUST honor all MUST/SHOULD/MAY signing
   algorithm statements specified in [PKIXALGS].

4.2.5   Serial Number

   For any conforming AC, the issuer/serialNumber pair MUST form a
   unique combination, even if ACs are very short-lived.

   AC issuers MUST force the serialNumber to be a positive integer, that
   is, the sign bit in the DER encoding of the INTEGER value MUST be
   zero - this can be done by adding a leading (leftmost) '00'H octet if
   necessary.  This removes a potential ambiguity in mapping between a
   string of octets and an integer value.

   Given the uniqueness and timing requirements above, serial numbers
   can be expected to contain long integers.  AC users MUST be able to
   handle serialNumber values longer than 4 octets.  Conformant ACs MUST
   NOT contain serialNumber values longer than 20 octets.




Farrell & Housley           Standards Track                    [Page 12]

RFC 3281           An Internet Attribute Certificate          April 2002


   There is no requirement that the serial numbers used by any AC issuer
   follow any particular ordering.  In particular, they need not be
   monotonically increasing with time.  Each AC issuer MUST ensure that
   each AC that it issues contains a unique serial number.

4.2.6   Validity Period

   The attrCertValidityPeriod (a.k.a. validity) field specifies the
   period for which the AC issuer certifies that the binding between the
   holder and the attributes fields will be valid.

   The generalized time type, GeneralizedTime, is a standard ASN.1 type
   for variable precision representation of time.  The GeneralizedTime
   field can optionally include a representation of the time
   differential between the local time zone and Greenwich Mean Time.

   For the purposes of this profile, GeneralizedTime values MUST be
   expressed in Coordinated universal time (UTC) (also known as
   Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times
   are YYYYMMDDHHMMSSZ), even when the number of seconds is zero.
   GeneralizedTime values MUST NOT include fractional seconds.

   (Note: this is the same as specified in [PKIXPROF], section
   4.1.2.5.2.)

   AC users MUST be able to handle an AC which, at the time of
   processing, has parts of its validity period or all its validity
   period in the past or in the future (a post-dated AC).  This is valid
   for some applications, such as backup.

4.2.7   Attributes

   The attributes field gives information about the AC holder.  When the
   AC is used for authorization, this will often contain a set of
   privileges.

   The attributes field contains a SEQUENCE OF Attribute.  Each
   Attribute MAY contain a SET OF values.  For a given AC, each
   AttributeType OBJECT IDENTIFIER in the sequence MUST be unique.  That
   is, only one instance of each attribute can occur in a single AC, but
   each instance can be multi-valued.

   AC users MUST be able to handle multiple values for all attribute
   types.

   An AC MUST contain at least one attribute.  That is, the SEQUENCE OF
   Attributes MUST NOT be of zero length.




Farrell & Housley           Standards Track                    [Page 13]

RFC 3281           An Internet Attribute Certificate          April 2002


   Some standard attribute types are defined in section 4.4.

4.2.8   Issuer Unique Identifier

   This field MUST NOT be used unless it is also used in the AC issuer's
   PKC, in which case it MUST be used.  Note that [PKIXPROF] states that
   this field SHOULD NOT be used by conforming CAs, but that
   applications SHOULD be able to parse PKCs containing the field.

4.2.9   Extensions

   The extensions field generally gives information about the AC as
   opposed to information about the AC holder.

   An AC that has no extensions conforms to the profile; however,
   section 4.3 defines the extensions that MAY be used with this
   profile, and whether or not they may be marked critical.  If any
   other critical extension is used, the AC does not conform to this
   profile.  However, if any other non-critical extension is used, the
   AC does conform to this profile.

   The extensions defined for ACs provide methods for associating
   additional attributes with holders.  This profile also allows
   communities to define private extensions to carry information unique
   to those communities.  Each extension in an AC may be designated as
   critical or non-critical.  An AC using system MUST reject an AC if it
   encounters a critical extension it does not recognize; however, a
   non-critical extension may be ignored if it is not recognized.
   Section 4.3 presents recommended extensions used within Internet ACs
   and standard locations for information.  Communities may elect to use
   additional extensions; however, caution should be exercised in
   adopting any critical extensions in ACs which might prevent use in a
   general context.

4.3 Extensions

4.3.1   Audit Identity

   In some circumstances, it is required (e.g. by data protection/data
   privacy legislation) that audit trails not contain records which
   directly identify individuals.  This circumstance may make the use of
   the AC holder field unsuitable for use in audit trails.

   To allow for such cases, an AC MAY contain an audit identity
   extension.  Ideally it SHOULD be infeasible to derive the AC holder's
   identity from the audit identity value without the cooperation of the
   AC issuer.




Farrell & Housley           Standards Track                    [Page 14]

RFC 3281           An Internet Attribute Certificate          April 2002


   The value of the audit identity, along with the AC issuer/serial,
   SHOULD then be used for audit/logging purposes.  If the value of the
   audit identity is suitably chosen, a server/service administrator can
   use audit trails to track the behavior of an AC holder without being
   able to identify the AC holder.

   The server/service administrator in combination with the AC issuer
   MUST be able to identify the AC holder in cases where misbehavior is
   detected.  This means that the AC issuer MUST be able to determine
   the actual identity of the AC holder from the audit identity.

   Of course, auditing could be based on the AC issuer/serial pair;
   however, this method does not allow tracking of the same AC holder
   with multiple ACs.  Thus, an audit identity is only useful if it
   lasts for longer than the typical AC lifetime.  Auditing could also
   be based on the AC holder's PKC issuer/serial; however, this will
   often allow the server/service administrator to identify the AC
   holder.

   As the AC verifier might otherwise use the AC holder or some other
   identifying value for audit purposes, this extension MUST be critical
   when used.

   Protocols that use ACs will often expose the identity of the AC
   holder in the bits on-the-wire.  In such cases, an opaque audit
   identity does not make use of the AC anonymous; it simply ensures
   that the ensuing audit trails do not contain identifying information.

   The value of an audit identity MUST be longer than zero octets.  The
   value of an audit identity MUST NOT be longer than 20 octets.

      name           id-pe-ac-auditIdentity
      OID            { id-pe 4 }
      syntax         OCTET STRING
      criticality    MUST be TRUE

4.3.2   AC Targeting

   To target an AC, the target information extension, imported from
   [X.509-2000], MAY be used to specify a number of servers/services.
   The intent is that the AC SHOULD only be usable at the specified
   servers/services.  An (honest) AC verifier who is not amongst the
   named servers/services MUST reject the AC.

   If this extension is not present, the AC is not targeted and may be
   accepted by any server.





Farrell & Housley           Standards Track                    [Page 15]

RFC 3281           An Internet Attribute Certificate          April 2002


   In this profile, the targeting information simply consists of a list
   of named targets or groups.

   The following syntax is used to represent the targeting information:

            Targets ::= SEQUENCE OF Target

            Target  ::= CHOICE {
              targetName          [0] GeneralName,
              targetGroup         [1] GeneralName,
              targetCert          [2] TargetCert
            }

            TargetCert  ::= SEQUENCE {
              targetCertificate    IssuerSerial,
              targetName           GeneralName OPTIONAL,
              certDigestInfo       ObjectDigestInfo OPTIONAL
            }

   The targetCert CHOICE within the Target structure is only present to
   allow future compatibility with [X.509-2000] and MUST NOT be used.

   The targets check passes if the current server (recipient) is one of
   the targetName fields in the Targets SEQUENCE, or if the current
   server is a member of one of the targetGroup fields in the Targets
   SEQUENCE.  In this case, the current server is said to "match" the
   targeting extension.

   How the membership of a target within a targetGroup is determined is
   not defined here.  It is assumed that any given target "knows" the
   names of the targetGroups to which it belongs or can otherwise
   determine its membership.  For example, the targetGroup specifies a
   DNS domain, and the AC verifier knows the DNS domain to which it
   belongs.  For another example, the targetGroup specifies "PRINTERS,"
   and the AC verifier knows whether or not it is a printer or print
   server.

   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
   Targets".  Conforming AC issuer implementations MUST only produce one
   "Targets" element.  Confirming AC users MUST be able to accept a
   "SEQUENCE OF Targets".  If more than one Targets element is found in
   an AC, the extension MUST be treated as if all Target elements had
   been found within one Targets element.

      name           id-ce-targetInformation
      OID            { id-ce 55 }
      syntax         SEQUENCE OF Targets
      criticality    MUST be TRUE



Farrell & Housley           Standards Track                    [Page 16]

RFC 3281           An Internet Attribute Certificate          April 2002


4.3.3   Authority Key Identifier

   The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY
   be used to assist the AC verifier in checking the signature of the
   AC.  The [PKIXPROF] description should be read as if "CA" meant "AC
   issuer."  As with PKCs, this extension SHOULD be included in ACs.

   Note: An AC, where the issuer field used the baseCertificateID
   CHOICE, would not need an authorityKeyIdentifier extension, as it is
   explicitly linked to the key in the referred certificate.  However,
   as this profile states (in section 4.2.3), ACs MUST use the v2Form
   with issuerName CHOICE, this duplication does not arise.

      name           id-ce-authorityKeyIdentifier
      OID            { id-ce 35 }
      syntax         AuthorityKeyIdentifier
      criticality    MUST be FALSE

4.3.4   Authority Information Access

   The authorityInformationAccess extension, as defined in [PKIXPROF],
   MAY be used to assist the AC verifier in checking the revocation
   status of the AC.  Support for the id-ad-caIssuers accessMethod is
   NOT REQUIRED by this profile since AC chains are not expected.

   The following accessMethod is used to indicate that revocation status
   checking is provided for this AC, using the OCSP protocol defined in
   [OCSP]:

      id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

   The accessLocation MUST contain a URI, and the URI MUST contain an
   HTTP URL [URL] that specifies the location of an OCSP responder.  The
   AC issuer MUST, of course, maintain an OCSP responder at this
   location.

      name           id-ce-authorityInfoAccess
      OID            { id-pe 1 }
      syntax         AuthorityInfoAccessSyntax
      criticality    MUST be FALSE

4.3.5   CRL Distribution Points

   The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY
   be used to assist the AC verifier in checking the revocation status
   of the AC.  See section 6 for details on revocation.





Farrell & Housley           Standards Track                    [Page 17]

RFC 3281           An Internet Attribute Certificate          April 2002


   If the crlDistributionPoints extension is present, then exactly one
   distribution point MUST be present.  The crlDistributionPoints
   extension MUST use the DistributionPointName option, which MUST
   contain a fullName, which MUST contain a single name form.  That name
   MUST contain either a distinguished name or a URI.  The URI MUST be
   either an HTTP URL or an LDAP URL [URL].

      name           id-ce-cRLDistributionPoints
      OID            { id-ce 31 }
      syntax         CRLDistPointsSyntax
      criticality    MUST be FALSE

4.3.6   No Revocation Available

   The noRevAvail extension, defined in [X.509-2000], allows an AC
   issuer to indicate that no revocation information will be made
   available for this AC.

   This extension MUST be non-critical.  An AC verifier that does not
   understand this extension might be able to find a revocation list
   from the AC issuer, but the revocation list will never include an
   entry for the AC.

      name           id-ce-noRevAvail
      OID            { id-ce 56 }
      syntax         NULL (i.e. '0500'H is the DER encoding)
      criticality    MUST be FALSE

4.4 Attribute Types

   Some of the attribute types defined below make use of the
   IetfAttrSyntax type, also defined below.  The reasons for using this
   type are:

   1. It allows a separation between the AC issuer and the attribute
      policy authority.  This is useful for situations where a single
      policy authority (e.g. an organization) allocates attribute
      values, but where multiple AC issuers are deployed for performance
      or other reasons.

   2. The syntaxes allowed for values are restricted to OCTET STRING,
      OBJECT IDENTIFIER, and UTF8String, which significantly reduces the
      complexity associated with matching more general syntaxes.  All
      multi-valued attributes using this syntax are restricted so that
      each value MUST use the same choice of value syntax.  For example,
      AC issuers must not use one value with an oid and a second value
      with a string.




Farrell & Housley           Standards Track                    [Page 18]

RFC 3281           An Internet Attribute Certificate          April 2002


               IetfAttrSyntax ::= SEQUENCE {
                    policyAuthority [0] GeneralNames    OPTIONAL,
                    values          SEQUENCE OF CHOICE {
                                  octets    OCTET STRING,
                                  oid       OBJECT IDENTIFIER,
                                  string    UTF8String
                   }
               }

   In the descriptions below, each attribute type is either tagged
   "Multiple Allowed" or "One Attribute value only; multiple values
   within the IetfAttrSyntax".  This refers to the SET OF
   AttributeValues; the AttributeType still only occurs once, as
   specified in section 4.2.7.

4.4.1   Service Authentication Information

   The SvceAuthInfo attribute identifies the AC holder to the
   server/service by a name, and the attribute MAY include optional
   service specific authentication information.  Typically this will
   contain a username/password pair for a "legacy" application.

   This attribute provides information that can be presented by the AC
   verifier to be interpreted and authenticated by a separate
   application within the target system.  Note that this is a different
   use to that intended for the accessIdentity attribute in 4.4.2 below.

   This attribute type will typically be encrypted when the authInfo
   field contains sensitive information, such as a password.

      name      id-aca-authenticationInfo
      OID       { id-aca 1 }
      Syntax    SvceAuthInfo
      values:   Multiple allowed

           SvceAuthInfo ::=    SEQUENCE {
                service   GeneralName,
                ident     GeneralName,
                authInfo  OCTET STRING OPTIONAL
           }

4.4.2   Access Identity

   The accessIdentity attribute identifies the AC holder to the
   server/service.  For this attribute the authInfo field MUST NOT be
   present.





Farrell & Housley           Standards Track                    [Page 19]

RFC 3281           An Internet Attribute Certificate          April 2002


   This attribute is intended to be used to provide information about
   the AC holder, that can be used by the AC verifier (or a larger
   system of which the AC verifier is a component) to authorize the
   actions of the AC holder within the AC verifier's system.  Note that
   this is a different use to that intended for the svceAuthInfo
   attribute described in 4.4.1 above.

      name      id-aca-accessIdentity
      OID       { id-aca 2 }
      syntax    SvceAuthInfo
      values:   Multiple allowed

4.4.3   Charging Identity

   The chargingIdentity attribute identifies the AC holder for charging
   purposes.  In general, the charging identity will be different from
   other identities of the holder.  For example, the holder's company
   may be charged for service.

      name      id-aca-chargingIdentity
      OID       { id-aca 3 }
      syntax    IetfAttrSyntax
      values:   One Attribute value only; multiple values within the
                IetfAttrSyntax

4.4.4   Group

   The group attribute carries information about group memberships of
   the AC holder.

      name      id-aca-group
      OID       { id-aca 4 }
      syntax    IetfAttrSyntax
      values:   One Attribute value only; multiple values within the
                IetfAttrSyntax

4.4.5   Role

   The role attribute, specified in [X.509-2000], carries information
   about role allocations of the AC holder.

   The syntax used for this attribute is:

         RoleSyntax ::= SEQUENCE {
                 roleAuthority   [0] GeneralNames OPTIONAL,
                 roleName        [1] GeneralName
         }




Farrell & Housley           Standards Track                    [Page 20]

RFC 3281           An Internet Attribute Certificate          April 2002


   The roleAuthority field MAY be used to specify the issuing authority
   for the role specification certificate.  There is no requirement that
   a role specification certificate necessarily exists for the
   roleAuthority.  This differs from [X.500-2000], where the
   roleAuthority field is assumed to name the issuer of a role
   specification certificate.  For example, to distinguish the
   administrator role as defined by "Baltimore" from that defined by
   "SPYRUS", one could put the value "urn:administrator" in the roleName
   field and the value "Baltimore" or "SPYRUS" in the roleAuthority
   field.

   The roleName field MUST be present, and roleName MUST use the
   uniformResourceIdentifier CHOICE of the GeneralName.

      name      id-at-role
      OID       { id-at 72 }
      syntax    RoleSyntax
      values:   Multiple allowed

4.4.6   Clearance

   The clearance attribute, specified in [X.501-1993], carries clearance
   (associated with security labeling) information about the AC holder.

   The policyId field is used to identify the security policy to which
   the clearance relates.  The policyId indicates the semantics of the
   classList and securityCategories fields.

   This specification includes the classList field exactly as it is
   specified in [X.501-1993].  Additional security classification
   values, and their position in the classification hierarchy, may be
   defined by a security policy as a local matter or by bilateral
   agreement.  The basic security classification hierarchy is, in
   ascending order: unmarked, unclassified, restricted, confidential,
   secret, and top-secret.

   An organization can develop its own security policy that defines
   security classification values and their meanings.  However, the BIT
   STRING positions 0 through 5 are reserved for the basic security
   classification hierarchy.

   If present, the SecurityCategory field provides further authorization
   information.  The security policy identified by the policyId field
   indicates the syntaxes that are allowed to be present in the
   securityCategories SET.  An OBJECT IDENTIFIER identifies each of the
   allowed syntaxes.  When one of these syntaxes is present in the
   securityCategories SET, the OBJECT IDENTIFIER associated with that
   syntax is carried in the SecurityCategory.type field.



Farrell & Housley           Standards Track                    [Page 21]

RFC 3281           An Internet Attribute Certificate          April 2002


            Clearance  ::=  SEQUENCE {
                 policyId  [0] OBJECT IDENTIFIER,
                 classList [1] ClassList DEFAULT {unclassified},
                 securityCategories
                           [2] SET OF SecurityCategory OPTIONAL
            }

            ClassList  ::=  BIT STRING {
                 unmarked       (0),
                 unclassified   (1),
                 restricted     (2)
                 confidential   (3),
                 secret         (4),
                 topSecret      (5)
            }

            SecurityCategory ::= SEQUENCE {
                 type      [0]  IMPLICIT OBJECT IDENTIFIER,
                 value     [1]  ANY DEFINED BY type
            }

            -- This is the same as the original syntax which was defined
            -- using the MACRO construct, as follows:
            -- SecurityCategory ::= SEQUENCE {
            --      type      [0]  IMPLICIT SECURITY-CATEGORY,
            --      value     [1]  ANY DEFINED BY type
            -- }
            --
            -- SECURITY-CATEGORY MACRO  ::=
            -- BEGIN
            -- TYPE NOTATION ::= type | empty
            -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
            -- END



       name      { id-at-clearance }
       OID       { joint-iso-ccitt(2) ds(5) module(1)
                   selected-attribute-types(5) clearance (55) }
       syntax    Clearance - imported from [X.501-1993]
       values    Multiple allowed

4.5 Profile of AC issuer's PKC

   The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
   extension in the PKC MUST NOT explicitly indicate that the AC
   issuer's public key cannot be used to validate a digital signature.
   In order to avoid confusion regarding serial numbers and revocations,



Farrell & Housley           Standards Track                    [Page 22]

RFC 3281           An Internet Attribute Certificate          April 2002


   an AC issuer MUST NOT also be a PKC Issuer.  That is, an AC issuer
   cannot be a CA as well.  So, the AC issuer's PKC MUST NOT have a
   basicConstraints extension with the cA BOOLEAN set to TRUE.

5. Attribute Certificate Validation

   This section describes a basic set of rules that all valid ACs MUST
   satisfy.  Some additional checks are also described which AC
   verifiers MAY choose to implement.

   To be valid an AC MUST satisfy all of the following:

   1. Where the holder uses a PKC to authenticate to the AC verifier,
      the AC holder's PKC MUST be found, and the entire certification
      path of that PKC MUST be verified in accordance with [PKIXPROF].
      As noted in the security considerations section, if some other
      authentication scheme is used, AC verifiers need to be very
      careful mapping the identities (authenticated identity, holder
      field) involved.

   2. The AC signature must be cryptographically correct, and the AC
      issuer's entire PKC certification path MUST be verified in
      accordance with [PKIXPROF].

   3. The AC issuer's PKC MUST also conform to the profile specified in
      section 4.5 above.

   4. The AC issuer MUST be directly trusted as an AC issuer (by
      configuration or otherwise).

   5. The time for which the AC is being evaluated MUST be within the AC
      validity.  If the evaluation time is equal to either notBeforeTime
      or notAfterTime, then the AC is timely and this check succeeds.
      Note that in some applications, the evaluation time MAY not be the
      same as the current time.

   6. The AC targeting check MUST pass as specified in section 4.3.2.

   7. If the AC contains an unsupported critical extension, the AC MUST
      be rejected.

   Support for an extension in this context means:

   1. The AC verifier MUST be able to parse the extension value.

   2. Where the extension value SHOULD cause the AC to be rejected, the
      AC verifier MUST reject the AC.




Farrell & Housley           Standards Track                    [Page 23]

RFC 3281           An Internet Attribute Certificate          April 2002


   Additional Checks:

   1. The AC MAY be rejected on the basis of further AC verifier
      configuration.  For example, an AC verifier may be configured to
      reject ACs which contain or lack certain attributes.

   2. If the AC verifier provides an interface that allows applications
      to query the contents of the AC, then the AC verifier MAY filter
      the attributes from the AC on the basis of configured information.
      For example, an AC verifier might be configured not to return
      certain attributes to certain servers.

6. Revocation

   In many environments, the validity period of an AC is less than the
   time required to issue and distribute revocation information.
   Therefore, short-lived ACs typically do not require revocation
   support.  However, long-lived ACs and environments where ACs enable
   high value transactions MAY require revocation support.

   Two revocation schemes are defined, and the AC issuer should elect
   the one that is best suited to the environment in which the AC will
   be employed.

   "Never revoke" scheme:

      ACs may be marked so that the relying party understands that no
      revocation status information will be made available.  The
      noRevAvail extension is defined in section 4.3.6, and the
      noRevAvail extension MUST be present in the AC to indicate use of
      this scheme.

      Where no noRevAvail is present, the AC issuer is implicitly
      stating that revocation status checks are supported, and some
      revocation method MUST be provided to allow AC verifiers to
      establish the revocation status of the AC.

   "Pointer in AC" scheme:

      ACs may "point" to sources of revocation status information, using
      either an authorityInfoAccess extension or a crlDistributionPoints
      extension within the AC.

   For AC users, the "never revoke" scheme MUST be supported, and the
   "pointer in AC" scheme SHOULD be supported.  If only the "never
   revoke" scheme is supported, then all ACs that do not contain a
   noRevAvail extension, MUST be rejected.




Farrell & Housley           Standards Track                    [Page 24]

RFC 3281           An Internet Attribute Certificate          April 2002


   For AC issuers, the "never revoke" scheme MUST be supported.  If all
   ACs that will ever be issued by that AC issuer, contains a noRevAvail
   extension, the "pointer in AC" scheme need not be supported.  If any
   AC can be issued that does not contain the noRevAvail extension, the
   "pointer in AC" scheme MUST be supported.

   An AC MUST NOT contain both a noRevAvail and a "pointer in AC".

   An AC verifier MAY use any source for AC revocation status
   information.

7. Optional Features

   This section specifies features that MAY be implemented.  Conformance
   to this profile does NOT require support for these features; however,
   if these features are offered, they MUST be offered as described
   below.

7.1 Attribute Encryption

   Where an AC will be carried in clear within an application protocol
   or where an AC contains some sensitive information like a legacy
   application username/password, then encryption of AC attributes MAY
   be needed.

   When a set of attributes are to be encrypted within an AC, the
   Cryptographic Message Syntax, EnvelopedData structure [CMS] is used
   to carry the ciphertext and associated per-recipient keying
   information.

   This type of attribute encryption is targeted.  Before the AC is
   signed, the attributes are encrypted for a set of predetermined
   recipients.

   The AC then contains the ciphertext inside its signed data.  The
   EnvelopedData (id-envelopedData) ContentType is used, and the content
   field will contain the EnvelopedData type.

   The ciphertext is included in the AC as the value of an encAttrs
   attribute.  Only one encAttrs attribute can be present in an AC;
   however, the encAttrs attribute MAY be multi-valued, and each of its
   values will contain an independent EnvelopedData.

   Each value can contain a set of attributes (each possibly a multi-
   valued attribute) encrypted for a set of predetermined recipients.






Farrell & Housley           Standards Track                    [Page 25]

RFC 3281           An Internet Attribute Certificate          April 2002


   The cleartext that is encrypted has the type:

      ACClearAttrs ::= SEQUENCE {
           acIssuer  GeneralName,
           acSerial  INTEGER,
           attrs     SEQUENCE OF Attribute
      }

   The DER encoding of the ACClearAttrs structure is used as the
   encryptedContent field of the EnvelopedData.  The DER encoding MUST
   be embedded in an OCTET STRING.

   The acIssuer and acSerial fields are present to prevent ciphertext
   stealing.  When an AC verifier has successfully decrypted an
   encrypted attribute, it MUST then check that the AC issuer and
   serialNumber fields contain the same values.  This prevents a
   malicious AC issuer from copying ciphertext from another AC (without
   knowing its corresponding plaintext).

   The procedure for an AC issuer when encrypting attributes is
   illustrated by the following (any other procedure that gives the same
   result MAY be used):

      1.   Identify the sets of attributes that are to be encrypted for
           each set of recipients.
      2.   For each attribute set which is to be encrypted:
         2.1. Create an EnvelopedData structure for the data for this
              set of recipients.
         2.2. Encode the ContentInfo containing the EnvelopedData as a
              value of the encAttrs attribute.
         2.3. Ensure the cleartext attributes are not present in the
              to-be-signed AC.
      3.   Add the encAttrs (with its multiple values) to the AC.

   Note that there may be more than one attribute of the same type (the
   same OBJECT IDENTIFIER) after decryption.  That is, an AC MAY contain
   the same attribute type both in clear and in encrypted form (and
   indeed several times if the same recipient is associated with more
   than one EnvelopedData).  One approach implementers may choose, would
   be to merge attribute values following decryption in order to re-
   establish the "once only" constraint.

      name      id-aca-encAttrs
      OID       { id-aca 6}
      Syntax    ContentInfo
      values    Multiple Allowed





Farrell & Housley           Standards Track                    [Page 26]

RFC 3281           An Internet Attribute Certificate          April 2002


   If an AC contains attributes, apparently encrypted for the AC
   verifier, the decryption process MUST not fail.  If decryption does
   fail, the AC MUST be rejected.

7.2 Proxying

   When a server acts as a client for another server on behalf of the AC
   holder, the server MAY need to proxy an AC.  Such proxying MAY have
   to be done under the AC issuer's control, so that not every AC is
   proxiable and so that a given proxiable AC can be proxied in a
   targeted fashion.  Support for chains of proxies (with more than one
   intermediate server) MAY also be required.  Note that this does not
   involve a chain of ACs.

   In order to meet this requirement we define another extension,
   ProxyInfo, similar to the targeting extension.

   When this extension is present, the AC verifier must check that the
   entity from which the AC was received was allowed to send it and that
   the AC is allowed to be used by this verifier.

   The proxying information consists of a set of proxy information, each
   of which is a set of targeting information.  If the verifier and the
   sender of the AC are both named in the same proxy set, the AC can
   then be accepted (the exact rule is given below).

   The effect is that the AC holder can send the AC to any valid target
   which can then only proxy to targets which are in one of the same
   proxy sets as itself.

   The following data structure is used to represent the
   targeting/proxying information.

         ProxyInfo ::= SEQUENCE OF Targets

   As in the case of targeting, the targetCert CHOICE MUST NOT be used.

   A proxy check succeeds if either one of the conditions below is met:

   1. The identity of the sender, as established by the underlying
      authentication service, matches the holder field of the AC, and
      the current server "matches" any one of the proxy sets.  Recall
      that "matches" is as defined section 4.3.2.








Farrell & Housley           Standards Track                    [Page 27]

RFC 3281           An Internet Attribute Certificate          April 2002


   2. The identity of the sender, as established by the underlying
      authentication service, "matches" one of the proxy sets (call it
      set "A"), and the current server is one of the targetName fields
      in the set "A", or the current server is a member of one of the
      targetGroup fields in set "A".

   When an AC is proxied more than once, a number of targets will be on
   the path from the original client, which is normally, but not always,
   the AC holder.  In such cases, prevention of AC "stealing" requires
   that the AC verifier MUST check that all targets on the path are
   members of the same proxy set.  It is the responsibility of the AC-
   using protocol to ensure that a trustworthy list of targets on the
   path is available to the AC verifier.

      name           id-pe-ac-proxying
      OID            { id-pe 10 }
      syntax         ProxyInfo
      criticality    MUST be TRUE

7.3 Use of ObjectDigestInfo

   In some environments, it may be required that the AC is not linked
   either to an identity (via entityName) or to a PKC (via
   baseCertificateID).  The objectDigestInfo CHOICE in the holder field
   allows support for this requirement.

   If the holder is identified with the objectDigestInfo field, then the
   AC version field MUST contain v2 (the integer 1).

   The idea is to link the AC to an object by placing a hash of that
   object into the holder field of the AC.  For example, this allows
   production of ACs that are linked to public keys rather than names.
   It also allows production of ACs which contain privileges associated
   with an executable object such as a Java class.  However, this
   profile only specifies how to use a hash over a public key or PKC.
   That is, conformant ACs MUST NOT use the otherObjectTypes value for
   the digestedObjectType.

   To link an AC to a public key, the hash must be calculated over the
   representation of that public key which would be present in a PKC,
   specifically, the input for the hash algorithm MUST be the DER
   encoding of a SubjectPublicKeyInfo representation of the key.  Note:
   This includes the AlgorithmIdentifier as well as the BIT STRING.  The
   rules given in [PKIXPROF] for encoding keys MUST be followed.  In
   this case, the digestedObjectType MUST be publicKey and the
   otherObjectTypeID field MUST NOT be present.





Farrell & Housley           Standards Track                    [Page 28]

RFC 3281           An Internet Attribute Certificate          April 2002


   Note that if the public key value used as input to the hash function
   has been extracted from a PKC, it is possible that the
   SubjectPublicKeyInfo from that PKC is NOT the value which should be
   hashed.  This can occur if DSA Dss-parms are inherited as described
   in section 7.3.3 of [PKIXPROF].  The correct input for hashing in
   this context will include the value of the parameters inherited from
   the CA's PKC, and thus may differ from the SubjectPublicKeyInfo
   present in the PKC.

   Implementations which support this feature MUST be able to handle the
   representations of public keys for the algorithms specified in
   section 7.3 of [PKIXPROF].  In this case, the digestedObjectType MUST
   be publicKey and the otherObjectTypeID field MUST NOT be present.

   In order to link an AC to a PKC via a digest, the digest MUST be
   calculated over the DER encoding of the entire PKC, including the
   signature value.  In this case the digestedObjectType MUST be
   publicKeyCert and the otherObjectTypeID field MUST NOT be present.

7.4 AA Controls

   During AC validation a relying party has to answer the question: is
   this AC issuer trusted to issue ACs containing this attribute?  The
   AAControls PKC extension MAY be used to help answer the question.
   The AAControls extension is intended to be used in CA and AC issuer
   PKCs.

         id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }

         AAControls ::= SEQUENCE {
            pathLenConstraint   INTEGER (0..MAX) OPTIONAL,
            permittedAttrs      [0] AttrSpec OPTIONAL,
            excludedAttrs       [1] AttrSpec OPTIONAL,
            permitUnSpecified   BOOLEAN DEFAULT TRUE
         }

         AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER

   The AAControls extension is used as follows:

   The pathLenConstraint, if present, is interpreted as in [PKIXPROF].
   It restricts the allowed distance between the AA CA (a CA directly
   trusted to include AAControls in its PKCs), and the AC issuer.

   The permittedAttrs field specifies a set of attribute types that any
   AC issuer below this AA CA is allowed to include in ACs.  If this
   field is not present, it means that no attribute types are explicitly
   allowed.



Farrell & Housley           Standards Track                    [Page 29]

RFC 3281           An Internet Attribute Certificate          April 2002


   The excludedAttrs field specifies a set of attribute types that no AC
   issuer is allowed to include in ACs.  If this field is not present,
   it means that no attribute types are explicitly disallowed.

   The permitUnSpecified field specifies how to handle attribute types
   which are not present in either the permittedAttrs or excludedAttrs
   fields.  TRUE (the default) means that any unspecified attribute type
   is allowed in ACs; FALSE means that no unspecified attribute type is
   allowed.

   When AAControls are used, the following additional checks on an AA's
   PKC chain MUST all succeed for the AC to be valid:

   1. Some CA on the ACs certificate path MUST be directly trusted to
      issue PKCs which precede the AC issuer in the certification path;
      call this CA the "AA CA".

   2. All PKCs on the path from the AA CA, down to and including the AC
      issuer's PKC, MUST contain an AAControls extension; however, the
      AA CA's PKC need not contain this extension.

   3. Only those attributes in the AC which are allowed, according to
      all of the AAControls extension values in all of the PKCs from the
      AA CA to the AC issuer, may be used for authorization decisions;
      all other attributes MUST be ignored.  This check MUST be applied
      to the set of attributes following attribute decryption, and the
      id-aca-encAttrs type MUST also be checked.

      name           id-pe-aaControls
      OID            { id-pe 6 }
      syntax         AAControls
      criticality    MAY be TRUE

8. Security Considerations

   The protection afforded for private keys is a critical factor in
   maintaining security.  Failure of AC issuers to protect their private
   keys will permit an attacker to masquerade as them, potentially
   generating false ACs or revocation status.  Existence of bogus ACs
   and revocation status will undermine confidence in the system.  If
   the compromise is detected, all ACs issued by the AC issuer MUST be
   revoked.  Rebuilding after such a compromise will be problematic, so
   AC issuers are advised to implement a combination of strong technical
   measures (e.g., tamper-resistant cryptographic modules) and
   appropriate management procedures (e.g., separation of duties) to
   avoid such an incident.





Farrell & Housley           Standards Track                    [Page 30]

RFC 3281           An Internet Attribute Certificate          April 2002


   Loss of an AC issuer's private signing key may also be problematic.
   The AC issuer would not be able to produce revocation status or
   perform AC renewal.  AC issuers are advised to maintain secure backup
   for signing keys.  The security of the key backup procedures is a
   critical factor in avoiding key compromise.

   The availability and freshness of revocation status will affect the
   degree of assurance that should be placed in a long-lived AC.  While
   long-lived ACs expire naturally, events may occur during its natural
   lifetime which negate the binding between the AC holder and the
   attributes.  If revocation status is untimely or unavailable, the
   assurance associated with the binding is clearly reduced.

   The binding between an AC holder and attributes cannot be stronger
   than the cryptographic module implementation and algorithms used to
   generate the signature.  Short key lengths or weak hash algorithms
   will limit the utility of an AC.  AC issuers are encouraged to note
   advances in cryptology so they can employ strong cryptographic
   techniques.

   Inconsistent application of name comparison rules may result in
   acceptance of invalid targeted or proxied ACs, or rejection of valid
   ones.  The X.500 series of specifications defines rules for comparing
   distinguished names.  These rules require comparison of strings
   without regard to case, character set, multi-character white space
   substrings, or leading and trailing white space.  This specification
   and [PKIXPROF] relaxes these requirements, requiring support for
   binary comparison at a minimum.

   AC issuers MUST encode the distinguished name in the AC
   holder.entityName field identically to the distinguished name in the
   holder's PKC.  If different encodings are used, implementations of
   this specification may fail to recognize that the AC and PKC belong
   to the same entity.

   If an attribute certificate is tied to the holder's PKC using the
   baseCertificateID component of the Holder field and the PKI in use
   includes a rogue CA with the same issuer name specified in the
   baseCertificateID component, this rogue CA could issue a PKC to a
   malicious party, using the same issuer name and serial number as the
   proper holder's PKC.  Then the malicious party could use this PKC in
   conjunction with the AC.  This scenario SHOULD be avoided by properly
   managing and configuring the PKI so that there cannot be two CAs with
   the same name.  Another alternative is to tie ACs to PKCs using the
   publicKeyCert type in the ObjectDigestInfo field.  Failing this, AC
   verifiers have to establish (using other means) that the potential
   collisions cannot actually occur, for example, the CPSs of the CAs
   involved may make it clear that no such name collisions can occur.



Farrell & Housley           Standards Track                    [Page 31]

RFC 3281           An Internet Attribute Certificate          April 2002


   Implementers MUST ensure that following validation of an AC, only
   attributes that the issuer is trusted to issue are used in
   authorization decisions.  Other attributes, which MAY be present MUST
   be ignored.  Given that the AA controls PKC extension is optional to
   implement, AC verifiers MUST be provided with this information by
   other means.  Configuration information is a likely alternative
   means.  This becomes very important if an AC verifier trusts more
   than one AC issuer.

   There is often a requirement to map between the authentication
   supplied by a particular security protocol (e.g. TLS, S/MIME) and the
   AC holder's identity.  If the authentication uses PKCs, then this
   mapping is straightforward.  However, it is envisaged that ACs will
   also be used in environments where the holder may be authenticated
   using other means.  Implementers SHOULD be very careful in mapping
   the authenticated identity to the AC holder.

9. IANA Considerations

   Attributes and attribute certificate extensions are identified by
   object identifiers (OIDs).  Many of the OIDs used in this document
   are copied from X.509 [X.509-2000].  Other OIDs were assigned from an
   arc delegated by the IANA.  No further action by the IANA is
   necessary for this document or any anticipated updates.

10. References

   [CMC]        Myers, M., Liu, X., Schaad, J. and J. Weinstein,
                "Certificate Management Messages over CMS", RFC 2797,
                April 2000.

   [CMP]        Adams, C. and S. Farrell, "Internet X.509 Public Key
                Infrastructure - Certificate Management Protocols", RFC
                2510, March 1999.

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

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

   [KRB]        Kohl, J. and C. Neuman, "The Kerberos Network
                Authentication Service (V5)", RFC 1510, September 1993.

   [LDAP]       Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
                Access Protocol (v3)", RFC 2251, December 1997.





Farrell & Housley           Standards Track                    [Page 32]

RFC 3281           An Internet Attribute Certificate          April 2002


   [OCSP]       Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
                Adams, "X.509 Internet Public Key Infrastructure -
                Online Certificate Status Protocol - OCSP", RFC 2560,
                June 1999.

   [PKIXALGS]   Bassham, L., Polk, W. and R. Housley, "Algorithms and
                Identifiers for the Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation
                Lists CRL Profile", RFC 3279, April 2002.

   [PKIXPROF]   Housley, R., Polk, T, Ford, W. and Solo, D., "Internet
                X.509 Public Key Infrastructure Certificate and
                Certificate Revocation List (CRL) Profile", RFC 3280,
                April 2002.

   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
                3", BCP 9, RFC 2026, October 1996.

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

   [URL]        Berners-Lee, T., Masinter L. and M. McCahill, "Uniform
                Resource Locators (URL)", RFC 1738, December 1994.

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

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

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

   [X.501-1993] ITU-T Recommendation X.501 : Information Technology -
                Open Systems Interconnection - The Directory: Models,
                1993.

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

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

   [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key
                and Attribute Certificate Frameworks.  2000





Farrell & Housley           Standards Track                    [Page 33]

RFC 3281           An Internet Attribute Certificate          April 2002


Appendix A: Object Identifiers

   This (normative) appendix lists the new object identifiers which are
   defined in this specification.  Some of these are required only for
   support of optional features and are not required for conformance to
   this profile.  This specification mandates support for OIDs which
   have arc elements with values that are less than 2^32, (i.e. they
   MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less
   than 2^31 (i.e. less than or equal to 2,147,483,647).  This allows
   each arc element to be represented within a single 32 bit word.
   Implementations MUST also support OIDs where the length of the dotted
   decimal (see [LDAP], section 4.1.2) string representation can be up
   to 100 bytes (inclusive).  Implementations MUST be able to handle
   OIDs with up to 20 elements (inclusive).  AA's SHOULD NOT issue ACs
   which contain OIDs that breach these requirements.

   The following OIDs are imported from [PKIXPROF]:

      id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
      id-mod  OBJECT IDENTIFIER ::= { id-pkix 0 }
      id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
      id-ad   OBJECT IDENTIFIER ::= { id-pkix 48 }
      id-at   OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
      id-ce   OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

   The following new ASN.1 module OID is defined:

      id-mod-attribute-cert        OBJECT IDENTIFIER ::= { id-mod 12 }

   The following AC extension OIDs are defined:

      id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }
      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }
      id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }

   The following PKC extension OIDs are defined:

      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }












Farrell & Housley           Standards Track                    [Page 34]

RFC 3281           An Internet Attribute Certificate          April 2002


   The following attribute OIDs are defined:

      id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }
      id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }
      id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }
      id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }
      id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }
      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }
      id-at-role                   OBJECT IDENTIFIER ::= { id-at 72 }
      id-at-clearance              OBJECT IDENTIFIER ::=
                  { joint-iso-ccitt(2) ds(5) module(1)
                    selected-attribute-types(5) clearance (55) }

Appendix B: ASN.1 Module

   PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                id-mod-attribute-cert(12)}

      DEFINITIONS IMPLICIT TAGS ::=

      BEGIN

      -- EXPORTS ALL --

      IMPORTS

            -- IMPORTed module OIDs MAY change if [PKIXPROF] changes
            -- PKIX Certificate Extensions
               Attribute, AlgorithmIdentifier, CertificateSerialNumber,
               Extensions, UniqueIdentifier,
               id-pkix, id-pe, id-kp, id-ad, id-at
               FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                        dod(6) internet(1) security(5) mechanisms(5)
                        pkix(7) id-mod(0) id-pkix1-explicit-88(1)}

               GeneralName, GeneralNames, id-ce
               FROM PKIX1Implicit88 {iso(1) identified-organization(3)
                        dod(6) internet(1) security(5) mechanisms(5)
                        pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;

      id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }
      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }
      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }
      id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }

      id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }




Farrell & Housley           Standards Track                    [Page 35]

RFC 3281           An Internet Attribute Certificate          April 2002


      id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }
      id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }
      id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }
      id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }
      -- { id-aca 5 } is reserved
      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }

      id-at-role                   OBJECT IDENTIFIER ::= { id-at 72}
      id-at-clearance              OBJECT IDENTIFIER ::=
                  { joint-iso-ccitt(2) ds(5) module(1)
                    selected-attribute-types(5) clearance (55) }

             -- Uncomment this if using a 1988 level ASN.1 compiler
             -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

             AttributeCertificate ::= SEQUENCE {
                   acinfo               AttributeCertificateInfo,
                   signatureAlgorithm   AlgorithmIdentifier,
                   signatureValue       BIT STRING
             }

             AttributeCertificateInfo ::= SEQUENCE {
                version        AttCertVersion  -- version is v2,
                holder         Holder,
                issuer         AttCertIssuer,
                signature      AlgorithmIdentifier,
                serialNumber   CertificateSerialNumber,
                attrCertValidityPeriod   AttCertValidityPeriod,
                attributes     SEQUENCE OF Attribute,
                issuerUniqueID UniqueIdentifier OPTIONAL,
                extensions     Extensions     OPTIONAL
             }

             AttCertVersion ::= INTEGER { v2(1) }

             Holder ::= SEQUENCE {
                   baseCertificateID   [0] IssuerSerial OPTIONAL,
                             -- the issuer and serial number of
                             -- the holder's Public Key Certificate
                   entityName          [1] GeneralNames OPTIONAL,
                             -- the name of the claimant or role
                   objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
                             -- used to directly authenticate the
                             -- holder, for example, an executable
             }






Farrell & Housley           Standards Track                    [Page 36]

RFC 3281           An Internet Attribute Certificate          April 2002


             ObjectDigestInfo    ::= SEQUENCE {
                   digestedObjectType  ENUMERATED {
                        publicKey            (0),
                        publicKeyCert        (1),
                        otherObjectTypes     (2) },
                                -- otherObjectTypes MUST NOT
                                -- MUST NOT be used in this profile
                   otherObjectTypeID   OBJECT IDENTIFIER  OPTIONAL,
                   digestAlgorithm     AlgorithmIdentifier,
                   objectDigest        BIT STRING
             }

             AttCertIssuer ::= CHOICE {
                   v1Form   GeneralNames,  -- MUST NOT be used in this
                                           -- profile
                   v2Form   [0] V2Form     -- v2 only
             }

             V2Form ::= SEQUENCE {
                   issuerName            GeneralNames  OPTIONAL,
                   baseCertificateID     [0] IssuerSerial  OPTIONAL,
                   objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
                      -- issuerName MUST be present in this profile
                      -- baseCertificateID and objectDigestInfo MUST
                      -- NOT be present in this profile
             }

             IssuerSerial  ::=  SEQUENCE {
                   issuer         GeneralNames,
                   serial         CertificateSerialNumber,
                   issuerUID      UniqueIdentifier OPTIONAL
             }

             AttCertValidityPeriod  ::= SEQUENCE {
                   notBeforeTime  GeneralizedTime,
                   notAfterTime   GeneralizedTime
             }

             Targets ::= SEQUENCE OF Target

             Target  ::= CHOICE {
                   targetName     [0] GeneralName,
                   targetGroup    [1] GeneralName,
                   targetCert     [2] TargetCert
             }






Farrell & Housley           Standards Track                    [Page 37]

RFC 3281           An Internet Attribute Certificate          April 2002


             TargetCert  ::= SEQUENCE {
                   targetCertificate  IssuerSerial,
                   targetName         GeneralName OPTIONAL,
                   certDigestInfo     ObjectDigestInfo OPTIONAL
             }

             IetfAttrSyntax ::= SEQUENCE {
                  policyAuthority[0] GeneralNames    OPTIONAL,
                  values         SEQUENCE OF CHOICE {
                                 octets    OCTET STRING,
                                 oid       OBJECT IDENTIFIER,
                                 string    UTF8String
                 }
             }

             SvceAuthInfo ::=    SEQUENCE {
                   service       GeneralName,
                   ident         GeneralName,
                   authInfo      OCTET STRING OPTIONAL
             }

             RoleSyntax ::= SEQUENCE {
                   roleAuthority  [0] GeneralNames OPTIONAL,
                   roleName       [1] GeneralName
             }

             Clearance  ::=  SEQUENCE {
                   policyId       [0] OBJECT IDENTIFIER,
                   classList      [1] ClassList DEFAULT {unclassified},
                   securityCategories
                                  [2] SET OF SecurityCategory  OPTIONAL
             }

             ClassList  ::=  BIT STRING {
                   unmarked       (0),
                   unclassified   (1),
                   restricted     (2),
                   confidential   (3),
                   secret         (4),
                   topSecret      (5)
             }

             SecurityCategory ::= SEQUENCE {
                   type      [0]  IMPLICIT OBJECT IDENTIFIER,
                   value     [1]  ANY DEFINED BY type
             }





Farrell & Housley           Standards Track                    [Page 38]

RFC 3281           An Internet Attribute Certificate          April 2002


             AAControls ::= SEQUENCE {
                   pathLenConstraint INTEGER (0..MAX) OPTIONAL,
                   permittedAttrs    [0] AttrSpec OPTIONAL,
                   excludedAttrs     [1] AttrSpec OPTIONAL,
                   permitUnSpecified BOOLEAN DEFAULT TRUE
             }

             AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER

             ACClearAttrs ::= SEQUENCE {
                   acIssuer          GeneralName,
                   acSerial          INTEGER,
                   attrs             SEQUENCE OF Attribute
             }

             ProxyInfo ::= SEQUENCE OF Targets

      END

Author's Addresses

   Stephen Farrell
   Baltimore Technologies
   39/41 Parkgate Street
   Dublin 8
   IRELAND

   EMail: stephen.farrell@baltimore.ie

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: rhousley@rsasecurity.com

Acknowledgements

   Russ Housley thanks the management at SPYRUS, who supported the
   development of this specification while he was employed at SPYRUS.
   Russ Housley also thanks the management at RSA Laboratories, who
   supported the completion of the specification after a job change.








Farrell & Housley           Standards Track                    [Page 39]

RFC 3281           An Internet Attribute Certificate          April 2002


Full Copyright Statement

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

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

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

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

Acknowledgement

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



















Farrell & Housley           Standards Track                    [Page 40]