discontinued / server · Files

index.html 220 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 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 5070 5071 5072 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127 5128 5129 5130 5131 5132 5133 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 
<?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 Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
  <meta http-equiv="content-type" content=
  "text/html; charset=us-ascii" />

  <title>XML Signature Syntax and Processing (Second
  Edition)</title>
  <style type="text/css" xml:space="preserve">
/*<![CDATA[*/
  /**/
  /**/
  /**/
    u        { background: white; color: red;}
    ins,.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;}

    del  a { text-decoration: line-through; color: silver; }
    ins  a { color: red; }



  /**/

  /**/

  /*
  */
  /*]]>*/
  </style>
  <link rel="stylesheet" type="text/css" href=
  "http://www.w3.org/StyleSheets/TR/base.css" />
  <link rel="stylesheet" type="text/css"
	href="http://www.w3.org/StyleSheets/TR/W3C-REC"/>
</head>

<body xml:lang="en" lang="en">
  <div class="head">
    <a href="http://www.w3.org/"><img height="48" width="72"
  alt="W3C" src="http://www.w3.org/Icons/w3c_home"/></a>

    <h1 class="notoc">XML Signature Syntax and Processing (Second
    Edition)</h1>

    <h2 class="notoc">W3C Recommendation 10 June 2008</h2>

    <dl>
      <dt>This version:</dt>
      <dd><a href="http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/">http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/</a></dd>

      <dt>Latest version:</dt>

      <dd><a href="http://www.w3.org/TR/xmldsig-core/" shape=
      "rect">http://www.w3.org/TR/xmldsig-core/</a></dd>

      <dt>Previous version:</dt>
      <dd><a href="http://www.w3.org/TR/2008/PER-xmldsig-core-20080326/">http://www.w3.org/TR/2008/PER-xmldsig-core-20080326/</a></dd>

      <dt>Editors</dt>

      <dd>Donald Eastlake &lt;<a href="mailto:d3e3e3@gmail.com"
      shape="rect">d3e3e3@gmail.com</a>&gt;<br clear="none" />
      Joseph Reagle &lt;<a href="mailto:reagle@mit.edu" shape=
      "rect">reagle@mit.edu</a>&gt;<br clear="none" />
      David Solo &lt;<a href="mailto:dsolo@alum.mit.edu" shape=
      "rect">dsolo@alum.mit.edu</a>&gt;<br clear="none" />
      Frederick Hirsch &lt;<a href=
      "mailto:frederick.hirsch@nokia.com" shape=
      "rect">frederick.hirsch@nokia.com</a>&gt; (2nd
      edition)<br clear="none" />
      Thomas Roessler &lt;<a href="mailto:tlr@w3.org" shape=
      "rect">tlr@w3.org</a>&gt; (2nd edition)</dd>

      <dt>Authors</dt>

      <dd>Mark Bartel &lt;<a href="mailto:mbartel@adobe.com" shape=
      "rect">mbartel@adobe.com</a>&gt;</dd>

      <dd>John Boyer &lt;<a href="mailto:boyerj@ca.ibm.com" shape=
      "rect">boyerj@ca.ibm.com</a>&gt;<br clear="none" />
      Barb Fox &lt;<a href="mailto:bfox@Exchange.Microsoft.com"
      shape="rect">bfox@Exchange.Microsoft.com</a>&gt;</dd>

      <dd>Brian LaMacchia &lt;<a href="mailto:bal@microsoft.com"
      shape="rect">bal@microsoft.com</a>&gt;</dd>

      <dd>Ed Simon &lt;<a href="mailto:edsimon@xmlsec.com" shape=
      "rect">edsimon@xmlsec.com</a>&gt;</dd>

      <dt>Contributors</dt>

      <dd>See <a href="#sec-Acknowledgements" shape=
      "rect">Acknowledgements</a></dd>
    </dl>
	
    <p>Please refer to the <a href="http://www.w3.org/2008/06/xmldsigcore-errata.html"><strong>errata</strong></a>  for this document, which may include some normative corrections.</p>

    <p>This document is also available in these non-normative
    formats: <a href="review.html" shape="rect">XHTML with
    color-coded revision indicators against the previous recommendation version.</a></p>
    
    <p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xmldsig-core-80"><strong>translations</strong></a>.</p>

    <p class="copyright"><a href=
    "http://www.w3.org/Consortium/Legal/ipr-notice#Copyright"
    shape="rect">Copyright</a> &copy; 2008 <a href=
    "http://www.ietf.org/" shape="rect">The Internet Society</a>
    &amp; <a href="http://www.w3.org/" shape="rect"><abbr title=
    "World Wide Web Consortium">W3C</abbr></a>&reg; (<a href=
    "http://www.csail.mit.edu/" shape="rect"><abbr title=
    "Massachusetts Institute of Technology">MIT</abbr></a>,
    <a href="http://www.inria.fr/" shape="rect"><abbr xml:lang="fr"
    lang="fr" title=
    "European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
    <a href="http://www.keio.ac.jp/" shape="rect">Keio</a>), All
    Rights Reserved. W3C <a href=
    "http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer"
    shape="rect">liability</a>, <a href=
    "http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks"
    shape="rect">trademark</a> and <a href=
    "http://www.w3.org/Consortium/Legal/copyright-documents" shape=
    "rect">document use</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" shape="rect">integrity</a>, <a href=
  "#def-AuthenticationMessage" class="link-def" shape=
  "rect">message authentication</a>, and/or <a href=
  "#def-AuthenticationSigner" class="link-def" shape="rect">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" shape=
  "rect"></a>Status of this document</h2>

  <p><em>This section describes the status of this document at the
  time of its publication. Other documents may supersede this
  document. A list of current W3C publications and the latest
  revision of this technical report can be found in the <a href=
  "http://www.w3.org/TR/" shape="rect">W3C technical reports
  index</a> at http://www.w3.org/TR/.</em></p>

  <div>
    <p class="notoc">The <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/">original
    version</a> of this specification was produced by the IETF/W3C <a
    href="http://www.w3.org/Signature/" shape="rect">XML Signature Working Group</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"
    shape="rect">Interoperability Report</a> shows at least 10 implementations with at least two
    interoperable implementations over every feature.</p>

    <p>This Second Edition was produced by the W3C <a href=
    "http://www.w3.org/2007/xmlsec/" shape="rect">XML Security
    Specifications Maintenance Working Group</a>, part of the W3C
    Security Activity (<a href="http://www.w3.org/Security/" shape=
    "rect">Activity Statement</a>).</p>

    <p>This Second Edition of XML Signature Syntax and
    Processing adds Canonical XML 1.1 as a required
    canonicalization algorithm and recommends its use for inclusive
    canonicalization. This version of Canonical XML enables use of
    <code>xml:id</code> and <code>xml:base</code> Recommendations
    with XML Signature and also enables other possible future
    attributes in the XML namespace. Additional minor changes,
    including the incorporation of known errata, are documented in
    <a href="explain.html" title=
    "Changes in XML Signature Syntax and Processing (Second Edition)"
    shape="rect">Changes in XML Signature Syntax and Processing
    (Second Edition)</a>.</p>

    <p>The Working Group conducted an interoperability test as part
    of its activity. The <a href=
    "http://www.w3.org/TR/2008/NOTE-xmldsig2ed-tests-20080610/"
    title="Test Cases for C14N 1.1 and XMLDSig Interoperability"
    shape="rect">Test Cases for C14N 1.1 and XMLDSig Interoperability</a> [<a
    href="#ref-TESTCASES">TESTCASES</a>] are available as a companion Working Group Note.  The <a href=
    "http://www.w3.org/2007/xmlsec/interop/xmldsig/report.html"
    title="Implementation Report for XML Signature, Second Edition"
    shape="rect">Implementation Report for XML Signature, Second
    Edition</a> is also publicly available.</p>
    
    <p>Please send comments about this document to <a href="mailto:public-xmlsec-comments@w3.org">public-xmlsec-comments@w3.org</a> (with <a
    href="http://lists.w3.org/Archives/Public/public-xmlsec-comments/">public archive</a>).</p>
    
    <p>This document has been reviewed by W3C Members, by software                  
     developers, and by other W3C groups and interested parties, and              
     is endorsed by the Director as a W3C Recommendation. It is a                 
     stable document and may be used as reference material or cited               
     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>This document is governed by the <a href=
    "http://www.w3.org/TR/2002/NOTE-patent-practice-20020124"
    shape="rect">24 January 2002 CPP</a> as amended by the <a href=
    "http://www.w3.org/2004/02/05-pp-transition" shape="rect">W3C
    Patent Policy Transition Procedure</a>. W3C maintains a <a rel=
    "disclosure" href=
    "http://www.w3.org/2004/01/pp-impl/40279/status" shape=
    "rect">public list of any patent disclosures</a> made in
    connection with the deliverables of the group; that page also
    includes instructions for disclosing a patent. An individual
    who has actual knowledge of a patent which the individual
    believes contains <a href=
    "http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential"
    shape="rect">Essential Claim(s)</a> must disclose the
    information in accordance with <a href=
    "http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure"
    shape="rect">section 6 of the W3C Patent Policy</a>. Patent
    disclosures relevant to this specification may be found on the
    <a href="http://www.ietf.org/ipr.html" shape="rect">IETF Page
    of Intellectual Property Rights Notices</a>, in conformance
    with IETF policy.</p>

    <p>The English version of this specification is the only
    normative version.</p>

  </div>

  <h2 id="contents">Table of Contents</h2>

  <ol>
    <li>
      <a href="#sec-Introduction" shape="rect">Introduction</a>

      <ol>
        <li><a href="#sec-Editorial" shape="rect">Editorial
        Conventions</a></li>

        <li><a href="#sec-Design" shape="rect">Design
        Philosophy</a></li>

        <li><a href="#sec-Versions" shape="rect">Versions,
        Namespaces and Identifiers</a></li>

        <li><a href="#sec-Acknowledgements" shape=
        "rect">Acknowledgements</a></li>
      </ol>
    </li>

    <li>
      <a href="#sec-Overview" shape="rect">Signature Overview and
      Examples</a>

      <ol>
        <li>
          <a href="#sec-o-Simple" shape="rect">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" shape="rect">More on
            <code>Reference</code></a></li>
          </ol>
        </li>

        <li><a href="#sec-o-SignatureProperty" shape=
        "rect">Extended Example (<code>Object</code> and
        <code>SignatureProperty</code>)</a></li>

        <li><a href="#sec-o-Manifest" shape="rect">Extended Example
        (<code>Object</code> and <code>Manifest</code>)</a></li>
      </ol>
    </li>

    <li>
      <a href="#sec-Processing" shape="rect">Processing Rules</a>

      <ol>
        <li><a href="#sec-CoreGeneration" shape="rect">Signature
        Generation</a></li>

        <li><a href="#sec-CoreValidation" shape="rect">Signature
        Validation</a></li>
      </ol>
    </li>

    <li>
      <a href="#sec-CoreSyntax" shape="rect">Core Signature
      Syntax</a>

      <ol>
        <li><a href="#sec-Signature" shape="rect">The
        <code>Signature</code> element</a></li>

        <li><a href="#sec-SignatureValue" shape="rect">The
        <code>SignatureValue</code> Element</a></li>

        <li>
          <a href="#sec-SignedInfo" shape="rect">The
          <code>SignedInfo</code> Element</a>

          <ol>
            <li><a href="#sec-CanonicalizationMethod" shape=
            "rect">The <code>CanonicalizationMethod</code>
            Element</a></li>

            <li><a href="#sec-SignatureMethod" shape="rect">The
            <code>SignatureMethod</code> Element</a></li>

            <li>
              <a href="#sec-Reference" shape="rect">The
              <code>Reference</code> Element</a>

              <ol>
                <li><a href="#sec-URI" shape="rect">The
                <code>URI</code> Attribute</a></li>

                <li><a href="#sec-ReferenceProcessingModel" shape=
                "rect">The Reference Processing Model</a></li>

                <li><a href="#sec-Same-Document" shape=
                "rect">Same-Document URI-References</a></li>

                <li><a href="#sec-Transforms" shape="rect">The
                <code>Transforms</code> Element</a></li>

                <li><a href="#sec-DigestMethod" shape="rect">The
                <code>DigestMethod</code> Element</a></li>

                <li><a href="#sec-DigestValue" shape="rect">The
                <code>DigestValue</code> Element</a></li>
              </ol>
            </li>
          </ol>
        </li>

        <li>
          <a href="#sec-KeyInfo" shape="rect">The
          <code>KeyInfo</code> Element</a>

          <ol>
            <li><a href="#sec-KeyName" shape="rect">The
            <code>KeyName</code> Element</a></li>

            <li>
              <a href="#sec-KeyValue" shape="rect">The
              <code>KeyValue</code> Element</a>

              <ol>
                <li><a href="#sec-DSAKeyValue" shape="rect">The
                <code>DSAKeyValue</code> Element</a></li>

                <li><a href="#sec-RSAKeyValue" shape="rect">The
                <code>RSAKeyValue</code> Element</a></li>
              </ol>
            </li>

            <li><a href="#sec-RetrievalMethod" shape="rect">The
            <code>RetrievalMethod</code> Element</a></li>

            <li>
              <a href="#sec-X509Data" shape="rect">The
              <code>X509Data</code> Element</a>

              <ol>
                <li><a href="#dname-encrules" shape=
                "rect">Distinguished Name Encoding Rules</a></li>
              </ol>
            </li>

            <li><a href="#sec-PGPData" shape="rect">The
            <code>PGPData</code> Element</a></li>

            <li><a href="#sec-SPKIData" shape="rect">The
            <code>SPKIData</code> Element</a></li>

            <li><a href="#sec-MgmtData" shape="rect">The
            <code>MgmtData</code> Element</a></li>
          </ol>
        </li>

        <li><a href="#sec-Object" shape="rect">The
        <code>Object</code> Element</a></li>
      </ol>
    </li>

    <li>
      <a href="#sec-AdditionalSyntax" shape="rect">Additional
      Signature Syntax</a>

      <ol>
        <li><a href="#sec-Manifest" shape="rect">The
        <code>Manifest</code> Element</a></li>

        <li><a href="#sec-SignatureProperties" shape="rect">The
        <code>SignatureProperties</code> Element</a></li>

        <li><a href="#sec-PI" shape="rect">Processing
        Instructions</a></li>

        <li><a href="#sec-comments" shape="rect">Comments in dsig
        Elements</a></li>
      </ol>
    </li>

    <li>
      <a href="#sec-Algorithms" shape="rect">Algorithms</a>

      <ol>
        <li><a href="#sec-AlgID" shape="rect">Algorithm Identifiers
        and Implementation Requirements</a></li>

        <li><a href="#sec-MessageDigests" shape="rect">Message
        Digests</a></li>

        <li><a href="#sec-MACs" shape="rect">Message Authentication
        Codes</a></li>

        <li><a href="#sec-SignatureAlg" shape="rect">Signature
        Algorithms</a></li>

        <li>
          <a href="#sec-c14nAlg" shape="rect">Canonicalization
          Algorithms</a>

          <ol>
            <li><a href="#sec-Canonical" shape="rect">Canonical XML
            1.0</a></li>

            <li><a href="#sec-Canonical11" shape="rect">Canonical
            XML 1.1</a></li>
          </ol>
        </li>

        <li>
          <a href="#sec-TransformAlg" shape="rect">Transform
          Algorithms</a>

          <ol>
            <li><a href="#sec-Canonicalization" shape=
            "rect">Canonicalization</a></li>

            <li><a href="#sec-Base-64" shape="rect">Base64</a></li>

            <li><a href="#sec-XPath" shape="rect">XPath
            Filtering</a></li>

            <li><a href="#sec-EnvelopedSignature" shape=
            "rect">Enveloped Signature Transform</a></li>

            <li><a href="#sec-XSLT" shape="rect">XSLT
            Transform</a></li>
          </ol>
        </li>
      </ol>
    </li>

    <li>
      <a href="#sec-XML-Canonicalization" shape="rect">XML
      Canonicalization and Syntax Constraint Considerations</a>

      <ol>
        <li><a href="#sec-XML-1" shape="rect">XML 1.0, Syntax
        Constraints, and Canonicalization</a></li>

        <li><a href="#sec-DOM-SAX" shape="rect">DOM/SAX Processing
        and Canonicalization</a></li>

        <li><a href="#sec-NamespaceContext" shape="rect">Namespace
        Context and Portable Signatures</a></li>
      </ol>
    </li>

    <li>
      <a href="#sec-Security" shape="rect">Security
      Considerations</a>

      <ol>
        <li>
          <a href="#sec-Security-Transofrms" shape=
          "rect">Transforms</a>

          <ol>
            <li><a href="#sec-Secure" shape="rect">Only What is
            Signed is Secure</a></li>

            <li><a href="#sec-Seen" shape="rect">Only What is
            "Seen" Should be Signed</a></li>

            <li><a href="#sec-See" shape="rect">"See" What is
            Signed</a></li>
          </ol>
        </li>

        <li><a href="#sec-Check" shape="rect">Check the Security
        Model</a></li>

        <li><a href="#sec-KeyLength" shape="rect">Algorithms, Key
        Lengths, Etc.</a></li>
      </ol>
    </li>

    <li><a href="#sec-Schema" shape="rect">Schema, DTD, Data Model,
    and Valid Examples</a></li>

    <li><a href="#sec-Definitions" shape=
    "rect">Definitions</a></li>

    <li><a href="#sec-References" shape="rect">References</a></li>

    <li><a href="#sec-Authors" shape="rect">Authors'
    Address</a></li>
  </ol>
  <hr />

  <h2>1.0 <a id="sec-Introduction" name="sec-Introduction" shape=
  "rect">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"
  shape="rect">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"
  shape="rect">Enveloped</a> or <a href="#def-SignatureEnveloping"
  class="link-def" shape="rect">enveloping</a> signatures are over
  data within the same XML document as the signature; <a href=
  "#def-SignatureDetached" class="link-def" shape=
  "rect">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" shape="rect">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" shape="rect">Security Considerations</a> (section
  8).</p>

  <h3>1.1 <a id="sec-Editorial" name="sec-Editorial" shape=
  "rect">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" shape=
  "rect">Check the Security Model</a>, section 8.3.)</p>

  <p>This specification provides an XML Schema [<a href=
  "#ref-XML-schema" shape="rect">XML-schema</a>] and DTD [<a href=
  "#ref-XML" shape="rect">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" shape=
  "rect">RFC2119</a> [<a href="#ref-KEYWORDS" shape=
  "rect">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" shape=
  "rect">XML-ns</a>] is described as "REQUIRED."</p>

  <h3>1.2 <a id="sec-Design" name="sec-Design" shape=
  "rect">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" shape=
  "rect">XML-Signature-RD</a>].</p>

  <h3>1.3 <a id="sec-Versions" name="sec-Versions" shape=
  "rect">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" shape=
  "rect">XML-ns</a>] URI that MUST be used by implementations of
  this (dated) specification is:</p>
  <pre class="xml-example" xml:space="preserve">
   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" shape=
  "rect">internal entities</a> [<a href="#ref-XML" shape=
  "rect">XML</a>] or our "dsig" XML <a href=
  "http://www.w3.org/TR/1999/REC-xml-names-19990114/#dt-prefix"
  shape="rect">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" shape="rect">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" shape="rect">URN</a>] or Uniform Resource
  Locators [<a href="#ref-URL" shape="rect">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-2. <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" shape="rect">XML
  internal entities</a> [<a href="#ref-XML" shape="rect">XML</a>]
  within URIs. For instance:</p>
  <pre class="xml-example" xml:space="preserve">
   &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"
  shape="rect">Acknowledgements</a></h3>

  <p>The contributions of the following Working Group members to
  this specification are gratefully acknowledged:</p>

  <ul>
    <li>Mark Bartel, Adobe, was Accelio (Author)</li>

    <li>John Boyer, IBM (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, NYU, was 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" shape="rect">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/" shape=
    "rect">Internationalization WG/IG</a>.</li>

    <li>Jonathan Marsh, Microsoft, on behalf of the <a href=
    "http://www.w3.org/Style/XSL/" shape="rect">Extensible
    Stylesheet Language WG</a>.</li>
  </ul>

  <p>The following members of the XML Security Specification
  Maintenance Working Group contributed to the second edition:</p>

  <ul>
    <li>Juan Carlos Cruellas, Universitat Polit&egrave;cnica de
    Catalunya</li>

    <li>Pratik Datta, Oracle Corporation</li>

    <li>Phillip Hallam-Baker, VeriSign, Inc.</li>

    <li>Frederick Hirsch, Nokia, (Chair, Editor)</li>

    <li>Konrad Lanz, A-SIT</li>

    <li>Hal Lockhart, BEA Systems, Inc.</li>

    <li>Robert Miller, MITRE Corporation</li>

    <li>Sean Mullan, Sun Microsystems, Inc.</li>

    <li>Bruce Rich, IBM Corporation</li>

    <li>Thomas Roessler, W3C/ERCIM, (Staff contact, Editor)</li>

    <li>Ed Simon, W3C Invited Expert</li>

    <li>Greg Whitehead, HP</li>
  </ul>

  <h2>2.0 <a id="sec-Overview" name="sec-Overview" shape=
  "rect">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"
  shape="rect">Processing Rules</a> (section 3). The formal syntax
  is found in <a href="#sec-CoreSyntax" shape="rect">Core Signature
  Syntax</a> (section 4) and <a href="#sec-AdditionalSyntax" shape=
  "rect">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" shape="rect">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" xml:space="preserve">
  &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" shape="rect">data objects</a> via URIs [<a href=
  "#ref-URI" shape="rect">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" shape=
  "rect">enveloping</a> signature or can enclose an <a href=
  "#def-SignatureEnveloped" class="link-def" shape=
  "rect">enveloped</a> signature. <a href="#def-SignatureDetached"
  class="link-def" shape="rect">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" shape="rect">ID
  uniqueness validity constraint</a> [<a href="#ref-XML" shape=
  "rect">XML</a>].</p>

  <h3>2.1 <a id="sec-o-Simple" name="sec-o-Simple" shape=
  "rect">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" xml:space="preserve">
   [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/2006/12/xml-c14n11"/&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/2006/12/xml-c14n11"/&gt; 
   [s08]     &lt;/Transforms&gt; 
   [s09]     &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt; 
   [s10]     &lt;DigestValue&gt;dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK.../DigestValue&gt; 
   [s11]   &lt;/Reference&gt; 
   [s12] &lt;/SignedInfo&gt; 
   [s13]   &lt;SignatureValue&gt;...&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" shape="rect">Core
  validation</a> of <code>SignedInfo</code> consists of two
  mandatory processes: <a href="#def-ValidationSignature" class=
  "link-def" shape="rect">validation of the signature</a> over
  <code>SignedInfo</code> and <a href="#def-ValidationReference"
  class="link-def" shape="rect">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" shape=
  "rect">reference</a> and <a href="#def-ValidationSignature"
  class="link-def" shape="rect">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"
  shape="rect"><code>Reference</code></a></h3>
  <pre class="xml-example" xml:space="preserve">
   [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/2006/12/xml-c14n11"/&gt; 
   [s08]     &lt;/Transforms&gt; 
   [s09]     &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt; 
   [s10]     &lt;DigestValue&gt;dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...&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" shape=
  "rect"><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" shape="rect">integrity</a>,
  <a href="#def-AuthenticationMessage" class="link-def" shape=
  "rect">message authentication</a>, and/or <a href=
  "#def-AuthenticationSigner" class="link-def" shape="rect">signer
  authentication</a>). Applications that wish to represent other
  semantics must rely upon other technologies, such as [<a href=
  "#ref-XML" shape="rect">XML</a>, <a href="#ref-RDF" shape=
  "rect">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"
  shape="rect">detached</a> <code>[p02]</code> but <a href=
  "#def-SignatureEnveloping" class="link-def" shape=
  "rect">enveloping</a> <code>[p03]</code>.)</p>
  <pre class="xml-example" xml:space="preserve">
   [   ]  &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;Transforms&gt; 
   [p06]      &lt;Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/&gt; 
   [p07]    &lt;/Transforms&gt; 
   [p08]    &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt;    
   [p09]    &lt;DigestValue&gt;dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...&lt;/DigestValue&gt;
   [p10]   &lt;/Reference&gt;    
   [p11]  &lt;/SignedInfo&gt;  
   [p12]  ...  
   [p13]  &lt;Object&gt; 
   [p14]   &lt;SignatureProperties&gt; 
   [p15]     &lt;SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature"&gt; 
   [p16]        &lt;timestamp xmlns="http://www.ietf.org/rfcXXXX.txt"&gt;  
   [p17]          &lt;date&gt;19990914&lt;/date&gt;  
   [p18]          &lt;time&gt;14:34:34:34&lt;/time&gt;  
   [p19]        &lt;/timestamp&gt;  
   [p20]     &lt;/SignatureProperty&gt; 
   [p21]   &lt;/SignatureProperties&gt; 
   [p22]  &lt;/Object&gt;  
   [p23]&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>[p13]</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>[p14-21]</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" shape=
  "rect"><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" shape=
  "rect">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" shape=
  "rect">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" shape="rect">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" shape="rect">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" xml:space="preserve">
   [   ] ...
   [m01]   &lt;Reference URI="#MyFirstManifest"
   [m02]     Type="http://www.w3.org/2000/09/xmldsig#Manifest"&gt;
   [m03]     &lt;Transforms&gt; 
   [m04]       &lt;Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/&gt; 
   [m05]     &lt;/Transforms&gt; 
   [m06]     &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt; 
   [m07]     &lt;DigestValue&gt;dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...=&lt;/DigestValue&gt; 
   [m08]   &lt;/Reference&gt;  
   [   ] ...
   [m09] &lt;Object&gt;
   [m10]   &lt;Manifest Id="MyFirstManifest"&gt;
   [m11]     &lt;Reference&gt;
   [m12]     ...
   [m13]     &lt;/Reference&gt;   
   [m14]     &lt;Reference&gt;
   [m15]     ...
   [m16]     &lt;/Reference&gt;
   [m17]   &lt;/Manifest&gt;
   [m18] &lt;/Object&gt;
</pre>

  <h2>3.0 <a id="sec-Processing" name="sec-Processing" shape=
  "rect">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"
  shape="rect">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" shape="rect">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>The <a href="#sec-ReferenceProcessingModel" shape=
  "rect">Reference Processing Model</a> (section 4.3.3.2) requires
  use of Canonical XML 1.0 [<a href="#ref-XML-C14N" shape=
  "rect">XML-C14N</a>] as default processing behavior when a
  transformation is expecting an octet-stream, but the data object
  resulting from URI dereferencing or from the previous
  transformation in the list of <code>Transform</code> elements is
  a node-set. We RECOMMEND that, when generating signatures,
  signature applications do not rely on this default behavior, but
  explicitly identify the transformation that is applied to perform
  this mapping. In cases in which inclusive canonicalization is
  desired, we RECOMMEND that Canonical XML 1.1 [<a href=
  "#ref-XML-C14N11" shape="rect">XML-C14N11</a>] be used.<!--  
<ins>
<p class="discuss"><a name="Editors-Note-C14N11-AppendixA1" id="EdNote-C14N11-AppendixA1">
Editors Note</a>: There has been a correction to Appendix A of the C14N11 Candidate Recommendation. This
correction is available at 
<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html">
http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html</a>.
The XML Security Specifications Maintenance WG anticipates this change will be adopted as part of 
C14N11 CR review and will use this update to Appendix A for Interop testing.
</p>
</ins>
-->

  <h4>3.1.2 <a id="sec-SignatureGeneration" name=
  "sec-SignatureGeneration" shape="rect">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" shape="rect">XML</a>] or
      [<a href="#ref-XML-schema" shape="rect">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"
  shape="rect">Validation</a></h3>

  <p>The REQUIRED steps of <a href="#def-ValidationCore" class=
  "link-def" shape="rect">core validation</a> include (1) <a href=
  "#def-ValidationReference" class="link-def" shape=
  "rect">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" shape=
  "rect">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" shape="rect">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" shape=
  "rect">CanonicalizationMethod</a></code> (section 4.3)) and that
  it <a href="#sec-See" shape="rect">Sees What is Signed</a>, which
  is the canonical form.</p>

  <h4>3.2.2 <a id="sec-SignatureValidation" name=
  "sec-SignatureValidation" shape="rect">Signature
  Validation</a></h4>

  <ol>
    <li>Obtain the keying information from <code><a href=
    "#sec-KeyInfo" shape="rect">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" shape=
  "rect">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" shape="rect">XML-C14N</a>] of this
  specification does not change URIs.</p>

  <h2>4.0 <a id="sec-CoreSyntax" name="sec-CoreSyntax" shape=
  "rect">Core Signature Syntax</a></h2>

  <p>The general structure of an XML signature is described in
  <a href="#sec-Overview" shape="rect">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" shape=
  "rect">XML-Schema</a>] with the following XML preamble,
  declaration, and internal entity.</p>
  <pre class="xml-dtd" xml:space="preserve">
   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" xml:space="preserve">
   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"
  shape="rect">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" shape="rect">MIME</a>]
  encoded. (The conversion from integer to octet string is
  equivalent to IEEE 1363's I2OSP [<a href="#ref-1363" shape=
  "rect">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" shape=
  "rect"><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" xml:space="preserve">
   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" shape=
  "rect"><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"
  shape="rect">laxly schema valid</a> [<a href="#ref-XML-schema"
  shape="rect">XML-schema</a>] <code>Signature</code> elements as
  specified by the following schema:</p>
  <pre class="xml-dtd" xml:space="preserve">
   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" xml:space="preserve">
   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"
  shape="rect"><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" shape="rect">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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" shape=
  "rect">Algorithm Identifiers and Implementation Requirements</a>
  (section 6.1). Implementations MUST support the REQUIRED <a href=
  "#sec-c14nAlg" shape="rect">canonicalization algorithms</a>.</p>

  <p>Alternatives to the REQUIRED <a href="#sec-c14nAlg" shape=
  "rect">canonicalization algorithms</a> (section 6.5), such as
  <a href="#sec-Canonical" shape="rect">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"
  shape="rect">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" shape="rect">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" shape="rect">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" shape=
    "rect">markup and character data</a> (i.e., the <a href=
    "http://www.w3.org/TR/1998/REC-xml-19980210#dt-text" shape=
    "rect">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" shape=
  "rect">standalone</a> XML instances [<a href="#ref-XML" shape=
  "rect">XML</a>].</p>

  <p><a name="sec-CanonicalizationMethod-NOTE" id=
  "sec-CanonicalizationMethod-NOTE" shape="rect">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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" shape="rect">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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><code>URI</code></a> Attribute</h4>

  <p>The <code>URI</code> attribute identifies a data object using
  a URI-Reference [<a href="#ref-URI" shape="rect">URI</a>].</p>

  <p>The mapping from this attribute's value to a URI reference
  MUST be performed as specified in section 3.2.17 of [<a href=
  "#ref-XML-schema" shape="rect">XMLSCHEMA Datatypes, 2nd
  Edition</a>]. Additionally: Some existing implementations are
  known to verify the value of the URI attribute against the
  grammar in [<a href="#ref-URI" shape="rect">URI</a>]. It is
  therefore safest to perform any necessary escaping while
  generating the URI attribute.</p>

  <p>We RECOMMEND XML signature applications 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"
  shape="rect">Status Code Definitions</a> of [<a href="#ref-HTTP"
  shape="rect">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" shape="rect">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 after all <code>ds:Reference</code>
  transforms have been applied. This is represented as a URI. For
  example:</p>

  <p><code>Type=<a href="http://www.w3.org/2000/09/xmldsig#Object"
  shape=
  "rect">"http://www.w3.org/2000/09/xmldsig#Object"</a><br clear=
  "none" />
  Type=<a href="http://www.w3.org/2000/09/xmldsig#Manifest" shape=
  "rect">"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 results in the
  digesting of 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" shape="rect">Reference Processing
  Model</a></h4>

  <p class="comment"><a name="Note-Xpath" id="Note-Xpath" shape=
  "rect">Note</a>: XPath is RECOMMENDED. Signature applications
  need not conform to [<a href="#ref-XPath" shape="rect">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" shape=
  "rect">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" shape="rect">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" shape="rect">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" shape="rect">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><strong>Note:</strong> The <a href="#sec-ReferenceGeneration"
  shape="rect">Reference Generation Model</a> (section 3.1.1)
  includes further restrictions on the reliance upon defined
  default transformations when applications generate
  signatures.</p>

  <p>In this specification, a 'same-document' reference is defined
  as a URI-Reference that consists of a hash sign ('#') followed by
  a fragment or alternatively consists of an empty URI [<a href=
  "#ref-URI" shape="rect">URI</a>].</p>

  <p>Unless the URI-Reference is such a 'same-document' reference ,
  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" shape=
  "rect">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 in this case that the
  <code>URI</code>&nbsp; attribute not include fragment identifiers
  and that such processing be specified as an additional <a href=
  "#sec-XPath" shape="rect">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
  shortname XPointer [<a href="#ref-XPointer-Framework" shape=
  "rect">XPointer-Framework</a>]. We RECOMMEND support for the
  same-document XPointers '<code>#xpointer(/)</code>' and
  '<code>#xpointer(id('ID'))</code>' if the application also
  intends to support any <a href="#sec-Canonical" shape=
  "rect">canonicalization</a> that preserves comments. (Otherwise
  <code>URI="#foo"</code> will automatically remove comments before
  the canonicalization can even be invoked due to the processing
  defined in <a href="#sec-Same-Document" shape=
  "rect">Same-Document URI-References</a> (section 4.3.3.3).) All
  other support for XPointers is OPTIONAL, especially all support
  for shortname 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>'<code>#xpointer(/)</code>' MUST be interpreted to identify
  the root node [<a href="#ref-XPath" shape="rect">XPath</a>] of
  the document that contains the <code>URI</code> attribute.</p>

  <p>'<code>#xpointer(id('<em>ID</em>'))</code>' MUST be
  interpreted to identify the element node identified by
  '<code>#element(<em>ID</em>)</code>' [<a href=
  "#ref-XPointer-Element" shape="rect">XPointer-Element</a>] when
  evaluated with respect to the document that contains the
  <code>URI</code> attribute.</p>

  <p>The original edition of this specification [<a href=
  "#ref-XMLDSIG-2002" shape="rect">XMLDSIG-2002</a>] referenced the
  XPointer Candidate Recommendation [<a href="#ref-XPTR-2001"
  shape="rect">XPTR-2001</a>] and some implementations support it
  optionally. That Candidate Recommendation has been superseded by
  the [<a href="#ref-XPointer-Framework" shape=
  "rect">XPointer-Framework</a>], [<a href="#ref-XPointer-xmlns"
  shape="rect">XPointer-xmlns</a>] and [<a href=
  "#ref-XPointer-Element" shape="rect">XPointer-Element</a>]
  Recommendations, and -- at the time of this edition -- the
  [<a href="#ref-XPointer-xpointer" shape=
  "rect">XPointer-xpointer</a>] Working Draft. Therefore, the use
  of the <code>xpointer()</code> scheme [<a href=
  "#ref-XPointer-xpointer" shape="rect">XPointer-xpointer</a>]
  beyond the usage discussed in this section is discouraged.</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
    (shortname 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 descendants including
    namespaces and attributes -- but not comments.</dd>
  </dl>

  <h4>4.3.3.3 <a name="sec-Same-Document" id="sec-Same-Document"
  shape="rect">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" shape="rect">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-Framework" shape=
  "rect">XPointer-Framework</a>]. When processing an XPointer, the
  application MUST behave as if the XPointer was evaluated with
  respect to the XML document containing the <code>URI</code>
  attribute . The application MUST behave as if the result of
  XPointer processing [<a href="#ref-XPointer-Framework" shape=
  "rect">XPointer-Framework</a>] were a node-set derived from the
  resultant subresource as follows:</p>

  <ol>
    <li>include XPath nodes having full or partial content within
    the subresource</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 has no fragment identifier or the fragment
    identifier is a shortname 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 and shortname
  XPointers . It is necessary because when [<a href="#ref-XML-C14N"
  shape="rect">XML-C14N</a>] or [<a href="#ref-XML-C14N11" shape=
  "rect">XML-C14N11</a>] is passed a node-set, it processes the
  node-set as is: with or without comments. Only when it is 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 scheme-based
  XPointer. To retain comments while selecting an element by an
  identifier <em>ID</em>, use the following scheme-based XPointer:
  <code>URI='#xpointer(id('<em>ID</em>'))'</code>. To retain
  comments while selecting the entire document, use the following
  scheme-based XPointer: <code>URI='#xpointer(/)'</code>.</p>

  <p>The interpretation of these XPointers is defined in <a href=
  "#sec-ReferenceProcessingModel" shape="rect">The Reference
  Processing Model</a> (section 4.3.3.2).</p>

  <h4>4.3.3.4 The <a id="sec-Transforms" name="sec-Transforms"
  shape="rect"><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" shape="rect">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" shape="rect">Algorithm
  Identifiers and Implementation Requirements</a> (section 6).)</p>

  <p>As described in <a href="#sec-ReferenceProcessingModel" shape=
  "rect">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" shape="rect">MIME</a>],
  canonicalization [<a href="#ref-XML-C14N" shape=
  "rect">XML-C14N</a>], XPath filtering [<a href="#ref-XPath"
  shape="rect">XPath</a>], and XSLT [<a href="#ref-XSLT" shape=
  "rect">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-TransformAlg" shape="rect">Transform Algorithms</a>
  (section 6.6) defines the list of standard transformations.</p>
  <pre class="xml-dtd" xml:space="preserve">
   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" xml:space="preserve">
   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"
  shape="rect"><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" shape=
  "rect">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"
  shape="rect">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" xml:space="preserve">
   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" xml:space="preserve">
   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"
  shape="rect"><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" shape="rect">MIME</a>].</p>
  <pre class="xml-dtd" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" shape="rect">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" shape="rect"><code>KeyValue</code></a> (section
  4.4.2) and SHOULD implement <code><a href="#sec-RetrievalMethod"
  shape="rect">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"
    shape=
    "rect">http://www.w3.org/2000/09/xmldsig#DSAKeyValue</a></li>

    <li><a href="http://www.w3.org/2000/09/xmldsig#RSAKeyValue"
    shape=
    "rect">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a></li>

    <li><a href="http://www.w3.org/2000/09/xmldsig#X509Data" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#X509Data</a></li>

    <li><a href="http://www.w3.org/2000/09/xmldsig#PGPData" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#PGPData</a></li>

    <li><a href="http://www.w3.org/2000/09/xmldsig#SPKIData" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#SPKIData</a></li>

    <li><a href="http://www.w3.org/2000/09/xmldsig#MgmtData" shape=
    "rect">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" shape="rect">binary
  (ASN.1 DER) X.509 Certificate</a>.</p>

  <ul>
    <li><a href=
    "http://www.w3.org/2000/09/xmldsig#rawX509Certificate" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#rawX509Certificate</a></li>
  </ul>
  <pre class="xml-dtd" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" xml:space="preserve">
   Schema Definition:

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

   &lt;!ELEMENT KeyName (#PCDATA) &gt;
</pre>

  <h4>4.4.2 The <a id="sec-KeyValue" name="sec-KeyValue" shape=
  "rect"><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" shape=
  "rect">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" xml:space="preserve">
   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" xml:space="preserve">
   DTD:

   &lt;!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue %KeyValue.ANY;)* &gt;
</pre>

  <h4>4.4.2.1 The <a id="sec-DSAKeyValue" name="sec-DSAKeyValue"
  shape="rect"><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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#DSAKeyValue</a>"<br clear="none" />
    </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" shape="rect">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" shape=
  "rect"><code>ds:CryptoBinary</code> type</a>.</p>
  <pre class="xml-dtd" xml:space="preserve">
   <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" xml:space="preserve">
   <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"
  shape="rect"><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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a>"<br clear="none" />
    </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" xml:space="preserve">
   &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" shape=
  "rect"><code>ds:CryptoBinary</code> type</a>.</p>
  <pre class="xml-dtd" xml:space="preserve">
   <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" xml:space="preserve">
   <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" shape=
  "rect"><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" shape=
  "rect"><code>Reference</code>'s URI</a> (section 4.3.3.1) and
  <a href="#sec-ReferenceProcessingModel" shape="rect">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 retrieved after all transforms have been applied. The result
  of dereferencing a <code>RetrievalMethod</code> <code><a href=
  "#sec-URI" shape="rect">Reference</a></code> for all <a href=
  "#sec-KeyInfo" shape="rect"><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" xml:space="preserve">
   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" xml:space="preserve">
   DTD

   &lt;!ELEMENT RetrievalMethod (Transforms?) &gt;
   &lt;!ATTLIST RetrievalMethod
      URI   CDATA #REQUIRED 
      Type  CDATA #IMPLIED &gt;
</pre>

  <p><strong>Note:</strong> The schema for the <code>URI</code>
  attribute of RetrievalMethod erroneously omitted the attribute:
  <code>use="required"</code></p>

  <p>The DTD is correct. However, this error only results in a more
  lax schema which permits all valid RetrievalMethod elements.
  Because the existing schema is embedded in many applications,
  which may include the schema in their signatures, the schema has
  not been corrected to be more restrictive.</p>

  <h4>4.4.4 The <a id="sec-X509Data" name="sec-X509Data" shape=
  "rect"><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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#X509Data</a></code>
    "<br clear="none" />
    (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. The distinguished name SHOULD be represented as a
        string that complies with section 3 of RFC4514 [<a href=
        "#ref-LDAP-DN" shape="rect">LDAP-DN</a>], to be generated
        according to the <a href="#dname-encrules" shape=
        "rect">Distinguished Name Encoding Rules</a> section
        below,</li>

        <li>The <code>X509SubjectName</code> element, which
        contains an X.509 subject distinguished name that SHOULD be
        represented as a string that complies with section 3 of
        RFC4514 [<a href="#ref-LDAP-DN" shape="rect">LDAP-DN</a>],
        to be generated according to the <a href="#dname-encrules"
        shape="rect">Distinguished Name Encoding Rules</a> section
        below,</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" shape=
        "rect">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" shape="rect">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" xml:space="preserve">
   &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>

  <h4><a name="dname-encrules" id="dname-encrules" shape=
  "rect">4.4.4.1 Distinguished Name Encoding Rules</a></h4>

  <p>To encode a distinguished name
  (<code>X509IssuerSerial</code>,<code>X509SubjectName</code>, and
  <code>KeyName</code> if appropriate), the encoding rules in
  section 2 of RFC 4514 [<a href="#ref-LDAP-DN" shape=
  "rect">LDAP-DN</a>] SHOULD be applied, except that the character
  escaping rules in section 2.4 of RFC 4514 [<a href="#ref-LDAP-DN"
  shape="rect">LDAP-DN</a>] MAY be augmented as follows:</p>

  <ul>
    <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 space characters (Unicode \x20) by
    replacing them with "\20", instead of using the escape sequence
    "\ ".</li>
  </ul>

  <p>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.</p>
  <pre class="xml-dtd" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
"rect"><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" shape=
  "rect"><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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#PGPData</a></code>
    "<br clear="none" />
    (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" shape=
  "rect">PGP</a>, section 11.2]. The <code>PGPKeyPacket</code>
  contains a base64-encoded Key Material Packet as defined in
  [<a href="#ref-PGP" shape="rect">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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#SPKIData</a></code>
    "<br clear="none" />
    (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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#MgmtData</a></code>
    "<br clear="none" />
    (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" xml:space="preserve">
   Schema Definition:

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

   &lt;!ELEMENT MgmtData (#PCDATA)&gt;
</pre>

  <h3>4.5 The <a id="sec-Object" name="sec-Object" shape=
  "rect"><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" shape=
    "rect">"http://www.w3.org/2000/09/xmldsig#Object"</a><br clear=
    "none" /></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" shape="rect">MIME</a>]. For
  example, if the <code>Object</code> contains base64 encoded
  <a href="http://www.w3.org/Graphics/PNG/" shape="rect">PNG</a>,
  the <code>Encoding</code> may be specified as
  'http://www.w3.org/2000/09/xmldsig#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" shape=
  "rect">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" shape="rect">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" xml:space="preserve">
   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" xml:space="preserve">
   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"
  shape="rect">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" shape=
  "rect"><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"
    shape=
    "rect">"http://www.w3.org/2000/09/xmldsig#Manifest"</a><br clear="none" />
    </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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect"><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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#SignatureProperties</a>"<br clear="none" />
    </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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape="rect">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" shape=
  "rect">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" shape="rect">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" shape=
  "rect">XML-C14N</a>], is specified.</p>

  <h2>6.0 <a id="sec-Algorithms" name="sec-Algorithms" shape=
  "rect">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" shape=
  "rect">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 clear="none" />
        <a href="http://www.w3.org/2000/09/xmldsig#sha1" shape=
        "rect">http://www.w3.org/2000/09/xmldsig#sha1</a></li>
      </ol>
    </dd>

    <dt>Encoding</dt>

    <dd>
      <ol>
        <li>Required base64<br clear="none" />
        <a href="http://www.w3.org/2000/09/xmldsig#base64" shape=
        "rect"><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 clear="none" />
        <a href="http://www.w3.org/2000/09/xmldsig#hmac-sha1"
        shape="rect">http://www.w3.org/2000/09/xmldsig#hmac-sha1</a></li>
      </ol>
    </dd>

    <dt>Signature</dt>

    <dd>
      <ol>
        <li>Required DSAwithSHA1 (DSS)<br clear="none" />
        <a href="http://www.w3.org/2000/09/xmldsig#dsa-sha1" shape=
        "rect"><span style=
        "font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span>dsa-sha1</a></li>

        <li>Recommended RSAwithSHA1<br clear="none" />
        <a href="http://www.w3.org/2000/09/xmldsig#rsa-sha1" shape=
        "rect"><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 1.0(omits comments)<br clear=
        "none" />
        <a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
        shape=
        "rect">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a></li>

        <li>Recommended Canonical XML 1.0with Comments<br clear=
        "none" />
        <a href=
        "http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"
        shape=
        "rect">http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments</a></li>

        <li>Required Canonical XML 1.1 (omits comments)<br clear=
        "none" />
        <a href="http://www.w3.org/2006/12/xml-c14n11" shape=
        "rect">http://www.w3.org/2006/12/xml-c14n11</a></li>

        <li>Recommended Canonical XML 1.1 with Comments<br clear=
        "none" />
        <a href="http://www.w3.org/2006/12/xml-c14n11#WithComments"
        shape=
        "rect">http://www.w3.org/2006/12/xml-c14n11#WithComments</a></li>
      </ol>
    </dd>

    <dt>Transform</dt>

    <dd>
      <ol>
        <li>Optional XSLT<br clear="none" />
        <a href="http://www.w3.org/TR/1999/REC-xslt-19991116"
        shape="rect">http://www.w3.org/TR/1999/REC-xslt-19991116</a></li>

        <li>Recommended XPath<br clear="none" />
        <a href="http://www.w3.org/TR/1999/REC-xpath-19991116"
        shape=
        "rect">http://www.w3.org/TR/1999/REC-xpath-19991116</a></li>

        <li>Required Enveloped Signature*<br clear="none" />
        <a href=
        "http://www.w3.org/2000/09/xmldsig#enveloped-signature"
        shape=
        "rect">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" shape="rect">Enveloped Signature
  Transform</a>; it MUST have the same effect as that specified by
  the <a href="#sec-XPath" shape="rect">XPath Transform</a>.</p>

  <h3>6.2 <a id="sec-MessageDigests" name="sec-MessageDigests"
  shape="rect">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" shape="rect">MD5</a>
  [<a href="#ref-MD5" shape="rect">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" shape=
  "rect">SHA-1</a></h4>

  <dl>
    <dt>Identifier:</dt>

    <dd><a id="sha1" href="http://www.w3.org/2000/09/xmldsig#sha1"
    name="sha1" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#sha1</a></dd>
  </dl>

  <p>The <a href=
  "http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf"
  shape="rect">SHA-1</a> algorithm [<a href="#ref-SHA-1" shape=
  "rect">SHA-1</a>] takes no explicit parameters. An example of an
  SHA-1 DigestAlg element is:</p>
  <pre class="xml-example" xml:space="preserve">
<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" xml:space="preserve">
   A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
</pre>

  <p>from Appendix A of the SHA-1 standard would be:</p>
  <pre class="xml-example" xml:space="preserve">
   &lt;DigestValue&gt;qZk+NkcGgWq6PiVxeFDCbJzQ2J0=&lt;/DigestValue&gt;
</pre>

  <h3>6.3 <a id="sec-MACs" name="sec-MACs" shape="rect">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" shape=
  "rect">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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#hmac-sha1</a></dd>
  </dl>

  <p>The <a href="http://www.ietf.org/rfc/rfc2104.txt" shape=
  "rect">HMAC</a> algorithm (RFC2104 [<a href="#ref-HMAC" shape=
  "rect">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" xml:space="preserve">
   &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" xml:space="preserve">
   9294727A 3638BB1C 13F48EF8 158BFC9D
</pre>

  <p>from the test vectors in [<a href="#ref-HMAC" shape=
  "rect">HMAC</a>] would be</p>
  <pre class="xml-example" xml:space="preserve">
   &lt;SignatureValue&gt;kpRyejY4uxwT9I74FYv8nQ==&lt;/SignatureValue&gt;
</pre>
  <pre class="xml-dtd" xml:space="preserve">
   Schema Definition:

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

   &lt;!ELEMENT HMACOutputLength (#PCDATA)&gt;
</pre>

  <h3>6.4 <a id="sec-SignatureAlg" name="sec-SignatureAlg" shape=
  "rect">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" shape=
  "rect">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" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#dsa-sha1</a></dd>
  </dl>

  <p>The DSA algorithm [<a href="#ref-DSS" shape="rect">DSS</a>]
  takes no explicit parameters. An example of a DSA
  <code>SignatureMethod</code> element is:</p>
  <pre class="xml-example" xml:space="preserve">
   <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" shape="rect">RFC 2437</a>
  [<a href="#ref-PKCS1" shape="rect">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" xml:space="preserve">
   <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" xml:space="preserve">
   <code>&lt;SignatureValue&gt;</code>
   <code>i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==&lt;/SignatureValue&gt;</code>
</pre>

  <h4>6.4.2 <a id="sec-PKCS1" name="sec-PKCS1" shape=
  "rect">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"
    shape=
    "rect">http://www.w3.org/2000/09/xmldsig#rsa-sha1</a></dd>
  </dl>

  <p>The expression "RSA algorithm" as used in this specification
  refers to the RSASSA-PKCS1-v1_5 algorithm described in <a href=
  "http://www.ietf.org/rfc/rfc2437.txt" shape="rect">RFC 2437</a>
  [<a href="#ref-PKCS1" shape="rect">PKCS1</a>]. The RSA algorithm
  takes no explicit parameters. An example of an RSA
  SignatureMethod element is:</p>
  <pre class="xml-example" xml:space="preserve">
   <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" shape="rect">MIME</a>]
  encoding of the octet string computed as per <a href=
  "http://www.ietf.org/rfc/rfc2437.txt" shape="rect">RFC 2437</a>
  [<a href="#ref-PKCS1" shape="rect">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" shape="rect">RFC 2437</a>
  [<a href="#ref-PKCS1" shape="rect">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" xml:space="preserve">
   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" xml:space="preserve">
   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" xml:space="preserve">
   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" shape=
  "rect">MIME</a>] string is the value of the child text node of
  the SignatureValue element, e.g.</p>
  <pre class="xml-example" xml:space="preserve">
&lt;SignatureValue&gt;
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
&lt;/SignatureValue&gt;
</pre>

  <h3>6.5 <a id="sec-c14nAlg" name="sec-c14nAlg" shape=
  "rect">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" shape="rect">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" shape="rect">UTF-8</a>].The algorithms
  below understand at least [<a href="#ref-UTF-8" shape=
  "rect">UTF-8</a>] and [<a href="#ref-UTF-16" shape=
  "rect">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 output of these algorithms
  will be in NFC [<a href="#ref-NFC" shape="rect">NFC</a>, <a href=
  "#ref-NFC-Corrigendum" shape="rect">NFC-Corrigendum</a>]. This is
  because the XML processor used to prepare the XPath data model
  input is required (by the Data Model) to use Normalization Form C
  when converting an XML document to the UCS character domain from
  any encoding that is not UCS-based.</p>

  <p>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" shape=
  "rect">XML-Japanese</a>] Note.)</p>

  <p>This specification REQUIRES implementation of both Canonical
  XML 1.0 [<a href="#ref-XML-C14N" shape="rect">XML-C14N</a>] and
  Canonical XML 1.1 [<a href="#ref-XML-C14N11" shape=
  "rect">XML-C14N11</a>]. We RECOMMEND that applications that
  generate signatures choose Canonical XML 1.1 [<a href=
  "#ref-XML-C14N11" shape="rect">XML-C14N11</a>] when inclusive
  canonicalization is desired.</p>

  <p><b>Note</b>: Canonical XML 1.0 [<a href="#ref-XML-C14N" shape=
  "rect">XML-C14N</a>] and Canonical XML 1.1 [<a href=
  "#ref-XML-C14N11" shape="rect">XML-C14N11</a>] specify a standard
  serialization of XML that, when applied to a subdocument,
  includes the subdocument's ancestor context including all of the
  namespace declarations and some attributes in the 'xml:'
  namespace. However, some applications require a method which, to
  the extent practical, excludes unused ancestor context from a
  canonicalized subdocument. The Exclusive XML Canonicalization
  Recommendation [<a href="#ref-XML-exc-C14N" shape=
  "rect">XML-exc-C14N</a>] may be used to address requirements
  resulting from scenarios where a subdocument is moved between
  contexts.</p>

  <h4>6.5.1 <a id="sec-Canonical" name="sec-Canonical" shape=
  "rect">Canonical</a> XML 1.0</h4>

  <dl>
    <dt>Identifier for REQUIRED Canonical XML 1.0 (omits
    comments):</dt>

    <dd><a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
    shape=
    "rect">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a></dd>
  </dl>

  <dl>
    <dt>Identifier for Canonical XML 1.0 with Comments:</dt>

    <dd><a href=
    "http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"
    shape=
    "rect">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" xml:space="preserve">
   <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 XML1.0 is [<a href=
  "#ref-XML-C14N" shape="rect">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>

  <h4 id="sec-Canonical11">6.5.2 Canonical XML 1.1</h4>

  <dl>
    <dt>Identifier for REQUIRED Canonical XML 1.1 (omits
    comments):</dt>

    <dd><a href="http://www.w3.org/2006/12/xml-c14n11" shape=
    "rect">http://www.w3.org/2006/12/xml-c14n11</a></dd>

    <dt>Identifier for Canonical XML 1.1 with Comments:</dt>

    <dd><a href="http://www.w3.org/2006/12/xml-c14n11#WithComments"
    shape=
    "rect">http://www.w3.org/2006/12/xml-c14n11#WithComments</a></dd>
  </dl>

  <p>The normative specification of Canonical XML 1.1 is [<a href=
  "#ref-XML-C14N11" shape="rect">XML-C14N11</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 1.1 is easily
  parameterized (via an additional URI) to omit or retain
  comments.</p><!--  
<ins>
<p class="discuss"><a name="Editors-Note-C14N11-AppendixA2" id="Editors-Note-C14N11-AppendixA2">
Editors Note</a>: There has been a correction to Appendix A of the C14N11 Candidate Recommendation. This
correction is available at 
<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html">
http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html</a>.
The XML Security Specifications Maintenance WG anticipates this change will be adopted as part of 
C14N11 CR review and will use this update to Appendix A for Interop testing.
</p>
</ins>
-->

  <h3>6.6 <a id="sec-TransformAlg" name="sec-TransformAlg" shape=
  "rect"><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" shape="rect">Canonicalization</a></h4>

  <p>Any canonicalization algorithm that can be used for
  <code>CanonicalizationMethod</code> (such as those in&nbsp;
  <a href="#sec-c14nAlg" shape="rect">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" shape=
  "rect">Base64</a></h4>

  <dl>
    <dt>Identifiers:</dt>

    <dd><a id="base64" href=
    "http://www.w3.org/2000/09/xmldsig#base64" name="base64" shape=
    "rect">http://www.w3.org/2000/09/xmldsig#base64</a></dd>
  </dl>

  <p>The normative specification for base64 decoding transforms is
  [<a href="#ref-MIME" shape="rect">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 shortname 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" shape=
  "rect">XPath</a> Filtering</h4>

  <dl>
    <dt>Identifier:</dt>

    <dd><a href="http://www.w3.org/TR/1999/REC-xpath-19991116"
    shape=
    "rect">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" shape="rect">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 shortname 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>Note that the XML-Signature XPath Filter 2.0 Recommendation
  [<a href="#ref-XPath-Filter-2" shape="rect">XPath-Filter-2</a>]
  may be used for this purpose. This recommendation defines an
  XPath transform that permits the easy specification of subtree
  selection and omission that can be efficiently implemented.</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" shape=
    "rect">XPath]</a> plus a function named <strong><a href=
    "#function-here" shape="rect">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" shape="rect">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" shape=
  "rect"><strong>Function:</strong> <em>node-set</em>
  <strong>here</strong>()</a></p>

  <p>The <strong><a href="#function-here" shape=
  "rect">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" xml:space="preserve">
   &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" shape="rect">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" xml:space="preserve">
   &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" shape="rect">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" shape=
    "rect">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" xml:space="preserve">
   &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" shape="rect">XSLT</a>
  Transform</h4>

  <dl>
    <dt>Identifier:</dt>

    <dd><a href="http://www.w3.org/TR/1999/REC-xslt-19991116"
    shape="rect">http://www.w3.org/TR/1999/REC-xslt-19991116</a></dd>
  </dl>

  <p>The normative specification for XSL Transformations is
  [<a href="#ref-XSLT" shape="rect">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"
  shape="rect"><code>xsl:include</code></a> or <a href=
  "http://www.w3.org/TR/1999/REC-xslt-19991116#section-Combining-Stylesheets"
  shape="rect"><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" shape="rect">Canonical XML</a>]) as described in
  <a href="#sec-ReferenceProcessingModel" shape="rect">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" shape=
  "rect">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" shape=
  "rect">XHTML</a>].</p>

  <h2>7.0 <a id="sec-XML-Canonicalization" name=
  "sec-XML-Canonicalization" shape="rect">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" shape="rect">XML</a>], as described
  in 7.1 below. There are those related to [<a href="#ref-DOM"
  shape="rect">DOM</a>], [<a href="#ref-SAX" shape="rect">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" shape="rect">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" shape="rect">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" shape="rect">NFC</a>, <a href="#ref-NFC-Corrigendum"
  shape="rect">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" shape="rect">XML
  1.0</a>, Syntax Constraints, and Canonicalization</h3>

  <p>XML 1.0 [<a href="#ref-XML" shape="rect">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"
  shape="rect">laxly schema valid</a> [<a href="#ref-XML-schema"
  shape="rect">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" shape=
  "rect">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" shape="rect">DOM</a>] or the Simple API
  for XML&nbsp; [<a href="#ref-SAX" shape="rect">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" shape="rect">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" shape="rect">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"
  shape="rect">Namespace Context</a> and Portable Signatures</h3>

  <p>In [<a href="#ref-XPath" shape="rect">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" shape=
    "rect">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" xml:space="preserve">
   &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" shape=
  "rect">SOAP</a>] envelope for transport:</p>
  <pre class="xml-example" xml:space="preserve">
   &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" shape="rect">XML-C14N</a>] purposefully
    attracts such context.</li>
  </ol>

  <h2>8.0 <a id="sec-Security" name="sec-Security" shape=
  "rect">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" shape="rect">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" shape=
  "rect">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" shape="rect">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" shape=
  "rect">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" shape=
  "rect">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" shape="rect">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" shape="rect">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" shape="rect">"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"
  shape="rect">embedded style sheet</a> [<a href="#ref-XSLT" shape=
  "rect">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" shape=
    "rect">NFC</a>, <a href="#ref-NFC-Corrigendum" shape=
    "rect">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" shape="rect">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"
  shape="rect">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" shape="rect">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" shape=
  "rect">Schema</a>, DTD, Data Model, and Valid Examples</h2>

  <dl>
    <dt>XML Signature Schema Instance</dt>

    <dd><a href="xmldsig-core-schema.xsd" shape=
    "rect">xmldsig-core-schema.xsd</a></dd>

    <dd>Valid XML schema instance based on the 20001024 Schema/DTD
    [<a href="#ref-XML-schema" shape="rect">XML-Schema</a>].</dd>

    <dt>XML Signature DTD</dt>

    <dd><a href="xmldsig-core-schema.dtd" shape=
    "rect">xmldsig-core-schema.dtd</a></dd>

    <dt>RDF Data Model</dt>

    <dd><a href="xmldsig-datamodel-20000112.gif" shape=
    "rect">xmldsig-datamodel-20000112.gif</a></dd>

    <dt>XML Signature Object Example</dt>

    <dd><a href="signature-example.xml" shape=
    "rect">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" shape=
    "rect">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" shape=
    "rect">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" shape=
  "rect">Definitions</a></h2>

  <dl>
    <dt><a id="def-AuthenticationCode" name=
    "def-AuthenticationCode" shape="rect">Authentication Code</a>
    (<a name="def-ProtectedChecksum" id="def-ProtectedChecksum"
    shape="rect">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" shape="rect">message authentication</a> (and
    <a href="#def-Integrity" class="link-def" shape=
    "rect">integrity</a>) but not <a href=
    "#def-AuthenticationSigner" class="link-def" shape=
    "rect">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" shape=
    "rect">SEC</a>]</dd>

    <dt><a id="def-AuthenticationMessage" name=
    "def-AuthenticationMessage" shape="rect">Authentication,
    Message</a></dt>

    <dd>The property, given an <a href="#def-AuthenticationCode"
    class="link-def" shape="rect">authentication code</a>/<a href=
    "#def-ProtectedChecksum" class="link-def" shape=
    "rect">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" shape=
    "rect">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" shape=
    "rect">Digital Signature Guidelines</a>, <a href="#ref-ABA"
    shape="rect">ABA</a>].</dd>

    <dt><a id="def-AuthenticationSigner" name=
    "def-AuthenticationSigner" shape="rect">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" shape=
    "rect">Digital Signature Guidelines</a>, <a href="#ref-ABA"
    shape="rect">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" shape=
    "rect">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"
    shape="rect">SEC</a>]</dd>

    <dt><a id="def-Core" name="def-Core" shape="rect">Core</a></dt>

    <dd>The syntax and processing defined by this specification,
    including <a href="#def-ValidationCore" class="link-def" shape=
    "rect">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" shape=
    "rect">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"
    shape="rect">HTTP entity</a> [<a href="#ref-HTTP" shape=
    "rect">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" shape="rect">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" shape="rect">XML</a>]. The term <em>XML
    document</em> is used to describe data objects which conform to
    the XML specification [<a href="#ref-XML" shape=
    "rect">XML</a>].</dd>

    <dt><a id="def-Integrity" name="def-Integrity" shape=
    "rect">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" shape="rect">SEC</a>] A simple <a href=
    "#def-Checksum" class="link-def" shape="rect">checksum</a> can
    provide integrity from incidental changes in the data; <a href=
    "#def-AuthenticationMessage" class="link-def" shape=
    "rect">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" shape=
    "rect">Object</a></dt>

    <dd>An XML Signature element wherein arbitrary (non-<a href=
    "#def-Core" class="link-def" shape="rect">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" shape=
    "rect">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" shape="rect">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" shape=
    "rect">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" shape="rect">integrity</a>, <a href=
    "#def-AuthenticationMessage" class="link-def" shape=
    "rect">message authentication</a> and/or <a href=
    "#def-AuthenticationSigner" class="link-def" shape=
    "rect">signer authentication</a>. (However, we sometimes use
    the term signature generically such that it encompasses
    <a href="#def-AuthenticationCode" class="link-def" shape=
    "rect">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" shape=
    "rect">signer authentication</a> is relevant to the
    exposition.) A signature may be (non-exclusively) described as
    <a href="#def-SignatureDetached" class="link-def" shape=
    "rect">detached</a>, <a href="#def-SignatureEnveloping" class=
    "link-def" shape="rect">enveloping</a>, or <a href=
    "#def-SignatureEnveloped" class="link-def" shape=
    "rect">enveloped</a>.</dd>

    <dt><a name="def-SignatureApplication" id=
    "def-SignatureApplication" shape="rect">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"
    shape="rect">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" shape="rect">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" shape="rect">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" shape=
    "rect">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" shape=
    "rect">Validation, Core</a></dt>

    <dd>The core processing requirements of this specification
    requiring <a href="#def-ValidationSignature" class="link-def"
    shape="rect">signature validation</a> and
    <code>SignedInfo</code> <a href="#def-ValidationReference"
    class="link-def" shape="rect">reference validation</a>.</dd>

    <dt><a id="def-ValidationReference" name=
    "def-ValidationReference" shape="rect">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" shape="rect">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" shape="rect">Core Validation</a> (section
    3.2).</dd>

    <dt><a id="def-ValidationTrustApplication" name=
    "def-ValidationTrustApplication" shape="rect">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" shape="rect">core</a>
    specification.</dd>
  </dl>

  <h2>11.0 <a id="sec-References" name="sec-References" shape=
  "rect">References</a></h2>

  <dl>
    <dt><a id="ref-ABA" name="ref-ABA" shape="rect">ABA</a></dt>

    <dd><a href="http://www.abanet.org/scitech/ec/isc/dsgfree.html"
    shape="rect">Digital Signature Guidelines.</a><br clear=
    "none" />
    <a href="http://www.abanet.org/scitech/ec/isc/dsgfree.html"
    shape=
    "rect">http://www.abanet.org/scitech/ec/isc/dsgfree.html</a></dd>

    <dt><a id="ref-DOM" name="ref-DOM" shape="rect">DOM</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/" shape=
    "rect">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 clear="none" />
    <a href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/"
    shape=
    "rect">http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/</a></dd>

    <dt><a id="ref-DSS" name="ref-DSS" shape="rect">DSS</a></dt>

    <dd><a href=
    "http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf"
    shape="rect">FIPS PUB 186-2</a>. <em>Digital Signature Standard
    (DSS).</em> U.S. Department of Commerce/National Institute of
    Standards and Technology.<br clear="none" />
    <a href=
    "http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf"
    shape=
    "rect">http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf</a></dd>

    <dt><a id="ref-HMAC" name="ref-HMAC" shape="rect">HMAC</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2104.txt" shape=
    "rect">RFC 2104</a>. <em>HMAC: Keyed-Hashing for Message
    Authentication.</em> H. Krawczyk, M. Bellare, R. Canetti.
    February 1997.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2104.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2104.txt</a></dd>

    <dt><a id="ref-HTTP" name="ref-HTTP" shape="rect">HTTP</a></dt>

    <dd><a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html"
    shape="rect">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 clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2616.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2616.txt</a></dd>

    <dt><a id="ref-KEYWORDS" name="ref-KEYWORDS" shape=
    "rect">KEYWORDS</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2119.txt" shape=
    "rect">RFC 2119.</a> <em>Key words for use in RFCs to Indicate
    Requirement Levels.</em> S. Bradner. March 1997.<br clear=
    "none" />
    <a href="http://www.ietf.org/rfc/rfc2119.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2119.txt</a></dd>

    <dt><a id="ref-LDAP-DN" name="ref-LDAP-DN" shape=
    "rect">LDAP-DN</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc4514.txt" shape=
    "rect">RFC4514</a> . <em>Lightweight Directory Access Protocol
    : String Representation of Distinguished Names.</em> K.
    Zeilenga, Ed. June 2006.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2253.txt" shape=
    "rect"></a><a href="http://www.ietf.org/rfc/rfc4514.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc4514.txt</a></dd>

    <dt><a id="ref-MD5" name="ref-MD5" shape="rect">MD5</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc1321.txt" shape=
    "rect">RFC 1321</a>. <em>The MD5 Message-Digest Algorithm.</em>
    R. Rivest. April 1992.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc1321.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc1321.txt</a></dd>

    <dt><a id="ref-MIME" name="ref-MIME" shape="rect">MIME</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2045.txt" shape=
    "rect">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 clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2045.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2045.txt</a></dd>

    <dt><a id="ref-NFC" name="ref-NFC" shape="rect">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"
    shape=
    "rect">http://www.unicode.org/unicode/reports/tr15/tr15-18.html</a>.</dd>

    <dt><a id="ref-NFC-Corrigendum" name="ref-NFC-Corrigendum"
    shape="rect">NFC-Corrigendum</a></dt>

    <dd><em>Normalization Corrigendum</em>. The Unicode Consortium.
    <a href=
    "http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html"
    shape=
    "rect">http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html</a>.</dd>

    <dt><a id="ref-PGP" name="ref-PGP" shape="rect">PGP</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2440.txt" shape=
    "rect">RFC 2440</a>. <em>OpenPGP Message Format.</em> J.
    Callas, L. Donnerhacke, H. Finney, R. Thayer. November
    1998.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2440.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2440.txt</a></dd>

    <dt><a id="ref-RANDOM" name="ref-RANDOM" shape=
    "rect">RANDOM</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc1750.txt" shape=
    "rect">RFC 1750</a>. <em>Randomness Recommendations for
    Security.</em> D. Eastlake, S. Crocker, J. Schiller. December
    1994.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc1750.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc1750.txt</a></dd>

    <dt><a id="ref-RDF" name="ref-RDF" shape="rect">RDF</a></dt>

    <dd><a href="http://www.w3.org/TR/2000/CR-rdf-schema-20000327/"
    shape="rect">Resource Description Framework (RDF) Schema
    Specification 1.0.</a> W3C Candidate Recommendation. D.
    Brickley, R.V. Guha. March 2000.<br clear="none" />
    <a href="http://www.w3.org/TR/2000/CR-rdf-schema-20000327/"
    shape=
    "rect">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/" shape=
    "rect">Resource Description Framework (RDF) Model and Syntax
    Specification</a>. W3C Recommendation. O. Lassila, R. Swick.
    February 1999.<br clear="none" />
    <a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/"
    shape=
    "rect">http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/</a></dd>

    <dt><a id="ref-1363" name="ref-1363" shape="rect">1363</a></dt>

    <dd>IEEE 1363: Standard Specifications for Public Key
    Cryptography. August 2000.</dd>

    <dt><a id="ref-PKCS1" name="ref-PKCS1" shape=
    "rect">PKCS1</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2437.txt" shape=
    "rect">RFC 2437</a>. <em>PKCS #1: RSA Cryptography
    Specifications Version 2.0.</em> B. Kaliski, J. Staddon.
    October 1998.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2437.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2437.txt</a></dd>

    <dt><a id="ref-SAX" name="ref-SAX" shape="rect">SAX</a></dt>

    <dd><a href="http://www.megginson.com/downloads/SAX/" shape=
    "rect">SAX: The Simple API for XML</a>. D. Megginson, et al.
    May 1998.<br clear="none" />
    <a href="http://www.megginson.com/downloads/SAX/" shape=
    "rect">http://www.megginson.com/downloads/SAX/</a></dd>

    <dt><a name="ref-SEC" id="ref-SEC" shape="rect">SEC</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2828.txt" shape=
    "rect">RFC 2828</a>. <em>Internet Security Glossary.</em> R.
    Shirey. May 2000.<br clear="none" />
    <a href="http://www.faqs.org/rfcs/rfc2828.html" shape=
    "rect">http://www.faqs.org/rfcs/rfc2828.html</a></dd>

    <dt><a id="ref-SHA-1" name="ref-SHA-1" shape=
    "rect">SHA-1</a></dt>

    <dd><a href=
    "http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf"
    shape="rect">FIPS PUB 180-2</a>. <em>Secure Hash Standard.</em>
    U.S. Department of Commerce/National Institute of Standards and
    Technology.<br clear="none" />
    <a href=
    "http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf"
    shape=
    "rect">http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf</a></dd>

    <dt class="label"><a name="ref-SOAP" id="ref-SOAP" shape=
    "rect">SOAP</a></dt>

    <dd><a href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/"
    shape="rect">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/"
    shape=
    "rect">http://www.w3.org/TR/2000/NOTE-SOAP-20000508/</a></dd>
    
    <dt><a id="ref-TESTCASES" name="ref-TESTCASES">TESTCASES</a></dt>
    <dd><a href="http://www.w3.org/TR/2008/NOTE-xmldsig2ed-tests-20080610/">Test Cases for C14N 1.1
    and XMLDSig Interoperability</a>. W3C Working Group Note. J.C. Cruellas, K. Lanz, S. Mullan.
    June 2008.</dd>
    <dd><a href="http://www.w3.org/TR/2008/NOTE-xmldsig2ed-tests-20080610/">http://www.w3.org/TR/2008/NOTE-xmldsig2ed-tests-20080610/</a></dd>
    
    <dt><a name="ref-UTF-16" id="ref-UTF-16" shape=
    "rect">UTF-16</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2781.txt" shape=
    "rect">RFC 2781</a>. <em>UTF-16, an encoding of ISO 10646.</em>
    P. Hoffman , F. Yergeau. February 2000.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2781.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2781.txt</a></dd>

    <dt><a id="ref-UTF-8" name="ref-UTF-8" shape=
    "rect">UTF-8</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2279.txt" shape=
    "rect">RFC 2279</a>. <em>UTF-8, a transformation format of ISO
    10646</em>. F. Yergeau. January 1998.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2279.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2279.txt</a></dd>

    <dt><a id="ref-URI" name="ref-URI" shape="rect">URI</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc3986.txt" shape=
    "rect">RFC 3986</a>. <em>Uniform Resource Identifiers (URI):
    Generic Syntax.</em> T. Berners-Lee, R. Fielding, L. Masinter.
    January 2005.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc3986.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc3986.txt</a></dd>

    <dt><a id="ref-URL" name="ref-URL" shape="rect">URL</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc1738.txt" shape=
    "rect">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" shape=
    "rect">http://www.ietf.org/rfc/rfc1738.txt</a></dd>

    <dt><a id="ref-URN" name="ref-URN" shape="rect">URN</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2141.txt" shape=
    "rect">RFC 2141</a>. <em>URN Syntax.</em> R. Moats. May
    1997.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2141.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2141.txt</a></dd>

    <dd><a href="http://www.ietf.org/rfc/rfc2611.txt" shape=
    "rect">RFC 2611</a>. <em>URN Namespace Definition
    Mechanisms.</em> L. Daigle, D. van Gulik, R. Iannella, P.
    Falstrom. June 1999.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2611.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2611.txt</a></dd>

    <dt><a name="ref-X509v3" id="ref-X509v3" shape=
    "rect">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" shape="rect">XHTML
    1.0</a></dt>

    <dd><a href="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"
    shape="rect">XHTML(tm) 1.0: The Extensible Hypertext Markup
    Language</a>. W3C Recommendation. S. Pemberton, D. Raggett, et
    al. January 2000.<br clear="none" />
    <a href="http://www.w3.org/TR/2000/REC-xhtml1-20000126/" shape=
    "rect">http://www.w3.org/TR/2000/REC-xhtml1-20000126/</a></dd>

    <dt><a id="ref-XLink" name="ref-XLink" shape=
    "rect">XLink</a></dt>

    <dd><a href="http://www.w3.org/TR/2001/REC-xlink-20010627/"
    shape="rect">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/"
    shape=
    "rect">http://www.w3.org/TR/2001/REC-xlink-20010627/</a></dd>

    <dt><a id="ref-XML" name="ref-XML" shape="rect">XML</a></dt>

    <dd><a href="http://www.w3.org/TR/2006/REC-xml-20060816/"
    shape="rect">Extensible Markup Language (XML) 1.0 (Fourth
    Edition).</a> W3C Recommendation T. Bray, E. Maler, J. Paoli,
    C. M. Sperberg-McQueen, F.Yergeau. 16 August 2006, edited in
    place 29 September 2006.</dd>

    <dd><a href="http://www.w3.org/TR/2006/REC-xml-20060816/"
    shape="rect">http://www.w3.org/TR/2006/REC-xml-20060816/</a></dd>

    <dt><a id="ref-XML-C14N" name="ref-XML-C14N" shape=
    "rect">XML-C14N</a></dt>

    <dd><a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
    shape="rect">Canonical XML.</a> W3C Recommendation. J. Boyer.
    March 2001.</dd>

    <dd><a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
    shape=
    "rect">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a><br clear="none" />

    <a href="http://www.ietf.org/rfc/rfc3076.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc3076.txt</a></dd>

    <dt id="ref-XML-C14N11">XML-C14N11</dt>

    <dd><a href=
    "http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/" shape=
    "rect">Canonical XML 1.1.</a> W3C Recommendation. J. Boyer, G.
    Marcy. 2 May 2008.<br clear="none" />
    <a href="http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/"
    shape=
    "rect">http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/</a></dd>

    <dt><a id="ref-XML-exc-C14N" name="ref-XML-exc-C14N" shape=
    "rect">XML-exc-C14N</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/" shape=
    "rect">Exclusive XML Canonicalization Version 1.0</a> W3C
    Recommendation. J. Boyer, D. Eastlake 3rd., J. Reagle. July
    2002.<br clear="none" />
    <a href="http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/"
    shape=
    "rect">http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/</a></dd>

    <dt><a name="ref-XML-Japanese" id="ref-XML-Japanese" shape=
    "rect">XML-Japanese</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/" shape=
    "rect">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/" shape=
    "rect">http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/</a></dd>

    <dt><a name="ref-XML-MT" id="ref-XML-MT" shape=
    "rect">XML-MT</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2376.txt" shape=
    "rect">RFC 2376</a> . <em>XML Media Types</em>. E. Whitehead,
    M. Murata. July 1998.<br clear="none" />
    <a href="http://www.ietf.org/rfc/rfc2376.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2376.txt</a></dd>

    <dt><a id="ref-XML-ns" name="ref-XML-ns" shape=
    "rect">XML-ns</a></dt>

    <dd><a href="http://www.w3.org/TR/2006/REC-xml-names-20060816/"
    shape="rect">Namespaces in XML 1.0 (Second Edition)</a>. W3C
    Recommendation. T. Bray, D. Hollander, A. Layman, R. Tobin. 16
    August 2006.</dd>

    <dd><a href="http://www.w3.org/TR/2006/REC-xml-names-20060816/"
    shape=
    "rect">http://www.w3.org/TR/2006/REC-xml-names-20060816/</a></dd>

    <dt><a id="ref-XML-schema" name="ref-XML-schema" shape=
    "rect">XML-schema</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/" shape=
    "rect">XML Schema Part 1: Structures</a>. W3C Recommendation.
    H. Thompson,D. Beech, M. Maloney, N. Mendelsohn. October
    2004.</dd>

    <dd><a href=
    "http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/" shape=
    "rect">http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/</a><br clear="none" />

    <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/"
    shape="rect">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/" shape=
    "rect">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</a></dd>

    <dt><a id="ref-XML-Signature-RD" name="ref-XML-Signature-RD"
    shape="rect">XML-Signature-RD</a></dt>

    <dd><a href="http://www.ietf.org/rfc/rfc2807.txt" shape=
    "rect">RFC 2807</a>. <a href=
    "http://www.w3.org/TR/xmldsig-requirements" shape="rect">XML
    Signature Requirements.</a> W3C Working Draft. J. Reagle, April
    2000.<br clear="none" />
    <a href=
    "http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014.html"
    shape=
    "rect">http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014</a><br clear="none" />

    <a href="http://www.ietf.org/rfc/rfc2807.txt" shape=
    "rect">http://www.ietf.org/rfc/rfc2807.txt</a></dd>

    <dd><a href=
    "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/" shape=
    "rect">http://www.w3.org/TR/2002/REC-xmldsig-core-20020212//</a></dd>

    <dt><a name="ref-XMLDSIG-2002" id="ref-XMLDSIG-2002" shape=
    "rect">XMLDSIG-2002</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/" shape=
    "rect">XML-Signature Syntax and Processing</a>. D. Eastlake, J.
    Reagle, and D. Solo. W3C Recommendation, February 2002.</dd>

    <dd><a href=
    "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/" shape=
    "rect">http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/</a></dd>

    <dt><a id="ref-XPath" name="ref-XPath" shape=
    "rect">XPath</a></dt>

    <dd><a href="http://www.w3.org/TR/1999/REC-xpath-19991116"
    shape="rect">XML Path Language (XPath) Version 1.0</a>. W3C
    Recommendation. J. Clark, S. DeRose. October 1999.<br clear=
    "none" />
    <a href="http://www.w3.org/TR/1999/REC-xpath-19991116" shape=
    "rect">http://www.w3.org/TR/1999/REC-xpath-19991116</a></dd>

    <dt><a id="ref-XPath-Filter-2" name="ref-XPath-Filter-2" shape=
    "rect">XPath Filter-2</a></dt>

    <dd><a href="http://www.w3.org/TR/xmldsig-filter2/" shape=
    "rect">XML-Signature XPath Filter 2.0</a>. W3C Recommendation.
    J. Boyer, M. Hughes, J. Reagle. November 2002.<br clear=
    "none" />
    <a href=
    "http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/"
    shape="rect">http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/</a></dd>

    <dt><a id="ref-XPTR-2001" name="ref-XPTR-2001" shape=
    "rect">XPTR-2001</a></dt>

    <dd><a href="http://www.w3.org/TR/2001/CR-xptr-20010911/"
    shape="rect">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/"
    shape="rect">http://www.w3.org/TR/2001/CR-xptr-20010911/</a></dd>

    <dt><a name="ref-XPointer-Element" id="ref-XPointer-Element"
    shape="rect">XPointer-Element</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/2003/REC-xptr-element-20030325/" shape=
    "rect">XPointer element() Scheme</a>. W3C Recommendation. P.
    Grosso, E. Maler, J. Marsh, N. Walsh. March 2003.</dd>

    <dd><a href=
    "http://www.w3.org/TR/2003/REC-xptr-element-20030325/" shape=
    "rect">http://www.w3.org/TR/2003/REC-xptr-element-20030325/</a></dd>

    <dt><a name="ref-XPointer-Framework" id=
    "ref-XPointer-Framework" shape=
    "rect">XPointer-Framework</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/2003/REC-xptr-framework-20030325/" shape=
    "rect">XPointer Framework</a>. W3C Recommendation. P. Grosso,
    E. Maler, J. Marsh, N. Walsh. March 2003.</dd>

    <dd><a href=
    "http://www.w3.org/TR/2003/REC-xptr-framework-20030325/" shape=
    "rect">http://www.w3.org/TR/2003/REC-xptr-framework-20030325/</a></dd>

    <dt><a name="ref-XPointer-xpointer" id="ref-XPointer-xpointer"
    shape="rect">XPointer-xpointer</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/" shape=
    "rect">XPointer xpointer() Scheme</a>. W3C Working Draft. S.
    DeRose, E. Maler, R. Daniel. December 2002.</dd>

    <dd><a href=
    "http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/" shape=
    "rect">http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/</a></dd>

    <dt><a name="ref-XPointer-xmlns" id="ref-XPointer-xmlns" shape=
    "rect">XPointer-xmlns</a></dt>

    <dd><a href=
    "http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/" shape=
    "rect">XPointer xmlns() Scheme</a>. W3C Working Recommendation.
    S. DeRose, R. Daniel, E. Maler, J. Marsh. March 2003.</dd>

    <dd><a href=
    "http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/" shape=
    "rect">http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/</a></dd>

    <dd><a href="http://www.w3.org/TR/2001/REC-xsl-20011015/"
    shape="rect">http://www.w3.org/TR/2001/REC-xsl-20011015/</a></dd>

    <dt><a id="ref-XSLT" name="ref-XSLT" shape="rect">XSLT</a></dt>

    <dd><a href="http://www.w3.org/TR/1999/REC-xslt-19991116.html"
    shape="rect">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"
    shape=
    "rect">http://www.w3.org/TR/1999/REC-xslt-19991116.html</a></dd>
  </dl>

  <h2>12. <a id="sec-Authors" name="sec-Authors" shape=
  "rect">Authors'</a> Address</h2>

  <p>Donald E. Eastlake 3rd<br clear="none" />
  Motorola Laboratories<br clear="none" />
  111 Locke Drive<br clear="none" />
  Marlborough, MA 01752 USA<br clear="none" />
  Phone: +1-508-786-7554<br clear="none" />
  Email: <a href="mailto:d3e3e3@gmail.com" shape=
  "rect">d3e3e3@gmail.com</a></p>

  <p>Joseph M. Reagle Jr.<br clear="none" />
  Department of Media, Culture, and Communication<br clear=
  "none" />
  New York University<br clear="none" />
  Email: <a href="mailto:reagle@mit.edu" shape=
  "rect">reagle@mit.edu</a></p>

  <p>David Solo<br clear="none" />
  Citigroup<br clear="none" />
  909 Third Ave, 16th Floor<br clear="none" />
  NY, NY 10043 USA<br clear="none" />
  Phone +1-212-559-2900<br clear="none" />
  Email: <a href="mailto:dsolo@alum.mit.edu" shape=
  "rect">dsolo@alum.mit.edu</a></p>
</body>
</html>