File: rfc2704.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 (2075 lines) | stat: -rw-r--r-- 79,998 bytes parent folder | download | duplicates (8)
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






Network Working Group                                           M. Blaze
Request for Comments: 2704                                 J. Feigenbaum
Category: Informational                                     J. Ioannidis
                                                    AT&T Labs - Research
                                                            A. Keromytis
                                                      U. of Pennsylvania
                                                          September 1999


             The KeyNote Trust-Management System Version 2

Status of this Memo

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

Copyright Notice

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

Abstract

   This memo describes version 2 of the KeyNote trust-management system.
   It specifies the syntax and semantics of KeyNote `assertions',
   describes `action attribute' processing, and outlines the application
   architecture into which a KeyNote implementation can be fit.  The
   KeyNote architecture and language are useful as building blocks for
   the trust management aspects of a variety of Internet protocols and
   services.

1.  Introduction

   Trust management, introduced in the PolicyMaker system [BFL96], is a
   unified approach to specifying and interpreting security policies,
   credentials, and relationships; it allows direct authorization of
   security-critical actions.  A trust-management system provides
   standard, general-purpose mechanisms for specifying application
   security policies and credentials.  Trust-management credentials
   describe a specific delegation of trust and subsume the role of
   public key certificates; unlike traditional certificates, which bind
   keys to names, credentials can bind keys directly to the
   authorization to perform specific tasks.








Blaze, et al.                Informational                      [Page 1]

RFC 2704          The KeyNote Trust-Management System     September 1999


   A trust-management system has five basic components:

   *  A language for describing `actions', which are operations with
      security consequences that are to be controlled by the system.

   *  A mechanism for identifying `principals', which are entities that
      can be authorized to perform actions.

   *  A language for specifying application `policies', which govern the
      actions that principals are authorized to perform.

   *  A language for specifying `credentials', which allow principals to
      delegate authorization to other principals.

   *  A `compliance checker', which provides a service to applications
      for determining how an action requested by principals should be
      handled, given a policy and a set of credentials.

   The trust-management approach has a number of advantages over other
   mechanisms for specifying and controlling authorization, especially
   when security policy is distributed over a network or is otherwise
   decentralized.

   Trust management unifies the notions of security policy, credentials,
   access control, and authorization.  An application that uses a
   trust-management system can simply ask the compliance checker whether
   a requested action should be allowed.  Furthermore, policies and
   credentials are written in standard languages that are shared by all
   trust-managed applications; the security configuration mechanism for
   one application carries exactly the same syntactic and semantic
   structure as that of another, even when the semantics of the
   applications themselves are quite different.

   Trust-management policies are easy to distribute across networks,
   helping to avoid the need for application-specific distributed policy
   configuration mechanisms, access control lists, and certificate
   parsers and interpreters.

   For a general discussion of the use of trust management in
   distributed system security, see [Bla99].

   KeyNote is a simple and flexible trust-management system designed to
   work well for a variety of large- and small-scale Internet-based
   applications.  It provides a single, unified language for both local
   policies and credentials.  KeyNote policies and credentials, called
   `assertions', contain predicates that describe the trusted actions
   permitted by the holders of specific public keys.  KeyNote assertions
   are essentially small, highly-structured programs.  A signed



Blaze, et al.                Informational                      [Page 2]

RFC 2704          The KeyNote Trust-Management System     September 1999


   assertion, which can be sent over an untrusted network, is also
   called a `credential assertion'.  Credential assertions, which also
   serve the role of certificates, have the same syntax as policy
   assertions but are also signed by the principal delegating the trust.

   In KeyNote:

   *  Actions are specified as a collection of name-value pairs.

   *  Principal names can be any convenient string and can directly
      represent cryptographic public keys.

   *  The same language is used for both policies and credentials.

   *  The policy and credential language is concise, highly expressive,
      human readable and writable, and compatible with a variety of
      storage and transmission media, including electronic mail.

   *  The compliance checker returns an application-configured `policy
      compliance value' that describes how a request should be handled
      by the application.  Policy compliance values are always
      positively derived from policy and credentials, facilitating
      analysis of KeyNote-based systems.

   *  Compliance checking is efficient enough for high-performance and
      real-time applications.

   This document describes the KeyNote policy and credential assertion
   language, the structure of KeyNote action descriptions, and the
   KeyNote model of computation.

   We assume that applications communicate with a locally trusted
   KeyNote compliance checker via a `function call' style interface,
   sending a collection of KeyNote policy and credential assertions plus
   an action description as input and accepting the resulting policy
   compliance value as output.  However, the requirements of different
   applications, hosts, and environments may give rise to a variety of
   different interfaces to KeyNote compliance checkers; this document
   does not aim to specify a complete compliance checker API.

2.  KeyNote Concepts

   In KeyNote, the authority to perform trusted actions is associated
   with one or more `principals'.  A principal may be a physical entity,
   a process in an operating system, a public key, or any other
   convenient abstraction.  KeyNote principals are identified by a
   string called a `Principal Identifier'.  In some cases, a Principal
   Identifier will contain a cryptographic key interpreted by the



Blaze, et al.                Informational                      [Page 3]

RFC 2704          The KeyNote Trust-Management System     September 1999


   KeyNote system (e.g., for credential signature verification).  In
   other cases, Principal Identifiers may have a structure that is
   opaque to KeyNote.

   Principals perform two functions of concern to KeyNote: They request
   `actions' and they issue `assertions'.  Actions are any trusted
   operations that an application places under KeyNote control.
   Assertions delegate the authorization to perform actions to other
   principals.

   Actions are described to the KeyNote compliance checker in terms of a
   collection of name-value pairs called an `action attribute set'.  The
   action attribute set is created by the invoking application.  Its
   structure and format are described in detail in Section 3 of this
   document.

   KeyNote provides advice to applications about the interpretation of
   policy with regard to specific requested actions.  Applications
   invoke the KeyNote compliance checker by issuing a `query' containing
   a proposed action attribute set and identifying the principal(s)
   requesting it.  The KeyNote system determines and returns an
   appropriate `policy compliance value' from an ordered set of possible
   responses.

   The policy compliance value returned from a KeyNote query advises the
   application how to process the requested action.  In the simplest
   case, the compliance value is Boolean (e.g., "reject" or "approve").
   Assertions can also be written to select from a range of possible
   compliance values, when appropriate for the application (e.g., "no
   access", "restricted access", "full access").  Applications can
   configure the relative ordering (from `weakest' to `strongest') of
   compliance values at query time.

   Assertions are the basic programming unit for specifying policy and
   delegating authority.  Assertions describe the conditions under which
   a principal authorizes actions requested by other principals.  An
   assertion identifies the principal that made it, which other
   principals are being authorized, and the conditions under which the
   authorization applies.  The syntax of assertions is given in Section
   4.

   A special principal, whose identifier is "POLICY", provides the root
   of trust in KeyNote.  "POLICY" is therefore considered to be
   authorized to perform any action.







Blaze, et al.                Informational                      [Page 4]

RFC 2704          The KeyNote Trust-Management System     September 1999


   Assertions issued by the "POLICY" principal are called `policy
   assertions' and are used to delegate authority to otherwise untrusted
   principals.  The KeyNote security policy of an application consists
   of a collection of policy assertions.

   When a principal is identified by a public key, it can digitally sign
   assertions and distribute them over untrusted networks for use by
   other KeyNote compliance checkers.  These signed assertions are also
   called `credentials', and serve a role similar to that of traditional
   public key certificates.  Policies and credentials share the same
   syntax and are evaluated according to the same semantics.  A
   principal can therefore convert its policy assertions into
   credentials simply by digitally signing them.

   KeyNote is designed to encourage the creation of human-readable
   policies and credentials that are amenable to transmission and
   storage over a variety of media.  Its assertion syntax is inspired by
   the format of RFC822-style message headers [Cro82].  A KeyNote
   assertion contains a sequence of sections, called `fields', each of
   which specifies one aspect of the assertion's semantics.  Fields
   start with an identifier at the beginning of a line and continue
   until the next field is encountered.  For example:

      KeyNote-Version: 2
      Comment: A simple, if contrived, email certificate for user mab
      Local-Constants:  ATT_CA_key = "RSA:acdfa1df1011bbac"
                        mab_key = "DSA:deadbeefcafe001a"
      Authorizer: ATT_CA_key
      Licensees: mab_key
      Conditions: ((app_domain == "email")  # valid for email only
                && (address == "mab@research.att.com"));
      Signature: "RSA-SHA1:f00f2244"

   The meanings of the various sections are described in Sections 4 and
   5 of this document.

   KeyNote semantics resolve the relationship between an application's
   policy and actions requested by other principals, as supported by
   credentials.  The KeyNote compliance checker processes the assertions
   against the action attribute set to determine the policy compliance
   value of a requested action.  These semantics are defined in Section
   5.

   An important principle in KeyNote's design is `assertion
   monotonicity'; the policy compliance value of an action is always
   positively derived from assertions made by trusted principals.
   Removing an assertion never results in increasing the compliance
   value returned by KeyNote for a given query.  The monotonicity



Blaze, et al.                Informational                      [Page 5]

RFC 2704          The KeyNote Trust-Management System     September 1999


   property can simplify the design and analysis of complex network-
   based security protocols; network failures that prevent the
   transmission of credentials can never result in spurious
   authorization of dangerous actions.  A detailed discussion of
   monotonicity and safety in trust management can be found in [BFL96]
   and [BFS98].

3.  Action Attributes

   Trusted actions to be evaluated by KeyNote are described by a
   collection of name-value pairs called the `action attribute set'.
   Action attributes are the mechanism by which applications communicate
   requests to KeyNote and are the primary objects on which KeyNote
   assertions operate.  An action attribute set is passed to the KeyNote
   compliance checker with each query.

   Each action attribute consists of a name and a value.  The semantics
   of the names and values are not interpreted by KeyNote itself; they
   vary from application to application and must be agreed upon by the
   writers of applications and the writers of the policies and
   credentials that will be used by them.

   Action attribute names and values are represented by arbitrary-length
   strings.  KeyNote guarantees support of attribute names and values up
   to 2048 characters long.  The handling of longer attribute names or
   values is not specified and is KeyNote-implementation-dependent.
   Applications and assertions should therefore avoid depending on the
   the use of attributes with names or values longer than 2048
   characters.  The length of an attribute value is represented by an
   implementation-specific mechanism (e.g., NUL-terminated strings, an
   explicit length field, etc.).

   Attribute values are inherently untyped and are represented as
   character strings by default.  Attribute values may contain any non-
   NUL ASCII character.  Numeric attribute values should first be
   converted to an ASCII text representation by the invoking
   application, e.g., the value 1234.5 would be represented by the
   string "1234.5".

   Attribute names are of the form:

       <AttributeID>:: {Any string starting with a-z, A-Z, or the
                        underscore character, followed by any number of
                        a-z, A-Z, 0-9, or underscore characters} ;

   That is, an <AttributeID> begins with an alphabetic or underscore
   character and can be followed by any number of alphanumerics and
   underscores.  Attribute names are case-sensitive.



Blaze, et al.                Informational                      [Page 6]

RFC 2704          The KeyNote Trust-Management System     September 1999


   The exact mechanism for passing the action attribute set to the
   compliance checker is determined by the KeyNote implementation.
   Depending on specific requirements, an implementation may provide a
   mechanism for including the entire attribute set as an explicit
   parameter of the query, or it may provide some form of callback
   mechanism invoked as each attribute is dereferenced, e.g., for access
   to kernel variables.

   If an action attribute is not defined its value is considered to be
   the empty string.

   Attribute names beginning with the "_" character are reserved for use
   by the KeyNote runtime environment and cannot be passed from
   applications as part of queries.  The following special attribute
   names are used:

       Name                        Purpose
       ------------------------    ------------------------------------
       _MIN_TRUST                  Lowest-order (minimum) compliance
                                   value in query; see Section 5.1.

       _MAX_TRUST                  Highest-order (maximum) compliance
                                   value in query; see Section 5.1.

       _VALUES                     Linearly ordered set of compliance
                                   values in query; see Section 5.1.
                                   Comma separated.

       _ACTION_AUTHORIZERS         Names of principals directly
                                   authorizing action in query.
                                   Comma separated.

   In addition, attributes with names of the form "_<N>", where <N> is
   an ASCII-encoded integer, are used by the regular expression matching
   mechanism described in Section 5.

   The assignment and semantics of any other attribute names beginning
   with "_" is unspecified and implementation-dependent.

   The names of other attributes in the action attribute set are not
   specified by KeyNote but must be agreed upon by the writers of any
   policies and credentials that are to inter-operate in a specific
   KeyNote query evaluation.








Blaze, et al.                Informational                      [Page 7]

RFC 2704          The KeyNote Trust-Management System     September 1999


   By convention, the name of the application domain over which action
   attributes should be interpreted is given in the attribute named
   "app_domain".  The IANA (or some other suitable authority) will
   provide a registry of reserved app_domain names.  The registry will
   list the names and meanings of each application's attributes.

   The app_domain convention helps to ensure that credentials are
   interpreted as they were intended.  An attribute with any given name
   may be used in many different application domains but might have
   different meanings in each of them.  However, the use of a global
   registry is not always required for small-scale, closed applications;
   the only requirement is that the policies and credentials made
   available to the KeyNote compliance checker interpret attributes
   according to the same semantics assumed by the application that
   created them.

   For example, an email application might reserve the app_domain
   "RFC822-EMAIL" and might use the attributes named "address" (the
   email address of a message's sender), "name" (the human name of the
   message sender), and any "organization" headers present (the
   organization name).  The values of these attributes would be derived
   in the obvious way from the email message headers.  The public key of
   the message's signer would be given in the "_ACTION_AUTHORIZERS"
   attribute.

   Note that "RFC822-EMAIL" is a hypothetical example; such a name may
   or may not appear in the actual registry with these or different
   attributes.  (Indeed, we recognize that the reality of email security
   is considerably more complex than this example might suggest.)

4.  KeyNote Assertion Syntax

   In the following sections, the notation [X]* means zero or more
   repetitions of character string X.  The notation [X]+ means one or
   more repetitions of X.  The notation <X>* means zero or more
   repetitions of non-terminal <X>.  The notation <X>+ means one or more
   repetitions of X, whereas <X>? means zero or one repetitions of X.
   Nonterminal grammar symbols are enclosed in angle brackets.  Quoted
   strings in grammar productions represent terminals.

4.1  Basic Structure

       <Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
                     <LocalConstantsField>? <ConditionsField>?
                     <CommentField>? <SignatureField>? ;

   All KeyNote assertions are encoded in ASCII.




Blaze, et al.                Informational                      [Page 8]

RFC 2704          The KeyNote Trust-Management System     September 1999


   KeyNote assertions are divided into sections, called `fields', that
   serve various semantic functions.  Each field starts with an
   identifying label at the beginning of a line, followed by the ":"
   character and the field's contents.  There can be at most one field
   per line.

   A field may be continued over more than one line by indenting
   subsequent lines with at least one ASCII SPACE or TAB character.
   Whitespace (a SPACE, TAB, or NEWLINE character) separates tokens but
   is otherwise ignored outside of quoted strings.  Comments with a
   leading octothorp character (see Section 4.2) may begin in any
   column.

   One mandatory field is required in all assertions:

      Authorizer

   Six optional fields may also appear:

      Comment
      Conditions
      KeyNote-Version
      Licensees
      Local-Constants
      Signature

   All field names are case-insensitive.  The "KeyNote-Version" field,
   if present, appears first.  The "Signature" field, if present,
   appears last.  Otherwise, fields may appear in any order.  Each field
   may appear at most once in any assertion.

   Blank lines are not permitted in assertions.  Multiple assertions
   stored in a file (e.g., in application policy configurations),
   therefore, can be separated from one another unambiguously by the use
   of blank lines between them.

4.2  Comments

      <Comment>:: "#" {ASCII characters} ;

   The octothorp character ("#", ASCII 35 decimal) can be used to
   introduce comments.  Outside of quoted strings (see Section 4.3), all
   characters from the "#" character through the end of the current line
   are ignored.  However, commented text is included in the computation
   of assertion signatures (see Section 4.6.7).






Blaze, et al.                Informational                      [Page 9]

RFC 2704          The KeyNote Trust-Management System     September 1999


4.3  Strings

   A `string' is a lexical object containing a sequence of characters.
   Strings may contain any non-NUL characters, including newlines and
   nonprintable characters.  Strings may be given as literals, computed
   from complex expressions, or dereferenced from attribute names.

4.3.1  String Literals

      <StringLiteral>:: "\"" {see description below} "\"" ;

   A string literal directly represents the value of a string.  String
   literals must be quoted by preceding and following them with the
   double-quote character (ASCII 34 decimal).

   A printable character may be `escaped' inside a quoted string literal
   by preceding it with the backslash character (ASCII 92 decimal)
   (e.g., "like \"this\".").  This permits the inclusion of the double-
   quote and backslash characters inside string literals.

   A similar escape mechanism is also used to represent non-printable
   characters.  "\n" represents the newline character (ASCII character
   10 decimal), "\r" represents the carriage-return character (ASCII
   character 13 decimal), "\t" represents the tab character (ASCII
   character 9 decimal), and "\f" represents the form-feed character
   (ASCII character 12 decimal).  A backslash character followed by a
   newline suppresses all subsequent whitespace (including the newline)
   up to the next non-whitespace character (this allows the continuation
   of long string constants across lines).  Un-escaped newline and
   return characters are illegal inside string literals.

   The constructs "\0o", "\0oo", and "\ooo" (where o represents any
   octal digit) may be used to represent any non-NUL ASCII characters
   with their corresponding octal values (thus, "\012" is the same as
   "\n", "\101" is "A", and "\377" is the ASCII character 255 decimal).
   However, the NUL character cannot be encoded in this manner; "\0",
   "\00", and "\000" are converted to the strings "0", "00", and "000"
   respectively.  Similarly, all other escaped characters have the
   leading backslash removed (e.g., "\a" becomes "a", and "\\" becomes
   "\").  The following four strings are equivalent:

        "this string contains a newline\n followed by one space."
        "this string contains a newline\n \
        followed by one space."







Blaze, et al.                Informational                     [Page 10]

RFC 2704          The KeyNote Trust-Management System     September 1999


        "this str\
           ing contains a \
             newline\n followed by one space."

        "this string contains a newline\012\040followed by one space."

4.3.2  String Expressions

   In general, anywhere a quoted string literal is allowed, a `string
   expression' can be used.  A string expression constructs a string
   from string constants, dereferenced attributes (described in Section
   4.4), and a string concatenation operator.  String expressions may be
   parenthesized.

       <StrEx>:: <StrEx> "." <StrEx>    /* String concatenation */
               | <StringLiteral>        /* Quoted string */
               | "(" <StrEx> ")"
               | <DerefAttribute>       /* See Section 4.4 */
               | "$" <StrEx> ;          /* See Section 4.4 */

   The "$" operator has higher precedence than the "." operator.

4.4  Dereferenced Attributes

   Action attributes provide the primary mechanism for applications to
   pass information to assertions.  Attribute names are strings from a
   limited character set (<AttributeID> as defined in Section 3), and
   attribute values are represented internally as strings.  An attribute
   is dereferenced simply by using its name.  In general, KeyNote allows
   the use of an attribute anywhere a string literal is permitted.

   Attributes are dereferenced as strings by default.  When required,
   dereferenced attributes can be converted to integers or floating
   point numbers with the type conversion operators "@" and "&".  Thus,
   an attribute named "foo" having the value "1.2" may be interpreted as
   the string "1.2" (foo), the integer value 1 (@foo), or the floating
   point value 1.2 (&foo).

   Attributes converted to integer and floating point numbers are
   represented according to the ANSI C `long' and `float' types,
   respectively.  In particular, integers range from -2147483648 to
   2147483647, whilst floats range from 1.17549435E-38F to
   3.40282347E+38F.

   Any uninitialized attribute has the empty-string value when
   dereferenced as a string and the value zero when dereferenced as an
   integer or float.




Blaze, et al.                Informational                     [Page 11]

RFC 2704          The KeyNote Trust-Management System     September 1999


   Attribute names may be given literally or calculated from string
   expressions and may be recursively dereferenced.  In the simplest
   case, an attribute is dereferenced simply by using its name outside
   of quotes; e.g., the string value of the attribute named "foo" is by
   reference to `foo' (outside of quotes).  The "$<StrEx>" construct
   dereferences the attribute named in the string expression <StrEx>.
   For example, if the attribute named "foo" contains the string "bar",
   the attribute named "bar" contains the string "xyz", and the
   attribute "xyz" contains the string "qua", the following string
   comparisons are all true:

    foo == "bar"
    $("foo") == "bar"
    $foo == "xyz"
    $(foo) == "xyz"
    $$foo == "qua"

   If <StrEx> evaluates to an invalid or uninitialized attribute name,
   its value is considered to be the empty string (or zero if used as a
   numeric).

   The <DerefAttribute> token is defined as:

      <DerefAttribute>:: <AttributeID> ;

4.5  Principal Identifiers

   Principals are represented as ASCII strings called `Principal
   Identifiers'.  Principal Identifiers may be arbitrary labels whose
   structure is not interpreted by the KeyNote system or they may encode
   cryptographic keys that are used by KeyNote for credential signature
   verification.

       <PrincipalIdentifier>:: <OpaqueID>
                             | <KeyID> ;

   4.5.1  Opaque Principal Identifiers

   Principal Identifiers that are used by KeyNote only as labels are
   said to be `opaque'.  Opaque identifiers are encoded in assertions as
   strings (see Section 4.3):

       <OpaqueID>:: <StrEx> ;

   Opaque identifier strings should not contain the ":" character.






Blaze, et al.                Informational                     [Page 12]

RFC 2704          The KeyNote Trust-Management System     September 1999


4.5.2  Cryptographic Principal Identifiers

   Principal Identifiers that are used by KeyNote as keys, e.g., to
   verify credential signatures, are said to be `cryptographic'.
   Cryptographic identifiers are also lexically encoded as strings:

       <KeyID>:: <StrEx> ;

   Unlike Opaque Identifiers, however, Cryptographic Identifier strings
   have a special form.  To be interpreted by KeyNote (for signature
   verification), an identifier string should be of the form:

      <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;

   "ALGORITHM" is an ASCII substring that describes the algorithms to be
   used in interpreting the key's bits.  The ALGORITHM identifies the
   major cryptographic algorithm (e.g., RSA [RSA78], DSA [DSA94], etc.),
   structured format (e.g., PKCS1 [PKCS1]), and key bit encoding (e.g.,
   HEX or BASE64).  By convention, the ALGORITHM substring starts with
   an alphabetic character and can contain letters, digits, underscores,
   or dashes (i.e., it should match the regular expression "[a-zA-Z][a-
   zA-Z0-9_-]*").  The IANA (or some other appropriate authority) will
   provide a registry of reserved algorithm identifiers.

   "ENCODEDBITS" is a substring of characters representing the key's
   bits, the encoding and format of which depends on the ALGORITHM.  By
   convention, hexadecimal encoded keys use lower-case ASCII characters.

   Cryptographic Principal Identifiers are converted to a normalized
   canonical form for the purposes of any internal comparisons between
   them; see Section 5.2.

   Note that the keys used in examples throughout this document are
   fictitious and generally much shorter than would be required for
   security in practice.

4.6  KeyNote Fields

4.6.1  The KeyNote-Version Field

   The KeyNote-Version field identifies the version of the KeyNote
   assertion language under which the assertion was written.  The
   KeyNote-Version field is of the form

       <VersionField>:: "KeyNote-Version:" <VersionString> ;
       <VersionString>:: <StringLiteral>
                       | <IntegerLiteral> ;




Blaze, et al.                Informational                     [Page 13]

RFC 2704          The KeyNote Trust-Management System     September 1999


   where <VersionString> is an ASCII-encoded string.  Assertions in
   production versions of KeyNote use decimal digits in the version
   representing the version number of the KeyNote language under which
   they are to be interpreted.  Assertions written to conform with this
   document should be identified with the version string "2" (or the
   integer 2).  The KeyNote-Version field, if included, should appear
   first.

4.6.2  The Local-Constants Field

   This field adds or overrides action attributes in the current
   assertion only.  This mechanism allows the use of short names for
   (frequently lengthy) cryptographic principal identifiers, especially
   to make the Licensees field more readable.  The Local-Constants field
   is of the form:

       <LocalConstantsField>:: "Local-Constants:" <Assignments> ;
       <Assignments>:: /* can be empty */
                     | <AttributeID> "=" <StringLiteral> <Assignments> ;

   <AttributeID> is an attribute name from the action attribute
   namespace as defined in Section 3.  The name is available for use as
   an attribute in any subsequent field.  If the Local-Constants field
   defines more than one identifier, it can occupy more than one line
   and be indented.  <StringLiteral> is a string literal as described in
   Section 4.3.  Attributes defined in the Local-Constants field
   override any attributes with the same name passed in with the action
   attribute set.

   An attribute may be initialized at most once in the Local-Constants
   field.  If an attribute is initialized more than once in an
   assertion, the entire assertion is considered invalid and is not
   considered by the KeyNote compliance checker in evaluating queries.

4.6.3  The Authorizer Field

   The Authorizer identifies the Principal issuing the assertion.  This
   field is of the form

       <AuthField>:: "Authorizer:" <AuthID> ;
       <AuthID>:: <PrincipalIdentifier>
                | <DerefAttribute> ;

   The Principal Identifier may be given directly or by reference to the
   attribute namespace (as defined in Section 4.4).






Blaze, et al.                Informational                     [Page 14]

RFC 2704          The KeyNote Trust-Management System     September 1999


4.6.4   The Licensees Field

   The Licensees field identifies the principals authorized by the
   assertion.  More than one principal can be authorized, and
   authorization can be distributed across several principals through
   the use of `and' and threshold constructs.  This field is of the form

       <LicenseesField>:: "Licensees:" <LicenseesExpr> ;

       <LicenseesExpr>::      /* can be empty */
                         | <PrincExpr> ;

       <PrincExpr>:: "(" <PrincExpr> ")"
                     | <PrincExpr> "&&" <PrincExpr>
                     | <PrincExpr> "||" <PrincExpr>
                     | <K>"-of(" <PrincList> ")"        /* Threshold */
                     | <PrincipalIdentifier>
                     | <DerefAttribute> ;

       <PrincList>:: <PrincipalIdentifier>
                   | <DerefAttribute>
                   | <PrincList> "," <PrincList> ;

       <K>:: {Decimal number starting with a digit from 1 to 9} ;

   The "&&" operator has higher precedence than the "||" operator.  <K>
   is an ASCII-encoded positive decimal integer.  If a <PrincList>
   contains fewer than <K> principals, the entire assertion is omitted
   from processing.

4.6.5  The Conditions Field

   This field gives the `conditions' under which the Authorizer trusts
   the Licensees to perform an action.  `Conditions' are predicates that
   operate on the action attribute set.  The Conditions field is of the
   form:

    <ConditionsField>:: "Conditions:" <ConditionsProgram> ;

    <ConditionsProgram>:: /* Can be empty */
                          | <Clause> ";" <ConditionsProgram> ;

    <Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
             | <Test> "->" <Value>
             | <Test> ;

    <Value>:: <StrEx> ;




Blaze, et al.                Informational                     [Page 15]

RFC 2704          The KeyNote Trust-Management System     September 1999


    <Test>:: <RelExpr> ;

    <RelExpr>:: "(" <RelExpr> ")"        /* Parentheses */
              | <RelExpr> "&&" <RelExpr> /* Logical AND */
              | <RelExpr> "||" <RelExpr> /* Logical OR */
              | "!" <RelExpr>         /* Logical NOT */
              | <IntRelExpr>
              | <FloatRelExpr>
              | <StringRelExpr>
              | "true"        /* case insensitive */
              | "false" ;     /* case insensitive */

    <IntRelExpr>:: <IntEx> "==" <IntEx>
                 | <IntEx> "!=" <IntEx>
                 | <IntEx> "<" <IntEx>
                 | <IntEx> ">" <IntEx>
                 | <IntEx> "<=" <IntEx>
                 | <IntEx> ">=" <IntEx> ;

    <FloatRelExpr>:: <FloatEx> "<" <FloatEx>
                   | <FloatEx> ">" <FloatEx>
                   | <FloatEx> "<=" <FloatEx>
                   | <FloatEx> ">=" <FloatEx> ;

    <StringRelExpr>:: <StrEx> "==" <StrEx>  /* String equality */
                    | <StrEx> "!=" <StrEx>  /* String inequality */
                    | <StrEx> "<" <StrEx>   /* Alphanum. comparisons */
                    | <StrEx> ">" <StrEx>
                    | <StrEx> "<=" <StrEx>
                    | <StrEx> ">=" <StrEx>
                    | <StrEx> "~=" <RegExpr> ; /* Reg. expr. matching */

    <IntEx>:: <IntEx> "+" <IntEx>        /* Integer */
            | <IntEx> "-" <IntEx>
            | <IntEx> "*" <IntEx>
            | <IntEx> "/" <IntEx>
            | <IntEx> "%" <IntEx>
            | <IntEx> "^" <IntEx>        /* Exponentiation */
            | "-" <IntEx>
            | "(" <IntEx> ")"
            | <IntegerLiteral>
            | "@" <StrEx> ;

    <FloatEx>:: <FloatEx> "+" <FloatEx>  /* Floating point */
              | <FloatEx> "-" <FloatEx>
              | <FloatEx> "*" <FloatEx>
              | <FloatEx> "/" <FloatEx>
              | <FloatEx> "^" <FloatEx> /* Exponentiation */



Blaze, et al.                Informational                     [Page 16]

RFC 2704          The KeyNote Trust-Management System     September 1999


              | "-" <FloatEx>
              | "(" <FloatEx> ")"
              | <FloatLiteral>
              | "&" <StrEx> ;

    <IntegerLiteral>:: {Decimal number of at least one digit} ;
    <FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;

    <StringLiteral> is a quoted string as defined in Section 4.3
    <AttributeID> is defined in Section 3.

   The operation precedence classes are (from highest to lowest):
        { (, ) }
        {unary -, @, &, $}
        {^}
        {*, /, %}
        {+, -, .}

   Operators in the same precedence class are evaluated left-to-right.

   Note the inability to test for floating point equality,  as most
   floating point implementations (hardware or otherwise) do not
   guarantee accurate equality testing.

   Also note that integer and floating point expressions can only be
   used within clauses of condition fields, but in no other KeyNote
   field.

   The keywords "true" and "false" are not reserved; they can be used as
   attribute or principal identifier names (although this practice makes
   assertions difficult to understand and is discouraged).

   <RegExpr> is a standard regular expression, conforming to the POSIX
   1003.2 regular expression syntax and semantics.

   Any string expression (or attribute) containing the ASCII
   representation of a numeric value can be converted to an integer or
   float with the use of the "@" and "&" operators, respectively.  Any
   fractional component of an attribute value dereferenced as an integer
   is rounded down.  If an attribute dereferenced as a number cannot be
   properly converted (e.g., it contains invalid characters or is empty)
   its value is considered to be zero.









Blaze, et al.                Informational                     [Page 17]

RFC 2704          The KeyNote Trust-Management System     September 1999


4.6.6  The Comment Field

   The Comment field allows assertions to be annotated with information
   describing their purpose.  It is of the form

       <CommentField>:: "Comment:" <text> ;

   No interpretation of the contents of this field is performed by
   KeyNote.  Note that this is one of two mechanisms for including
   comments in KeyNote assertions; comments can also be inserted
   anywhere in an assertion's body by preceding them with the "#"
   character (except inside string literals).

4.6.7  The Signature Field

   The Signature field identifies a signed assertion and gives the
   encoded digital signature of the principal identified in the
   Authorizer field.  The Signature field is of the form:

       <SignatureField>:: "Signature:" <Signature> ;

       <Signature>:: <StrEx> ;

   The <Signature> string should be of the form:

       <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;

   The formats of the "ALGORITHM" and "ENCODEDBITS" substrings are as
   described for Cryptographic Principal Identifiers in Section 4.4.2
   The algorithm name should be the same as that of the principal
   appearing in the Authorizer field.  The IANA (or some other suitable
   authority) will provide a registry of reserved names.  It is not
   necessary that the encodings of the signature and the authorizer key
   be the same.

   If the signature field is included, the principal named in the
   Authorizer field must be a Cryptographic Principal Identifier, the
   algorithm must be known to the KeyNote implementation, and the
   signature must be correct for the assertion body and authorizer key.

   The signature is computed over the assertion text, beginning with the
   first field (including the field identifier string), up to (but not
   including) the Signature field identifier.  The newline preceding the
   signature field identifier is the last character included in
   signature calculation.  The signature is always the last field in a
   KeyNote assertion.  Text following this field is not considered part
   of the assertion.




Blaze, et al.                Informational                     [Page 18]

RFC 2704          The KeyNote Trust-Management System     September 1999


   The algorithms for computing and verifying signatures must be
   configured into each KeyNote implementation and are defined and
   documented separately.

   Note that all signatures used in examples in this document are
   fictitious and generally much shorter than would be required for
   security in practice.

5.   Query Evaluation Semantics

   The KeyNote compliance checker finds and returns the Policy
   Compliance Value of queries, as defined in Section 5.3, below.

5.1  Query Parameters

   A KeyNote query has four parameters:

   *  The identifier of the principal(s) requesting the action.

   *  The action attribute set describing the action.

   *  The set of compliance values of interest to the application,
      ordered from _MIN_TRUST to _MAX_TRUST

   *  The policy and credential assertions that should be included in
      the evaluation.

   The mechanism for passing these parameters to the KeyNote evaluator
   is application dependent.  In particular, an evaluator might provide
   for some parameters to be passed explicitly, while others are looked
   up externally (e.g., credentials might be looked up in a network-
   based distribution system), while still others might be requested
   from the application as needed by the evaluator, through a `callback'
   mechanism (e.g., for attribute values that represent values from
   among a very large namespace).

5.1.1  Action Requester

   At least one Principal must be identified in each query as the
   `requester' of the action.  Actions may be requested by several
   principals, each considered to have individually requested it.  This
   allows policies that require multiple authorizations, e.g., `two
   person control'.  The set of authorizing principals is made available
   in the special attribute "_ACTION_AUTHORIZERS"; if several principals
   are authorizers, their identifiers are separated with commas.






Blaze, et al.                Informational                     [Page 19]

RFC 2704          The KeyNote Trust-Management System     September 1999


5.1.2  Ordered Compliance Value Set

   The set of compliance values of interest to an application (and their
   relative ranking to one another) is determined by the invoking
   application and passed to the KeyNote evaluator as a parameter of the
   query.  In many applications, this will be Boolean, e.g., the ordered
   sets {FALSE, TRUE} or {REJECT, APPROVE}.  Other applications may
   require a range of possible values, e.g., {No_Access, Limited_Access,
   Full_Access}.  Note that applications should include in this set only
   compliance value names that are actually returned by the assertions.

   The lowest-order and highest-order compliance value strings given in
   the query are available in the special attributes named "_MIN_TRUST"
   and "_MAX_TRUST", respectively.  The complete set of query compliance
   values is made available in ascending order (from _MIN_TRUST to
   _MAX_TRUST) in the special attribute named "_VALUES".  Values are
   separated with commas; applications that use assertions that make use
   of the _VALUES attribute should therefore avoid the use of compliance
   value strings that themselves contain commas.

5.2  Principal Identifier Normalization

   Principal identifier comparisons among Cryptographic Principal
   Identifiers (that represent keys) in the Authorizer and Licensees
   fields or in an action's direct authorizers are performed after
   normalizing them by conversion to a canonical form.

   Every cryptographic algorithm used in KeyNote defines a method for
   converting keys to their canonical form and that specifies how the
   comparison for equality of two keys is performed.  If the algorithm
   named in the identifier is unknown to KeyNote, the identifier is
   treated as opaque.

   Opaque identifiers are compared as case-sensitive strings.

   Notice that use of opaque identifiers in the Authorizer field
   requires that the assertion's integrity be locally trusted (since it
   cannot be cryptographically verified by the compliance checker).

5.3  Policy Compliance Value Calculation

   The Policy Compliance Value of a query is the Principal Compliance
   Value of the principal named "POLICY".  This value is defined as
   follows:







Blaze, et al.                Informational                     [Page 20]

RFC 2704          The KeyNote Trust-Management System     September 1999


5.3.1  Principal Compliance Value

   The Compliance Value of a principal <X> is the highest order
   (maximum) of:

      -  the Direct Authorization Value of principal <X>; and

      -  the Assertion Compliance Values of all assertions identifying
         <X> in the Authorizer field.

5.3.2  Direct Authorization Value

   The Direct Authorization Value of a principal <X> is _MAX_TRUST if
   <X> is listed in the query as an authorizer of the action.
   Otherwise, the Direct Authorization Value of <X> is _MIN_TRUST.

5.3.3  Assertion Compliance Value

   The Assertion Compliance Value of an assertion is the lowest order
   (minimum) of the assertion's Conditions Compliance Value and its
   Licensee Compliance Value.

5.3.4 Conditions Compliance Value

   The Conditions Compliance Value of an assertion is the highest-order
   (maximum) value among all successful clauses listed in the conditions
   section.

   If no clause's test succeeds or the Conditions field is empty, an
   assertion's Conditions Compliance Value is considered to be the
   _MIN_TRUST value, as defined Section 5.1.

   If an assertion's Conditions field is missing entirely, its
   Conditions Compliance Value is considered to be the _MAX_TRUST value,
   as defined in Section 5.1.

   The set of successful test clause values is calculated as follows:

   Recall from the grammar of section 4.6.5 that each clause in the
   conditions section has two logical parts: a `test' and an optional
   `value', which, if present, is separated from the test with the "->"
   token.  The test subclause is a predicate that either succeeds
   (evaluates to logical `true') or fails (evaluates to logical
   `false').  The value subclause is a string expression that evaluates
   to one value from the ordered set of compliance values given with the
   query.  If the value subclause is missing, it is considered to be
   _MAX_TRUST.  That is, the clause




Blaze, et al.                Informational                     [Page 21]

RFC 2704          The KeyNote Trust-Management System     September 1999


       foo=="bar";

   is equivalent to

       foo=="bar" -> _MAX_TRUST;

   If the value component of a clause is present, in the simplest case
   it contains a string expression representing a possible compliance
   value.  For example, consider an assertion with the following
   Conditions field:

       Conditions:
          @user_id == 0 -> "full_access";             # clause (1)
          @user_id < 1000 -> "user_access";           # clause (2)
          @user_id < 10000 -> "guest_access";         # clause (3)
          user_name == "root" -> "full_access";       # clause (4)

   Here, if the value of the "user_id" attribute is "1073" and the
   "user_name" attribute is "root", the possible compliance value set
   would contain the values "guest_access" (by clause (3)) and
   "full_access" (by clause (4)).  If the ordered set of compliance
   values given in the query (in ascending order) is {"no_access",
   "guest_access", "user_access", "full_access"}, the Conditions
   Compliance Value of the assertion would be "full_access" (because
   "full_access" has a higher-order value than "guest_access").  If the
   "user_id" attribute had the value "19283" and the "user_name"
   attribute had the value "nobody", no clause would succeed and the
   Conditions Compliance Value would be "no_access", which is the
   lowest-order possible value (_MIN_TRUST).

   If a clause lists an explicit value, its value string must be named
   in the query ordered compliance value set.  Values not named in the
   query compliance value set are considered equivalent to _MIN_TRUST.

   The value component of a clause can also contain recursively-nested
   clauses.  Recursively-nested clauses are evaluated only if their
   parent test is true.  That is,

       a=="b" ->  { b=="c" -> "value1";
                    d=="e"  -> "value2";
                    true -> "value3"; } ;

   is equivalent to

       (a=="b") && (b=="c") -> "value1";
       (a=="b") && (d=="e") -> "value2";
       (a=="b") -> "value3";




Blaze, et al.                Informational                     [Page 22]

RFC 2704          The KeyNote Trust-Management System     September 1999


   String comparisons are case-sensitive.

   A regular expression comparison ("~=") is considered true if the
   left-hand-side string expression matches the right-hand-side regular
   expression.  If the POSIX regular expression group matching scheme is
   used, the number of groups matched is placed in the temporary meta-
   attribute "_0" (dereferenced as _0), and each match is placed in
   sequence in the temporary attributes (_1, _2, ..., _N).  These
   match-attributes' values are valid only within subsequent references
   made within the same clause.  Regular expression evaluation is case-
   sensitive.

   A runtime error occurring in the evaluation of a test, such as
   division by zero or an invalid regular expression, causes the test to
   be considered false.  For example:

      foo == "bar" -> {
                        @a == 1/0 -> "oneval";    # subclause 1
                        @a == 2 -> "anotherval";  # subclause 2
                      };

   Here, subclause 1 triggers a runtime error.  Subclause 1 is therefore
   false (and has the value _MIN_TRUST).  Subclause 2, however, would be
   evaluated normally.

   An invalid <RegExpr> is considered a runtime error and causes the
   test in which it occurs to be considered false.

5.3.5  Licensee Compliance Value

   The Licensee Compliance Value of an assertion is calculated by
   evaluating the expression in the Licensees field, based on the
   Principal Compliance Value of the principals named there.

   If an assertion's Licensees field is empty, its Licensee Compliance
   Value is considered to be _MIN_TRUST.  If an assertion's Licensees
   field is missing altogether, its Licensee Compliance Value is
   considered to be _MAX_TRUST.

   For each principal named in the Licensees field, its Principal
   Compliance Value is substituted for its name.  If no Principal
   Compliance Value can be found for some named principal, its name is
   substituted with the _MIN_TRUST value.

   The licensees expression (as defined in Section 4.6.4) is evaluated
   as follows:





Blaze, et al.                Informational                     [Page 23]

RFC 2704          The KeyNote Trust-Management System     September 1999


   *  A "(...)" expression has the value of the enclosed subexpression.

   *  A "&&" expression has the lower-order (minimum) of its two
        subexpression values.

   *  A "||" expression has the higher-order (maximum) of its two
      subexpression values.

   *  A "<K>-of(<List>)" expression has the K-th highest order
      compliance value listed in <list>.  Values that appear multiple
      times are counted with multiplicity.  For example, if K = 3 and
      the orders of the listed compliance values are (0, 1, 2, 2, 3),
      the value of the expression is the compliance value of order 2.

   For example, consider the following Licensees field:

        Licensees: ("alice" && "bob") || "eve"

   If the Principal Compliance Value is "yes" for principal "alice",
   "no" for principal "bob", and "no" for principal "eve", and "yes" is
   higher order than "no" in the query's Compliance Value Set, then the
   resulting Licensee Compliance Value is "no".

   Observe that if there are exactly two possible compliance values
   (e.g., "false" and "true"), the rules of Licensee Compliance Value
   resolution reduce exactly to standard Boolean logic.

5.4  Assertion Management

   Assertions may be either signed or unsigned.  Only signed assertions
   should be used as credentials or transmitted or stored on untrusted
   media.  Unsigned assertions should be used only to specify policy and
   for assertions whose integrity has already been verified as
   conforming to local policy by some mechanism external to the KeyNote
   system itself (e.g., X.509 certificates converted to KeyNote
   assertions by a trusted conversion program).

   Implementations that permit signed credentials to be verified by the
   KeyNote compliance checker generally provide two `channels' through
   which applications can make assertions available.  Unsigned,
   locally-trusted assertions are provided over a `trusted' interface,
   while signed credentials are provided over an `untrusted' interface.
   The KeyNote compliance checker verifies correct signatures for all
   assertions submitted over the untrusted interface.  The integrity of
   KeyNote evaluation requires that only assertions trusted as
   reflecting local policy are submitted to KeyNote via the trusted
   interface.




Blaze, et al.                Informational                     [Page 24]

RFC 2704          The KeyNote Trust-Management System     September 1999


   Note that applications that use KeyNote exclusively as a local policy
   specification mechanism need use only trusted assertions.  Other
   applications might need only a small number of infrequently changed
   trusted assertions to `bootstrap' a policy whose details are
   specified in signed credentials issued by others and submitted over
   the untrusted interface.

5.5  Implementation Issues

   Informally, the semantics of KeyNote evaluation can be thought of as
   involving the construction a directed graph of KeyNote assertions
   rooted at a POLICY assertion that connects with at least one of the
   principals that requested the action.

   Delegation of some authorization from principal <A> to a set of
   principals <B> is expressed as an assertion with principal <A> given
   in the Authorizer field, principal set <B> given in the Licensees
   field, and the authorization to be delegated encoded in the
   Conditions field.  How the expression digraph is constructed is
   implementation-dependent and implementations may use different
   algorithms for optimizing the graph's construction.  Some
   implementations might use a `bottom up' traversal starting at the
   principals that requested the action, others might follow a `top
   down' approach starting at the POLICY assertions, and still others
   might employ other heuristics entirely.

   Implementations are encouraged to employ mechanisms for recording
   exceptions (such as division by zero or syntax error), and reporting
   them to the invoking application if requested.  Such mechanisms are
   outside the scope of this document.

6.  Examples

   In this section, we give examples of KeyNote assertions that might be
   used in hypothetical applications.  These examples are intended
   primarily to illustrate features of KeyNote assertion syntax and
   semantics, and do not necessarily represent the best way to integrate
   KeyNote into applications.

   In the interest of readability, we use much shorter keys than would
   ordinarily be used in practice.  Note that the Signature fields in
   these examples do not represent the result of any real signature
   calculation.








Blaze, et al.                Informational                     [Page 25]

RFC 2704          The KeyNote Trust-Management System     September 1999


   1. TRADITIONAL CA / EMAIL

      A. A policy unconditionally authorizing RSA key abc123 for all
         actions.  This essentially defers the ability to specify
         policy to the holder of the secret key corresponding to
         abc123:

           Authorizer: "POLICY"
           Licensees: "RSA:abc123"

      B. A credential assertion in which RSA Key abc123 trusts either
         RSA key 4401ff92 (called `Alice') or DSA key d1234f (called
         `Bob') to perform actions in which the "app_domain" is
         "RFC822-EMAIL", where the "address" matches the regular
         expression "^.*@keynote\.research\.att\.com$".  In other
         words, abc123 trusts Alice and Bob as certification
         authorities for the keynote.research.att.com domain.

           KeyNote-Version: 2
           Local-Constants: Alice="DSA:4401ff92"  # Alice's key
                            Bob="RSA:d1234f"      # Bob's key
           Authorizer: "RSA:abc123"
           Licensees: Alice || Bob
           Conditions: (app_domain == "RFC822-EMAIL") &&
                       (address ~=   # only applies to one domain
                         "^.*@keynote\\.research\\.att\\.com$");
           Signature: "RSA-SHA1:213354f9"

      C. A certificate credential for a specific user whose email
         address is mab@keynote.research.att.com and whose name, if
         present, must be "M. Blaze". The credential was issued by the
         `Alice' authority (whose key is certified in Example B
         above):

           KeyNote-Version: 2
           Authorizer: "DSA:4401ff92"  # the Alice CA
           Licensees: "DSA:12340987"   # mab's key
           Conditions: ((app_domain == "RFC822-EMAIL") &&
                        (name == "M. Blaze" || name == "") &&
                        (address == "mab@keynote.research.att.com"));
           Signature: "DSA-SHA1:ab23487"










Blaze, et al.                Informational                     [Page 26]

RFC 2704          The KeyNote Trust-Management System     September 1999


      D. Another certificate credential for a specific user, also
         issued by the `Alice' authority.  This example allows three
         different keys to sign as jf@keynote.research.att.com (each
         for a different cryptographic algorithm).  This is, in
         effect, three credentials in one:

           KeyNote-Version: "2"
           Authorizer: "DSA:4401ff92"   # the Alice CA
           Licensees: "DSA:abc991" ||   # jf's DSA key
                      "RSA:cde773" ||   # jf's RSA key
                      "BFIK:fd091a"     # jf's BFIK key
           Conditions: ((app_domain == "RFC822-EMAIL") &&
                        (name == "J. Feigenbaum" || name == "") &&
                        (address == "jf@keynote.research.att.com"));
           Signature: "DSA-SHA1:8912aa"

         Observe that under policy A and credentials B, C and D, the
         following action attribute sets are accepted (they return
         _MAX_TRUST):

             _ACTION_AUTHORIZERS = "dsa:12340987"
             app_domain = "RFC822-EMAIL"
             address = "mab@keynote.research.att.com"
          and
             _ACTION_AUTHORIZERS = "dsa:12340987"
             app_domain = "RFC822-EMAIL"
             address = "mab@keynote.research.att.com"
             name = "M. Blaze"

         while the following are not accepted (they return
         _MIN_TRUST):

             _ACTION_AUTHORIZERS = "dsa:12340987"
             app_domain = "RFC822-EMAIL"
             address = "angelos@dsl.cis.upenn.edu"
          and
             _ACTION_AUTHORIZERS = "dsa:abc991"
             app_domain = "RFC822-EMAIL"
             address = "mab@keynote.research.att.com"
             name = "M. Blaze"
          and
             _ACTION_AUTHORIZERS = "dsa:12340987"
             app_domain = "RFC822-EMAIL"
             address = "mab@keynote.research.att.com"
             name = "J. Feigenbaum"






Blaze, et al.                Informational                     [Page 27]

RFC 2704          The KeyNote Trust-Management System     September 1999


   2. WORKFLOW/ELECTRONIC COMMERCE

      E. A policy that delegates authority for the "SPEND" application
         domain to RSA key dab212 when the amount given in the
         "dollars" attribute is less than 10000.

           Authorizer: "POLICY"
           Licensees: "RSA:dab212"  # the CFO's key
           Conditions: (app_domain=="SPEND") && (@dollars < 10000);

      F. RSA key dab212 delegates authorization to any two signers,
         from a list, one of which must be DSA key feed1234 in the
         "SPEND" application when @dollars < 7500.  If the amount in
         @dollars is 2500 or greater, the request is approved but
         logged.

           KeyNote-Version: 2
           Comment: This credential specifies a spending policy
           Authorizer: "RSA:dab212"        # the CFO
           Licensees: "DSA:feed1234" &&    # The vice president
                          ("RSA:abc123" || # middle manager #1
                           "DSA:bcd987" || # middle manager #2
                           "DSA:cde333" || # middle manager #3
                           "DSA:def975" || # middle manager #4
                           "DSA:978add")   # middle manager #5
           Conditions: (app_domain=="SPEND")  # note nested clauses
                         -> { (@(dollars) < 2500)
                                -> _MAX_TRUST;
                              (@(dollars) < 7500)
                                -> "ApproveAndLog";
                            };
           Signature: "RSA-SHA1:9867a1"

      G. According to this policy, any two signers from the list of
         managers will do if @(dollars) < 1000:

           KeyNote-Version: 2
           Authorizer: "POLICY"
           Licensees: 2-of("DSA:feed1234", # The VP
                           "RSA:abc123",   # Middle management clones
                           "DSA:bcd987",
                           "DSA:cde333",
                           "DSA:def975",
                           "DSA:978add")
           Conditions: (app_domain=="SPEND") &&
                       (@(dollars) < 1000);





Blaze, et al.                Informational                     [Page 28]

RFC 2704          The KeyNote Trust-Management System     September 1999


      H. A credential from dab212 with a similar policy, but only one
         signer is required if @(dollars) < 500.  A log entry is made if
         the amount is at least 100.

           KeyNote-Version: 2
           Comment: This one credential is equivalent to six separate
                    credentials, one for each VP and middle manager.
                    Individually, they can spend up to $500, but if
                    it's $100 or more, we log it.
           Authorizer: "RSA:dab212"      # From the CFO
           Licensees: "DSA:feed1234" ||  # The VP
                      "RSA:abc123" ||    # The middle management clones
                      "DSA:bcd987" ||
                      "DSA:cde333" ||
                      "DSA:def975" ||
                      "DSA:978add"
           Conditions: (app_domain="SPEND")  # nested clauses
                         -> { (@(dollars) < 100) -> _MAX_TRUST;
                              (@(dollars) < 500) -> "ApproveAndLog";
                            };
           Signature: "RSA-SHA1:186123"

      Assume a query in which the ordered set of Compliance Values is
      {"Reject", "ApproveAndLog", "Approve"}.  Under policies E and G,
      and credentials F and H, the Policy Compliance Value is
      "Approve" (_MAX_TRUST) when:

           _ACTION_AUTHORIZERS = "DSA:978add"
           app_domain = "SPEND"
           dollars = "45"
           unmentioned_attribute = "whatever"
       and
           _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333"
           app_domain = "SPEND"
           dollars = "550"

      The following return "ApproveAndLog":

           _ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333"
           app_domain = "SPEND"
           dollars = "5500"
       and
           _ACTION_AUTHORIZERS = "DSA:cde333"
           app_domain = "SPEND"
           dollars = "150"






Blaze, et al.                Informational                     [Page 29]

RFC 2704          The KeyNote Trust-Management System     September 1999


      However, the following return "Reject" (_MIN_TRUST):

           _ACTION_AUTHORIZERS = "DSA:def975"
           app_domain = "SPEND"
           dollars = "550"
       and
           _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add"
           app_domain = "SPEND"
           dollars = "5500"

7.  Trust-Management Architecture

   KeyNote provides a simple mechanism for describing security policy
   and representing credentials.  It differs from traditional
   certification systems in that the security model is based on binding
   keys to predicates that describe what the key is authorized by policy
   to do, rather than on resolving names.  The infrastructure and
   architecture to support a KeyNote system is therefore rather
   different from that required for a name-based certification scheme.
   The KeyNote trust-management architecture is based on that of
   PolicyMaker [BFL96,BFS98].

   It is important to understand the separation between the
   responsibilities of the KeyNote system and those of the application
   and other support infrastructure.  A KeyNote compliance checker will
   determine, based on policy and credential assertions, whether a
   proposed action is permitted according to policy.  The usefulness of
   KeyNote output as a policy enforcement mechanism depends on a number
   of factors:

   *  The action attributes and the assignment of their values must
      reflect accurately the security requirements of the application.
      Identifying the attributes to include in the action attribute set
      is perhaps the most important task in integrating KeyNote into new
      applications.

   *  The policy of the application must be correct and well-formed.  In
      particular, trust must be deferred only to principals that should,
      in fact, be trusted by the application.

   *  The application itself must be trustworthy.  KeyNote does not
      directly enforce policy; it only provides advice to the
      applications that call it.  In other words, KeyNote assumes that
      the application itself is trusted and that the policy assertions
      it specifies are correct.  Nothing prevents an application from
      submitting misleading or incorrect assertions to KeyNote or from
      ignoring KeyNote altogether.




Blaze, et al.                Informational                     [Page 30]

RFC 2704          The KeyNote Trust-Management System     September 1999


   It is also up to the application (or some service outside KeyNote) to
   select the appropriate credentials and policy assertions with which
   to run a particular query.  Note, however, that even if inappropriate
   credentials are provided to KeyNote, this cannot result in the
   approval of an illegal action (as long as the policy assertions are
   correct and the the action attribute set itself is correctly passed
   to KeyNote).

   KeyNote is monotonic; adding an assertion to a query can never result
   in a query's having a lower compliance value that it would have had
   without the assertion.  Omitting credentials may, of course, result
   in legal actions being disallowed.  Selecting appropriate credentials
   (e.g., from a distributed database or `key server') is outside the
   scope of the KeyNote language and may properly be handled by a remote
   client making a request, by the local application receiving the
   request, or by a network-based service, depending on the application.

   In addition, KeyNote does not itself provide credential revocation
   services, although credentials can be written to expire after some
   date by including a date test in the predicate.  Applications that
   require credential revocation can use KeyNote to help specify and
   implement revocation policies.  A future document will address
   expiration and revocation services in KeyNote.

   Because KeyNote is designed to support a variety of applications,
   several different application interfaces to a KeyNote implementation
   are possible.  In its simplest form, a KeyNote compliance checker
   would exist as a stand-alone application, with other applications
   calling it as needed.  KeyNote might also be implemented as a library
   to which applications are linked.  Finally, a KeyNote implementation
   might run as a local trusted service, with local applications
   communicating their queries via some interprocess communication
   mechanism.

8.  Security Considerations

   Trust management is itself a security service.  Bugs in or incorrect
   use of a KeyNote compliance checker implementation could have
   security implications for any applications in which it is used.

9. IANA Considerations

   This document contains three identifiers to be maintained by the
   IANA.  This section explains the criteria to be used by the IANA to
   assign additional identifiers in each of these lists.






Blaze, et al.                Informational                     [Page 31]

RFC 2704          The KeyNote Trust-Management System     September 1999


9.1  app_domain Identifiers

   The only thing required of IANA on allocation of these identifiers is
   that they be unique strings.  These strings are case-sensitive for
   KeyNote purposes, however it is strongly recommended that IANA assign
   different capitalizations of the same string only to the same
   organization.

9.2  Public Key Format Identifiers

   These strings uniquely identify a public key algorithm as used in the
   KeyNote system for representing keys.  Requests for assignment of new
   identifiers must be accompanied by an RFC-style document that
   describes the details of this encoding.  Example strings are "rsa-
   hex:" and "dsa-base64:".  These strings are case-insensitive.

9.3  Signature Algorithm Identifiers

   These strings uniquely identify a public key algorithm as used in the
   KeyNote system for representing public key signatures.  Requests for
   assignment of new identifiers must be accompanied by an RFC-style
   document that describes the details of this encoding. Example strings
   are "sig-rsa-md5-hex:" and "sig-dsa-sha1-base64:".  Note that all
   such strings must begin with the prefix "sig-".  These strings are
   case-insensitive.


























Blaze, et al.                Informational                     [Page 32]

RFC 2704          The KeyNote Trust-Management System     September 1999


A.  Acknowledgments

   We thank Lorrie Faith Cranor (AT&T Labs - Research) and Jonathan M.
   Smith (University of Pennsylvania) for their suggestions and comments
   on earlier versions of this document.

B.  Full BNF (alphabetical order)

   <ALGORITHM>:: {see section 4.4.2} ;

   <Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
                 <LocalConstantsField>? <ConditionsField>?
                 <CommentField>? <SignatureField>? ;

   <Assignments>:: "" | <AttributeID> "=" <StringLiteral> <Assignments>
   ;

   <AttributeID>:: {Any string starting with a-z, A-Z, or the
                    underscore character, followed by any number of
                    a-z, A-Z, 0-9, or underscore characters} ;

   <AuthField>:: "Authorizer:" <AuthID> ;

   <AuthID>:: <PrincipalIdentifier> | <DerefAttribute> ;

   <Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
            | <Test> "->" <Value> | <Test> ;

   <Comment>:: "#" {ASCII characters} ;

   <CommentField>:: "Comment:" {Free-form text} ;

   <ConditionsField>:: "Conditions:" <ConditionsProgram> ;

   <ConditionsProgram>:: "" | <Clause> ";" <ConditionsProgram> ;

   <DerefAttribute>:: <AttributeID> ;

   <ENCODEDBITS>:: {see section 4.4.2} ;

   <FloatEx>:: <FloatEx> "+" <FloatEx> | <FloatEx> "-" <FloatEx>
             | <FloatEx> "*" <FloatEx> | <FloatEx> "/" <FloatEx>
             | <FloatEx> "^" <FloatEx> | "-" <FloatEx>
             | "(" <FloatEx> ")" | <FloatLiteral> | "&" <StrEx> ;

   <FloatRelExpr>:: <FloatEx> "<" <FloatEx> | <FloatEx> ">" <FloatEx>
                  | <FloatEx> "<=" <FloatEx>
                  | <FloatEx> ">=" <FloatEx> ;



Blaze, et al.                Informational                     [Page 33]

RFC 2704          The KeyNote Trust-Management System     September 1999


   <FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;

   <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;

   <IntegerLiteral>:: {Decimal number of at least one digit} ;

   <IntEx>:: <IntEx> "+" <IntEx> | <IntEx> "-" <IntEx>
           | <IntEx> "*" <IntEx> | <IntEx> "/" <IntEx>
           | <IntEx> "%" <IntEx> | <IntEx> "^" <IntEx>
           | "-" <IntEx> | "(" <IntEx> ")" | <IntegerLiteral>
           | "@" <StrEx> ;

   <IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx>
                | <IntEx> "<" <IntEx>  | <IntEx> ">" <IntEx>
                | <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ;

   <K>:: {Decimal number starting with a digit from 1 to 9} ;

   <KeyID>:: <StrEx> ;

   <LicenseesExpr>:: "" | <PrincExpr> ;

   <LicenseesField>:: "Licensees:" <LicenseesExpr> ;

   <LocalConstantsField>:: "Local-Constants:" <Assignments> ;

   <OpaqueID>:: <StrEx> ;

   <PrincExpr>:: "(" <PrincExpr> ")" | <PrincExpr> "&&" <PrincExpr>
               | <PrincExpr> "||" <PrincExpr>
               | <K>"-of(" <PrincList> ")" | <PrincipalIdentifier>
               | <DerefAttribute> ;

   <PrincipalIdentifier>:: <OpaqueID> | <KeyID> ;

   <PrincList>:: <PrincipalIdentifier> | <DerefAttribute>
               | <PrincList> "," <PrincList> ;

   <RegExpr>:: {POSIX 1003.2 Regular Expression}

   <RelExpr>:: "(" <RelExpr> ")" | <RelExpr> "&&" <RelExpr>
             | <RelExpr> "||" <RelExpr> | "!" <RelExpr>
             | <IntRelExpr> | <FloatRelExpr> | <StringRelExpr>
             | "true" | "false" ;

   <Signature>:: <StrEx> ;

   <SignatureField>:: "Signature:" <Signature> ;



Blaze, et al.                Informational                     [Page 34]

RFC 2704          The KeyNote Trust-Management System     September 1999


   <StrEx>:: <StrEx> "." <StrEx> | <StringLiteral> | "(" <StrEx> ")"
           | <DerefAttribute> | "$" <StrEx> ;

   <StringLiteral>:: {see section 4.3.1} ;

   <StringRelExpr>:: <StrEx> "==" <StrEx> | <StrEx> "!=" <StrEx>
                   | <StrEx> "<" <StrEx> | <StrEx> ">" <StrEx>
                   | <StrEx> "<=" <StrEx> | <StrEx> ">=" <StrEx>
                   | <StrEx> "~=" <RegExpr> ;

   <Test>:: <RelExpr> ;

   <Value>:: <StrEx> ;

   <VersionField>:: "KeyNote-Version:" <VersionString> ;

   <VersionString>:: <StringLiteral> | <IntegerLiteral> ;

References

   [BFL96] M. Blaze, J. Feigenbaum, J. Lacy. Decentralized Trust
           Management. Proceedings of the 17th IEEE Symp. on Security
           and Privacy. pp 164-173.  IEEE Computer Society, 1996.
           Available at
           <ftp://ftp.research.att.com/dist/mab/policymaker.ps>

   [BFS98] M. Blaze, J. Feigenbaum, M. Strauss. Compliance-Checking in
           the PolicyMaker Trust-Management System. Proc. 2nd Financial
           Crypto Conference. Anguilla 1998.  LNCS #1465, pp 251-265,
           Springer-Verlag, 1998.  Available at
           <ftp://ftp.research.att.com/dist/mab/pmcomply.ps>

   [Bla99] M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis.  The
           Role of Trust Management in Distributed System Security.
           Chapter in Secure Internet Programming: Security Issues for
           Mobile and Distributed Objects (Vitek and Jensen, eds.).
           Springer-Verlag, 1999.  Available at
           <ftp://ftp.research.att.com/dist/mab/trustmgt.ps>.

   [Cro82] Crocker, D., "Standard for the Format of ARPA Internet Text
           Messages", STD 11, RFC 822, August 1982.

   [DSA94] Digital Signature Standard. FIPS-186. National Institute of
           Standards, U.S. Department of Commerce. May 1994.

   [PKCS1] PKCS #1: RSA Encryption Standard, Version 1.5. RSA
           Laboratories. November 1993.




Blaze, et al.                Informational                     [Page 35]

RFC 2704          The KeyNote Trust-Management System     September 1999


   [RSA78] R. L. Rivest, A. Shamir, L. M. Adleman.  A Method for
           Obtaining Digital Signatures and Public-Key Cryptosystems.
           Communications of the ACM, v21n2. pp 120-126.  February 1978.

Authors' Addresses

   Comments about this document should be discussed on the keynote-users
   mailing list hosted at nsa.research.att.com.  To subscribe, send an
   email message containing the single line
                 subscribe keynote-users
   in the message body to <majordomo@nsa.research.att.com>.

   Questions about this document can also be directed to the authors as
   a group at the keynote@research.att.com alias, or to the individual
   authors at:

   Matt Blaze
   AT&T Labs - Research
   180 Park Avenue
   Florham Park, New Jersey 07932-0971

   EMail: mab@research.att.com


   Joan Feigenbaum
   AT&T Labs - Research
   180 Park Avenue
   Florham Park, New Jersey 07932-0971

   EMail: jf@research.att.com


   John Ioannidis
   AT&T Labs - Research
   180 Park Avenue
   Florham Park, New Jersey 07932-0971

   EMail: ji@research.att.com


   Angelos D. Keromytis
   Distributed Systems Lab
   CIS Department, University of Pennsylvania
   200 S. 33rd Street
   Philadelphia, Pennsylvania  19104-6389

   EMail: angelos@dsl.cis.upenn.edu




Blaze, et al.                Informational                     [Page 36]

RFC 2704          The KeyNote Trust-Management System     September 1999


Full Copyright Statement

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

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

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

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

Acknowledgement

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



















Blaze, et al.                Informational                     [Page 37]