discontinued / server · Files

index.html 210 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta name="generator"
    content="HTML Tidy for Linux/x86 (vers 1st March 2002), see www.w3.org" />
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>
      XML-Signature Syntax and Processing
    </title>
<style type="text/css">
/*<![CDATA[*/
/**/
/**/
    u        { background: white; color: red;}
    ins      { background: white; color: red;}
    del,strike,.strike   { background: white; color: silver; text-decoration: line-through;}
    code     {font-weight: normal; }
    .link-def   { background: #FFFFFF; color: teal;  font-style: italic;}
    .comment    { background: #FFFFF5; color: black; padding: .7em;
                  border: navy thin solid;}
    .discuss    { color: blue; background: yellow; }
    .xml-example, .xml-dtd { margin-left: -1em; padding: .5em;
                  white-space: pre; border: none;}
    .xml-dtd    { background: #efeff8; color: black;}
  
  
  
  
  
/**/
  
/**/
  
/*]]>*/
</style>
    <link rel="stylesheet" type="text/css"
    href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" />
  </head>
  <body xml:lang="en" lang="en">
    <div class="head">
      <p>
        <a href="http://www.ietf.org"><img src="http://ietf.org/images/ietflogo2e.gif"
        alt="IETF" height="48" width="92" /></a><a href="http://www.w3.org/"><img
        src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a>
      </p>
      <h1 class="notoc">
        XML-Signature Syntax and Processing
      </h1>
      <h2 class="notoc">
        W3C Recommendation 12 February 2002
      </h2>
      <dl>
        <dt>
          This version:
        </dt>
        <dd>
          <a
          href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/">http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/</a>
        </dd>
        <dd>
          <a
          href="http://www.ietf.org/rfc/rfc3275.txt">http://www.ietf.org/rfc/rfc3275.txt</a>
        </dd>
        <dt>
          Latest version:
        </dt>
        <dd>
          <a
          href="http://www.w3.org/TR/xmldsig-core/">http://www.w3.org/TR/xmldsig-core/</a>
        </dd>
        <dt>
          Previous version:
        </dt>
        <dd>
          <a
          href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/">http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/</a>
        </dd>
        <dd>
          <a
          href="http://www.ietf.org/rfc/rfc3075.txt">http://www.ietf.org/rfc/rfc3075.txt</a>
          [corresponds to <a
          href="http://www.w3.org/TR/2001/CR-xmldsig-core-20010419/">CR-xmldsig-core-20001031</a>]<br />

        </dd>
        <dt>
          Editors
        </dt>
        <dd>
          Donald Eastlake &lt;<a
          href="mailto:dee3@torque.pothole.com">dee3@torque.pothole.com</a>&gt;<br />
           Joseph Reagle &lt;<a href="mailto:reagle@w3.org">reagle@w3.org</a>&gt;<br />
           David Solo &lt;<a
          href="mailto:dsolo@alum.mit.edu">dsolo@alum.mit.edu</a>&gt;
        </dd>
        <dt>
          Authors
        </dt>
        <dd>
          Mark Bartel &lt;<a
          href="mailto:mbartel@accelio.com">mbartel@accelio.com</a>&gt;
        </dd>
        <dd>
          John Boyer &lt;<a
          href="mailto:jboyer@PureEdge.com">jboyer@PureEdge.com</a>&gt;<br />
           Barb Fox &lt;<a
          href="mailto:bfox@Exchange.Microsoft.com">bfox@Exchange.Microsoft.com</a>&gt;
        </dd>
        <dd>
          Brian LaMacchia &lt;<a
          href="mailto:bal@microsoft.com">bal@microsoft.com</a>&gt;
        </dd>
        <dd>
          Ed Simon &lt;<a href="mailto:edsimon@xmlsec.com">edsimon@xmlsec.com</a>&gt;
        </dd>
        <dt>
          Contributors
        </dt>
        <dd>
          See <a href="#sec-Acknowledgements">Acknowledgements</a>
        </dd>
      </dl>
      <p class="copyright">
        <a
        href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
        &copy; 2002 <a href="http://www.ietf.org/">The Internet Society</a> &amp; <a
        href="http://www.w3.org/"><abbr
        title="World Wide Web Consortium">W3C</abbr></a>&reg; (<a
        href="http://www.lcs.mit.edu/"><abbr
        title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
        href="http://www.inria.fr/"><abbr xml:lang="fr" lang="fr"
        title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>,
        <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
        href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
        <a
        href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
        <a href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">docum
        ent use</a> and <a
        href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
        licensing</a> rules apply.
      </p>
      <hr title="Separator from Header" />
    </div>
    <h2 class="notoc">
      Abstract
    </h2>
    <p>
      This document specifies XML digital signature processing rules and syntax. XML
      Signatures provide <a href="#def-Integrity" class="link-def">integrity</a>, <a
      href="#def-AuthenticationMessage" class="link-def">message authentication</a>,
      and/or <a href="#def-AuthenticationSigner" class="link-def">signer
      authentication</a> services for data of any type, whether located within the XML
      that includes the signature or elsewhere.
    </p>
    <h2 class="notoc">
      <a id="status" name="status"></a>Status of this document
    </h2>
    <div class="">
      <p>
        This document has been reviewed by W3C Members and other interested parties and
        has been endorsed by the Director as a W3C Recommendation. It is a stable
        document and may be used as reference material or cited as a normative
        reference from another document. W3C's role in making the Recommendation is to
        draw attention to the specification and to promote its widespread deployment.
        This enhances the functionality and interoperability of the Web.
      </p>
      <p class="notoc">
        This specification was produced by the IETF/W3C <a
        href="http://www.w3.org/Signature/">XML Signature Working Group</a> (<a
        href="http://www.w3.org/Signature/Activity.html">W3C Activity Statement</a>)
        which believes the specification is sufficient for the creation of independent
        interoperable implementations; the <a
        href="http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html">Interoperability
        Report</a> shows at least 10 implementations with at least two interoperable
        implementations over every feature.
      </p>
      <p>
        Patent disclosures relevant to this specification may be found on the Working
        Group's <a href="http://www.w3.org/Signature/Disclosures.html">patent
        disclosure page</a>, in conformance with W3C policy, and the <a
        href="http://www.ietf.org/ipr.html">IETF Page of Intellectual Property Rights
        Notices</a>, in conformance with IETF policy.
      </p>
      <p>
        Please report errors in this document to <a
        href="mailto:w3c-ietf-xmldsig@w3.org">w3c-ietf-xmldsig@w3.org</a> (<a
        href="http://lists.w3.org/Archives/Public/xml-encryption/">archive</a>).
      </p>
      <p>
        The list of known errors in this specification is available at <a
        href="http://www.w3.org/2001/10/xmldsig-errata">http://www.w3.org/2001/10/xmldsig-errata</a>.
      </p>
      <p>
        The English version of this specification is the only normative version.
        Information about translations of this document (if any) is available <a
        href="http://www.w3.org/Signature/2002/02/xmldsig-translations">http://www.w3.org/Signature/2002/02/xmldsig-translations</a>
      </p>
      <p>
        A list of current W3C Technical Reports can be found at <a
        href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.
      </p>
    </div>
    <h2>
      Table of Contents
    </h2>
    <ol>
      <li>
        <a href="#sec-Introduction">Introduction</a> 
        <ol>
          <li>
            <a href="#sec-Editorial">Editorial Conventions</a>
          </li>
          <li>
            <a href="#sec-Design">Design Philosophy</a>
          </li>
          <li>
            <a href="#sec-Versions">Versions, Namespaces and Identifiers</a>
          </li>
          <li>
            <a href="#sec-Acknowledgements">Acknowledgements</a>
          </li>
        </ol>
      </li>
      <li>
        <a href="#sec-Overview">Signature Overview and Examples</a> 
        <ol>
          <li>
            <a href="#sec-o-Simple">Simple Example (<code>Signature</code>,
            <code>SignedInfo</code>, <code>Method</code>s, and
            <code>Reference</code>s)</a> 
            <ol>
              <li>
                <a href="#sec-o-Reference">More on <code>Reference</code></a>
              </li>
            </ol>
          </li>
          <li>
            <a href="#sec-o-SignatureProperty">Extended Example (<code>Object</code>
            and <code>SignatureProperty</code>)</a>
          </li>
          <li>
            <a href="#sec-o-Manifest">Extended Example (<code>Object</code> and
            <code>Manifest</code>)</a>
          </li>
        </ol>
      </li>
      <li>
        <a href="#sec-Processing">Processing Rules</a> 
        <ol>
          <li>
            <a href="#sec-CoreGeneration">Signature Generation</a>
          </li>
          <li>
            <a href="#sec-CoreValidation">Signature Validation</a>
          </li>
        </ol>
      </li>
      <li>
        <a href="#sec-CoreSyntax">Core Signature Syntax</a> 
        <ol>
          <li>
            <a href="#sec-Signature">The <code>Signature</code> element</a>
          </li>
          <li>
            <a href="#sec-SignatureValue">The <code>SignatureValue</code> Element</a>
          </li>
          <li>
            <a href="#sec-SignedInfo">The <code>SignedInfo</code> Element</a> 
            <ol>
              <li>
                <a href="#sec-CanonicalizationMethod">The
                <code>CanonicalizationMethod</code> Element</a>
              </li>
              <li>
                <a href="#sec-SignatureMethod">The <code>SignatureMethod</code>
                Element</a>
              </li>
              <li>
                <a href="#sec-Reference">The <code>Reference</code> Element</a> 
                <ol>
                  <li>
                    <a href="#sec-URI">The <code>URI</code> Attribute</a>
                  </li>
                  <li>
                    <a href="#sec-ReferenceProcessingModel">The Reference Processing
                    Model</a>
                  </li>
                  <li>
                    <a href="#sec-Same-Document">Same-Document URI-References</a>
                  </li>
                  <li>
                    <a href="#sec-Transforms">The <code>Transforms</code> Element</a>
                  </li>
                  <li>
                    <a href="#sec-DigestMethod">The <code>DigestMethod</code>
                    Element</a>
                  </li>
                  <li>
                    <a href="#sec-DigestValue">The <code>DigestValue</code> Element</a>
                  </li>
                </ol>
              </li>
            </ol>
          </li>
          <li>
            <a href="#sec-KeyInfo">The <code>KeyInfo</code> Element</a> 
            <ol>
              <li>
                <a href="#sec-KeyName">The <code>KeyName</code> Element</a>
              </li>
              <li>
                <a href="#sec-KeyValue">The <code>KeyValue</code> Element</a> 
                <ol>
                  <li>
                    <a href="#sec-DSAKeyValue">The <code>DSAKeyValue</code> Element</a>
                  </li>
                  <li>
                    <a href="#sec-RSAKeyValue">The <code>RSAKeyValue</code> Element</a>
                  </li>
                </ol>
              </li>
              <li>
                <a href="#sec-RetrievalMethod">The <code>RetrievalMethod</code>
                Element</a>
              </li>
              <li>
                <a href="#sec-X509Data">The <code>X509Data</code> Element</a>
              </li>
              <li>
                <a href="#sec-PGPData">The <code>PGPData</code> Element</a>
              </li>
              <li>
                <a href="#sec-SPKIData">The <code>SPKIData</code> Element</a>
              </li>
              <li>
                <a href="#sec-MgmtData">The <code>MgmtData</code> Element</a>
              </li>
            </ol>
          </li>
          <li>
            <a href="#sec-Object">The <code>Object</code> Element</a>
          </li>
        </ol>
      </li>
      <li>
        <a href="#sec-AdditionalSyntax">Additional Signature Syntax</a> 
        <ol>
          <li>
            <a href="#sec-Manifest">The <code>Manifest</code> Element</a>
          </li>
          <li>
            <a href="#sec-SignatureProperties">The <code>SignatureProperties</code>
            Element</a>
          </li>
          <li>
            <a href="#sec-PI">Processing Instructions</a>
          </li>
          <li>
            <a href="#sec-comments">Comments in dsig Elements</a>
          </li>
        </ol>
      </li>
      <li>
        <a href="#sec-Algorithms">Algorithms</a> 
        <ol>
          <li>
            <a href="#sec-AlgID">Algorithm Identifiers and Implementation
            Requirements</a>
          </li>
          <li>
            <a href="#sec-MessageDigests">Message Digests</a>
          </li>
          <li>
            <a href="#sec-MACs">Message Authentication Codes</a>
          </li>
          <li>
            <a href="#sec-SignatureAlg">Signature Algorithms</a>
          </li>
          <li>
            <a href="#sec-c14nAlg">Canonicalization Algorithms</a>
          </li>
          <li>
            <a href="#sec-TransformAlg">Transform Algorithms</a> 
            <ol>
              <li>
                <a href="#sec-Canonicalization">Canonicalization</a>
              </li>
              <li>
                <a href="#sec-Base-64">Base64</a>
              </li>
              <li>
                <a href="#sec-XPath">XPath Filtering</a>
              </li>
              <li>
                <a href="#sec-EnvelopedSignature">Enveloped Signature Transform</a>
              </li>
              <li>
                <a href="#sec-XSLT">XSLT Transform</a>
              </li>
            </ol>
          </li>
        </ol>
      </li>
      <li>
        <a href="#sec-XML-Canonicalization">XML Canonicalization and Syntax Constraint
        Considerations</a> 
        <ol>
          <li>
            <a href="#sec-XML-1">XML 1.0, Syntax Constraints, and Canonicalization</a>
          </li>
          <li>
            <a href="#sec-DOM-SAX">DOM/SAX Processing and Canonicalization</a>
          </li>
          <li>
            <a href="#sec-NamespaceContext">Namespace Context and Portable
            Signatures</a>
          </li>
        </ol>
      </li>
      <li>
        <a href="#sec-Security">Security Considerations</a> 
        <ol>
          <li>
            <a href="#sec-Security-Transofrms">Transforms</a> 
            <ol>
              <li>
                <a href="#sec-Secure">Only What is Signed is Secure</a>
              </li>
              <li>
                <a href="#sec-Seen">Only What is "Seen" Should be Signed</a>
              </li>
              <li>
                <a href="#sec-See">"See" What is Signed</a>
              </li>
            </ol>
          </li>
          <li>
            <a href="#sec-Check">Check the Security Model</a>
          </li>
          <li>
            <a href="#sec-KeyLength">Algorithms, Key Lengths, Etc.</a>
          </li>
        </ol>
      </li>
      <li>
        <a href="#sec-Schema">Schema, DTD, Data Model, and Valid Examples</a>
      </li>
      <li>
        <a href="#sec-Definitions">Definitions</a>
      </li>
      <li>
        <a href="#sec-References">References</a>
      </li>
      <li>
        <a href="#sec-Authors">Authors' Address</a>
      </li>
    </ol>
    <hr />
    <h2>
      1.0 <a id="sec-Introduction" name="sec-Introduction">Introduction</a>
    </h2>
    <p>
      This document specifies XML syntax and processing rules for creating and
      representing digital signatures. XML Signatures can be applied to any <a
      href="#def-DataObject" class="link-def">digital content (data object)</a>,
      including XML. An XML Signature may be applied to the content of one or more
      resources. <a href="#def-SignatureEnveloped" class="link-def">Enveloped</a> or <a
      href="#def-SignatureEnveloping" class="link-def">enveloping</a> signatures are
      over data within the same XML document as the signature; <a
      href="#def-SignatureDetached" class="link-def">detached</a> signatures are over
      data&nbsp;external to the signature element. More specifically, this
      specification defines an XML signature element type and an <a
      href="#def-SignatureApplication" class="link-def">XML signature application</a>;
      conformance requirements for each are specified by way of schema definitions and
      prose respectively. This specification also includes other useful types that
      identify methods for referencing collections of resources, algorithms, and keying
      and management information.
    </p>
    <p>
      The XML Signature is a method of associating a key with referenced data (octets);
      it does not normatively specify how keys are associated with persons or
      institutions, nor the meaning of the data being referenced and signed.
      Consequently, while this specification is an important component of secure XML
      applications, it itself is not sufficient to address all application
      security/trust concerns, particularly with respect to using signed XML (or other
      data formats) as a basis of human-to-human communication and agreement. Such an
      application must specify additional key, algorithm, processing and rendering
      requirements. For further information, please see <a
      href="#sec-Security">Security Considerations</a> (section 8).
    </p>
    <h3>
      1.1 <a id="sec-Editorial" name="sec-Editorial">Editorial</a> and Conformance
      Conventions
    </h3>
    <p>
      For readability, brevity, and historic reasons this document uses the term
      "signature" to generally refer to digital authentication values of all types.
      Obviously, the term is also strictly used to refer to authentication values that
      are based on public keys and that provide signer authentication. When
      specifically discussing authentication values based on symmetric secret key codes
      we use the terms authenticators or authentication codes. (See <a
      href="#sec-Check">Check the Security Model</a>, section 8.3.)
    </p>
    <p>
      This specification provides an XML Schema [<a
      href="#ref-XML-schema">XML-schema</a>] and DTD [<a href="#ref-XML">XML</a>]. The
      schema definition is normative.
    </p>
    <p>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
      "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to
      be interpreted as described in <a
      href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a> [<a
      href="#ref-KEYWORDS">KEYWORDS</a>]:
    </p>
    <blockquote>
      <p>
        "they MUST only be used where it is actually required for interoperation or to
        limit behavior which has potential for causing harm (e.g., limiting
        retransmissions)"
      </p>
    </blockquote>
    <p>
      Consequently, we use these capitalized key words to unambiguously specify
      requirements over protocol and application features and behavior that affect the
      interoperability and security of implementations. These key words are not used
      (capitalized) to describe XML grammar; schema definitions unambiguously describe
      such requirements and we wish to reserve the prominence of these terms for the
      natural language descriptions of protocols and features. For instance, an XML
      attribute might be described as being "optional." Compliance with the Namespaces
      in XML specification [<a href="#ref-XML-ns">XML-ns</a>] is described as
      "REQUIRED."
    </p>
    <h3>
      1.2 <a id="sec-Design" name="sec-Design">Design</a> Philosophy
    </h3>
    <p>
      The design philosophy and requirements of this specification are addressed in the
      XML-Signature Requirements document [<a
      href="#ref-XML-Signature-RD">XML-Signature-RD</a>].
    </p>
    <h3>
      1.3 <a id="sec-Versions" name="sec-Versions">Versions</a>, Namespaces and
      Identifiers
    </h3>
    <p>
      No provision is made for an explicit version number in this syntax. If a future
      version is needed, it will use a different namespace. The XML namespace [<a
      href="#ref-XML-ns">XML-ns</a>] URI that MUST be used by implementations of this
      (dated) specification is:
    </p>
<pre class="xml-example">
   xmlns="http://www.w3.org/2000/09/xmldsig#"
</pre>
    <p>
      This namespace is also used as the prefix for algorithm identifiers used by this
      specification. While applications MUST support XML and XML namespaces, the use of
      <a href="http://www.w3.org/TR/REC-xml#sec-internal-ent">internal entities</a> [<a
      href="#ref-XML">XML</a>] or our "dsig" XML <a
      href="http://www.w3.org/TR/1999/REC-xml-names-19990114/#dt-prefix">namespace
      prefix</a> and defaulting/scoping conventions are OPTIONAL; we use these
      facilities to provide compact and readable examples.
    </p>
    <p>
      This specification uses Uniform&nbsp;Resource Identifiers [<a
      href="#ref-URI">URI</a>] to identify resources, algorithms, and semantics. The
      URI in the namespace declaration above is also used as a prefix for URIs under
      the control of this specification. For resources not under the control of this
      specification, we use the designated Uniform Resource Names [<a
      href="#ref-URN">URN</a>] or Uniform Resource Locators [<a
      href="#ref-URL">URL</a>] defined by its normative external specification. If an
      external specification has not allocated itself a Uniform Resource Identifier we
      allocate an identifier under our own namespace. For instance:
    </p>
    <dl>
      <dt>
        <code>SignatureProperties</code> is identified and defined by this
        specification's namespace
      </dt>
      <dd>
        http://www.w3.org/2000/09/xmldsig#<span
        style="font-weight: normal">SignatureProperties</span>
      </dd>
      <dt>
        <span style="font-weight: normal">XSLT is identified and defined by an external
        URI</span>
      </dt>
      <dd>
        http://www.w3.org/TR/1999/REC-xslt-19991116
      </dd>
      <dt>
        SHA1 is identified via this specification's namespace and defined via a
        normative reference
      </dt>
      <dd>
        http://www.w3.org/2000/09/xmldsig#sha1
      </dd>
      <dd>
        FIPS PUB 180-1. <em>Secure Hash Standard.</em> U.S. Department of
        Commerce/National Institute of Standards and Technology.
      </dd>
    </dl>
    <p>
      Finally, in order to provide for terse namespace declarations we sometimes use <a
      href="http://www.w3.org/TR/REC-xml#sec-internal-ent">XML internal entities</a>
      [<a href="#ref-XML">XML</a>] within URIs. For instance:
    </p>
<pre class="xml-example">
   &lt;?xml version='1.0'?&gt;
   &lt;!DOCTYPE Signature SYSTEM 
     "xmldsig-core-schema.dtd" [ &lt;!ENTITY dsig
     "http://www.w3.org/2000/09/xmldsig#"&gt; ]&gt;
   &lt;Signature xmlns="&amp;dsig;" Id="MyFirstSignature"&gt;
     &lt;SignedInfo&gt;
     ...
</pre>
    <h3>
      1.4 <a id="sec-Acknowledgements" name="sec-Acknowledgements">Acknowledgements</a>
    </h3>
    <p>
      The contributions of the following Working Group members to this specification
      are gratefully acknowledged:
    </p>
    <ul>
      <li>
        Mark Bartel, Accelio (Author)
      </li>
      <li>
        John Boyer, PureEdge (Author)
      </li>
      <li>
        Mariano P. Consens, University of Waterloo
      </li>
      <li>
        John Cowan, Reuters Health
      </li>
      <li>
        Donald Eastlake 3rd, Motorola&nbsp; (Chair, Author/Editor)
      </li>
      <li>
        Barb Fox, Microsoft (Author)
      </li>
      <li>
        Christian Geuer-Pollmann, University Siegen
      </li>
      <li>
        Tom Gindin, IBM
      </li>
      <li>
        Phillip Hallam-Baker, VeriSign Inc
      </li>
      <li>
        Richard Himes, US Courts
      </li>
      <li>
        Merlin Hughes, Baltimore
      </li>
      <li>
        Gregor Karlinger, IAIK TU Graz
      </li>
      <li>
        Brian LaMacchia, Microsoft (Author)
      </li>
      <li>
        Peter Lipp, IAIK TU Graz
      </li>
      <li>
        Joseph Reagle, W3C (Chair, Author/Editor)
      </li>
      <li>
        Ed Simon, XMLsec (Author)
      </li>
      <li>
        David Solo, Citigroup (Author/Editor)
      </li>
      <li>
        Petteri Stenius, Capslock
      </li>
      <li>
        Raghavan Srinivas, Sun
      </li>
      <li>
        Kent Tamura, IBM
      </li>
      <li>
        Winchel Todd Vincent III, GSU
      </li>
      <li>
        Carl Wallace, Corsec Security, Inc.
      </li>
      <li>
        Greg Whitehead, Signio Inc.
      </li>
    </ul>
    <p>
      As are the Last Call comments from the following:
    </p>
    <ul>
      <li>
        Dan Connolly, W3C
      </li>
      <li>
        Paul Biron, Kaiser Permanente, on behalf of the <a
        href="http://www.w3.org/XML/Schema.html">XML Schema WG</a>.
      </li>
      <li>
        Martin J. Duerst, W3C; and Masahiro Sekiguchi, Fujitsu; on behalf of the <a
        href="http://www.w3.org/International/">Internationalization WG/IG</a>.
      </li>
      <li>
        Jonathan Marsh, Microsoft, on behalf of the <a
        href="http://www.w3.org/Style/XSL/">Extensible Stylesheet Language WG</a>.
      </li>
    </ul>
    <h2>
      2.0 <a id="sec-Overview" name="sec-Overview">Signature Overview</a> and Examples
    </h2>
    <p>
      This section provides an overview and examples of XML digital signature syntax.
      The specific processing is given in <a
      href="http://www.w3.org/TR/2000/WD-xmldsig-core-20000104/#sec-Processing">Processing
      Rules</a> (section 3). The formal syntax is found in <a
      href="#sec-CoreSyntax">Core Signature Syntax</a> (section 4) and <a
      href="#sec-AdditionalSyntax">Additional Signature Syntax</a> (section 5).
    </p>
    <p>
      In this section, an&nbsp;informal representation and examples are used to
      describe the structure of the XML signature syntax. This representation and
      examples may omit attributes, details and potential features that are fully
      explained later.
    </p>
    <p>
      XML Signatures are applied to arbitrary <a href="#def-DataObject"
      class="link-def">digital content (data objects)</a> via an indirection. Data
      objects are digested, the resulting value is placed in an element (with other
      information) and that element is then digested and cryptographically signed. XML
      digital signatures are represented by the <code>Signature</code> element which
      has the following structure (where "?" denotes zero or one occurrence; "+"
      denotes one or more occurrences; and "*" denotes zero or more occurrences):
    </p>
<pre class="xml-example">
  &lt;Signature ID?&gt; 
     &lt;SignedInfo&gt;
       &lt;CanonicalizationMethod/&gt;
       &lt;SignatureMethod/&gt;
       (&lt;Reference URI? &gt;
         (&lt;Transforms&gt;)?
         &lt;DigestMethod&gt;
         &lt;DigestValue&gt;
       &lt;/Reference&gt;)+
     &lt;/SignedInfo&gt;
     &lt;SignatureValue&gt; 
    (&lt;KeyInfo&gt;)?
    (&lt;Object ID?&gt;)*
   &lt;/Signature&gt;
</pre>
    <p>
      Signatures are related to <a href="#def-DataObject" class="link-def">data
      objects</a> via URIs [<a href="#ref-URI">URI</a>]. Within an XML document,
      signatures are related to local data objects via fragment identifiers. Such local
      data can be included within an <a href="#def-SignatureEnveloping"
      class="link-def">enveloping</a> signature or can enclose an <a
      href="#def-SignatureEnveloped" class="link-def">enveloped</a> signature. <a
      href="#def-SignatureDetached" class="link-def">Detached signatures</a> are over
      external network resources or local data objects that reside within the same XML
      document as sibling elements; in this case, the signature is neither enveloping
      (signature is parent) nor enveloped (signature is child). Since a
      <code>Signature</code> element (and its <code>Id</code> attribute value/name) may
      co-exist or be combined with other elements (and their IDs) within a single XML
      document, care should be taken in choosing names such that there are no
      subsequent collisions that violate the <a
      href="http://www.w3.org/TR/REC-xml#id">ID uniqueness validity constraint</a> [<a
      href="#ref-XML">XML</a>].
    </p>
    <h3>
      2.1 <a id="sec-o-Simple" name="sec-o-Simple">Simple Example</a>
      (<code>Signature</code>, <code>SignedInfo</code>, <code>Methods</code>, and
      <code>Reference</code>)s
    </h3>
    <p>
      The following example is a detached signature of the content of the HTML4 in XML
      specification.
    </p>
<pre class="xml-example">
   [s01] &lt;Signature Id="MyFirstSignature"
 xmlns="http://www.w3.org/2000/09/xmldsig#"&gt; 
   [s02]   &lt;SignedInfo&gt; 
   [s03]   &lt;CanonicalizationMethod
 Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/&gt; 
   [s04]   &lt;SignatureMethod
 Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/&gt; 
   [s05]   &lt;Reference
 URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"&gt; 
   [s06]     &lt;Transforms&gt; 
   [s07]       &lt;Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/&gt; 
   [s08]     &lt;/Transforms&gt; 
   [s09]     &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt; 
   [s10]     &lt;DigestValue&gt;j6lwx3rvEPO0vKtMup4NbeVu8nk=&lt;/DigestValue&gt; 
   [s11]   &lt;/Reference&gt; 
   [s12] &lt;/SignedInfo&gt; 
   [s13]   &lt;SignatureValue&gt;MC0CFFrVLtRlk=...&lt;/SignatureValue&gt; 
   [s14]   &lt;KeyInfo&gt; 
   [s15a]    &lt;KeyValue&gt;
   [s15b]      &lt;DSAKeyValue&gt; 
   [s15c]        &lt;P&gt;...&lt;/P&gt;&lt;Q&gt;...&lt;/Q&gt;&lt;G&gt;...&lt;/G&gt;&lt;Y&gt;...&lt;/Y&gt; 
   [s15d]      &lt;/DSAKeyValue&gt; 
   [s15e]    &lt;/KeyValue&gt; 
   [s16]   &lt;/KeyInfo&gt; 
   [s17] &lt;/Signature&gt;
</pre>
    <p>
      <code>[s02-12]</code> The required <code>SignedInfo</code> element is the
      information that is actually signed. <a href="#def-ValidationCore"
      class="link-def">Core validation</a> of <code>SignedInfo</code> consists of two
      mandatory processes: <a href="#def-ValidationSignature"
      class="link-def">validation of the signature</a> over <code>SignedInfo</code> and
      <a href="#def-ValidationReference" class="link-def">validation of each
      <code>Reference</code></a> digest within <code>SignedInfo</code>. Note that the
      algorithms used in calculating the <code>SignatureValue</code> are also included
      in the signed information while the <code>SignatureValue</code> element is
      outside <code>SignedInfo</code>.
    </p>
    <p>
      <code>[s03]</code> The <code>CanonicalizationMethod</code> is the algorithm that
      is used to canonicalize the <code>SignedInfo</code> element before it is digested
      as part of the signature operation. Note that this example, and all examples in
      this specification, are not in canonical form.
    </p>
    <p>
      <code>[s04]</code> The <code>SignatureMethod</code> is the algorithm that is used
      to convert the canonicalized <code>SignedInfo</code> into the
      <code>SignatureValue</code>. It is a combination of a digest algorithm and a key
      dependent algorithm and possibly other algorithms such as padding, for example
      RSA-SHA1. The algorithm names are signed to resist attacks based on substituting
      a weaker algorithm. To promote application interoperability we specify a set of
      signature algorithms that MUST be implemented, though their use is at the
      discretion of the signature creator. We specify additional algorithms as
      RECOMMENDED or OPTIONAL for implementation; the design also permits arbitrary
      user specified algorithms.
    </p>
    <p>
      <code>[s05-11]</code> Each <code>Reference</code> element includes the digest
      method and resulting digest value calculated over the identified data object. It
      also may include transformations that produced the input to the digest operation.
      A data object is signed by computing its digest value and a signature over that
      value. The signature is later checked via <a href="#def-ValidationReference"
      class="link-def">reference</a> and <a href="#def-ValidationSignature"
      class="link-def">signature validation</a>.
    </p>
    <p>
      <code>[s14-16]</code> <code>KeyInfo</code> indicates the key to be used to
      validate the signature. Possible forms for identification include certificates,
      key names, and key agreement algorithms and information -- we define only a few.
      <code>KeyInfo</code> is optional for two reasons. First, the signer may not wish
      to reveal key information to all document processing parties. Second, the
      information may be known within the application's context and need not be
      represented explicitly. Since <code>KeyInfo</code> is outside of
      <code>SignedInfo</code>, if the signer wishes to bind the keying information to
      the signature, a <code>Reference</code> can easily identify and include the
      <code>KeyInfo</code> as part of the signature.
    </p>
    <h3>
      2.1.1 More on <a id="sec-o-Reference"
      name="sec-o-Reference"><code>Reference</code></a>
    </h3>
<pre class="xml-example">
   [s05]   &lt;Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"&gt; 
   [s06]     &lt;Transforms&gt; 
   [s07]       &lt;Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/&gt; 
   [s08]     &lt;/Transforms&gt; 
   [s09]     &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt; 
   [s10]     &lt;DigestValue&gt;j6lwx3rvEPO0vKtMup4NbeVu8nk=&lt;/DigestValue&gt; 
   [s11]   &lt;/Reference&gt;
</pre>
    <p>
      <code>[s05]</code> The optional <code>URI</code> attribute of
      <code>Reference</code> identifies the data object to be signed. This attribute
      may be omitted on at most one <code>Reference</code> in a <code>Signature</code>.
      (This limitation is imposed in order to ensure that references and objects may be
      matched unambiguously.)
    </p>
    <p>
      <code>[s05-08]</code> This identification, along with the transforms, is a
      description provided by the signer on how they obtained the signed data object in
      the form it was digested (i.e. the digested content). The verifier may obtain the
      digested content in another method so long as the digest verifies. In particular,
      the verifier may obtain the content from a different location such as a local
      store than that specified in the <code>URI</code>.
    </p>
    <p>
      <code>[s06-08] Transforms</code> is an optional ordered list of processing steps
      that were applied to the resource's content before it was digested. Transforms
      can include operations such as canonicalization, encoding/decoding (including
      compression/inflation), XSLT, XPath, XML schema validation, or XInclude. XPath
      transforms permit the signer to derive an XML document that omits portions of the
      source document. Consequently those excluded portions can change without
      affecting signature validity. For example, if the resource being signed encloses
      the signature itself, such a transform must be used to exclude the signature
      value from its own computation. If no <code>Transforms</code> element is present,
      the resource's content is digested directly. While the Working Group has
      specified mandatory (and optional) canonicalization and decoding algorithms, user
      specified transforms are permitted.
    </p>
    <p>
      <code>[s09-10] DigestMethod</code> is the algorithm applied to the data after
      <code>Transforms</code> is applied (if specified) to yield the
      <code>DigestValue</code>. The signing of the <code>DigestValue</code> is what
      binds a resources content to the signer's key.
    </p>
    <h3>
      2.2 Extended Example (<code>Object</code> and <a id="sec-o-SignatureProperty"
      name="sec-o-SignatureProperty"><code>SignatureProperty</code></a>)
    </h3>
    <p>
      This specification does not address mechanisms for making statements or
      assertions. Instead, this document defines what it means for something to be
      signed by an XML Signature (<a href="#def-Integrity"
      class="link-def">integrity</a>, <a href="#def-AuthenticationMessage"
      class="link-def">message authentication</a>, and/or <a
      href="#def-AuthenticationSigner" class="link-def">signer authentication</a>).
      Applications that wish to represent other semantics must rely upon other
      technologies, such as [<a href="#ref-XML">XML</a>, <a href="#ref-RDF">RDF</a>].
      For instance, an application might use a <code>foo:assuredby</code> attribute
      within its own markup to reference a <code>Signature</code> element.
      Consequently, it's the application that must understand and know how to make
      trust decisions given the validity of the signature and the meaning of
      <code>assuredby</code> syntax. We also define a <code>SignatureProperties</code>
      element type for the inclusion of assertions about the signature itself (e.g.,
      signature semantics, the time of signing or the serial number of hardware used in
      cryptographic processes). Such assertions may be signed by including a
      <code>Reference</code> for the <code>SignatureProperties</code> in
      <code>SignedInfo</code>. While the signing application should be very careful
      about what it signs (it should understand what is in the
      <code>SignatureProperty</code>) a receiving application has no obligation to
      understand that semantic (though its parent trust engine may wish to). Any
      content about the signature generation may be located within the
      <code>SignatureProperty</code> element. The mandatory <code>Target</code>
      attribute references the <code>Signature</code> element to which the property
      applies.
    </p>
    <p>
      Consider the preceding example with an additional reference to a local
      <code>Object</code> that includes a <code>SignatureProperty</code> element. (Such
      a signature would not only be <a href="#def-SignatureDetached"
      class="link-def">detached</a> <code>[p02]</code> but <a
      href="#def-SignatureEnveloping" class="link-def">enveloping</a>
      <code>[p03]</code>.)
    </p>
<pre class="xml-example">
   [   ]  &lt;Signature Id="MySecondSignature" ...&gt;
   [p01]  &lt;SignedInfo&gt;  
   [   ]   ...  
   [p02]   &lt;Reference URI="http://www.w3.org/TR/xml-stylesheet/"&gt;   
   [   ]   ... 
   [p03]   &lt;Reference URI="#AMadeUpTimeStamp"  
   [p04]         Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"&gt;  
   [p05]    &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt;    
   [p06]    &lt;DigestValue&gt;k3453rvEPO0vKtMup4NbeVu8nk=&lt;/DigestValue&gt;
   [p07]   &lt;/Reference&gt;    
   [p08]  &lt;/SignedInfo&gt;  
   [p09]  ...  
   [p10]  &lt;Object&gt; 
   [p11]   &lt;SignatureProperties&gt; 
   [p12]     &lt;SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature"&gt; 
   [p13]        &lt;timestamp xmlns="http://www.ietf.org/rfcXXXX.txt"&gt;  
   [p14]          &lt;date&gt;19990908&lt;/date&gt;  
   [p15]          &lt;time&gt;14:34:34:34&lt;/time&gt;  
   [p16]        &lt;/timestamp&gt;  
   [p17]     &lt;/SignatureProperty&gt; 
   [p18]   &lt;/SignatureProperties&gt; 
   [p19]  &lt;/Object&gt;  
   [p20]&lt;/Signature&gt;
</pre>
    <p>
      <code>[p04]</code> The optional <code>Type</code> attribute of
      <code>Reference</code> provides information about the resource identified by the
      <code>URI</code>. In particular, it can indicate that it is an
      <code>Object</code>, <code>SignatureProperty</code>, or <code>Manifest</code>
      element. This can be used by applications to initiate special processing of some
      <code>Reference</code> elements. References to an XML data element within an
      <code>Object</code> element SHOULD identify the actual element pointed to. Where
      the element content is not XML (perhaps it is binary or encoded data) the
      reference should identify the <code>Object</code> and the <code>Reference</code>
      <code>Type</code>, if given, SHOULD indicate <code>Object</code>. Note that
      <code>Type</code> is advisory and no action based on it or checking of its
      correctness is required by core behavior.
    </p>
    <p>
      <code>[p10]</code> <code>Object</code> is an optional element for including data
      objects within the signature element or elsewhere. The <code>Object</code> can be
      optionally typed and/or encoded.
    </p>
    <p>
      <code>[p11-18]</code> Signature properties, such as time of signing, can be
      optionally signed by identifying them from within a <code>Reference</code>.
      (These properties are traditionally called signature "attributes" although that
      term has no relationship to the XML term "attribute".)
    </p>
    <h3>
      2.3 Extended Example (<code>Object</code> and <a id="sec-o-Manifest"
      name="sec-o-Manifest"><code>Manifest</code></a>)
    </h3>
    <p>
      The <code>Manifest</code> element is provided to meet additional requirements not
      directly addressed by the mandatory parts of this specification. Two requirements
      and the way the <code>Manifest</code> satisfies them follow.
    </p>
    <p>
      First, applications frequently need to efficiently sign multiple data objects
      even where the signature operation itself is an expensive public key signature.
      This requirement can be met by including multiple <code>Reference</code> elements
      within <code>SignedInfo</code> since the inclusion of each digest secures the
      data digested. However, some applications may not want the <a
      href="#def-ValidationCore" class="link-def">core validation</a> behavior
      associated with this approach because it requires every <code>Reference</code>
      within <code>SignedInfo</code> to undergo <a href="#def-ValidationReference"
      class="link-def">reference validation</a> -- the <code>DigestValue</code>
      elements are checked. These applications may wish to reserve reference validation
      decision logic to themselves. For example, an application might receive a <a
      href="#def-ValidationSignature" class="link-def">signature valid</a>
      <code>SignedInfo</code> element that includes three <code>Reference</code>
      elements. If a single <code>Reference</code> fails (the identified data object
      when digested does not yield the specified <code>DigestValue</code>) the
      signature would fail <a href="#def-ValidationCore" class="link-def">core
      validation</a>. However, the application may wish to treat the signature over the
      two valid <code>Reference</code> elements as valid or take different actions
      depending on which fails.&nbsp; To accomplish this, <code>SignedInfo</code> would
      reference a <code>Manifest</code> element that contains one or more
      <code>Reference</code> elements (with the same structure as those in
      <code>SignedInfo</code>). Then, reference validation of the <code>Manifest</code>
      is under application control.
    </p>
    <p>
      Second, consider an application where many signatures (using different keys) are
      applied to a large number of documents. An inefficient solution is to have a
      separate signature (per key) repeatedly applied to a large
      <code>SignedInfo</code> element (with many <code>Reference</code>s); this is
      wasteful and redundant. A more efficient solution is to include many references
      in a single <code>Manifest</code> that is then referenced from multiple
      <code>Signature</code> elements.
    </p>
    <p>
      The example below includes a <code>Reference</code> that signs a
      <code>Manifest</code> found within the <code>Object</code> element.
    </p>
<pre class="xml-example">
   [   ] ...
   [m01]   &lt;Reference URI="#MyFirstManifest"
   [m02]     Type="http://www.w3.org/2000/09/xmldsig#Manifest"&gt;
   [m03]     &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt; 
   [m04]     &lt;DigestValue&gt;345x3rvEPO0vKtMup4NbeVu8nk=&lt;/DigestValue&gt; 
   [m05]   &lt;/Reference&gt;  
   [   ] ...
   [m06] &lt;Object&gt;
   [m07]   &lt;Manifest Id="MyFirstManifest"&gt;
   [m08]     &lt;Reference&gt;
   [m09]     ...
   [m10]     &lt;/Reference&gt;   
   [m11]     &lt;Reference&gt;
   [m12]     ...
   [m13]     &lt;/Reference&gt;
   [m14]   &lt;/Manifest&gt;
   [m15] &lt;/Object&gt;
</pre>
    <h2>
      3.0 <a id="sec-Processing" name="sec-Processing">Processing</a> Rules
    </h2>
    <p>
      The sections below describe the operations to be performed as part of signature
      generation and validation.
    </p>
    <h3>
      3.1 Core <a id="sec-CoreGeneration" name="sec-CoreGeneration">Generation</a>
    </h3>
    <p>
      The REQUIRED steps include the generation of <code>Reference</code> elements and
      the <code>SignatureValue</code> over <code>SignedInfo</code>.
    </p>
    <h4>
      3.1.1 <a id="sec-ReferenceGeneration" name="sec-ReferenceGeneration">Reference
      Generation</a>
    </h4>
    <p>
      For each data object being signed:
    </p>
    <ol>
      <li>
        Apply the <code>Transforms</code>, as determined by the application, to the
        data object.
      </li>
      <li>
        Calculate the digest value over the resulting data object.
      </li>
      <li>
        Create a <code>Reference</code> element, including the (optional)
        identification of the data object, any (optional) transform elements, the
        digest algorithm and the <code>DigestValue</code>. (Note, it is the canonical
        form of these references that are signed in 3.1.2 and validated in 3.2.1 .)
      </li>
    </ol>
    <h4>
      3.1.2 <a id="sec-SignatureGeneration" name="sec-SignatureGeneration">Signature
      Generation</a>
    </h4>
    <ol>
      <li>
        Create <code>SignedInfo</code> element with <code>SignatureMethod</code>,
        <code>CanonicalizationMethod</code> and <code>Reference</code>(s).
      </li>
      <li>
        Canonicalize and then calculate the <code>SignatureValue</code> over
        <code>SignedInfo</code> based on algorithms specified in
        <code>SignedInfo</code>.
      </li>
      <li>
        Construct the <code>Signature</code> element that includes
        <code>SignedInfo</code>, <code>Object</code>(s) (if desired, encoding may be
        different than that used for signing), <code>KeyInfo</code> (if required), and
        <code>SignatureValue</code>. 
        <p>
          Note, if the <code>Signature</code> includes same-document references, [<a
          href="#ref-XML">XML</a>] or [<a href="#ref-XML-schema">XML-schema</a>]
          validation of the document might introduce changes that break the signature.
          Consequently, applications should be careful to consistently process the
          document or refrain from using external contributions (e.g., defaults and
          entities).
        </p>
      </li>
    </ol>
    <h3>
      3.2 Core <a id="sec-CoreValidation" name="sec-CoreValidation">Validation</a>
    </h3>
    <p>
      The REQUIRED steps of <a href="#def-ValidationCore" class="link-def">core
      validation</a> include (1) <a href="#def-ValidationReference"
      class="link-def">reference validation</a>, the verification of the digest
      contained in each <code>Reference</code> in <code>SignedInfo</code>, and (2) the
      cryptographic <a href="#def-ValidationSignature" class="link-def">signature
      validation</a> of the signature calculated over <code>SignedInfo</code>.
    </p>
    <p>
      Note, there may be valid signatures that some signature applications are unable
      to validate. Reasons for this include failure to implement optional parts of this
      specification, inability or unwillingness to execute specified algorithms, or
      inability or unwillingness to dereference specified URIs (some URI schemes may
      cause undesirable side effects), etc.
    </p>
    <p>
      Comparison of values in reference and signature validation are over the numeric
      (e.g., integer) or decoded octet sequence of the value. Different implementations
      may produce different encoded digest and signature values when processing the
      same resources because of variances in their encoding, such as accidental white
      space. But if one uses numeric or octet comparison (choose one) on both the
      stated and computed values these problems are eliminated.
    </p>
    <h4>
      3.2.1 <a id="sec-ReferenceValidation" name="sec-ReferenceValidation">Reference
      Validation</a>
    </h4>
    <ol>
      <li>
        Canonicalize the <code>SignedInfo</code> element based on the
        <code>CanonicalizationMethod</code> in <code>SignedInfo</code>.
      </li>
      <li>
        For each <code>Reference</code> in <code>SignedInfo</code>: 
        <ol>
          <li>
            Obtain the data object to be digested. (For example, the signature
            application may dereference the <code>URI</code> and execute
            <code>Transforms</code> provided by the signer in the
            <code>Reference</code> element, or it may obtain the content through other
            means such as a local cache.)
          </li>
          <li>
            Digest the resulting data object using the <code>DigestMethod</code>
            specified in its <code>Reference</code> specification.
          </li>
          <li>
            Compare the generated digest value against <code>DigestValue</code> in the
            <code>SignedInfo</code> <code>Reference</code>; if there is any mismatch,
            validation fails.
          </li>
        </ol>
      </li>
    </ol>
    <p>
      Note, <code>SignedInfo</code> is canonicalized in step 1. The application must
      ensure that the CanonicalizationMethod has no dangerous side affects, such as
      rewriting URIs, (see <code><a
      href="#sec-CanonicalizationMethod-NOTE">CanonicalizationMethod</a></code>
      (section 4.3)) and that it <a href="#sec-See">Sees What is Signed</a>, which is
      the canonical form.
    </p>
    <h4>
      3.2.2 <a id="sec-SignatureValidation" name="sec-SignatureValidation">Signature
      Validation</a>
    </h4>
    <ol>
      <li>
        Obtain the keying information from <code><a
        href="#sec-KeyInfo">KeyInfo</a></code> or from an external source.
      </li>
      <li>
        Obtain the canonical form of the <code>SignatureMethod</code> using the
        <code>CanonicalizationMethod</code> and use the&nbsp;result (and previously
        obtained <code>KeyInfo</code>) to confirm the <code>SignatureValue</code> over
        the <code>SignedInfo</code> element.
      </li>
    </ol>
    <p>
      Note, <code><a href="#sec-KeyInfo">KeyInfo</a></code> (or some transformed
      version thereof) may be signed via a <code>Reference</code> element.
      Transformation and validation of this reference (3.2.1) is orthogonal to
      Signature Validation which uses the <code>KeyInfo</code> as parsed.
    </p>
    <p>
      Additionally, the <code>SignatureMethod</code> URI may have been altered by the
      canonicalization of <code>SignedInfo</code> (e.g., absolutization of relative
      URIs) and it is the canonical form that MUST be used. However, the required
      canonicalization [<a href="#ref-XML-C14N">XML-C14N</a>] of this specification
      does not change URIs.
    </p>
    <h2>
      4.0 <a id="sec-CoreSyntax" name="sec-CoreSyntax">Core Signature Syntax</a>
    </h2>
    <p>
      The general structure of an XML signature is described in <a
      href="#sec-Overview">Signature Overview</a> (section 2). This section provides
      detailed syntax of the core signature features. Features described in this
      section are mandatory to implement unless otherwise indicated. The syntax is
      defined via DTDs and [<a href="#ref-XML-schema">XML-Schema</a>] with the
      following XML preamble, declaration, and internal entity.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;?xml version="1.0" encoding="utf-8"?&gt;
   &lt;!DOCTYPE schema
     PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd"
    [
      &lt;!ATTLIST schema 
        xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#"&gt;
      &lt;!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'&gt; 
      &lt;!ENTITY % p ''&gt;
      &lt;!ENTITY % s ''&gt;
     ]&gt;

   &lt;schema xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
           targetNamespace="http://www.w3.org/2000/09/xmldsig#"
           version="0.1" elementFormDefault="qualified"&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!--

   The following entity declarations enable external/flexible content in
   the Signature content model.

   #PCDATA emulates schema:string; when combined with element types it
   emulates schema mixed="true".

   %foo.ANY permits the user to include their own element types from
   other namespaces, for example:
     &lt;!ENTITY % KeyValue.ANY '| ecds:ECDSAKeyValue'&gt;
     ...
     &lt;!ELEMENT ecds:ECDSAKeyValue (#PCDATA)  &gt;

   --&gt;

   &lt;!ENTITY % Object.ANY ''&gt;
   &lt;!ENTITY % Method.ANY ''&gt;
   &lt;!ENTITY % Transform.ANY ''&gt;
   &lt;!ENTITY % SignatureProperty.ANY ''&gt;
   &lt;!ENTITY % KeyInfo.ANY ''&gt;
   &lt;!ENTITY % KeyValue.ANY ''&gt;
   &lt;!ENTITY % PGPData.ANY ''&gt;
   &lt;!ENTITY % X509Data.ANY ''&gt;
   &lt;!ENTITY % SPKIData.ANY ''&gt;
</pre>
    <h4>
      4.0.1 The ds:<a name="sec-CryptoBinary" id="sec-CryptoBinary">CryptoBinary</a>
      Simple Type
    </h4>
    <p>
      This specification defines the <code>ds:CryptoBinary</code> simple type for
      representing arbitrary-length integers (e.g. "bignums") in XML as octet strings.
      The integer value is first converted to a "big endian" bitstring. The bitstring
      is then padded with leading zero bits so that the total number of bits == 0 mod 8
      (so that there are an integral number of octets). If the bitstring contains
      entire leading octets that are zero, these are removed (so the high-order octet
      is always non-zero). This octet string is then base64 [<a
      href="#ref-MIME">MIME</a>] encoded. (The conversion from integer to octet string
      is equivalent to IEEE 1363's I2OSP [<a href="#ref-1363">1363</a>] with minimal
      length).
    </p>
    <p>
      This type is used by "bignum" values such as <code>RSAKeyValue</code> and
      <code>DSAKeyValue</code>. If a value can be of type <code>base64Binary</code> or
      <code>ds:CryptoBinary</code> they are defined as <a
      href="http://www.w3.org/TR/xmlschema-2/#base64Binary"><code>base64Binary</code></a>.
      For example, if the signature algorithm is RSA or DSA then
      <code>SignatureValue</code> represents a bignum and could be
      <code>ds:CryptoBinary</code>. However, if HMAC-SHA1 is the signature algorithm
      then <code>SignatureValue</code> could have leading zero octets that must be
      preserved. Thus <code>SignatureValue</code> is generically defined as of type
      <code>base64Binary</code>.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;simpleType name="CryptoBinary"&gt;
     &lt;restriction base="base64Binary"&gt;
     &lt;/restriction&gt;
   &lt;/simpleType&gt;
</pre>
    <h3>
      4.1 The <a id="sec-Signature" name="sec-Signature"><code>Signature</code></a>
      element
    </h3>
    <p>
      The <code>Signature</code> element is the root element of an XML Signature.
      Implementation MUST generate <a
      href="http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#cvc-elt-lax">laxly
      schema valid</a> [<a href="#ref-XML-schema">XML-schema</a>]
      <code>Signature</code> elements as specified by the following schema:
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="Signature" type="ds:SignatureType"/&gt;
   &lt;complexType name="SignatureType"&gt;
     &lt;sequence&gt; 
       &lt;element ref="ds:SignedInfo"/&gt; 
       &lt;element ref="ds:SignatureValue"/&gt; 
       &lt;element ref="ds:KeyInfo" minOccurs="0"/&gt; 
       &lt;element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/&gt; 
     &lt;/sequence&gt;  
     &lt;attribute name="Id" type="ID" use="optional"/&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*)  &gt;
   &lt;!ATTLIST Signature  
    xmlns   CDATA   #FIXED 'http://www.w3.org/2000/09/xmldsig#'
    Id      ID  #IMPLIED &gt;
</pre>
    <h3>
      4.2 The <a id="sec-SignatureValue"
      name="sec-SignatureValue"><code>SignatureValue</code></a> Element
    </h3>
    <p>
      The <code>SignatureValue</code> element contains the actual value of the digital
      signature; it is always encoded using base64 [<a href="#ref-MIME">MIME</a>].
      While we identify two <code>SignatureMethod</code> algorithms, one mandatory and
      one optional to implement, user specified algorithms may be used as well.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="SignatureValue" type="ds:SignatureValueType"/&gt; 
   &lt;complexType name="SignatureValueType"&gt;
     &lt;simpleContent&gt;
       &lt;extension base="base64Binary"&gt;
         &lt;attribute name="Id" type="ID" use="optional"/&gt;
       &lt;/extension&gt;
     &lt;/simpleContent&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT SignatureValue (#PCDATA) &gt;
   &lt;!ATTLIST SignatureValue  
             Id  ID      #IMPLIED&gt;
</pre>
    <h3>
      4.3 The <a id="sec-SignedInfo" name="sec-SignedInfo"><code>SignedInfo</code></a>
      Element
    </h3>
    <p>
      The structure of <code>SignedInfo</code> includes the canonicalization algorithm,
      a signature algorithm, and one or more references. The <code>SignedInfo</code>
      element may contain an optional ID attribute that will allow it to be referenced
      by other signatures and objects.
    </p>
    <p>
      <code>SignedInfo</code> does not include explicit signature or digest properties
      (such as calculation time, cryptographic device serial number, etc.). If an
      application needs to associate properties with the signature or digest, it may
      include such information in a <code>SignatureProperties</code> element within an
      <code>Object</code> element.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="SignedInfo" type="ds:SignedInfoType"/&gt; 
   &lt;complexType name="SignedInfoType"&gt;
     &lt;sequence&gt; 
       &lt;element ref="ds:CanonicalizationMethod"/&gt;
       &lt;element ref="ds:SignatureMethod"/&gt; 
       &lt;element ref="ds:Reference" maxOccurs="unbounded"/&gt; 
     &lt;/sequence&gt;  
     &lt;attribute name="Id" type="ID" use="optional"/&gt; 
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT SignedInfo (CanonicalizationMethod, 
    SignatureMethod,  Reference+)  &gt;
   &lt;!ATTLIST SignedInfo  
    Id   ID      #IMPLIED
</pre>
    <h4>
      4.3.1 The <a id="sec-CanonicalizationMethod"
      name="sec-CanonicalizationMethod"><code>CanonicalizationMethod</code></a> Element
    </h4>
    <p>
      <code>CanonicalizationMethod</code> is a required element that specifies the
      canonicalization algorithm applied to the <code>SignedInfo</code> element prior
      to performing signature calculations. This element uses the general structure for
      algorithms described in <a href="#sec-AlgID">Algorithm Identifiers and
      Implementation Requirements</a> (section 6.1). Implementations MUST support the
      REQUIRED <a href="#sec-c14nAlg">canonicalization algorithms</a>.
    </p>
    <p>
      Alternatives to the REQUIRED <a href="#sec-c14nAlg">canonicalization
      algorithms</a> (section 6.5), such as <a href="#sec-Canonical">Canonical XML with
      Comments</a> (section 6.5.1) or a minimal canonicalization (such as CRLF and
      charset normalization), may be explicitly specified but are NOT REQUIRED.
      Consequently, their use may not interoperate with other applications that do not
      support the specified algorithm (see <a href="#sec-XML-Canonicalization">XML
      Canonicalization and Syntax Constraint Considerations</a>, section 7). Security
      issues may also arise in the treatment of entity processing and comments if
      non-XML aware canonicalization algorithms are not properly constrained (see
      section 8.2: <a href="#sec-Seen">Only What is "Seen" Should be Signed</a>).
    </p>
    <p>
      The way in which the <code>SignedInfo</code> element is presented to the
      canonicalization method is dependent on that method. The following applies to
      algorithms which process XML as nodes or characters:
    </p>
    <ul>
      <li>
        XML based canonicalization implementations MUST be provided with a [<a
        href="#ref-XPath">XPath</a>] node-set originally formed from the document
        containing the <code>SignedInfo</code> and currently indicating the
        <code>SignedInfo</code>, its descendants, and the attribute and namespace nodes
        of <code>SignedInfo</code> and its descendant elements.
      </li>
      <li>
        Text based canonicalization algorithms (such as CRLF and charset normalization)
        should be provided with the UTF-8 octets that represent the well-formed
        SignedInfo element, from the first character to the last character of the XML
        representation, inclusive. This includes the entire text of the start and end
        tags of the SignedInfo element as well as all descendant <a
        href="http://www.w3.org/TR/1998/REC-xml-19980210#syntax">markup and character
        data</a> (i.e., the <a
        href="http://www.w3.org/TR/1998/REC-xml-19980210#dt-text">text</a>) between
        those tags. Use of text based canonicalization of SignedInfo is NOT
        RECOMMENDED.
      </li>
    </ul>
    <p>
      We recommend applications that implement a text-based instead of XML-based
      canonicalization -- such as resource constrained apps -- generate canonicalized
      XML as their output serialization so as to mitigate interoperability and security
      concerns. For instance, such an implementation SHOULD (at least) generate <a
      href="http://www.w3.org/TR/REC-xml#sec-rmd">standalone</a> XML instances [<a
      href="#ref-XML">XML</a>].
    </p>
    <p>
      <a name="sec-CanonicalizationMethod-NOTE"
      id="sec-CanonicalizationMethod-NOTE">NOTE</a>: The signature application must
      exercise great care in accepting and executing an arbitrary
      <code>CanonicalizationMethod</code>. For example, the canonicalization method
      could rewrite the URIs of the <code>Reference</code>s being validated. Or, the
      method could massively transform <code>SignedInfo</code> so that validation would
      always succeed (i.e., converting it to a trivial signature with a known key over
      trivial data). Since <code>CanonicalizationMethod</code> is inside
      <code>SignedInfo</code>, in the resulting canonical form it could erase itself
      from <code>SignedInfo</code> or modify the <code>SignedInfo</code> element so
      that it appears that a different canonicalization function was used! Thus a
      <code>Signature</code> which appears to authenticate the desired data with the
      desired key, <code>DigestMethod</code>, and <code>SignatureMethod</code>, can be
      meaningless if a capricious <code>CanonicalizationMethod</code> is used.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/&gt; 
   &lt;complexType name="CanonicalizationMethodType" mixed="true"&gt;
     &lt;sequence&gt;
       &lt;any namespace="##any" minOccurs="0" maxOccurs="unbounded"/&gt;
       &lt;!-- (0,unbounded) elements from (1,1) namespace --&gt;
     &lt;/sequence&gt;
     &lt;attribute name="Algorithm" type="anyURI" use="required"/&gt; 
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT CanonicalizationMethod (#PCDATA %Method.ANY;)* &gt; 
   &lt;!ATTLIST CanonicalizationMethod 
    Algorithm CDATA #REQUIRED &gt;
</pre>
    <h4>
      4.3.2 The <a id="sec-SignatureMethod"
      name="sec-SignatureMethod"><code>SignatureMethod</code></a> Element
    </h4>
    <p>
      <code>SignatureMethod</code> is a required element that specifies the algorithm
      used for signature generation and validation. This algorithm identifies all
      cryptographic functions involved in the signature operation (e.g. hashing, public
      key algorithms, MACs, padding, etc.). This element uses the general structure
      here for algorithms described in section 6.1: <a href="#sec-AlgID">Algorithm
      Identifiers and Implementation Requirements</a>. While there is a single
      identifier, that identifier may specify a format containing multiple distinct
      signature values.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="SignatureMethod" type="ds:SignatureMethodType"/&gt;
   &lt;complexType name="SignatureMethodType" mixed="true"&gt;
     &lt;sequence&gt;
       &lt;element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLengthType"/&gt;
       &lt;any namespace="##other" minOccurs="0" maxOccurs="unbounded"/&gt;
       &lt;!-- (0,unbounded) elements from (1,1) external namespace --&gt;
      &lt;/sequence&gt;
    &lt;attribute name="Algorithm" type="anyURI" use="required"/&gt; 
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT SignatureMethod (#PCDATA|HMACOutputLength %Method.ANY;)* &gt;
   &lt;!ATTLIST SignatureMethod 
    Algorithm CDATA #REQUIRED &gt;
</pre>
    <h4>
      4.3.3 The <a id="sec-Reference" name="sec-Reference"><code>Reference</code></a>
      Element
    </h4>
    <p>
      <code>Reference</code> is an element that may occur one or more times. It
      specifies a digest algorithm and digest value, and optionally an identifier of
      the object being signed, the type of the object, and/or a list of transforms to
      be applied prior to digesting. The identification (URI) and transforms describe
      how the digested content (i.e., the input to the digest method) was created. The
      <code>Type</code> attribute facilitates the processing of referenced data. For
      example, while this specification makes no requirements over external data, an
      application may wish to signal that the referent is a <code>Manifest</code>. An
      optional ID attribute permits a <code>Reference</code> to be referenced from
      elsewhere.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="Reference" type="ds:ReferenceType"/&gt;
   &lt;complexType name="ReferenceType"&gt;
     &lt;sequence&gt; 
       &lt;element ref="ds:Transforms" minOccurs="0"/&gt; 
       &lt;element ref="ds:DigestMethod"/&gt; 
       &lt;element ref="ds:DigestValue"/&gt; 
     &lt;/sequence&gt;
     &lt;attribute name="Id" type="ID" use="optional"/&gt; 
     &lt;attribute name="URI" type="anyURI" use="optional"/&gt; 
     &lt;attribute name="Type" type="anyURI" use="optional"/&gt; 
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT Reference (Transforms?, DigestMethod, DigestValue)  &gt;
   &lt;!ATTLIST Reference  
    Id  ID  #IMPLIED
    URI CDATA   #IMPLIED
    Type    CDATA   #IMPLIED&gt;
</pre>
    <h4>
      4.3.3.1 The <a name="sec-URI" id="sec-URI"><code>URI</code></a> Attribute
    </h4>
    <p>
      The <code>URI</code> attribute identifies a data object using a URI-Reference, as
      specified by RFC2396 [<a href="#ref-URI">URI</a>]. The set of allowed characters
      for <code>URI</code> attributes is the same as for XML, namely <a
      href="#ref-Unicode">[Unicode]</a>. However, some Unicode characters are
      disallowed from URI references including all non-ASCII characters and the
      excluded characters listed in RFC2396 [<a href="#ref-URI">URI</a>, section 2.4].
      However, the number sign (#), percent sign (%), and square bracket characters
      re-allowed in RFC 2732 [<a href="#ref-URI-Literal">URI-Literal</a>] are
      permitted. Disallowed characters must be escaped as follows:
    </p>
    <ol>
      <li>
        Each disallowed character is converted to [<a href="#ref-UTF-8">UTF-8</a>] as
        one or more octets.
      </li>
      <li>
        Any octets corresponding to a disallowed character are escaped with the URI
        escaping mechanism (that is, converted to %HH, where HH is the hexadecimal
        notation of the octet value).
      </li>
      <li>
        The original character is replaced by the resulting character sequence.
      </li>
    </ol>
    <p>
      XML signature applications MUST be able to parse URI syntax. We RECOMMEND they be
      able to dereference URIs in the HTTP scheme. Dereferencing a URI in the HTTP
      scheme MUST comply with the <a
      href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4">Status
      Code Definitions</a> of [<a href="#ref-HTTP">HTTP</a>] (e.g., 302, 305 and 307
      redirects are followed to obtain the entity-body of a 200 status code response).
      Applications should also be cognizant of the fact that protocol parameter and
      state information, (such as HTTP cookies, HTML device profiles or content
      negotiation), may affect the content yielded by dereferencing a URI.
    </p>
    <p>
      If a resource is identified by more than one URI, the most specific should be
      used (e.g. http://www.w3.org/2000/06/interop-pressrelease.html.en instead of
      http://www.w3.org/2000/06/interop-pressrelease). (See the <a
      href="#sec-CoreValidation">Reference Validation</a> (section 3.2.1) for a further
      information on reference processing.)
    </p>
    <p>
      If the <code>URI</code> attribute is omitted altogether, the receiving
      application is expected to know the identity of the object. For example, a
      lightweight data protocol might omit this attribute given the identity of the
      object is part of the application context. This attribute may be omitted from at
      most one <code>Reference</code> in any particular <code>SignedInfo</code>, or
      <code>Manifest</code>.
    </p>
    <p>
      The optional Type attribute contains information about the type of object being
      signed. This is represented as a URI. For example:
    </p>
    <p>
      <code>Type=<a
      href="http://www.w3.org/2000/09/xmldsig#Object">"http://www.w3.org/2000/09/xmldsig#Object"</a><br />

      Type=<a
      href="http://www.w3.org/2000/09/xmldsig#Manifest">"http://www.w3.org/2000/09/xmldsig#Manifest"</a></code>
    </p>
    <p>
      The Type attribute applies to the item being pointed at, not its contents. For
      example, a reference that identifies an <code>Object</code> element containing a
      <code>SignatureProperties</code> element is still of type <code>#Object</code>.
      The type attribute is advisory. No validation of the type information is required
      by this specification.
    </p>
    <h4>
      4.3.3.2 The <a name="sec-ReferenceProcessingModel"
      id="sec-ReferenceProcessingModel">Reference Processing Model</a>
    </h4>
    <p class="comment">
      <a name="Note-Xpath" id="Note-Xpath">Note</a>: XPath is RECOMMENDED. Signature
      applications need not conform to [<a href="#ref-XPath">XPath</a>] specification
      in order to conform to this specification. However, the XPath data model,
      definitions (e.g., <a href="http://www.w3.org/TR/xpath#node-sets">node-sets</a>)
      and syntax is used within this document in order to describe functionality for
      those that want to process XML-as-XML (instead of octets) as part of signature
      generation. For those that want to use these features, a conformant [<a
      href="#ref-XPath">XPath</a>] implementation is one way to implement these
      features, but it is not required. Such applications could use a sufficiently
      functional replacement to a node-set and implement only those XPath expression
      behaviors REQUIRED by this specification. However, for simplicity we generally
      will use XPath terminology without including this qualification on every point.
      Requirements over "XPath node-sets" can include a node-set functional equivalent.
      Requirements over XPath processing can include application behaviors that are
      equivalent to the corresponding XPath behavior.
    </p>
    <p>
      The data-type of the result of URI dereferencing or subsequent Transforms is
      either an octet stream or an XPath node-set.
    </p>
    <p>
      The <code>Transforms</code> specified in this document are defined with respect
      to the input they require. The following is the default signature application
      behavior:
    </p>
    <ul>
      <li>
        If the data object is an octet stream and the next transform requires a
        node-set, the signature application MUST attempt to parse the octets yielding
        the required node-set via [<a href="#ref-XML">XML</a>] well-formed processing.
      </li>
      <li>
        If the data object is a node-set and the next transform requires octets, the
        signature application MUST attempt to convert the node-set to an octet stream
        using Canonical XML [<a href="#ref-XML-C14N">XML-C14N</a>].
      </li>
    </ul>
    <p>
      Users may specify alternative transforms that override these defaults in
      transitions between transforms that expect different inputs. The final octet
      stream contains the data octets being secured. The digest algorithm specified by
      <code>DigestMethod</code> is then applied to these data octets, resulting in the
      <code>DigestValue</code>.
    </p>
    <p>
      Unless the URI-Reference is a 'same-document' reference as defined in [<a
      href="#ref-URI">URI</a>, Section 4.2], the result of dereferencing the
      URI-Reference MUST be an octet stream. In particular, an XML document identified
      by URI is not parsed by the signature application unless the URI is a
      same-document reference or unless a transform that requires XML parsing is
      applied. (See <a href="#sec-Transforms">Transforms</a> (section 4.3.3.1).)
    </p>
    <p>
      When a fragment is preceded by an absolute or relative URI in the URI-Reference,
      the meaning of the fragment is defined by the resource's MIME type. Even for XML
      documents, URI dereferencing (including the fragment processing) might be done
      for the signature application by a proxy. Therefore, reference validation might
      fail if fragment processing is not performed in a standard way (as defined in the
      following section for same-document references). Consequently, we RECOMMEND that
      the <code>URI</code>&nbsp; attribute not include fragment identifiers and that
      such processing be specified as an additional <a href="#sec-XPath">XPath
      Transform</a>.
    </p>
    <p>
      When a fragment is not preceded by a URI in the URI-Reference, XML signature
      applications MUST support the null URI and barename XPointer. We RECOMMEND
      support for the same-document XPointers '#xpointer(/)' and '#xpointer(id('ID'))'
      if the application also intends to support any <a
      href="#sec-Canonical">canonicalization</a> that preserves comments. (Otherwise
      URI="#foo" will automatically remove comments before the canonicalization can
      even be invoked.) All other support for XPointers is OPTIONAL, especially all
      support for barename and other XPointers in external resources since the
      application may not have control over how the fragment is generated (leading to
      interoperability problems and validation failures).
    </p>
    <p>
      The following examples demonstrate what the URI attribute identifies and how it
      is dereferenced:
    </p>
    <dl>
      <dt>
        <code>URI="http://example.com/bar.xml"</code>
      </dt>
      <dd>
        Identifies the octets that represent the external resource
        'http://example.com/bar.xml', that is probably an XML document given its file
        extension.
      </dd>
      <dt>
        <code>URI="http://example.com/bar.xml#chapter1"</code>
      </dt>
      <dd>
        Identifies the element with ID attribute value 'chapter1' of the external XML
        resource 'http://example.com/bar.xml', provided as an octet stream. Again, for
        the sake of interoperability, the element identified as 'chapter1' should be
        obtained using an XPath transform rather than a URI fragment (barename XPointer
        resolution in external resources is not REQUIRED in this specification).
      </dd>
      <dt>
        <code>URI=""</code>
      </dt>
      <dd>
        Identifies the node-set (minus any comment nodes) of the XML resource
        containing the signature
      </dd>
      <dt>
        <code>URI="#chapter1"</code>
      </dt>
      <dd>
        Identifies a node-set containing the element with ID attribute value 'chapter1'
        of the XML resource containing the signature. XML Signature (and its
        applications) modify this node-set to include the element plus all descendents
        including namespaces and attributes -- but not comments.
      </dd>
    </dl>
    <h4>
      4.3.3.3 <a name="sec-Same-Document" id="sec-Same-Document">Same-Document</a>
      URI-References
    </h4>
    <p>
      Dereferencing a same-document reference MUST result in an XPath node-set suitable
      for use by Canonical XML [<a href="#ref-XML-C14N">XML-C14N</a>]. Specifically,
      dereferencing a null URI (<code>URI=""</code>) MUST result in an XPath node-set
      that includes every non-comment node of the XML document containing the
      <code>URI</code> attribute. In a fragment URI, the characters after the number
      sign ('#') character conform to the XPointer syntax [<a
      href="#ref-XPointer">Xptr</a>]. When processing an XPointer, the application MUST
      behave as if the root node of the XML document containing the <code>URI</code>
      attribute were used to initialize the XPointer evaluation context. The
      application MUST behave as if the result of XPointer processing were a node-set
      derived from the resultant location-set as follows:
    </p>
    <ol>
      <li>
        discard point nodes
      </li>
      <li>
        replace each range node with all XPath nodes having full or partial content
        within the range
      </li>
      <li>
        replace the root node with its children (if it is in the node-set)
      </li>
      <li>
        replace any element node <strong>E</strong> with <strong>E</strong> plus all
        descendants of <strong>E</strong> (text, comment, PI, element) and all
        namespace and attribute nodes of <strong>E</strong> and its descendant
        elements.
      </li>
      <li>
        if the URI is not a full XPointer, then delete all comment nodes
      </li>
    </ol>
    <p>
      The second to last replacement is necessary because XPointer typically indicates
      a subtree of an XML document's parse tree using just the element node at the root
      of the subtree, whereas Canonical XML treats a node-set as a set of nodes in
      which absence of descendant nodes results in absence of their representative text
      from the canonical form.
    </p>
    <p>
      The last step is performed for null URIs, barename XPointers and child sequence
      XPointers. It's necessary because when [<a href="#ref-XML-C14N">XML-C14N</a>] is
      passed a node-set, it processes the node-set as is: with or without comments.
      Only when it's called with an octet stream does it invoke its own XPath
      expressions (default or without comments). Therefore to retain the default
      behavior of stripping comments when passed a node-set, they are removed in the
      last step if the URI is not a full XPointer. To retain comments while selecting
      an element by an identifier <em>ID</em>, use the following full XPointer:
      <code>URI='#xpointer(id('ID'))'</code>. To retain comments while selecting the
      entire document, use the following full XPointer:
      <code>URI='#xpointer(/)'</code>. This XPointer contains a simple XPath expression
      that includes the root node, which the second to last step above replaces with
      all nodes of the parse tree (all descendants, plus all attributes, plus all
      namespaces nodes).
    </p>
    <h4>
      4.3.3.4 The <a id="sec-Transforms"
      name="sec-Transforms"><code>Transforms</code></a> Element
    </h4>
    <p>
      The optional <code>Transforms</code> element contains an ordered list of
      <code>Transform</code> elements; these describe how the signer obtained the data
      object that was digested. The output of each <code>Transform</code> serves as
      input to the next <code>Transform</code>. The input to the first
      <code>Transform</code> is the result of dereferencing the <code>URI</code>
      attribute of the <code>Reference</code> element. The output from the last
      <code>Transform</code> is the input for the <code>DigestMethod</code> algorithm.
      When transforms are applied the signer is not signing the native (original)
      document but the resulting (transformed) document. (See <a
      href="#sec-Secure">Only What is Signed is Secure</a> (section 8.1).)
    </p>
    <p>
      Each <code>Transform</code> consists of an <code>Algorithm</code> attribute and
      content parameters, if any, appropriate for the given algorithm. The
      <code>Algorithm</code> attribute value specifies the name of the algorithm to be
      performed, and the <code>Transform</code> content provides additional data to
      govern the algorithm's processing of the transform input. (See <a
      href="#sec-AlgID">Algorithm Identifiers and Implementation Requirements</a>
      (section 6).)
    </p>
    <p>
      As described in <a href="#sec-ReferenceProcessingModel">The Reference Processing
      Model</a> (section&nbsp; 4.3.3.2), some transforms take an XPath node-set as
      input, while others require an octet stream. If the actual input matches the
      input needs of the transform, then the transform operates on the unaltered input.
      If the transform input requirement differs from the format of the actual input,
      then the input must be converted.
    </p>
    <p>
      Some <code>Transform</code>s may require explicit MIME type, charset (IANA
      registered "character set"), or other such information concerning the data they
      are receiving from an earlier <code>Transform</code> or the source data, although
      no <code>Transform</code> algorithm specified in this document needs such
      explicit information. Such data characteristics are provided as parameters to the
      <code>Transform</code> algorithm and should be described in the specification for
      the algorithm.
    </p>
    <p>
      Examples of transforms include but are not limited to base64 decoding [<a
      href="#ref-MIME">MIME</a>], canonicalization [<a
      href="#ref-XML-C14N">XML-C14N</a>], XPath filtering [<a
      href="#ref-XPath">XPath</a>], and XSLT [<a href="#ref-XSLT">XSLT</a>]. The
      generic definition of the <code>Transform</code> element also allows
      application-specific transform algorithms. For example, the transform could be a
      decompression routine given by a Java class appearing as a base64 encoded
      parameter to a Java <code>Transform</code> algorithm. However, applications
      should refrain from using application-specific transforms if they wish their
      signatures to be verifiable outside of their application domain. <a
      href="#sec-Transforms">Transform Algorithms</a> (section 6.6) defines the list of
      standard transformations.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="Transforms" type="ds:TransformsType"/&gt;
   &lt;complexType name="TransformsType"&gt;
     &lt;sequence&gt;
       &lt;element ref="ds:Transform" maxOccurs="unbounded"/&gt;  
     &lt;/sequence&gt;
   &lt;/complexType&gt;

   &lt;element name="Transform" type="ds:TransformType"/&gt;
   &lt;complexType name="TransformType" mixed="true"&gt;
     &lt;choice minOccurs="0" maxOccurs="unbounded"&gt; 
       &lt;any namespace="##other" processContents="lax"/&gt;
       &lt;!-- (1,1) elements from (0,unbounded) namespaces --&gt;
       &lt;element name="XPath" type="string"/&gt; 
     &lt;/choice&gt;
     &lt;attribute name="Algorithm" type="anyURI" use="required"/&gt; 
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT Transforms (Transform+)&gt;

   &lt;!ELEMENT Transform (#PCDATA|XPath %Transform.ANY;)* &gt;
   &lt;!ATTLIST Transform 
    Algorithm    CDATA    #REQUIRED &gt;

   &lt;!ELEMENT XPath (#PCDATA) &gt;
</pre>
    <h4>
      4.3.3.5 The <a id="sec-DigestMethod"
      name="sec-DigestMethod"><code>DigestMethod</code></a> Element
    </h4>
    <p>
      <code>DigestMethod</code> is a required element that identifies the digest
      algorithm to be applied to the signed object. This element uses the general
      structure here for algorithms specified in <a href="#sec-AlgID">Algorithm
      Identifiers and Implementation Requirements</a> (section 6.1).
    </p>
    <p>
      If the result of the URI dereference and application of Transforms is an XPath
      node-set (or sufficiently functional replacement implemented by the application)
      then it must be converted as described in <a
      href="#sec-ReferenceProcessingModel">the Reference Processing Model</a>
      (section&nbsp; 4.3.3.2). If the result of URI dereference and application of
      transforms is an octet stream, then no conversion occurs (comments might be
      present if the Canonical XML with Comments was specified in the Transforms). The
      digest algorithm is applied to the data octets of the resulting octet stream.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="DigestMethod" type="ds:DigestMethodType"/&gt;
   &lt;complexType name="DigestMethodType" mixed="true"&gt; 
     &lt;sequence&gt;
       &lt;any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/&gt;
     &lt;/sequence&gt;    
     &lt;attribute name="Algorithm" type="anyURI" use="required"/&gt; 
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT DigestMethod (#PCDATA %Method.ANY;)* &gt;
   &lt;!ATTLIST DigestMethod
    Algorithm       CDATA   #REQUIRED &gt;
</pre>
    <h4>
      4.3.3.6 The <a id="sec-DigestValue"
      name="sec-DigestValue"><code>DigestValue</code></a> Element
    </h4>
    <p>
      DigestValue is an element that contains the encoded value of the digest. The
      digest is always encoded using base64 [<a href="#ref-MIME">MIME</a>].
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="DigestValue" type="ds:DigestValueType"/&gt;
   &lt;simpleType name="DigestValueType"&gt;
     &lt;restriction base="base64Binary"/&gt;
   &lt;/simpleType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT DigestValue  (#PCDATA)  &gt;
   <code>&lt;!-- base64 encoded digest value --&gt;</code>
</pre>
    <h3>
      4.4 The <a id="sec-KeyInfo" name="sec-KeyInfo"><code>KeyInfo</code></a> Element
    </h3>
    <p>
      <code>KeyInfo</code> is an optional element that enables the recipient(s) to
      obtain the key needed to validate the signature.&nbsp; <code>KeyInfo</code> may
      contain keys, names, certificates and other public key management information,
      such as in-band key distribution or key agreement data. This specification
      defines a few simple types but applications may extend those types or all
      together replace them with their own key identification and exchange semantics
      using the XML namespace facility. [<a href="#ref-XML-ns">XML-ns</a>] However,
      questions of trust of such key information (e.g., its authenticity or&nbsp;
      strength) are out of scope of this specification and left to the application.
    </p>
    <p>
      If <code>KeyInfo</code> is omitted, the recipient is expected to be able to
      identify the key based on application context. Multiple declarations within
      <code>KeyInfo</code> refer to the same key. While applications may define and use
      any mechanism they choose through inclusion of elements from a different
      namespace, compliant versions MUST implement <a
      href="#sec-KeyValue"><code>KeyValue</code></a> (section 4.4.2) and SHOULD
      implement <code><a href="#sec-RetrievalMethod">RetrievalMethod</a></code>
      (section 4.4.3).
    </p>
    <p>
      The schema/DTD specifications of many of <code>KeyInfo</code>'s children (e.g.,
      <code>PGPData</code>, <code>SPKIData</code>, <code>X509Data</code>) permit their
      content to be extended/complemented with elements from another namespace. This
      may be done only if it is safe to ignore these extension elements while claiming
      support for the types defined in this specification. Otherwise, external
      elements, including <em>alternative</em> structures to those defined by this
      specification, MUST be a child of <code>KeyInfo</code>. For example, should a
      complete XML-PGP standard be defined, its root element MUST be a child of
      <code>KeyInfo</code>. (Of course, new structures from external namespaces can
      incorporate elements from the <code>&amp;dsig;</code> namespace via features of
      the type definition language. For instance, they can create a DTD that mixes
      their own and dsig qualified elements, or a schema that permits, includes,
      imports, or derives new types based on <code>&amp;dsig;</code> elements.)
    </p>
    <p>
      The following list summarizes the <code>KeyInfo</code> types that are allocated
      an identifier in the <code>&amp;dsig;</code> namespace; these can be used within
      the <code>RetrievalMethod</code> <code>Type</code> attribute to describe a remote
      <code>KeyInfo</code> structure.
    </p>
    <ul>
      <li>
        <a
        href="http://www.w3.org/2000/09/xmldsig#DSAKeyValue">http://www.w3.org/2000/09/xmldsig#DSAKeyValue</a>
      </li>
      <li>
        <a
        href="http://www.w3.org/2000/09/xmldsig#RSAKeyValue">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a>
      </li>
      <li>
        <a
        href="http://www.w3.org/2000/09/xmldsig#X509Data">http://www.w3.org/2000/09/xmldsig#X509Data</a>
      </li>
      <li>
        <a
        href="http://www.w3.org/2000/09/xmldsig#PGPData">http://www.w3.org/2000/09/xmldsig#PGPData</a>
      </li>
      <li>
        <a
        href="http://www.w3.org/2000/09/xmldsig#SPKIData">http://www.w3.org/2000/09/xmldsig#SPKIData</a>
      </li>
      <li>
        <a
        href="http://www.w3.org/2000/09/xmldsig#MgmtData">http://www.w3.org/2000/09/xmldsig#MgmtData</a>
      </li>
    </ul>
    <p>
      In addition to the types above for which we define an XML structure, we specify
      one additional type to indicate a <a name="rawX509Certificate"
      id="rawX509Certificate">binary (ASN.1 DER) X.509 Certificate</a>.
    </p>
    <ul>
      <li>
        <a
        href="http://www.w3.org/2000/09/xmldsig#rawX509Certificate">http://www.w3.org/2000/09/xmldsig#rawX509Certificate</a>
      </li>
    </ul>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="KeyInfo" type="ds:KeyInfoType"/&gt; 
   &lt;complexType name="KeyInfoType" mixed="true"&gt;
     &lt;choice maxOccurs="unbounded"&gt;     
       &lt;element ref="ds:KeyName"/&gt; 
       &lt;element ref="ds:KeyValue"/&gt; 
       &lt;element ref="ds:RetrievalMethod"/&gt; 
       &lt;element ref="ds:X509Data"/&gt; 
       &lt;element ref="ds:PGPData"/&gt; 
       &lt;element ref="ds:SPKIData"/&gt;
       &lt;element ref="ds:MgmtData"/&gt;
       &lt;any processContents="lax" namespace="##other"/&gt;
       &lt;!-- (1,1) elements from (0,unbounded) namespaces --&gt;
     &lt;/choice&gt;
     &lt;attribute name="Id" type="ID" use="optional"/&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod|
               X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* &gt;
   &lt;!ATTLIST KeyInfo  
    Id  ID   #IMPLIED &gt;
</pre>
    <h4>
      4.4.1 The <a id="sec-KeyName" name="sec-KeyName"><code>KeyName</code></a> Element
    </h4>
    <p>
      The <code>KeyName</code> element contains a string value (in which white space is
      significant) which may be used by the signer to communicate a key identifier to
      the recipient. Typically, <code>KeyName</code> contains an identifier related to
      the key pair used to sign the message, but it may contain other protocol-related
      information that indirectly identifies a key pair. (Common uses of
      <code>KeyName</code> include simple string names for keys, a key index, a
      distinguished name (DN), an email address, etc.)
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="KeyName" type="string"/&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT KeyName (#PCDATA) &gt;
</pre>
    <h4>
      4.4.2 The <a id="sec-KeyValue" name="sec-KeyValue"><code>KeyValue</code></a>
      Element
    </h4>
    <p>
      The <code>KeyValue</code> element contains a single public key that may be useful
      in validating the signature. Structured formats for defining DSA (REQUIRED) and
      RSA (RECOMMENDED) public keys are defined in <a
      href="#sec-SignatureAlg">Signature Algorithms</a> (section 6.4). The
      <code>KeyValue</code> element may include externally defined public keys values
      represented as PCDATA or element types from an external namespace.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="KeyValue" type="ds:KeyValueType"/&gt; 
   &lt;complexType name="KeyValueType" mixed="true"&gt;
    &lt;choice&gt;
      &lt;element ref="ds:DSAKeyValue"/&gt;
      &lt;element ref="ds:RSAKeyValue"/&gt;
      &lt;any namespace="##other" processContents="lax"/&gt;
    &lt;/choice&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue %KeyValue.ANY;)* &gt;
</pre>
    <h4>
      4.4.2.1 The <a id="sec-DSAKeyValue"
      name="sec-DSAKeyValue"><code>DSAKeyValue</code></a> Element
    </h4>
    <dl>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type="<a name="DSAKeyValue" id="DSAKeyValue"
        href="http://www.w3.org/2000/09/xmldsig#DSAKeyValue">http://www.w3.org/2000/09/xmldsig#DSAKeyValue</a>"<br />

        </code> (this can be used within a <code>RetrievalMethod</code> or
        <code>Reference</code> element to identify the referent's type)
      </dd>
    </dl>
    <p>
      DSA keys and the DSA signature algorithm are specified in [DSS]. DSA public key
      values can have the following fields:
    </p>
    <dl>
      <dt>
        <code>P</code>
      </dt>
      <dd>
        a prime modulus meeting the [DSS] requirements
      </dd>
      <dt>
        <code>Q</code>
      </dt>
      <dd>
        an integer in the range 2**159 &lt; Q &lt; 2**160 which is a prime divisor of
        P-1
      </dd>
      <dt>
        <code>G</code>
      </dt>
      <dd>
        an integer with certain properties with respect to P and Q
      </dd>
      <dt>
        <code>Y</code>
      </dt>
      <dd>
        G**X mod P (where X is part of the private key and not made public)
      </dd>
      <dt>
        <code>J</code>
      </dt>
      <dd>
        (P - 1) / Q
      </dd>
      <dt>
        <code>seed</code>
      </dt>
      <dd>
        a DSA prime generation seed
      </dd>
      <dt>
        <code>pgenCounter</code>
      </dt>
      <dd>
        a DSA prime generation counter
      </dd>
    </dl>
    <p>
      Parameter J is available for inclusion solely for efficiency as it is
      calculatable from P and Q. Parameters seed and pgenCounter are used in the DSA
      prime number generation algorithm specified in [DSS]. As such, they are optional
      but must either both be present or both be absent. This prime generation
      algorithm is designed to provide assurance that a weak prime is not being used
      and it yields a P and Q value. Parameters P, Q, and G can be public and common to
      a group of users. They might be known from application context. As such, they are
      optional but P and Q must either both appear or both be absent. If all of
      <code>P</code>, <code>Q</code>, <code>seed</code>, and <code>pgenCounter</code>
      are present, implementations are not required to check if they are consistent and
      are free to use either <code>P</code> and <code>Q</code> or <code>seed</code> and
      <code>pgenCounter</code>. All parameters are encoded as base64 [<a
      href="#ref-MIME">MIME</a>] values.
    </p>
    <p>
      Arbitrary-length integers (e.g. "bignums" such as RSA moduli) are represented in
      XML as octet strings as defined by the <a
      href="#sec-CryptoBinary"><code>ds:CryptoBinary</code> type</a>.
    </p>
<pre class="xml-dtd">
   <code>Schema Definition:</code>

   &lt;element name="DSAKeyValue" type="ds:DSAKeyValueType"/&gt; 
   &lt;complexType name="DSAKeyValueType"&gt; 
     &lt;sequence&gt;
       &lt;sequence minOccurs="0"&gt;
         &lt;element name="P" type="ds:CryptoBinary"/&gt; 
         &lt;element name="Q" type="ds:CryptoBinary"/&gt;
       &lt;/sequence&gt;
       &lt;element name="G" type="ds:CryptoBinary" minOccurs="0"/&gt; 
       &lt;element name="Y" type="ds:CryptoBinary"/&gt; 
       &lt;element name="J" type="ds:CryptoBinary" minOccurs="0"/&gt;
       &lt;sequence minOccurs="0"&gt;
         &lt;element name="Seed" type="ds:CryptoBinary"/&gt; 
         &lt;element name="PgenCounter" type="ds:CryptoBinary"/&gt; 
       &lt;/sequence&gt;
     &lt;/sequence&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   <code>DTD Definition:</code>

   &lt;!ELEMENT DSAKeyValue ((P, Q)?, G?, Y, J?, (Seed, PgenCounter)?) &gt; 
   &lt;!ELEMENT P (#PCDATA) &gt;
   &lt;!ELEMENT Q (#PCDATA) &gt;
   &lt;!ELEMENT G (#PCDATA) &gt;
   &lt;!ELEMENT Y (#PCDATA) &gt;
   &lt;!ELEMENT J (#PCDATA) &gt;
   &lt;!ELEMENT Seed (#PCDATA) &gt;
   &lt;!ELEMENT PgenCounter (#PCDATA) &gt;
</pre>
    <h4>
      4.4.2.2 The <a id="sec-RSAKeyValue"
      name="sec-RSAKeyValue"><code>RSAKeyValue</code></a> Element
    </h4>
    <dl>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type="<a name="RSAKeyValue" id="RSAKeyValue"
        href="http://www.w3.org/2000/09/xmldsig#RSAKeyValue">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a>"<br />

        </code> (this can be used within a <code>RetrievalMethod</code> or
        <code>Reference</code> element to identify the referent's type)
      </dd>
    </dl>
    <p>
      RSA key values have two fields: Modulus and Exponent.
    </p>
<pre class="xml-example">
   &lt;RSAKeyValue&gt;
     &lt;Modulus&gt;xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
      jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
      5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
     &lt;/Modulus&gt;
     &lt;Exponent&gt;AQAB&lt;/Exponent&gt;
   &lt;/RSAKeyValue&gt;
</pre>
    <p>
      Arbitrary-length integers (e.g. "bignums" such as RSA moduli) are represented in
      XML as octet strings as defined by the <a
      href="#sec-CryptoBinary"><code>ds:CryptoBinary</code> type</a>.
    </p>
<pre class="xml-dtd">
   <code>Schema Definition:</code>

   &lt;element name="RSAKeyValue" type="ds:RSAKeyValueType"/&gt;
   &lt;complexType name="RSAKeyValueType"&gt;
     &lt;sequence&gt;
       &lt;element name="Modulus" type="ds:CryptoBinary"/&gt; 
       &lt;element name="Exponent" type="ds:CryptoBinary"/&gt;
     &lt;/sequence&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   <code>DTD Definition:</code>

   &lt;!ELEMENT RSAKeyValue (Modulus, Exponent) &gt; 
   &lt;!ELEMENT Modulus (#PCDATA) &gt;
   &lt;!ELEMENT Exponent (#PCDATA) &gt;
</pre>
    <h4>
      4.4.3 The <a id="sec-RetrievalMethod"
      name="sec-RetrievalMethod"><code>RetrievalMethod</code></a> Element
    </h4>
    <p>
      A <code>RetrievalMethod</code> element within <code>KeyInfo</code> is used to
      convey a reference to <code>KeyInfo</code> information that is stored at another
      location. For example, several signatures in a document might use a key verified
      by an X.509v3 certificate chain appearing once in the document or remotely
      outside the document; each signature's <code>KeyInfo</code> can reference this
      chain using a single <code>RetrievalMethod</code> element instead of including
      the entire chain with a sequence of <code>X509Certificate</code> elements.
    </p>
    <p>
      <code>RetrievalMethod</code> uses the same syntax and dereferencing behavior as
      <a href="#sec-URI"><code>Reference</code>'s URI</a> (section 4.3.3.1) and <a
      href="#sec-ReferenceProcessingModel">The Reference Processing Model</a> (section
      4.3.3.2) except that there is no <code>DigestMethod</code> or
      <code>DigestValue</code> child elements and presence of the URI is mandatory.
    </p>
    <p>
      <code>Type</code> is an optional identifier for the type of data to be retrieved.
      The result of dereferencing a <code>RetrievalMethod</code> <code><a
      href="#sec-URI">Reference</a></code> for all <a
      href="#sec-KeyInfo"><code>KeyInfo</code> types defined by this specification</a>
      (section 4.4) with a corresponding XML structure is an XML element or document
      with that element as the root. The <code>rawX509Certificate</code>
      <code>KeyInfo</code> (for which there is no XML structure) returns a binary X509
      certificate.
    </p>
<pre class="xml-dtd">
   Schema Definition

   &lt;element name="RetrievalMethod" type="ds:RetrievalMethodType"/&gt; 
   &lt;complexType name="RetrievalMethodType"&gt;
     &lt;sequence&gt;
       &lt;element ref="ds:Transforms" minOccurs="0"/&gt; 
     &lt;/sequence&gt;  
     &lt;attribute name="URI" type="anyURI"/&gt;
     &lt;attribute name="Type" type="anyURI" use="optional"/&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD

   &lt;!ELEMENT RetrievalMethod (Transforms?) &gt;
   &lt;!ATTLIST RetrievalMethod
      URI   CDATA #REQUIRED 
      Type  CDATA #IMPLIED &gt;
</pre>
    <h4>
      4.4.4 The <a id="sec-X509Data" name="sec-X509Data"><code>X509Data</code></a>
      Element
    </h4>
    <dl>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type="<a name="X509Data" id="X509Data"
        href="http://www.w3.org/2000/09/xmldsig#SPKIData">http://www.w3.org/2000/09/xmldsig#X509Data</a></code>
        "<br />
         (this can be used within a <code>RetrievalMethod</code> or
        <code>Reference</code> element to identify the referent's type)
      </dd>
    </dl>
    <p>
      An <code>X509Data</code> element within <code>KeyInfo</code> contains one or more
      identifiers of keys or X509 certificates (or certificates' identifiers or a
      revocation list). The content of <code>X509Data</code> is:
    </p>
    <ol>
      <li>
        At least one element, from the following set of element types; any of these may
        appear together or more than once iff (if and only if) each instance describes
        or is related to the same certificate:
      </li>
      <li style="list-style: none">
        <ul>
          <li>
            The <code>X509IssuerSerial</code> element, which contains an X.509 issuer
            distinguished name/serial number pair that SHOULD be compliant with RFC2253
            [<a href="#ref-LDAP-DN">LDAP-DN</a>],
          </li>
          <li>
            The <code>X509SubjectName</code> element, which contains an X.509 subject
            distinguished name that SHOULD be compliant with RFC2253 [<a
            href="#ref-LDAP-DN">LDAP-DN</a>],
          </li>
          <li>
            The <code>X509SKI</code> element, which contains the base64 encoded plain
            (i.e. non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier extension.
          </li>
          <li>
            The <code>X509Certificate</code> element, which contains a base64-encoded
            [<a href="#ref-X509v3">X509v3</a>] certificate, and
          </li>
          <li>
            Elements from an external namespace which accompanies/complements any of
            the elements above.
          </li>
          <li>
            The <code>X509CRL</code> element, which contains a base64-encoded
            certificate revocation list (CRL) [<a href="#ref-X509v3">X509v3</a>].
          </li>
        </ul>
      </li>
    </ol>
    <p>
      Any <code>X509IssuerSerial</code>, <code>X509SKI</code>, and
      <code>X509SubjectName</code> elements that appear MUST refer to the certificate
      or certificates containing the validation key. All such elements that refer to a
      particular individual certificate MUST be grouped inside a single
      <code>X509Data</code> element and if the certificate to which they refer appears,
      it MUST also be in that <code>X509Data</code> element.
    </p>
    <p>
      Any <code>X509IssuerSerial</code>, <code>X509SKI</code>, and
      <code>X509SubjectName</code> elements that relate to the same key but different
      certificates MUST be grouped within a single <code>KeyInfo</code> but MAY occur
      in multiple <code>X509Data</code> elements.
    </p>
    <p>
      All certificates appearing in an <code>X509Data</code> element MUST relate to the
      validation key by either containing it or being part of a certification chain
      that terminates in a certificate containing the validation key.
    </p>
    <p>
      No ordering is implied by the above constraints. The comments in the following
      instance demonstrate these constraints:
    </p>
<pre class="xml-example">
   &lt;KeyInfo&gt;
     &lt;X509Data&gt; &lt;!-- two pointers to certificate-A --&gt;
       &lt;X509IssuerSerial&gt; 
         &lt;X509IssuerName&gt;<span class="tx">CN=TAMURA Kent, OU=TRL, O=IBM, 
           L=Yamato-shi, ST=Kanagawa, C=JP</span>&lt;/X509IssuerName&gt;
         &lt;X509SerialNumber&gt;12345678&lt;/X509SerialNumber&gt;
       &lt;/X509IssuerSerial&gt;
       &lt;X509SKI&gt;31d97bd7&lt;/X509SKI&gt; 
     &lt;/X509Data&gt;
     &lt;X509Data&gt;&lt;!-- single pointer to certificate-B --&gt;
       &lt;X509SubjectName&gt;Subject of Certificate B&lt;/X509SubjectName&gt;
     &lt;/X509Data&gt;
     &lt;X509Data&gt; &lt;!-- certificate chain --&gt;
       &lt;!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4--&gt;
       &lt;X509Certificate&gt;MIICXTCCA..&lt;/X509Certificate&gt;
       &lt;!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US 
            issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US --&gt;
       &lt;X509Certificate&gt;MIICPzCCA...&lt;/X509Certificate&gt;
       &lt;!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US --&gt;
       &lt;X509Certificate&gt;MIICSTCCA...&lt;/X509Certificate&gt;
     &lt;/X509Data&gt;
   &lt;/KeyInfo&gt;
</pre>
    <p>
      Note, there is no direct provision for a PKCS#7 encoded "bag" of certificates or
      CRLs. However, a set of certificates and CRLs can occur within an
      <code>X509Data</code> element and multiple <code>X509Data</code> elements can
      occur in a <code>KeyInfo</code>. Whenever multiple certificates occur in an
      <code>X509Data</code> element, at least one such certificate must contain the
      public key which verifies the signature.
    </p>
    <p>
      Also, strings in DNames
      (<code>X509IssuerSerial</code>,<code>X509SubjectName</code>, and
      <code>KeyName</code> if approriate) should be encoded as follows:
    </p>
    <ul>
      <li>
        Consider the string as consisting of Unicode characters.
      </li>
      <li>
        Escape occurrences of the following special characters by prefixing it with the
        "\" character: 
        <ul>
          <li>
            a "#" character occurring at the beginning of the string
          </li>
          <li>
            one of the characters ",", "+", """, "\", "&lt;", "&gt;" or ";"
          </li>
        </ul>
      </li>
      <li>
        Escape all occurrences of ASCII control characters (Unicode range \x00 - \x1f)
        by replacing them with "\" followed by a two digit hex number showing its
        Unicode number.
      </li>
      <li>
        Escape any trailing white space by replacing "\ " with "\20".
      </li>
      <li>
        Since a XML document logically consists of characters, not octets, the
        resulting Unicode string is finally encoded according to the character encoding
        used for producing the physical representation of the XML document.
      </li>
    </ul>
<pre class="xml-dtd">
   Schema Definition

   &lt;element name="X509Data" type="ds:X509DataType"/&gt; 
   &lt;complexType name="X509DataType"&gt;
     &lt;sequence maxOccurs="unbounded"&gt;
       &lt;choice&gt;
         &lt;element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/&gt;
         &lt;element name="X509SKI" type="base64Binary"/&gt;
         &lt;element name="X509SubjectName" type="string"/&gt;
         &lt;element name="X509Certificate" type="base64Binary"/&gt;
         &lt;element name="X509CRL" type="base64Binary"/&gt;
         &lt;any namespace="##other" processContents="lax"/&gt;
       &lt;/choice&gt;
     &lt;/sequence&gt;
   &lt;/complexType&gt;

   &lt;complexType name="X509IssuerSerialType"&gt; 
     &lt;sequence&gt; 
       &lt;element name="X509IssuerName" type="string"/&gt; 
       &lt;element name="X509SerialNumber" type="integer"/&gt; 
     &lt;/sequence&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD

   &lt;!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
                        X509Certificate | X509CRL)+ %X509.ANY;)&gt;
   &lt;!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) &gt;
   &lt;!ELEMENT X509IssuerName (#PCDATA) &gt;
   &lt;!ELEMENT X509SubjectName (#PCDATA) &gt;
   &lt;!ELEMENT X509SerialNumber (#PCDATA) &gt;
   &lt;!ELEMENT X509SKI (#PCDATA) &gt;
   &lt;!ELEMENT X509Certificate (#PCDATA) &gt;
   &lt;!ELEMENT X509CRL (#PCDATA) &gt;

   &lt;!-- Note, this DTD and schema permit <code>X509Data</code> to be empty; this is 
   precluded by the text in <a
href="#sec-KeyInfo"><code>KeyInfo</code> Element</a> (section 4.4) which states 
   that at least one element from the dsig namespace should be present 
   in the PGP, SPKI, and X509 structures. This is easily expressed for 
   the other key types, but not for X509Data because of its rich 
   structure. --&gt;
</pre>
    <h4>
      4.4.5 The <a id="sec-PGPData" name="sec-PGPData"><code>PGPData</code></a> Element
    </h4>
    <dl>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type="<a name="PGPData" id="PGPData"
        href="http://www.w3.org/2000/09/xmldsig#PGPData">http://www.w3.org/2000/09/xmldsig#PGPData</a></code>
        "<br />
         (this can be used within a <code>RetrievalMethod</code> or
        <code>Reference</code> element to identify the referent's type)
      </dd>
    </dl>
    <p>
      The <code>PGPData</code> element within <code>KeyInfo</code> is used to convey
      information related to PGP public key pairs and signatures on such keys. The
      <code>PGPKeyID</code>'s value is a base64Binary sequence containing a standard
      PGP public key identifier as defined in [<a href="#ref-PGP">PGP</a>, section
      11.2]. The <code>PGPKeyPacket</code> contains a base64-encoded Key Material
      Packet as defined in [<a href="#ref-PGP">PGP</a>, section 5.5]. These children
      element types can be complemented/extended by siblings from an external namespace
      within <code>PGPData</code>, or <code>PGPData</code> can be replaced all together
      with an alternative PGP XML structure as a child of <code>KeyInfo</code>.
      <code>PGPData</code> must contain one <code>PGPKeyID</code> and/or one
      <code>PGPKeyPacket</code> and 0 or more elements from an external namespace.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="PGPData" type="ds:PGPDataType"/&gt; 
   &lt;complexType name="PGPDataType"&gt; 
     &lt;choice&gt;
       &lt;sequence&gt;
         &lt;element name="PGPKeyID" type="base64Binary"/&gt; 
         &lt;element name="PGPKeyPacket" type="base64Binary" minOccurs="0"/&gt; 
         &lt;any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/&gt;
       &lt;/sequence&gt;
       &lt;sequence&gt;
         &lt;element name="PGPKeyPacket" type="base64Binary"/&gt; 
         &lt;any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/&gt;
       &lt;/sequence&gt;
     &lt;/choice&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

 &lt;!ELEMENT PGPData ((PGPKeyID, PGPKeyPacket?) | (PGPKeyPacket) %PGPData.ANY;) &gt;
   &lt;!ELEMENT PGPKeyPacket  (#PCDATA)  &gt;
   &lt;!ELEMENT PGPKeyID  (#PCDATA)  &gt;
</pre>
    <h4>
      4.4.6 The <a id="sec-SPKIData" name="sec-SPKIData"><code>SPKIData</code></a>
      Element
    </h4>
    <dl>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type="<a name="SPKIData" id="SPKIData"
        href="http://www.w3.org/2000/09/xmldsig#SPKIData">http://www.w3.org/2000/09/xmldsig#SPKIData</a></code>
        "<br />
         (this can be used within a <code>RetrievalMethod</code> or
        <code>Reference</code> element to identify the referent's type)
      </dd>
    </dl>
    <p>
      The <code>SPKIData</code> element within <code>KeyInfo</code> is used to convey
      information related to SPKI public key pairs, certificates and other SPKI data.
      <code>SPKISexp</code> is the base64 encoding of a SPKI canonical S-expression.
      <code>SPKIData</code> must have at least one <code>SPKISexp</code>;
      <code>SPKISexp</code> can be complemented/extended by siblings from an external
      namespace within <code>SPKIData</code>, or <code>SPKIData</code> can be entirely
      replaced with an alternative SPKI XML structure as a child of
      <code>KeyInfo</code>.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="SPKIData" type="ds:SPKIDataType"/&gt; 
   &lt;complexType name="SPKIDataType"&gt;
     &lt;sequence maxOccurs="unbounded"&gt;
       &lt;element name="SPKISexp" type="base64Binary"/&gt;
       &lt;any namespace="##other" processContents="lax" minOccurs="0"/&gt;
     &lt;/sequence&gt;
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

 &lt;!ELEMENT SPKIData (SPKISexp %SPKIData.ANY;)  &gt;
   &lt;!ELEMENT SPKISexp  (#PCDATA)  &gt;
</pre>
    <h4>
      4.4.7 The <a id="sec-MgmtData" name="sec-MgmtData"><code>MgmtData</code></a>
      Element
    </h4>
    <dl>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type="<a name="MgmtData" id="MgmtData"
        href="http://www.w3.org/2000/09/xmldsig#MgmtData">http://www.w3.org/2000/09/xmldsig#MgmtData</a></code>
        "<br />
         (this can be used within a <code>RetrievalMethod</code> or
        <code>Reference</code> element to identify the referent's type)
      </dd>
    </dl>
    <p>
      The <code>MgmtData</code> element within <code>KeyInfo</code> is a string value
      used to convey in-band key distribution or agreement data. For example, DH key
      exchange, RSA key encryption, etc. Use of this element is NOT RECOMMENDED. It
      provides a syntactic hook where in-band key distribution or agreement data can be
      placed. However, superior interoperable child elements of <code>KeyInfo</code>
      for the transmission of encrypted keys and for key agreement are being specified
      by the W3C XML Encryption Working Group and they should be used instead of
      <code>MgmtData</code>.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="MgmtData" type="string"/&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT MgmtData (#PCDATA)&gt;
</pre>
    <h3>
      4.5 The <a id="sec-Object" name="sec-Object"><code>Object</code></a> Element
    </h3>
    <dl>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type=<a id="Object" href="http://www.w3.org/2000/09/xmldsig#Object"
        name="Object">"http://www.w3.org/2000/09/xmldsig#Object"</a><br />
        </code> (this can be used within a <code>Reference</code> element to identify
        the referent's type)
      </dd>
    </dl>
    <p>
      <code>Object</code> is an optional element that may occur one or more times. When
      present, this element may contain any data. The <code>Object</code> element may
      include optional MIME type, ID, and encoding attributes.
    </p>
    <p>
      The <code>Object</code>'s <code>Encoding</code> attributed may be used to provide
      a URI that identifies the method by which the object is encoded (e.g., a binary
      file).
    </p>
    <p>
      The <code>MimeType</code> attribute is an optional attribute which describes the
      data within the <code>Object</code> (independent of its encoding). This is a
      string with values defined by [<a href="#ref-MIME">MIME</a>]. For example, if the
      <code>Object</code> contains base64 encoded <a
      href="http://www.w3.org/Graphics/PNG/">PNG</a>, the <code>Encoding</code> may be
      specified as 'base64' and the <code>MimeType</code> as 'image/png'. This
      attribute is purely advisory; no validation of the <code>MimeType</code>
      information is required by this specification. Applications which require
      normative type and encoding information for signature validation should specify
      <code><a href="#sec-Transforms">Transforms</a></code> with well defined resulting
      types and/or encodings.
    </p>
    <p>
      The <code>Object</code>'s <code>Id</code> is commonly referenced from a
      <code>Reference</code> in <code>SignedInfo</code>, or <code>Manifest</code>. This
      element is typically used for <a href="#def-SignatureEnveloping"
      class="link-def">enveloping signatures</a> where the object being signed is to be
      included in the signature element. The digest is calculated over the entire
      <code>Object</code> element including start and end tags.
    </p>
    <p>
      Note, if the application wishes to exclude the <code>&lt;Object&gt;</code> tags
      from the digest calculation the <code>Reference</code> must identify the actual
      data object (easy for XML documents) or a transform must be used to remove the
      <code>Object</code> tags (likely where the data object is non-XML). Exclusion of
      the object tags may be desired for cases where one wants the signature to remain
      valid if the data object is moved from inside a signature to outside the
      signature (or vice versa), or where the content of the <code>Object</code> is an
      encoding of an original binary document and it is desired to extract and decode
      so as to sign the original bitwise representation.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="Object" type="ds:ObjectType"/&gt; 
   &lt;complexType name="ObjectType" mixed="true"&gt;
     &lt;sequence minOccurs="0" maxOccurs="unbounded"&gt;
       &lt;any namespace="##any" processContents="lax"/&gt;
     &lt;/sequence&gt;
     &lt;attribute name="Id" type="ID" use="optional"/&gt; 
     &lt;attribute name="MimeType" type="string" use="optional"/&gt;
     &lt;attribute name="Encoding" type="anyURI" use="optional"/&gt; 
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT Object (#PCDATA|Signature|SignatureProperties|Manifest %Object.ANY;)* &gt;
   &lt;!ATTLIST Object  
    Id  ID  #IMPLIED 
    MimeType    CDATA   #IMPLIED 
    Encoding    CDATA   #IMPLIED &gt;
</pre>
    <h2>
      5.0 <a id="sec-AdditionalSyntax" name="sec-AdditionalSyntax">Additional Signature
      Syntax</a>
    </h2>
    <p>
      This section describes the optional to implement <code>Manifest</code> and
      <code>SignatureProperties</code> elements and describes the handling of XML
      processing instructions and comments. With respect to the elements
      <code>Manifest</code> and <code>SignatureProperties</code> this section specifies
      syntax and little behavior -- it is left to the application. These elements can
      appear anywhere the parent's content model permits; the <code>Signature</code>
      content model only permits them within <code>Object</code>.
    </p>
    <h3>
      5.1 The <a id="sec-Manifest" name="sec-Manifest"><code>Manifest</code></a>
      Element
    </h3>
    <dl>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type=<a id="Manifest" href="http://www.w3.org/2000/09/xmldsig#Manifest"
        name="Manifest">"http://www.w3.org/2000/09/xmldsig#Manifest"</a><br />
        </code> (this can be used within a <code>Reference</code> element to identify
        the referent's type)
      </dd>
    </dl>
    <p>
      The <code>Manifest</code> element provides a list of <code>Reference</code>s. The
      difference from the list in <code>SignedInfo</code> is that it is application
      defined which, if any, of the digests are actually checked against the objects
      referenced and what to do if the object is inaccessible or the digest compare
      fails. If a <code>Manifest</code> is pointed to from <code>SignedInfo</code>, the
      digest over the <code>Manifest</code> itself will be checked by the core
      signature validation behavior. The digests within such a <code>Manifest</code>
      are checked at the application's discretion. If a <code>Manifest</code> is
      referenced from another <code>Manifest</code>, even the overall digest of this
      two level deep <code>Manifest</code> might not be checked.
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="Manifest" type="ds:ManifestType"/&gt; 
   &lt;complexType name="ManifestType"&gt;
     &lt;sequence&gt;
       &lt;element ref="ds:Reference" maxOccurs="unbounded"/&gt; 
     &lt;/sequence&gt;  
     &lt;attribute name="Id" type="ID" use="optional"/&gt; 
   &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT Manifest (Reference+)  &gt;
   &lt;!ATTLIST Manifest  
             Id ID  #IMPLIED &gt;
</pre>
    <h3>
      5.2 The <a id="sec-SignatureProperties"
      name="sec-SignatureProperties"><code>SignatureProperties</code></a> Element
    </h3>
    <dl>
      <dt>
        &nbsp;
      </dt>
      <dt>
        Identifier
      </dt>
      <dd>
        <code>Type="<a id="SignatureProperties"
        href="http://www.w3.org/2000/09/xmldsig#SignatureProperties"
        name="SignatureProperties">http://www.w3.org/2000/09/xmldsig#SignatureProperties</a>"<br />

        </code> (this can be used within a <code>Reference</code> element to identify
        the referent's type)
      </dd>
    </dl>
    <p>
      Additional information items concerning the generation of the signature(s) can be
      placed in a <code>SignatureProperty</code> element (i.e., date/time stamp or the
      serial number of cryptographic hardware used in signature generation).
    </p>
<pre class="xml-dtd">
   Schema Definition:

   &lt;element name="SignatureProperties" type="ds:SignaturePropertiesType"/&gt; 
   &lt;complexType name="SignaturePropertiesType"&gt;
     &lt;sequence&gt;
       &lt;element ref="ds:SignatureProperty" maxOccurs="unbounded"/&gt; 
     &lt;/sequence&gt;
     &lt;attribute name="Id" type="ID" use="optional"/&gt; 
   &lt;/complexType&gt;

      &lt;element name="SignatureProperty" type="ds:SignaturePropertyType"/&gt; 
      &lt;complexType name="SignaturePropertyType" mixed="true"&gt;
        &lt;choice maxOccurs="unbounded"&gt;
          &lt;any namespace="##other" processContents="lax"/&gt;
          &lt;!-- (1,1) elements from (1,unbounded) namespaces --&gt;
        &lt;/choice&gt;
        &lt;attribute name="Target" type="anyURI" use="required"/&gt; 
        &lt;attribute name="Id" type="ID" use="optional"/&gt; 
      &lt;/complexType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT SignatureProperties (SignatureProperty+)  &gt;
   &lt;!ATTLIST SignatureProperties  
             Id ID   #IMPLIED  &gt;

   &lt;!ELEMENT SignatureProperty (#PCDATA %SignatureProperty.ANY;)* &gt;
   &lt;!ATTLIST SignatureProperty  
    Target  CDATA    #REQUIRED
    Id  ID   #IMPLIED  &gt;
</pre>
    <h3>
      5.3 <a id="sec-PI" name="sec-PI">Processing Instructions</a> in Signature
      Elements
    </h3>
    <p>
      No XML processing instructions (PIs) are used by this specification.
    </p>
    <p>
      Note that PIs placed inside <code>SignedInfo</code> by an application will be
      signed unless the <code>CanonicalizationMethod</code> algorithm discards them.
      (This is true for any signed XML content.) All of the
      <code>CanonicalizationMethod</code>s identified within this specification retain
      PIs. When a PI is part of content that is signed (e.g., within
      <code>SignedInfo</code> or referenced XML documents) any change to the PI will
      obviously result in a signature failure.
    </p>
    <h3>
      5.4 <a id="sec-comments" name="sec-comments">Comments</a> in Signature Elements
    </h3>
    <p>
      XML comments are not used by this specification.
    </p>
    <p>
      Note that unless <code>CanonicalizationMethod</code> removes comments within
      <code>SignedInfo</code> or any other referenced XML (which [<a
      href="#ref-XML-C14N">XML-C14N</a>] does), they will be signed. Consequently, if
      they are retained, a change to the comment will cause a signature failure.
      Similarly, the XML signature over any XML data will be sensitive to comment
      changes unless a comment-ignoring canonicalization/transform method, such as the
      Canonical XML [<a href="#ref-XML-C14N">XML-C14N</a>], is specified.
    </p>
    <h2>
      6.0 <a id="sec-Algorithms" name="sec-Algorithms">Algorithms</a>
    </h2>
    <p>
      This section identifies algorithms used with the XML digital signature
      specification. Entries contain the identifier to be used in
      <code>Signature</code> elements, a reference to the formal specification, and
      definitions, where applicable, for the representation of keys and the results of
      cryptographic operations.
    </p>
    <h3>
      6.1 <a id="sec-AlgID" name="sec-AlgID">Algorithm</a> Identifiers and
      Implementation Requirements
    </h3>
    <p>
      Algorithms are identified by URIs that appear as an attribute to the element that
      identifies the algorithms' role (<code>DigestMethod</code>,
      <code>Transform</code>, <code>SignatureMethod</code>, or
      <code>CanonicalizationMethod</code>). All algorithms used herein take parameters
      but in many cases the parameters are implicit. For example, a
      <code>SignatureMethod</code> is implicitly given two parameters: the keying info
      and the output of <code>CanonicalizationMethod</code>. Explicit additional
      parameters to an algorithm appear as content elements within the algorithm role
      element. Such parameter elements have a descriptive element name, which is
      frequently algorithm specific, and MUST be in the XML Signature namespace or an
      algorithm specific namespace.
    </p>
    <p>
      This specification defines a set of algorithms, their URIs, and requirements for
      implementation. Requirements are specified over implementation, not over
      requirements for signature use. Furthermore, the mechanism is extensible;
      alternative algorithms may be used by signature applications.
    </p>
    <dl>
      <dt>
        Digest
      </dt>
      <dd>
        <ol>
          <li>
            Required SHA1<br />
             <a
            href="http://www.w3.org/2000/09/xmldsig#sha1">http://www.w3.org/2000/09/xmldsig#sha1</a>
          </li>
        </ol>
      </dd>
      <dt>
        Encoding
      </dt>
      <dd>
        <ol>
          <li>
            Required base64<br />
             <a href="http://www.w3.org/2000/09/xmldsig#base64"><span
            style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span>base64</a>
          </li>
        </ol>
      </dd>
      <dt>
        MAC
      </dt>
      <dd>
        <ol>
          <li>
            Required HMAC-SHA1<br />
             <a
            href="http://www.w3.org/2000/09/xmldsig#hmac-sha1">http://www.w3.org/2000/09/xmldsig#hmac-sha1</a>
          </li>
        </ol>
      </dd>
      <dt>
        Signature
      </dt>
      <dd>
        <ol>
          <li>
            Required DSAwithSHA1 (DSS)<br />
             <a href="http://www.w3.org/2000/09/xmldsig#dsa-sha1"><span
            style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span>dsa-sha1</a>
          </li>
          <li>
            Recommended RSAwithSHA1<br />
             <a href="http://www.w3.org/2000/09/xmldsig#rsa-sha1"><span
            style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span>rsa-sha1</a>
          </li>
        </ol>
      </dd>
      <dt>
        Canonicalization
      </dt>
      <dd>
        <ol>
          <li>
            Required Canonical XML (omits comments)<br />
             <a
            href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a>
          </li>
          <li>
            Recommended Canonical XML with Comments<br />
             <a
            href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments">http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments</a>
          </li>
        </ol>
      </dd>
      <dt>
        Transform
      </dt>
      <dd>
        <ol>
          <li>
            Optional XSLT<br />
             <a
            href="http://www.w3.org/TR/1999/REC-xslt-19991116">http://www.w3.org/TR/1999/REC-xslt-19991116</a>
          </li>
          <li>
            Recommended XPath<br />
             <a
            href="http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/TR/1999/REC-xpath-19991116</a>
          </li>
          <li>
            Required Enveloped Signature*<br />
             <a
            href="http://www.w3.org/2000/09/xmldsig#enveloped-signature">http://www.w3.org/2000/09/xmldsig#enveloped-signature</a>
          </li>
        </ol>
      </dd>
    </dl>
    <p>
      * The Enveloped Signature transform removes the <code>Signature</code> element
      from the calculation of the signature when the signature is within the content
      that it is being signed. This MAY be implemented via the RECOMMENDED XPath
      specification specified in 6.6.4: <a href="#sec-EnvelopedSignature">Enveloped
      Signature Transform</a>; it MUST have the same effect as that specified by the <a
      href="#sec-XPath">XPath Transform</a>.
    </p>
    <h3>
      6.2 <a id="sec-MessageDigests" name="sec-MessageDigests">Message Digests</a>
    </h3>
    <p>
      Only one digest algorithm is defined herein. However, it is expected that one or
      more additional strong digest algorithms will be developed in connection with the
      US Advanced Encryption Standard effort. Use of <a
      href="http://www.ietf.org/rfc/rfc1321.txt">MD5</a> [<a href="#ref-MD5">MD5</a>]
      is NOT RECOMMENDED because recent advances in cryptanalysis have cast doubt on
      its strength.
    </p>
    <h4>
      6.2.1 <a id="sec-SHA-1" name="sec-SHA-1">SHA-1</a>
    </h4>
    <dl>
      <dt>
        Identifier:
      </dt>
      <dd>
        <a id="sha1" href="http://www.w3.org/2000/09/xmldsig#sha1"
        name="sha1">http://www.w3.org/2000/09/xmldsig#sha1</a>
      </dd>
    </dl>
    <p>
      The <a
      href="http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt">SHA-1</a>
      algorithm [<a href="#ref-SHA-1">SHA-1</a>] takes no explicit parameters. An
      example of an SHA-1 DigestAlg element is:
    </p>
<pre class="xml-example">
<code>&lt;DigestMethod Algorithm="</code><span
style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span><code>sha1"/&gt;</code>
</pre>
    <p>
      A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall
      be the base64 encoding of this bit string viewed as a 20-octet octet stream. For
      example, the DigestValue element for the message digest:
    </p>
<pre class="xml-example">
   A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
</pre>
    <p>
      from Appendix A of the SHA-1 standard would be:
    </p>
<pre class="xml-example">
   &lt;DigestValue&gt;qZk+NkcGgWq6PiVxeFDCbJzQ2J0=&lt;/DigestValue&gt;
</pre>
    <h3>
      6.3 <a id="sec-MACs" name="sec-MACs">Message Authentication Codes</a>
    </h3>
    <p>
      MAC algorithms take two implicit parameters, their keying material determined
      from <code>KeyInfo</code> and the octet stream output by
      <code>CanonicalizationMethod</code>. MACs and signature algorithms are
      syntactically identical but a MAC implies a shared secret key.
    </p>
    <h4>
      6.3.1 <a id="sec-HMAC" name="sec-HMAC">HMAC</a>
    </h4>
    <dl>
      <dt>
        Identifier:
      </dt>
      <dd>
        <a id="hmac-sha1" name="hmac-sha1"
        href="http://www.w3.org/2000/09/xmldsig#hmac-sha1">http://www.w3.org/2000/09/xmldsig#hmac-sha1</a>
      </dd>
    </dl>
    <p>
      The <a href="http://www.ietf.org/rfc/rfc2104.txt">HMAC</a> algorithm (RFC2104 [<a
      href="#ref-HMAC">HMAC</a>]) takes the truncation length in bits as a parameter;
      if the parameter is not specified then all the bits of the hash are output. An
      example of an HMAC <code>SignatureMethod</code> element:
    </p>
<pre class="xml-example">
   &lt;SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"&gt;
      &lt;HMACOutputLength&gt;128&lt;/HMACOutputLength&gt;
   &lt;/SignatureMethod&gt;
</pre>
    <p>
      The output of the HMAC algorithm is ultimately the output (possibly truncated) of
      the chosen digest algorithm. This value shall be base64 encoded in the same
      straightforward fashion as the output of the digest algorithms. Example: the
      SignatureValue element for the HMAC-SHA1 digest
    </p>
<pre class="xml-example">
   9294727A 3638BB1C 13F48EF8 158BFC9D
</pre>
    <p>
      from the test vectors in [<a href="#ref-HMAC">HMAC</a>] would be
    </p>
<pre class="xml-example">
   &lt;SignatureValue&gt;kpRyejY4uxwT9I74FYv8nQ==&lt;/SignatureValue&gt;
</pre>
<pre class="xml-dtd">
   Schema Definition:

   &lt;simpleType name="HMACOutputLengthType"&gt;
     &lt;restriction base="integer"/&gt;
   &lt;/simpleType&gt;
</pre>
<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT HMACOutputLength (#PCDATA)&gt;
</pre>
    <h3>
      6.4 <a id="sec-SignatureAlg" name="sec-SignatureAlg">Signature Algorithms</a>
    </h3>
    <p>
      Signature algorithms take two implicit parameters, their keying material
      determined from <code>KeyInfo</code> and the octet stream output by
      <code>CanonicalizationMethod</code>. Signature and MAC algorithms are
      syntactically identical but a signature implies public key cryptography.
    </p>
    <h4>
      6.4.1 <a id="sec-DSA" name="sec-DSA">DSA</a>
    </h4>
    <dl>
      <dt>
        Identifier:
      </dt>
      <dd>
        <a id="dsa-sha1" name="dsa-sha1"
        href="http://www.w3.org/2000/09/xmldsig#dsa-sha1">http://www.w3.org/2000/09/xmldsig#dsa-sha1</a>
      </dd>
    </dl>
    <p>
      The DSA algorithm [<a href="#ref-DSS">DSS</a>] takes no explicit parameters. An
      example of a DSA <code>SignatureMethod</code> element is:
    </p>
<pre class="xml-example">
   <code>&lt;SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/&gt;</code>
</pre>
    <p>
      The output of the DSA algorithm consists of a pair of integers usually referred
      by the pair (r, s). The signature value consists of the base64 encoding of the
      concatenation of two octet-streams that respectively result from the
      octet-encoding of the values r and s in that order. Integer to octet-stream
      conversion must be done according to the I2OSP operation defined in the <a
      href="http://www.ietf.org/rfc/rfc2437.txt">RFC 2437</a> [<a
      href="#ref-PKCS1">PKCS1</a>] specification with a <code>l</code> parameter equal
      to 20. For example, the SignatureValue element for a DSA signature
      (<code>r</code>, <code>s</code>) with values specified in hexadecimal:
    </p>
<pre class="xml-example">
   <code>r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0</code> 
   <code>s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8</code>
</pre>
    <p>
      from the example in Appendix 5 of the DSS standard would be
    </p>
<pre class="xml-example">
   <code>&lt;SignatureValue&gt;</code>
   <code>i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==&lt;/SignatureValue&gt;</code>
</pre>
    <h4>
      6.4.2 <a id="sec-PKCS1" name="sec-PKCS1">PKCS1</a> (RSA-SHA1)
    </h4>
    <dl>
      <dt>
        Identifier:
      </dt>
      <dd>
        <a id="rsa-sha1" href="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
        name="rsa-sha1">http://www.w3.org/2000/09/xmldsig#rsa-sha1</a>
      </dd>
    </dl>
    <p>
      The expression "RSA algorithm" as used in this draft refers to the
      RSASSA-PKCS1-v1_5 algorithm described in <a
      href="http://www.ietf.org/rfc/rfc2437.txt">RFC 2437</a> [<a
      href="#ref-PKCS1">PKCS1</a>]. The RSA algorithm takes no explicit parameters. An
      example of an RSA SignatureMethod element is:
    </p>
<pre class="xml-example">
   <code>&lt;SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/&gt;</code>
</pre>
    <p>
      The <code>SignatureValue</code> content for an RSA signature is the base64 [<a
      href="#ref-MIME">MIME</a>] encoding of the octet string computed as per <a
      href="http://www.ietf.org/rfc/rfc2437.txt">RFC 2437</a> [<a
      href="#ref-PKCS1">PKCS1</a>, section 8.1.1: Signature generation for the
      RSASSA-PKCS1-v1_5 signature scheme]. As specified in the EMSA-PKCS1-V1_5-ENCODE
      function <a href="http://www.ietf.org/rfc/rfc2437.txt">RFC 2437</a> [<a
      href="#ref-PKCS1">PKCS1</a>, section 9.2.1], the value input to the signature
      function MUST contain a pre-pended algorithm object identifier for the hash
      function, but the availability of an ASN.1 parser and recognition of OIDs is not
      required of a signature verifier. The PKCS#1 v1.5 representation appears as:
    </p>
<pre class="xml-example">
   CRYPT (PAD (ASN.1 (OID, DIGEST (data))))
</pre>
    <p>
      Note that the padded ASN.1 will be of the following form:
    </p>
<pre class="xml-example">
   01 | FF* | 00 | prefix | hash
</pre>
    <p>
      where "|" is concatenation, "01", "FF", and "00" are fixed octets of the
      corresponding hexadecimal value, "hash" is the SHA1 digest of the data, and
      "prefix" is the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC
      2437], that is,
    </p>
<pre class="xml-example">
   hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
</pre>
    <p>
      This prefix is included to make it easier to use standard cryptographic
      libraries. The FF octet MUST be repeated the maximum number of times such that
      the value of the quantity being CRYPTed is one octet shorter than the RSA
      modulus.
    </p>
    <p>
      The resulting base64 [<a href="#ref-MIME">MIME</a>] string is the value of the
      child text node of the SignatureValue element, e.g.
    </p>
<pre class="xml-example">
&lt;SignatureValue&gt;
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
&lt;/SignatureValue&gt;
</pre>
    <h3>
      6.5 <a id="sec-c14nAlg" name="sec-c14nAlg">Canonicalization Algorithms</a>
    </h3>
    <p>
      If canonicalization is performed over octets, the canonicalization algorithms
      take two implicit parameters: the content and its charset. The charset is derived
      according to the rules of the transport protocols and media types (e.g, RFC2376
      [<a href="#ref-XML-MT">XML-MT</a>] defines the media types for XML). This
      information is necessary to correctly sign and verify documents and often
      requires careful server side configuration.
    </p>
    <p>
      Various canonicalization algorithms require conversion to [<a
      href="#ref-UTF-8">UTF-8</a>].The two algorithms below understand at least [<a
      href="#ref-UTF-8">UTF-8</a>] and [<a href="#ref-UTF-16">UTF-16</a>] as input
      encodings. We RECOMMEND that externally specified algorithms do the same.
      Knowledge of other encodings is OPTIONAL.
    </p>
    <p>
      Various canonicalization algorithms transcode from a non-Unicode encoding to
      Unicode. The two algorithms below perform text normalization during transcoding
      [<a href="#ref-NFC">NFC</a>, <a href="#ref-NFC-Corrigendum">NFC-Corrigendum</a>].
      We RECOMMEND that externally specified canonicalization algorithms do the same.
      (Note, there can be ambiguities in converting existing charsets to Unicode, for
      an example see the XML Japanese Profile [<a
      href="#ref-XML-Japanese">XML-Japanese</a>] Note.)
    </p>
    <h4>
      6.5.1 <a id="sec-Canonical" name="sec-Canonical">Canonical</a> XML
    </h4>
    <dl>
      <dt>
        Identifier for REQUIRED Canonical XML (omits comments):
      </dt>
      <dd>
        <a
        href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a>
      </dd>
    </dl>
    <dl>
      <dt>
        Identifier for Canonical XML with Comments:
      </dt>
      <dd>
        <a
        href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments">http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments</a>
      </dd>
    </dl>
    <p>
      An example of an XML canonicalization element is:
    </p>
<pre class="xml-example">
   <code>&lt;CanonicalizationMethod Algorithm="</code>http://www.w3.org/TR/2001/REC-xml-c14n-20010315<code>"/&gt;</code>
</pre>
    <p>
      The normative specification of Canonical XML is [<a
      href="#ref-XML-C14N">XML-C14N</a>]. The algorithm is capable of taking as input
      either an octet stream or an XPath node-set (or sufficiently functional
      alternative). The algorithm produces an octet stream as output. Canonical XML is
      easily parameterized (via an additional URI) to omit or retain comments.
    </p>
    <h3>
      6.6 <a id="sec-TransformAlg" name="sec-TransformAlg"><code>Transform</code></a>
      Algorithms
    </h3>
    <p>
      A <code>Transform</code> algorithm has a single implicit parameter: an octet
      stream from the <code>Reference</code> or the output of an earlier
      <code>Transform</code>.
    </p>
    <p>
      Application developers are strongly encouraged to support all transforms listed
      in this section as RECOMMENDED unless the application environment has resource
      constraints that would make such support impractical. Compliance with this
      recommendation will maximize application interoperability and libraries should be
      available to enable support of these transforms in applications without extensive
      development.
    </p>
    <h4>
      6.6.1 <a id="sec-Canonicalization"
      name="sec-Canonicalization">Canonicalization</a>
    </h4>
    <p>
      Any canonicalization algorithm that can be used for
      <code>CanonicalizationMethod</code> (such as those in&nbsp; <a
      href="#sec-c14nAlg">Canonicalization Algorithms</a> (section 6.5)) can be used as
      a <code>Transform</code>.
    </p>
    <h4>
      6.6.2 <a id="sec-Base-64" name="sec-Base-64">Base64</a>
    </h4>
    <dl>
      <dt>
        Identifiers:
      </dt>
      <dd>
        <a id="base64" href="http://www.w3.org/2000/09/xmldsig#base64"
        name="base64">http://www.w3.org/2000/09/xmldsig#base64</a>
      </dd>
    </dl>
    <p>
      The normative specification for base64 decoding transforms is [<a
      href="#ref-MIME">MIME</a>]. The base64 <code>Transform</code> element has no
      content. The input is decoded by the algorithms. This transform is useful if an
      application needs to sign the raw data associated with the encoded content of an
      element.
    </p>
    <p>
      This transform requires an octet stream for input. If an XPath node-set (or
      sufficiently functional alternative) is given as input, then it is converted to
      an octet stream by performing operations logically equivalent to 1) applying an
      XPath transform with expression <code>self::text()</code>, then 2) taking the
      string-value of the node-set. Thus, if an XML element is identified by a barename
      XPointer in the <code>Reference</code> URI, and its content consists solely of
      base64 encoded character data, then this transform automatically strips away the
      start and end tags of the identified element and any of its descendant elements
      as well as any descendant comments and processing instructions. The output of
      this transform is an octet stream.
    </p>
    <h4>
      6.6.3 <a name="sec-XPath" id="sec-XPath">XPath</a> Filtering
    </h4>
    <dl>
      <dt>
        Identifier:
      </dt>
      <dd>
        <a
        href="http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/TR/1999/REC-xpath-19991116</a>
      </dd>
    </dl>
    <p>
      The normative specification for XPath expression evaluation is [<a
      href="#ref-XPath">XPath</a>]. The XPath expression to be evaluated appears as the
      character content of a transform parameter child element named
      <code>XPath</code>.
    </p>
    <p>
      The input required by this transform is an XPath node-set. Note that if the
      actual input is an XPath node-set resulting from a null URI or barename XPointer
      dereference, then comment nodes will have been omitted. If the actual input is an
      octet stream, then the application MUST convert the octet stream to an XPath
      node-set suitable for use by Canonical XML with Comments. (A subsequent
      application of the REQUIRED Canonical XML algorithm would strip away these
      comments.) In other words, the input node-set should be equivalent to the one
      that would be created by the following process:
    </p>
    <ol>
      <li>
        Initialize an XPath evaluation context by setting the initial node equal to the
        input XML document's root node, and set the context position and size to 1.
      </li>
      <li>
        Evaluate the XPath expression <code>(//. | //@* | //namespace::*)</code>
      </li>
    </ol>
    <p>
      The evaluation of this expression includes all of the document's nodes (including
      comments) in the node-set representing the octet stream.
    </p>
    <p>
      The transform output is also an XPath node-set. The XPath expression appearing in
      the <code>XPath</code> parameter is evaluated once for each node in the input
      node-set. The result is converted to a boolean. If the boolean is true, then the
      node is included in the output node-set. If the boolean is false, then the node
      is omitted from the output node-set.
    </p>
    <p>
      <strong>Note:</strong> Even if the input node-set has had comments removed, the
      comment nodes still exist in the underlying parse tree and can separate text
      nodes. For example, the markup <code>&lt;e&gt;Hello, &lt;!-- comment
      --&gt;world!&lt;/e&gt;</code> contains two text nodes. Therefore, the expression
      <code>self::text()[string()="Hello, world!"]</code> would fail. Should this
      problem arise in the application, it can be solved by either canonicalizing the
      document before the XPath transform to physically remove the comments or by
      matching the node based on the parent element's string value (e.g. by using the
      expression <code>self::text()[string(parent::e)="Hello, world!"]</code>).
    </p>
    <p>
      The primary purpose of this transform is to ensure that only specifically defined
      changes to the input XML document are permitted after the signature is affixed.
      This is done by omitting precisely those nodes that are allowed to change once
      the signature is affixed, and including all other input nodes in the output. It
      is the responsibility of the XPath expression author to include all nodes whose
      change could affect the interpretation of the transform output in the application
      context.
    </p>
    <p>
      An important scenario would be a document requiring two enveloped signatures.
      Each signature must omit itself from its own digest calculations, but it is also
      necessary to exclude the second signature element from the digest calculations of
      the first signature so that adding the second signature does not break the first
      signature.
    </p>
    <p>
      The XPath transform establishes the following evaluation context for each node of
      the input node-set:
    </p>
    <ul>
      <li>
        A <strong>context node</strong> equal to a node of the input node-set.
      </li>
      <li>
        A <strong>context position</strong>, initialized to 1.
      </li>
      <li>
        A <strong>context size</strong>, initialized to 1.
      </li>
      <li>
        A <strong>library of functions</strong> equal to the function set defined in
        [<a href="#ref-XPath">XPath]</a> plus a function named <strong><a
        href="#function-here">here</a></strong>.
      </li>
      <li>
        A set of variable bindings. No means for initializing these is defined. Thus,
        the set of variable bindings used when evaluating the XPath expression is
        empty, and use of a variable reference in the XPath expression results in an
        error.
      </li>
      <li>
        The set of namespace declarations in scope for the XPath expression.
      </li>
    </ul>
    <p>
      As a result of the context node setting, the XPath expressions appearing in this
      transform will be quite similar to those used in used in [<a
      href="#ref-XSLT">XSLT</a>], except that the size and position are always 1 to
      reflect the fact that the transform is automatically visiting every node (in
      XSLT, one recursively calls the command <code>apply-templates</code> to visit the
      nodes of the input tree).
    </p>
    <p>
      <strong>The function <code>here()</code> is defined as follows:</strong>
    </p>
    <p>
      <a name="function-here" id="function-here"><strong>Function:</strong>
      <em>node-set</em> <strong>here</strong>()</a>
    </p>
    <p>
      The <strong><a href="#function-here">here</a></strong> function returns a
      node-set containing the attribute or processing instruction node or the parent
      element of the text node that directly bears the XPath expression.&nbsp; This
      expression results in an error if the containing XPath expression does not appear
      in the same XML document against which the XPath expression is being evaluated.
    </p>
    <p>
      As an example, consider creating an enveloped signature (a <code>Signature</code>
      element that is a descendant of an element being signed). Although the signed
      content should not be changed after signing, the elements within the
      <code>Signature</code> element are changing (e.g. the digest value must be put
      inside the <code>DigestValue</code> and the <code>SignatureValue</code> must be
      subsequently calculated). One way to prevent these changes from invalidating the
      digest value in <code>DigestValue</code> is to add an XPath
      <code>Transform</code> that omits all <code>Signature</code> elements and their
      descendants. For example,
    </p>
<pre class="xml-example">
   &lt;Document&gt;
   ...   
   &lt;Signature xmlns="http://www.w3.org/2000/09/xmldsig#"&gt;
     &lt;SignedInfo&gt;
      ...
       &lt;Reference URI=""&gt;
         &lt;Transforms&gt;
           &lt;Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"&gt;
             &lt;XPath xmlns:dsig="&amp;dsig;"&gt;
             not(ancestor-or-self::dsig:Signature)
             &lt;/XPath&gt;
           &lt;/Transform&gt;
         &lt;/Transforms&gt;
         &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt;
         &lt;DigestValue&gt;&lt;/DigestValue&gt;
       &lt;/Reference&gt;
     &lt;/SignedInfo&gt;
     &lt;SignatureValue&gt;&lt;/SignatureValue&gt;
    &lt;/Signature&gt;
    ...
   &lt;/Document&gt;
</pre>
    <p>
      Due to the null <code>Reference</code> URI in this example, the XPath transform
      input node-set contains all nodes in the entire parse tree starting at the root
      node (except the comment nodes). For each node in this node-set, the node is
      included in the output node-set except if the node or one of its ancestors has a
      tag of <code>Signature</code> that is in the namespace given by the replacement
      text for the entity <code>&amp;dsig;</code>.
    </p>
    <p>
      A more elegant solution uses the <strong><a
      href="#function-here">here</a></strong> function to omit only the
      <code>Signature</code> containing the XPath Transform, thus allowing enveloped
      signatures to sign other signatures. In the example above, use the
      <code>XPath</code> element:
    </p>
<pre class="xml-example">
   &lt;XPath xmlns:dsig="&amp;dsig;"&gt;
   count(ancestor-or-self::dsig:Signature |
   here()/ancestor::dsig:Signature[1]) &gt;
   count(ancestor-or-self::dsig:Signature)&lt;/XPath&gt;
</pre>
    <p>
      Since the XPath equality operator converts node sets to string values before
      comparison, we must instead use the XPath union operator (|). For each node of
      the document, the predicate expression is true if and only if the node-set
      containing the node and its <code>Signature</code> element ancestors does not
      include the enveloped <code>Signature</code> element containing the XPath
      expression (the union does not produce a larger set if the enveloped
      <code>Signature</code> element is in the node-set given by
      <code>ancestor-or-self::Signature</code>).
    </p>
    <h4>
      6.6.4 <a name="sec-EnvelopedSignature" id="sec-EnvelopedSignature">Enveloped
      Signature</a> Transform
    </h4>
    <dl>
      <dt>
        Identifier:
      </dt>
      <dd>
        <a href="http://www.w3.org/2000/09/xmldsig#enveloped-signature"
        name="enveloped-signature"
        id="enveloped-signature">http://www.w3.org/2000/09/xmldsig#enveloped-signature</a>
      </dd>
    </dl>
    <p>
      An enveloped signature transform <strong><em>T</em></strong> removes the whole
      <code>Signature</code> element containing <strong><em>T</em></strong> from the
      digest calculation of the <code>Reference</code> element containing
      <strong><em>T</em></strong>. The entire string of characters used by an XML
      processor to match the <code>Signature</code> with the XML production
      <code>element</code> is removed. The output of the transform is equivalent to the
      output that would result from replacing <strong><em>T</em></strong> with an XPath
      transform containing the following <code>XPath</code> parameter element:
    </p>
<pre class="xml-example">
   &lt;XPath xmlns:dsig="&amp;dsig;"&gt;
   count(ancestor-or-self::dsig:Signature |
   here()/ancestor::dsig:Signature[1]) &gt;
   count(ancestor-or-self::dsig:Signature)&lt;/XPath&gt;
</pre>
    <p>
      The input and output requirements of this transform are identical to those of the
      XPath transform, but may only be applied to a node-set from its parent XML
      document. Note that it is not necessary to use an XPath expression evaluator to
      create this transform. However, this transform MUST produce output in exactly the
      same manner as the XPath transform parameterized by the XPath expression above.
    </p>
    <h4>
      6.6.5 <a name="sec-XSLT" id="sec-XSLT">XSLT</a> Transform
    </h4>
    <dl>
      <dt>
        Identifier:
      </dt>
      <dd>
        <a
        href="http://www.w3.org/TR/1999/REC-xslt-19991116">http://www.w3.org/TR/1999/REC-xslt-19991116</a>
      </dd>
    </dl>
    <p>
      The normative specification for XSL Transformations is [<a
      href="#ref-XSLT">XSLT</a>]. Specification of a namespace-qualified stylesheet
      element, which MUST be the sole child of the <code>Transform</code> element,
      indicates that the specified style sheet should be used. Whether this
      instantiates in-line processing of local XSLT declarations within the resource is
      determined by the XSLT processing model; the ordered application of multiple
      stylesheet may require multiple <code>Transforms</code>. No special provision is
      made for the identification of a remote stylesheet at a given URI because it can
      be communicated via an <a
      href="http://www.w3.org/TR/1999/REC-xslt-19991116#section-Combining-Stylesheets"><code>
      xsl:include</code></a> or <a
      href="http://www.w3.org/TR/1999/REC-xslt-19991116#section-Combining-Stylesheets"><code>
      xsl:import</code></a> within the <code>stylesheet</code> child of the
      <code>Transform</code>.
    </p>
    <p>
      This transform requires an octet stream as input. If the actual input is an XPath
      node-set, then the signature application should attempt to convert it to octets
      (apply <a href="#sec-Canonical">Canonical XML</a>]) as described in <a
      href="#sec-ReferenceProcessingModel">the Reference Processing Model</a> (section
      4.3.3.2).
    </p>
    <p>
      The output of this transform is an octet stream. The processing rules for the XSL
      style sheet or transform element are stated in the XSLT specification [<a
      href="#ref-XSLT">XSLT</a>]. We RECOMMEND that XSLT transform authors use an
      output method of <code>xml</code> for XML and HTML. As XSLT implementations do
      not produce consistent serializations of their output, we further RECOMMEND
      inserting a transform after the XSLT transform to canonicalize the output. These
      steps will help to ensure interoperability of the resulting signatures among
      applications that support the XSLT transform. Note that if the output is actually
      HTML, then the result of these steps is logically equivalent [<a
      href="#ref-XHTML">XHTML</a>].
    </p>
    <h2>
      7.0 <a id="sec-XML-Canonicalization" name="sec-XML-Canonicalization">XML
      Canonicalization</a> and Syntax Constraint Considerations
    </h2>
    <p>
      Digital signatures only work if the verification calculations are performed on
      exactly the same bits as the signing calculations. If the surface representation
      of the signed data can change between signing and verification, then some way to
      standardize the changeable aspect must be used before signing and verification.
      For example, even for simple ASCII text there are at least three widely used line
      ending sequences. If it is possible for signed text to be modified from one line
      ending convention to another between the time of signing and signature
      verification, then the line endings need to be canonicalized to a standard form
      before signing and verification or the signatures will break.
    </p>
    <p>
      XML is subject to surface representation changes and to processing which discards
      some surface information. For this reason, XML digital signatures have a
      provision for indicating canonicalization methods in the signature so that a
      verifier can use the same canonicalization as the signer.
    </p>
    <p>
      Throughout this specification we distinguish between the canonicalization of a
      <code>Signature</code> element and other signed XML data objects. It is possible
      for an isolated XML document to be treated as if it were binary data so that no
      changes can occur. In that case, the digest of the document will not change and
      it need not be canonicalized if it is signed and verified as such. However, XML
      that is read and processed using standard XML parsing and processing techniques
      is frequently changed such that some of its surface representation information is
      lost or modified. In particular, this will occur in many cases for the
      <code>Signature</code> and enclosed <code>SignedInfo</code> elements since they,
      and possibly an encompassing XML document, will be processed as XML.
    </p>
    <p>
      Similarly, these considerations apply to <code>Manifest</code>,
      <code>Object</code>, and <code>SignatureProperties</code> elements if those
      elements have been digested, their <code>DigestValue</code> is to be checked, and
      they are being processed as XML.
    </p>
    <p>
      The kinds of changes in XML that may need to be canonicalized can be divided into
      four categories. There are those related to the basic [<a
      href="#ref-XML">XML</a>], as described in 7.1 below. There are those related to
      [<a href="#ref-DOM">DOM</a>], [<a href="#ref-SAX">SAX</a>], or similar processing
      as described in 7.2 below. Third, there is the possibility of coded character set
      conversion, such as between UTF-8 and UTF-16, both of which all&nbsp; [<a
      href="#ref-XML">XML</a>] compliant processors are required to support, which is
      described in the paragraph immediately below. And, fourth, there are changes that
      related to namespace declaration and XML namespace attribute context as described
      in 7.3 below.
    </p>
    <p>
      Any canonicalization algorithm should yield output in a specific fixed coded
      character set. All canonicalization <a href="#sec-c14nAlg">algorithms</a>
      identified in this document use UTF-8 (without a byte order mark (BOM)) and do
      not provide character normalization. We RECOMMEND that signature applications
      create XML content (<code>Signature</code> elements and their
      descendents/content) in Normalization Form C [<a href="#ref-NFC">NFC</a>, <a
      href="#ref-NFC-Corrigendum">NFC-Corrigendum</a>] and check that any XML being
      consumed is in that form as well; (if not, signatures may consequently fail to
      validate). Additionally, none of these algorithms provide data type
      normalization. Applications that normalize data types in varying formats (e.g.,
      (true, false) or (1,0)) may not be able to validate each other's signatures.
    </p>
    <h3>
      7.1 <a id="sec-XML-1" name="sec-XML-1">XML 1.0</a>, Syntax Constraints, and
      Canonicalization
    </h3>
    <p>
      XML 1.0 [<a href="#ref-XML">XML</a>] defines an interface where a conformant
      application reading XML is given certain information from that XML and not other
      information. In particular,
    </p>
    <ol>
      <li>
        line endings are normalized to the single character #xA by dropping #xD
        characters if they are immediately followed by a #xA and replacing them with
        #xA in all other cases,
      </li>
      <li>
        missing attributes declared to have default values are provided to the
        application as if present with the default value,&nbsp;
      </li>
      <li>
        character references are replaced with the corresponding character,
      </li>
      <li>
        entity references are replaced with the corresponding declared entity,
      </li>
      <li>
        attribute values are normalized by 
        <ol>
          <li>
            replacing character and entity references as above,
          </li>
          <li>
            replacing occurrences of #x9, #xA, and #xD with #x20 (space) except that
            the sequence #xD#xA is replaced by a single space, and
          </li>
          <li>
            if the attribute is not declared to be CDATA, stripping all leading and
            trailing spaces and replacing all interior runs of spaces with a single
            space.
          </li>
        </ol>
      </li>
    </ol>
    <p>
      Note that items (2), (4), and (5.3) depend on the presence of a schema, DTD or
      similar declarations. The <code>Signature</code> element type is <a
      href="http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#cvc-elt-lax">laxly
      schema valid</a> [<a href="#ref-XML-schema">XML-schema</a>], consequently
      external XML or even XML within the same document as the signature may be (only)
      well-formed or from another namespace (where permitted by the signature schema);
      the noted items may not be present. Thus, a signature with such content will only
      be verifiable by other signature applications if the following syntax constraints
      are observed when generating any signed material including the
      <code>SignedInfo</code> element:
    </p>
    <ol>
      <li>
        attributes having default values be explicitly present,
      </li>
      <li>
        all entity references (except "amp", "lt", "gt", "apos", "quot", and other
        character entities not representable in the encoding chosen) be expanded,
      </li>
      <li>
        attribute value white space be normalized
      </li>
    </ol>
    <h3>
      7.2 <a id="sec-DOM-SAX" name="sec-DOM-SAX">DOM/SAX</a> Processing and
      Canonicalization
    </h3>
    <p>
      In addition to the canonicalization and syntax constraints discussed above, many
      XML applications use the Document Object Model [<a href="#ref-DOM">DOM</a>] or
      the Simple API for XML&nbsp; [<a href="#ref-SAX">SAX</a>]. DOM maps XML into a
      tree structure of nodes and typically assumes it will be used on an entire
      document with subsequent processing being done on this tree. SAX converts XML
      into a series of events such as a start tag, content, etc. In either case, many
      surface characteristics such as the ordering of attributes and insignificant
      white space within start/end tags is lost. In addition, namespace declarations
      are mapped over the nodes to which they apply, losing the namespace prefixes in
      the source text and, in most cases, losing where namespace declarations appeared
      in the original instance.
    </p>
    <p>
      If an XML Signature is to be produced or verified on a system using the DOM or
      SAX processing, a canonical method is needed to serialize the relevant part of a
      DOM tree or sequence of SAX events. XML canonicalization specifications, such as
      [<a href="#ref-XML-C14N">XML-C14N</a>], are based only on information which is
      preserved by DOM and SAX. For an XML Signature to be verifiable by an
      implementation using DOM or SAX, not only must the <a href="#sec-XML-1">XML 1.0
      syntax constraints given in the previous section</a> be followed but an
      appropriate XML canonicalization MUST be specified so that the verifier can
      re-serialize DOM/SAX mediated input into the same octet stream that was signed.
    </p>
    <h3>
      7.3 <a name="sec-NamespaceContext" id="sec-NamespaceContext">Namespace
      Context</a> and Portable Signatures
    </h3>
    <p>
      In [<a href="#ref-XPath">XPath</a>] and consequently the Canonical XML data model
      an element has namespace nodes that correspond to those declarations within the
      element and its ancestors:
    </p>
    <blockquote>
      <p>
        "<strong>Note:</strong> An element <strong><em>E</em></strong> has namespace
        nodes that represent its namespace declarations <em>as well as</em> any
        namespace declarations made by its ancestors that have not been overridden in
        <strong><em>E</em></strong>'s declarations, the default namespace if it is
        non-empty, and the declaration of the prefix <code>xml</code>." [<a
        href="#ref-XML-C14N">XML-C14N</a>]
      </p>
    </blockquote>
    <p>
      When serializing a <code>Signature</code> element or signed XML data that's the
      child of other elements using these data models, that <code>Signature</code>
      element and its children, may contain namespace declarations from its ancestor
      context. In addition, the Canonical XML and Canonical XML with Comments
      algorithms import all xml namespace attributes (such as <code>xml:lang</code>)
      from the nearest ancestor in which they are declared to the apex node of
      canonicalized XML unless they are already declared at that node. This may
      frustrate the intent of the signer to create a signature in one context which
      remains valid in another. For example, given a signature which is a child of
      <code>B</code> and a grandchild of <code>A</code>:
    </p>
<pre class="xml-example,">
   &lt;A xmlns:n1="&amp;foo;"&gt;
     &lt;B xmlns:n2="&amp;bar;"&gt;
       &lt;Signature xmlns="&amp;dsig;"&gt;   ...
         &lt;Reference URI="#signme"/&gt; ...
       &lt;/Signature&gt;
       &lt;C ID="signme" xmlns="&amp;baz;"/&gt;
     &lt;/B&gt;
   &lt;/A&gt;
</pre>
    <p>
      when either the element <code>B</code> or the signed element <code>C</code> is
      moved into a [<a href="#ref-SOAP">SOAP</a>] envelope for transport:
    </p>
<pre class="xml-example,">
   &lt;SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"&gt;
     ...
     &lt;SOAP:Body&gt;
       &lt;B xmlns:n2="&amp;bar;"&gt;
         &lt;Signature xmlns="&amp;dsig;"&gt;
           ...
         &lt;/Signature&gt;
         &lt;C ID="signme" xmlns="&amp;baz;"/&gt;
       &lt;/B&gt;
     &lt;/SOAP:Body&gt;
   &lt;/SOAP:Envelope&gt;
</pre>
    <p>
      The canonical form of the signature in this context will contain new namespace
      declarations from the <code>SOAP:Envelope</code> context, invalidating the
      signature. Also, the canonical form will lack namespace declarations it may have
      originally had from element <code>A</code>'s context, also invalidating the
      signature. To avoid these problems, the application may:
    </p>
    <ol>
      <li>
        Rely upon the enveloping application to properly divorce its body (the
        signature payload) from the context (the envelope) before the signature is
        validated. Or,
      </li>
      <li>
        Use a canonicalization method that "repels/excludes" instead of "attracts"
        ancestor context. [<a href="#ref-XML-C14N">XML-C14N</a>] purposefully attracts
        such context.
      </li>
    </ol>
    <h2>
      8.0 <a id="sec-Security" name="sec-Security">Security Considerations</a>
    </h2>
    <p>
      The XML Signature specification provides a very flexible digital signature
      mechanism. Implementors must give consideration to their application threat
      models and to the following factors.
    </p>
    <h3>
      8.1 <a name="sec-Security-Transofrms" id="sec-Security-Transofrms">Transforms</a>
    </h3>
    <p>
      A requirement of this specification is to permit signatures to "apply to&nbsp;a
      part or totality of a XML document." (See [<a
      href="#ref-XML-Signature-RD">XML-Signature-RD</a>, section 3.1.3].) The
      <code>Transforms</code> mechanism meets this requirement by permitting one to
      sign data derived from processing the content of the identified resource. For
      instance, applications that wish to sign a form, but permit users to enter
      limited field data without invalidating a previous signature on the form might
      use [<a href="#ref-XPath">XPath</a>] to exclude those portions the user needs to
      change. <code>Transforms</code> may be arbitrarily specified and may include
      encoding transforms, canonicalization instructions or even XSLT transformations.
      Three cautions are raised with respect to this feature in the following sections.
    </p>
    <p>
      Note, <a class="link-def" href="#def-ValidationCore">core validation</a> behavior
      does not confirm that the signed data was obtained by applying each step of the
      indicated transforms. (Though it does check that the digest of the resulting
      content matches that specified in the signature.)&nbsp; For example, some
      applications may be satisfied with verifying an XML signature over a cached copy
      of already transformed data. Other applications might require that content be
      freshly dereferenced and transformed.
    </p>
    <h4>
      8.1.1 <strong><a id="sec-Secure" name="sec-Secure">Only What is Signed is
      Secure</a></strong>
    </h4>
    <p>
      First, obviously, signatures over a transformed document do not secure any
      information discarded by transforms: only what is signed is secure.
    </p>
    <p>
      Note that the use of Canonical&nbsp; XML [<a href="#ref-XML-C14N">XML-C14N</a>]
      ensures that all internal entities and XML namespaces are expanded within the
      content being signed. All entities are replaced with their definitions and the
      canonical form explicitly represents the namespace that an element would
      otherwise inherit. Applications that do not canonicalize XML content (especially
      the <code>SignedInfo</code> element) SHOULD NOT use internal entities and SHOULD
      represent the namespace explicitly within the content being signed since they can
      not rely upon canonicalization to do this for them. Also, users concerned with
      the integrity of the element type definitions associated with the XML instance
      being signed may wish to sign those definitions as well (i.e., the schema, DTD,
      or natural language description associated with the namespace/identifier).
    </p>
    <p>
      Second, an envelope containing signed information is not secured by the
      signature. For instance, when an encrypted envelope contains a signature, the
      signature does not protect the authenticity or integrity of unsigned envelope
      headers nor its ciphertext form, it only secures the plaintext actually signed.
    </p>
    <h4>
      8.1.2 <a id="sec-Seen" name="sec-Seen">Only What is "Seen" Should be Signed</a>
    </h4>
    <p>
      Additionally, the signature secures any information introduced by the transform:
      only what is "seen" (that which is represented to the user via visual, auditory
      or other media) should be signed. If signing is intended to convey the judgment
      or consent of a user (an automated mechanism or person), then it is normally
      necessary to secure as exactly as practical the information that was presented to
      that user. Note that this can be accomplished by literally signing what was
      presented, such as the screen images shown a user. However, this may result in
      data which is difficult for subsequent software to manipulate. Instead, one can
      sign the data along with whatever filters, style sheets, client profile or other
      information that affects its presentation.
    </p>
    <h4>
      8.1.3 <a name="sec-See" id="sec-See">"See" What is Signed</a>
    </h4>
    <p>
      Just as a user should only sign what he or she "sees," persons and automated
      mechanism that trust the validity of a transformed document on the basis of a
      valid signature should operate over the data that was transformed (including
      canonicalization) and signed, not the original pre-transformed data. This
      recommendation applies to transforms specified within the signature as well as
      those included as part of the document itself. For instance, if an XML document
      includes an <a
      href="http://www.w3.org/TR/xslt#section-Creating-Processing-Instructions">embedded
      style sheet</a> [<a href="#ref-XSLT">XSLT</a>] it is the transformed document
      that should be represented to the user and signed. To meet this recommendation
      where a document references an external style sheet, the content of that external
      resource should also be signed as via a signature <code>Reference</code>
      otherwise the content of that external content might change which alters the
      resulting document without invalidating the signature.
    </p>
    <p>
      Some applications might operate over the original or intermediary data but should
      be extremely careful about potential weaknesses introduced between the original
      and transformed data. This is a trust decision about the character and meaning of
      the transforms that an application needs to make with caution. Consider a
      canonicalization algorithm that normalizes character case (lower to upper) or
      character composition ('e and accent' to 'accented-e'). An adversary could
      introduce changes that are normalized and consequently inconsequential to
      signature validity but material to a DOM processor. For instance, by changing the
      case of a character one might influence the result of an XPath selection. A
      serious risk is introduced if that change is normalized for signature validation
      but the processor operates over the original data and returns a different result
      than intended.
    </p>
    <p>
      As a result:
    </p>
    <ul>
      <li>
        All documents operated upon and generated by signature applications MUST be in
        [<a href="#ref-NFC">NFC</a>, <a
        href="#ref-NFC-Corrigendum">NFC-Corrigendum</a>] (otherwise intermediate
        processors might unintentionally break the signature)
      </li>
      <li>
        Encoding normalizations SHOULD NOT be done as part of a signature transform, or
        (to state it another way) if normalization does occur, the application SHOULD
        always "see" (operate over) the normalized form.
      </li>
    </ul>
    <h3>
      8.2 <a id="sec-Check" name="sec-Check">Check the Security Model</a>
    </h3>
    <p>
      This specification uses public key signatures and keyed hash authentication
      codes. These have substantially different security models. Furthermore, it
      permits user specified algorithms which may have other models.
    </p>
    <p>
      With public key signatures, any number of parties can hold the public key and
      verify signatures while only the parties with the private key can create
      signatures. The number of holders of the private key should be minimized and
      preferably be one. Confidence by verifiers in the public key they are using and
      its binding to the entity or capabilities represented by the corresponding
      private key is an important issue, usually addressed by certificate or online
      authority systems.
    </p>
    <p>
      Keyed hash authentication codes, based on secret keys, are typically much more
      efficient in terms of the computational effort required but have the
      characteristic that all verifiers need to have possession of the same key as the
      signer. Thus any verifier can forge signatures.
    </p>
    <p>
      This specification permits user provided signature algorithms and keying
      information designators. Such user provided algorithms may have different
      security models. For example, methods involving biometrics usually depend on a
      physical characteristic of the authorized user that can not be changed the way
      public or secret keys can be and may have other security model differences.
    </p>
    <h3>
      8.3 Algorithms, <a id="sec-KeyLength" name="sec-KeyLength">Key Lengths</a>,
      Certificates, Etc.
    </h3>
    <p>
      The strength of a particular signature depends on all links in the security
      chain. This includes the signature and digest algorithms used, the strength of
      the key generation [<a href="#ref-RANDOM">RANDOM</a>] and the size of the key,
      the security of key and certificate authentication and distribution mechanisms,
      certificate chain validation policy, protection of cryptographic processing from
      hostile observation and tampering, etc.
    </p>
    <p>
      Care must be exercised by applications in executing the various algorithms that
      may be specified in an XML signature and in the processing of any "executable
      content" that might be provided to such algorithms as parameters, such as XSLT
      transforms. The algorithms specified in this document will usually be implemented
      via a trusted library but even there perverse parameters might cause unacceptable
      processing or memory demand. Even more care may be warranted with application
      defined algorithms.
    </p>
    <p>
      The security of an overall system will also depend on the security and integrity
      of its operating procedures, its personnel, and on the administrative enforcement
      of those procedures. All the factors listed in this section are important to the
      overall security of a system; however, most are beyond the scope of this
      specification.
    </p>
    <h2>
      9.0 <a id="sec-Schema" name="sec-Schema">Schema</a>, DTD, Data Model, and Valid
      Examples
    </h2>
    <dl>
      <dt>
        XML Signature Schema Instance
      </dt>
      <dd>
        <a href="xmldsig-core-schema.xsd">xmldsig-core-schema.xsd</a>
      </dd>
      <dd>
        Valid XML schema instance based on the 20001024 Schema/DTD [<a
        href="#ref-XML-schema">XML-Schema</a>].
      </dd>
      <dt>
        XML Signature DTD
      </dt>
      <dd>
        <a href="xmldsig-core-schema.dtd">xmldsig-core-schema.dtd</a>
      </dd>
      <dt>
        RDF Data Model
      </dt>
      <dd>
        <a href="xmldsig-datamodel-20000112.gif">xmldsig-datamodel-20000112.gif</a>
      </dd>
      <dt>
        XML Signature Object Example
      </dt>
      <dd>
        <a href="signature-example.xml">signature-example.xml</a>
      </dd>
      <dd>
        A cryptographical fabricated XML example that includes foreign content and
        validates under the schema, it also uses <code>schemaLocation</code> to aid
        automated schema fetching and validation.
      </dd>
      <dt>
        RSA XML Signature Example
      </dt>
      <dd>
        <a href="signature-example-rsa.xml">signature-example-rsa.xml</a>
      </dd>
      <dd>
        An XML Signature example with generated cryptographic values by Merlin Hughes
        and validated by Gregor Karlinger.
      </dd>
      <dt>
        DSA XML Signature Example
      </dt>
      <dd>
        <a href="signature-example-dsa.xml">signature-example-dsa.xml</a>
      </dd>
      <dd>
        Similar to above but uses DSA.
      </dd>
    </dl>
    <h2>
      10.0 <a id="sec-Definitions" name="sec-Definitions">Definitions</a>
    </h2>
    <dl>
      <dt>
        <a id="def-AuthenticationCode" name="def-AuthenticationCode">Authentication
        Code</a> (<a name="def-ProtectedChecksum" id="def-ProtectedChecksum">Protected
        Checksum</a>)
      </dt>
      <dd>
        A value generated from the application of a shared key to a message via a
        cryptographic algorithm such that it has the properties of <a
        href="#def-AuthenticationMessage" class="link-def">message authentication</a>
        (and <a href="#def-Integrity" class="link-def">integrity</a>) but not <a
        href="#def-AuthenticationSigner" class="link-def">signer authentication</a>.
        Equivalent to <em>protected checksum</em>, "A checksum that is computed for a
        data object by means that protect against active attacks that would attempt to
        change the checksum to make it match changes made to the data object."&nbsp;
        [<a href="#ref-SEC">SEC</a>]
      </dd>
      <dt>
        <a id="def-AuthenticationMessage"
        name="def-AuthenticationMessage">Authentication, Message</a>
      </dt>
      <dd>
        The property, given an <a href="#def-AuthenticationCode"
        class="link-def">authentication code</a>/<a href="#def-ProtectedChecksum"
        class="link-def">protected checksum</a>, that tampering with both the data and
        checksum, so as to introduce changes while seemingly preserving <a
        href="#def-Integrity" class="link-def">integrity</a>, are still detected. "A
        signature should identify what is signed, making it impracticable to falsify or
        alter either the signed matter or the signature without detection." [<a
        href="http://www.abanet.org/scitech/ec/isc/dsgfree.html">Digital Signature
        Guidelines</a>, <a href="#ref-ABA">ABA</a>].
      </dd>
      <dt>
        <a id="def-AuthenticationSigner"
        name="def-AuthenticationSigner">Authentication, Signer</a>
      </dt>
      <dd>
        The property that the identity of the signer is as claimed. "A signature should
        indicate who signed a document, message or record, and should be difficult for
        another person to produce without authorization." [<a
        href="http://www.abanet.org/scitech/ec/isc/dsgfree.html">Digital Signature
        Guidelines</a>, <a href="#ref-ABA">ABA</a>] Note, signer authentication is an
        application decision (e.g., does the signing key actually correspond to a
        specific identity) that is supported by, but out of scope, of this
        specification.
      </dd>
      <dt>
        <a name="def-Checksum" id="def-Checksum">Checksum</a>
      </dt>
      <dd>
        "A value that (a) is computed by a function that is dependent on the contents
        of a data object and (b) is stored or transmitted together with the object, for
        the purpose of detecting changes in the data."&nbsp; [<a
        href="#ref-SEC">SEC</a>]
      </dd>
      <dt>
        <a id="def-Core" name="def-Core">Core</a>
      </dt>
      <dd>
        The syntax and processing defined by this specification, including <a
        href="#def-ValidationCore" class="link-def">core validation</a>. We use this
        term to distinguish other markup, processing, and applications semantics from
        our own.
      </dd>
      <dt>
        <a id="def-DataObject" name="def-DataObject">Data Object</a> (Content/Document)
      </dt>
      <dd>
        The actual binary/octet data being operated on (transformed, digested, or
        signed) by an application -- frequently an <a
        href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7">HTTP
        entity</a> [<a href="#ref-HTTP">HTTP</a>]. Note that the proper noun
        <code>Object</code> designates a specific XML element. Occasionally we refer to
        a data object as a <em>document</em> or as a <em><a href="#def-Resource"
        class="link-def">resource</a>'s content</em>. The term <em>element content</em>
        is used to describe the data between XML start and end tags [<a
        href="#ref-XML">XML</a>]. The term <em>XML document</em> is used to describe
        data objects which conform to the XML specification [<a
        href="#ref-XML">XML</a>].
      </dd>
      <dt>
        <a id="def-Integrity" name="def-Integrity">Integrity</a>
      </dt>
      <dd>
        "The property that data has not been changed, destroyed, or lost in an
        unauthorized or accidental manner." [<a href="#ref-SEC">SEC</a>] A simple <a
        href="#def-Checksum" class="link-def">checksum</a> can provide integrity from
        incidental changes in the data; <a href="#def-AuthenticationMessage"
        class="link-def">message authentication</a> is similar but also protects
        against an active attack to alter the data whereby a change in the checksum is
        introduced so as to match the change in the data.&nbsp;
      </dd>
      <dt>
        <a id="def-Object" name="def-Object">Object</a>
      </dt>
      <dd>
        An XML Signature element wherein arbitrary (non-<a href="#def-Core"
        class="link-def">core</a>) data may be placed. An <code>Object</code> element
        is merely one type of digital data (or document) that can be signed via a
        <code>Reference</code>.
      </dd>
      <dt>
        <a id="def-Resource" name="def-Resource">Resource</a>
      </dt>
      <dd>
        "A resource can be anything that has identity. Familiar examples include an
        electronic document, an image, a service (e.g., 'today's weather report for Los
        Angeles'), and a collection of other resources.... The resource is the
        conceptual mapping to an entity or set of entities, not necessarily the entity
        which corresponds to that mapping at any particular instance in time. Thus, a
        resource can remain constant even when its content---the entities to which it
        currently corresponds---changes over time, provided that the conceptual mapping
        is not changed in the process." [<a href="#ref-URI">URI</a>] In order to avoid
        a collision of the term <em>entity</em> within the URI and XML specifications,
        we use the term <em>data object</em>, <em>content</em> or <em>document</em> to
        refer to the actual bits/octets being operated upon.
      </dd>
      <dt>
        <a id="def-Signature" name="def-Signature">Signature</a>
      </dt>
      <dd>
        Formally speaking, a value generated from the application of a private key to a
        message via a cryptographic algorithm such that it has the properties of <a
        href="#def-Integrity" class="link-def">integrity</a>, <a
        href="#def-AuthenticationMessage" class="link-def">message authentication</a>
        and/or <a href="#def-AuthenticationSigner" class="link-def">signer
        authentication</a>. (However, we sometimes use the term signature generically
        such that it encompasses <a href="#def-AuthenticationCode"
        class="link-def">Authentication Code</a> values as well, but we are careful to
        make the distinction when the property of <a href="#def-AuthenticationSigner"
        class="link-def">signer authentication</a> is relevant to the exposition.) A
        signature may be (non-exclusively) described as <a
        href="#def-SignatureDetached" class="link-def">detached</a>, <a
        href="#def-SignatureEnveloping" class="link-def">enveloping</a>, or <a
        href="#def-SignatureEnveloped" class="link-def">enveloped</a>.
      </dd>
      <dt>
        <a name="def-SignatureApplication" id="def-SignatureApplication">Signature,
        Application</a>
      </dt>
      <dd>
        An application that implements the MANDATORY (REQUIRED/MUST) portions of this
        specification; these conformance requirements are over application behavior,
        the structure of the <code>Signature</code> element type and its children
        (including <code>SignatureValue</code>) and the specified algorithms.
      </dd>
      <dt>
        <a id="def-SignatureDetached" name="def-SignatureDetached">Signature,
        Detached</a>
      </dt>
      <dd>
        The signature is over content external to the <code>Signature</code> element,
        and can be identified via a <code>URI</code> or transform. Consequently, the
        signature is "detached" from the content it signs. This definition typically
        applies to separate data objects, but it also includes the instance where the
        <code>Signature</code> and data object reside within the same XML document but
        are sibling elements.
      </dd>
      <dt>
        <a id="def-SignatureEnveloping" name="def-SignatureEnveloping">Signature,
        Enveloping</a>
      </dt>
      <dd>
        The signature is over content found within an <code>Object</code> element of
        the signature itself. The <code>Object</code> (or its content) is identified
        via a <code>Reference</code> (via a <code>URI</code> fragment identifier or
        transform).
      </dd>
      <dt>
        <a id="def-SignatureEnveloped" name="def-SignatureEnveloped">Signature,
        Enveloped</a>
      </dt>
      <dd>
        The signature is over the XML content that contains the signature as an
        element. The content provides the root XML document element. Obviously,
        enveloped signatures must take care not to include their own value in the
        calculation of the <code>SignatureValue</code>.
      </dd>
      <dt>
        <a id="def-Transform" name="def-Transform">Transform</a>
      </dt>
      <dd>
        The processing of a data from its source to its derived form. Typical
        transforms include XML Canonicalization, XPath, and XSLT.
      </dd>
      <dt>
        <a id="def-ValidationCore" name="def-ValidationCore">Validation, Core</a>
      </dt>
      <dd>
        The core processing requirements of this specification requiring <a
        href="#def-ValidationSignature" class="link-def">signature validation</a> and
        <code>SignedInfo</code> <a href="#def-ValidationReference"
        class="link-def">reference validation</a>.
      </dd>
      <dt>
        <a id="def-ValidationReference" name="def-ValidationReference">Validation,
        Reference</a>
      </dt>
      <dd>
        The hash value of the identified and transformed content, specified by
        <code>Reference</code>, matches its specified <code>DigestValue</code>.
      </dd>
      <dt>
        <a id="def-ValidationSignature" name="def-ValidationSignature">Validation,
        Signature</a>
      </dt>
      <dd>
        The <code>SignatureValue</code> matches the result of processing
        <code>SignedInfo</code> with&nbsp; <code>CanonicalizationMethod</code> and
        <code>SignatureMethod</code> as specified in <a href="#sec-CoreValidation">Core
        Validation</a> (section 3.2).
      </dd>
      <dt>
        <a id="def-ValidationTrustApplication"
        name="def-ValidationTrustApplication">Validation, Trust/Application</a>
      </dt>
      <dd>
        The application determines that the semantics associated with a signature are
        valid. For example, an application may validate the time stamps or the
        integrity of the signer key -- though this behavior is external to this <a
        href="#def-ValidationCore" class="link-def">core</a> specification.
      </dd>
    </dl>
    <h2>
      11.0 <a id="sec-References" name="sec-References">References</a>
    </h2>
    <dl>
      <dt>
        <a id="ref-ABA" name="ref-ABA">ABA</a>
      </dt>
      <dd>
        <a href="http://www.abanet.org/scitech/ec/isc/dsgfree.html">Digital Signature
        Guidelines.</a><br />
         <a
        href="http://www.abanet.org/scitech/ec/isc/dsgfree.html">http://www.abanet.org/scitech/ec/isc/dsgfree.html</a>
      </dd>
      <dt>
        <a id="ref-DOM" name="ref-DOM">DOM</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/">Document Object
        Model (DOM) Level 1 Specification.</a> W3C Recommendation. V. Apparao, S.
        Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R.
        Sutor, C. Wilson, L. Wood. October 1998.<br />
         <a
        href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/">http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/</a>
      </dd>
      <dt>
        <a id="ref-DSS" name="ref-DSS">DSS</a>
      </dt>
      <dd>
        <a href="http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf">FIPS
        PUB 186-2</a> . <em>Digital Signature Standard (DSS).</em> U.S. Department of
        Commerce/National Institute of Standards and Technology.<br />
         <a
        href="http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf">http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf</a>
      </dd>
      <dt>
        <a id="ref-HMAC" name="ref-HMAC">HMAC</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2104.txt">RFC 2104</a>. <em>HMAC:
        Keyed-Hashing for Message Authentication.</em> H. Krawczyk, M. Bellare, R.
        Canetti. February 1997.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2104.txt">http://www.ietf.org/rfc/rfc2104.txt</a>
      </dd>
      <dt>
        <a id="ref-HTTP" name="ref-HTTP">HTTP</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">RFC 2616</a>.
        <em>Hypertext Transfer Protocol -- HTTP/1.1</em>. J. Gettys, J. Mogul, H.
        Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>
      </dd>
      <dt>
        <a id="ref-KEYWORDS" name="ref-KEYWORDS">KEYWORDS</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119.</a> <em>Key words for
        use in RFCs to Indicate Requirement Levels.</em> S. Bradner. March 1997.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
      </dd>
      <dt>
        <a id="ref-LDAP-DN" name="ref-LDAP-DN">LDAP-DN</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2253.txt">RFC 2253</a>. <em>Lightweight
        Directory Access Protocol (v3): UTF-8 String Representation of Distinguished
        Names.</em> M. Wahl, S. Kille, T. Howes. December 1997.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2253.txt">http://www.ietf.org/rfc/rfc2253.txt</a>
      </dd>
      <dt>
        <a id="ref-MD5" name="ref-MD5">MD5</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc1321.txt">RFC 1321</a>. <em>The MD5
        Message-Digest Algorithm.</em> R. Rivest. April 1992.<br />
         <a
        href="http://www.ietf.org/rfc/rfc1321.txt">http://www.ietf.org/rfc/rfc1321.txt</a>
      </dd>
      <dt>
        <a id="ref-MIME" name="ref-MIME">MIME</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2045.txt">RFC 2045</a>. <em>Multipurpose
        Internet Mail Extensions (MIME) Part One: Format of Internet Message
        Bodies</em>. N. Freed &amp; N. Borenstein. November 1996.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2045.txt">http://www.ietf.org/rfc/rfc2045.txt</a>
      </dd>
      <dt>
        <a id="ref-NFC" name="ref-NFC">NFC</a>
      </dt>
      <dd>
        <em>TR15, Unicode Normalization Forms.</em> M. Davis, M. D&uuml;rst. Revision
        18: November 1999. <a
        href="http://www.unicode.org/unicode/reports/tr15/tr15-18.html">http://www.unicode.org/unicode/reports/tr15/tr15-18.html</a>.
      </dd>
      <dt>
        <a id="ref-NFC-Corrigendum" name="ref-NFC-Corrigendum">NFC-Corrigendum</a>
      </dt>
      <dd>
        <em>Normalization Corrigendum</em>. The Unicode Consortium. <a
        href="http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html">
        http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html</a>.
      </dd>
      <dt>
        <a id="ref-PGP" name="ref-PGP">PGP</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2440.txt">RFC 2440</a>. <em>OpenPGP Message
        Format.</em> J. Callas, L. Donnerhacke, H. Finney, R. Thayer. November
        1998.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2440.txt">http://www.ietf.org/rfc/rfc2440.txt</a>
      </dd>
      <dt>
        <a id="ref-RANDOM" name="ref-RANDOM">RANDOM</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc1750.txt">RFC 1750</a>. <em>Randomness
        Recommendations for Security.</em> D. Eastlake, S. Crocker, J. Schiller.
        December 1994.<br />
         <a
        href="http://www.ietf.org/rfc/rfc1750.txt">http://www.ietf.org/rfc/rfc1750.txt</a>
      </dd>
      <dt>
        <a id="ref-RDF" name="ref-RDF">RDF</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2000/CR-rdf-schema-20000327/">Resource
        Description Framework (RDF) Schema Specification 1.0.</a> W3C Candidate
        Recommendation. D. Brickley, R.V. Guha. March 2000.<br />
         <a
        href="http://www.w3.org/TR/2000/CR-rdf-schema-20000327/">http://www.w3.org/TR/2000/CR-rdf-schema-20000327/</a>
      </dd>
      <dd>
        <a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">Resource
        Description Framework (RDF) Model and Syntax Specification</a>. W3C
        Recommendation. O. Lassila, R. Swick. February 1999.<br />
         <a
        href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/</a>
      </dd>
      <dt>
        <a id="ref-1363" name="ref-1363">1363</a>
      </dt>
      <dd>
        IEEE 1363: Standard Specifications for Public Key Cryptography. August 2000.
      </dd>
      <dt>
        <a id="ref-PKCS1" name="ref-PKCS1">PKCS1</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2437.txt">RFC 2437</a>. <em>PKCS #1: RSA
        Cryptography Specifications Version 2.0.</em> B. Kaliski, J. Staddon. October
        1998.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2437.txt">http://www.ietf.org/rfc/rfc2437.txt</a>
      </dd>
      <dt>
        <a id="ref-SAX" name="ref-SAX">SAX</a>
      </dt>
      <dd>
        <a href="http://www.megginson.com/SAX/index.html">SAX: The Simple API for
        XML</a>. D. Megginson, et al. May 1998.<br />
         <a
        href="http://www.megginson.com/SAX/index.html">http://www.megginson.com/SAX/index.html</a>
      </dd>
      <dt>
        <a name="ref-SEC" id="ref-SEC">SEC</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2828.txt">RFC 2828</a>. <em>Internet
        Security Glossary.</em> R. Shirey. May 2000.<br />
         <a
        href="http://www.faqs.org/rfcs/rfc2828.html">http://www.faqs.org/rfcs/rfc2828.html</a>
      </dd>
      <dt>
        <a id="ref-SHA-1" name="ref-SHA-1">SHA-1</a>
      </dt>
      <dd>
        <a href="http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt">FIPS
        PUB 180-1</a>. <em>Secure Hash Standard.</em> U.S. Department of
        Commerce/National Institute of Standards and Technology.<br />
         <a
        href="http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt">http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt</a>
      </dd>
      <dt class="label">
        <a name="ref-SOAP" id="ref-SOAP">SOAP</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object Access
        Protocol (SOAP) Version 1.1</a>. W3C Note. D. Box, D. Ehnebuske, G. Kakivaya,
        A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S. Thatte, D. Winer. May 2001.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">http://www.w3.org/TR/2000/NOTE-SOAP-20000508/</a>
      </dd>
      <dt class="label">
        <a id="ref-Unicode" name="ref-Unicode">Unicode</a>
      </dt>
      <dd>
        The Unicode Consortium. <em>The Unicode Standard.</em><br />
         <a
        href="http://www.unicode.org/unicode/standard/standard.html">http://www.unicode.org/unicode/standard/standard.html</a>
      </dd>
      <dt>
        <a name="ref-UTF-16" id="ref-UTF-16">UTF-16</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2781.txt">RFC 2781</a>. <em>UTF-16, an
        encoding of ISO 10646.</em> P. Hoffman , F. Yergeau. February 2000.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2781.txt">http://www.ietf.org/rfc/rfc2781.txt</a>
      </dd>
      <dt>
        <a id="ref-UTF-8" name="ref-UTF-8">UTF-8</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2279.txt">RFC 2279</a>. <em>UTF-8, a
        transformation format of ISO 10646</em>. F. Yergeau. January 1998.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2279.txt">http://www.ietf.org/rfc/rfc2279.txt</a>
      </dd>
      <dt>
        <a id="ref-URI" name="ref-URI">URI</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>. <em>Uniform
        Resource Identifiers (URI): Generic Syntax.</em> T. Berners-Lee, R. Fielding,
        L. Masinter. August 1998.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a>
      </dd>
      <dt class="label">
        <a name="ref-URI-Literal" id="ref-URI-Literal">URI-Literal</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2732.txt">RFC 2732</a>. <em>Format for
        Literal IPv6 Addresses in URL's</em>. R. Hinden, B. Carpenter, L. Masinter.
        December 1999.
      </dd>
      <dd>
        <a
        href="http://www.ietf.org/rfc/rfc2732.txt">http://www.ietf.org/rfc/rfc2732.txt</a>
      </dd>
      <dt>
        <a id="ref-URL" name="ref-URL">URL</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc1738.txt">RFC 1738.</a> <em>Uniform
        Resource Locators (URL).</em> T. Berners-Lee, L. Masinter, and M. McCahill.
        December 1994.
      </dd>
      <dd>
        <a
        href="http://www.ietf.org/rfc/rfc1738.txt">http://www.ietf.org/rfc/rfc1738.txt</a>
      </dd>
      <dt>
        <a id="ref-URN" name="ref-URN">URN</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2141.txt">RFC 2141</a>. <em>URN
        Syntax.</em> R. Moats. May 1997.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2141.txt">http://www.ietf.org/rfc/rfc2141.txt</a>
      </dd>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2611.txt">RFC 2611</a>. <em>URN Namespace
        Definition Mechanisms.</em> L. Daigle, D. van Gulik, R. Iannella, P. Falstrom.
        June 1999.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2611.txt">http://www.ietf.org/rfc/rfc2611.txt</a>
      </dd>
      <dt>
        <a name="ref-X509v3" id="ref-X509v3">X509v3</a>
      </dt>
      <dd>
        ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open
        Systems Interconnection - The Directory Authentication Framework"&nbsp; ISO/IEC
        9594-8:1997.
      </dd>
      <dt>
        <a id="ref-XHTML" name="ref-XHTML">XHTML 1.0</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">XHTML(tm) 1.0: The
        Extensible Hypertext Markup Language</a>. W3C Recommendation. S. Pemberton, D.
        Raggett, et al. January 2000.<br />
         <a
        href="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">http://www.w3.org/TR/2000/REC-xhtml1-20000126/</a>
      </dd>
      <dt>
        <a id="ref-XLink" name="ref-XLink">XLink</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2001/REC-xlink-20010627/">XML Linking
        Language.</a> W3C Recommendation. S. DeRose, E. Maler, D. Orchard. June 2001.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/2001/REC-xlink-20010627/">http://www.w3.org/TR/2001/REC-xlink-20010627/</a>
      </dd>
      <dt>
        <a id="ref-XML" name="ref-XML">XML</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language
        (XML) 1.0 (Second Edition).</a> W3C Recommendation. T. Bray, E. Maler, J.
        Paoli, C. M. Sperberg-McQueen. October 2000.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/2000/REC-xml-20001006">http://www.w3.org/TR/2000/REC-xml-20001006</a>
      </dd>
      <dt>
        <a id="ref-XML-C14N" name="ref-XML-C14N">XML-C14N</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">Canonical XML.</a>
        W3C Recommendation. J. Boyer. March 2001.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a><br />

         <a
        href="http://www.ietf.org/rfc/rfc3076.txt">http://www.ietf.org/rfc/rfc3076.txt</a>
      </dd>
      <dt>
        <a name="ref-XML-Japanese" id="ref-XML-Japanese">XML-Japanese</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/">XML Japanese
        Profile</a>. W3C Note. <span class="author">M. <span
        class="name">Murata</span></span> April 2000 <a class="loc"
        href="http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/">http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/</a>
      </dd>
      <dt>
        <a name="ref-XML-MT" id="ref-XML-MT">XML-MT</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2376.txt">RFC 2376</a> . <em>XML Media
        Types</em>. E. Whitehead, M. Murata. July 1998.<br />
         <a
        href="http://www.ietf.org/rfc/rfc2376.txt">http://www.ietf.org/rfc/rfc2376.txt</a>
      </dd>
      <dt>
        <a id="ref-XML-ns" name="ref-XML-ns">XML-ns</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">Namespaces in
        XML</a>. W3C Recommendation. T. Bray, D. Hollander, A. Layman. January 1999.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114</a>
      </dd>
      <dt>
        <a id="ref-XML-schema" name="ref-XML-schema">XML-schema</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML Schema Part
        1: Structures</a>. W3C Recommendation. D. Beech, M. Maloney, N. Mendelsohn, H.
        Thompson. May 2001.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/</a><br />

         <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">XML Schema Part
        2: Datatypes</a> W3C Recommendation. P. Biron, A. Malhotra. May 2001.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</a>
      </dd>
      <dt>
        <a id="ref-XML-Signature-RD" name="ref-XML-Signature-RD">XML-Signature-RD</a>
      </dt>
      <dd>
        <a href="http://www.ietf.org/rfc/rfc2807.txt">RFC 2807</a>. <a
        href="http://www.w3.org/TR/xmldsig-requirements">XML Signature
        Requirements.</a> W3C Working Draft. J. Reagle, April 2000.<br />
         <a
        href="http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014.html">http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014</a><br />

         <a
        href="http://www.ietf.org/rfc/rfc2807.txt">http://www.ietf.org/rfc/rfc2807.txt</a>
      </dd>
      <dt>
        <a id="ref-XPath" name="ref-XPath">XPath</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/1999/REC-xpath-19991116">XML Path Language
        (XPath) Version 1.0</a>. W3C Recommendation. J. Clark, S. DeRose. October
        1999.<br />
         <a
        href="http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/TR/1999/REC-xpath-19991116</a>
      </dd>
      <dt>
        <a id="ref-XPointer" name="ref-XPointer">XPointer</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2001/CR-xptr-20010911/">XML Pointer Language
        (XPointer)</a>. W3C Candidate Recommendation. S. DeRose, R. Daniel, E. Maler.
        January 2001.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/2001/CR-xptr-20010911/">http://www.w3.org/TR/2001/CR-xptr-20010911/</a>
      </dd>
      <dt>
        <a id="ref-XSL" name="ref-XSL">XSL</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/2001/REC-xsl-20011015/">Extensible Stylesheet
        Language (XSL)</a>. W3C Recommendation. S. Adler, A. Berglund, J. Caruso, S.
        Deach, T. Graham, P. Grosso, E. Gutentag, A. Milowski, S. Parnell, J. Richman,
        S. Zilles. October 2001.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/2001/REC-xsl-20011015/">http://www.w3.org/TR/2001/REC-xsl-20011015/</a>
      </dd>
      <dt>
        <a id="ref-XSLT" name="ref-XSLT">XSLT</a>
      </dt>
      <dd>
        <a href="http://www.w3.org/TR/1999/REC-xslt-19991116.html">XSL Transforms
        (XSLT) Version 1.0</a>. W3C Recommendation. J. Clark. November 1999.
      </dd>
      <dd>
        <a
        href="http://www.w3.org/TR/1999/REC-xslt-19991116.html">http://www.w3.org/TR/1999/REC-xslt-19991116.html</a>
      </dd>
    </dl>
    <h2>
      12. <a id="sec-Authors" name="sec-Authors">Authors'</a> Address
    </h2>
    <p>
      Donald E. Eastlake 3rd<br />
      Motorola, 20 Forbes Boulevard<br />
      Mansfield, MA 02048 USA<br />
      Phone: 1-508-261-5434<br />
      Email: <a
      href="mailto:Donald.Eastlake@motorola.com">Donald.Eastlake@motorola.com</a>
    </p>
    <p>
      Joseph M. Reagle Jr., <a href="http://www.w3.org/">W3C</a><br />
      Massachusetts Institute of Technology<br />
      Laboratory for Computer Science<br />
      NE43-350, 545 Technology Square<br />
      Cambridge, MA 02139<br />
      Phone: + 1.617.258.7621<br />
      Email: <a href="mailto:reagle@w3.org">reagle@w3.org</a>
    </p>
    <p>
      David Solo<br />
      Citigroup<br />
      909 Third Ave, 16th Floor<br />
      NY, NY 10043 USA<br />
      Phone +1-212-559-2900<br />
      Email: <a href="mailto:dsolo@alum.mit.edu">dsolo@alum.mit.edu</a>
    </p>
  </body>
</html>