discontinued / server · Files

index.html 276 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 
<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html lang="en" dir="ltr">
<head>
    <title>XML Signature Syntax and Processing Version 1.1</title>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
    
<!--      <script src='../../../dap-dev/ReSpec.js/js/respec.js' -->
<!--              class='remove'></script> -->
     
    
  <style type="text/css">
/*****************************************************************
 * ReSpec CSS
 * Robin Berjon (robin at berjon dot com)
 * v0.05 - 2009-07-31
 *****************************************************************/


/* --- INLINES --- */
em.rfc2119 { 
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  medium solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  medium dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

code {
    color:  #ff4500;
}


/* --- WEB IDL --- */
pre.idl {
    border-top: 1px solid #90b8de;
    border-bottom: 1px solid #90b8de;
    padding:    1em;
    line-height:    120%;
}

pre.idl::before {
    content:    "WebIDL";
    display:    block;
    width:      150px;
    background: #90b8de;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

.idlType {
    color:  #ff4500;
    font-weight:    bold;
    text-decoration:    none;
}

/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID {
    font-weight:    bold;
    color:  #005a9c;
}

.idlSuperclass {
    font-style: italic;
    color:  #005a9c;
}

/*.idlAttribute*/
.idlAttrType, .idlFieldType {
    color:  #005a9c;
}
.idlAttrName, .idlFieldName {
    color:  #ff4500;
}
.idlAttrName a, .idlFieldName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlMethod*/
.idlMethType {
    color:  #005a9c;
}
.idlMethName {
    color:  #ff4500;
}
.idlMethName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlParam*/
.idlParamType {
    color:  #005a9c;
}
.idlParamName {
    font-style: italic;
}

.extAttr {
    color:  #666;
}

/*.idlConst*/
.idlConstType {
    color:  #005a9c;
}
.idlConstName {
    color:  #ff4500;
}
.idlConstName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlException*/
.idlExceptionID {
    font-weight:    bold;
    color:  #c00;
}

.idlTypedefID, .idlTypedefType {
    color:  #005a9c;
}

.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
    color:  #c00;
    font-weight:    normal;
}

.excName a {
    font-family:    monospace;
}

.idlRaises a.idlType, .excName a.idlType {
    border-bottom:  1px dotted #c00;
}

.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
    width:  45px;
    text-align: center;
}
.excGetSetTrue, .prmNullTrue, .prmOptTrue { color:  #0c0; }
.excGetSetFalse, .prmNullFalse, .prmOptFalse { color:  #c00; }

.idlImplements a {
    font-weight:    bold;
}

dl.attributes, dl.methods, dl.constants, dl.fields {
    margin-left:    2em;
}

.attributes dt, .methods dt, .constants dt, .fields dt {
    font-weight:    normal;
}

.attributes dt code, .methods dt code, .constants dt code, .fields dt code {
    font-weight:    bold;
    color:  #000;
    font-family:    monospace;
}

.attributes dt code, .fields dt code {
    background:  #ffffd2;
}

.attributes dt .idlAttrType code, .fields dt .idlFieldType code {
    color:  #005a9c;
    background:  transparent;
    font-family:    inherit;
    font-weight:    normal;
    font-style: italic;
}

.methods dt code {
    background:  #d9e6f8;
}

.constants dt code {
    background:  #ddffd2;
}

.attributes dd, .methods dd, .constants dd, .fields dd {
    margin-bottom:  1em;
}

table.parameters, table.exceptions {
    border-spacing: 0;
    border-collapse:    collapse;
    margin: 0.5em 0;
    width:  100%;
}
table.parameters { border-bottom:  1px solid #90b8de; }
table.exceptions { border-bottom:  1px solid #deb890; }

.parameters th, .exceptions th {
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
    font-family:    initial;
    font-weight:    normal;
    text-shadow:    #666 1px 1px 0;
}
.parameters th { background: #90b8de; }
.exceptions th { background: #deb890; }

.parameters td, .exceptions td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
    vertical-align: top;
}

.parameters tr:first-child td, .exceptions tr:first-child td {
    border-top: none;
}

.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
    width:  100px;
}

.parameters td.prmType {
    width:  120px;
}

table.exceptions table {
    border-spacing: 0;
    border-collapse:    collapse;
    width:  100%;
}

/* --- TOC --- */
.toc a {
    text-decoration:    none;
}

a .secno {
    color:  #000;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}

/* --- EXAMPLES --- */
pre.example {
    border-top: 1px solid #ff4500;
    border-bottom: 1px solid #ff4500;
    padding:    1em;
    margin-top: 1em;
}

pre.example::before {
    content:    "Example";
    display:    block;
    width:      150px;
    background: #ff4500;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

/* --- EDITORIAL NOTES --- */
.issue {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #ffc;
}

.issue::before {
    content:    "Issue";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.note {
    margin: 1em 0em 0em;
    padding:    1em;
    border: 2px solid #cff6d9;
    background: #e2fff0;
}

.note::before {
    content:    "Note";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #cff6d9;
    background: #fff;
    padding:    3px 1em;
}

/* --- Best Practices --- */
div.practice {
    border: solid #bebebe 1px;
    margin: 2em 1em 1em 2em;
}

span.practicelab {
    margin: 1.5em 0.5em 1em 1em;
    font-weight: bold;
    font-style: italic;
}

span.practicelab   { background: #dfffff; }

span.practicelab {
    position: relative;
    padding: 0 0.5em;
    top: -1.5em;
}

p.practicedesc {
    margin: 1.5em 0.5em 1em 1em;
}

@media screen {
    p.practicedesc {
        position: relative;
        top: -2em;
        padding: 0;
        margin: 1.5em 0.5em -1em 1em;
}

/* --- SYNTAX HIGHLIGHTING --- */
pre.sh_sourceCode {
  background-color: white;
  color: black;
  font-style: normal;
  font-weight: normal;
}

pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; }           /* language keywords */
pre.sh_sourceCode .sh_type { color: #666; }                            /* basic types */
pre.sh_sourceCode .sh_usertype { color: teal; }                             /* user defined types */
pre.sh_sourceCode .sh_string { color: red; font-family: monospace; }        /* strings and chars */
pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; }     /* regular expressions */
pre.sh_sourceCode .sh_specialchar { color: 	#ffc0cb; font-family: monospace; }  /* e.g., \n, \t, \\ */
pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; }         /* comments */
pre.sh_sourceCode .sh_number { color: purple; }                             /* literal numbers */
pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; }       /* e.g., #include, import */
pre.sh_sourceCode .sh_symbol { color: blue; }                            /* e.g., *, + */
pre.sh_sourceCode .sh_function { color: black; font-weight: bold; }         /* function calls and declarations */
pre.sh_sourceCode .sh_cbracket { color: red; }                              /* block brackets (e.g., {, }) */
pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; }   /* TODO and FIXME */

/* Predefined variables and functions (for instance glsl) */
pre.sh_sourceCode .sh_predef_var { color: #00008B; }
pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }

/* for OOP */
pre.sh_sourceCode .sh_classname { color: teal; }

/* line numbers (not yet implemented) */
pre.sh_sourceCode .sh_linenum { display: none; }

/* Internet related */
pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }

/* for ChangeLog and Log files */
pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }

/* for Prolog, Perl... */
pre.sh_sourceCode .sh_variable { color: #006400; }

/* for LaTeX */
pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
pre.sh_sourceCode .sh_argument { color: #006400; }
pre.sh_sourceCode .sh_optionalargument { color: purple; }
pre.sh_sourceCode .sh_math { color: orange; }
pre.sh_sourceCode .sh_bibtex { color: blue; }

/* for diffs */
pre.sh_sourceCode .sh_oldfile { color: orange; }
pre.sh_sourceCode .sh_newfile { color: #006400; }
pre.sh_sourceCode .sh_difflines { color: blue; }

/* for css */
pre.sh_sourceCode .sh_selector { color: purple; }
pre.sh_sourceCode .sh_property { color: blue; }
pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }

/* other */
pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }

</style><link href="http://www.w3.org/StyleSheets/TR/W3C-CR" rel="stylesheet" type="text/css" charset="utf-8"></head><body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">XML Signature Syntax and Processing Version 1.1</h1><h2 id="w3c-candidate-recommendation-03-march-2011">W3C Candidate Recommendation 03 March 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/">http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/xmldsig-core1/">http://www.w3.org/TR/xmldsig-core1/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/">http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-xmldsig-core1-20101130/">http://www.w3.org/TR/2010/WD-xmldsig-core1-20101130/</a></dd><dt>Latest recommendation:</dt><dd><a href="http://www.w3.org/TR/xmldsig-core/">http://www.w3.org/TR/xmldsig-core/</a></dd><dt>Editors:</dt><dd><span>Donald Eastlake</span>, <a href="mailto:d3e3e3@gmail.com">d3e3e3@gmail.com</a> </dd>
<dd><span>Joseph Reagle</span>, <a href="mailto:reagle@mit.edu">reagle@mit.edu</a> </dd>
<dd><span>David Solo</span>, <a href="mailto:dsolo@alum.mit.edu">dsolo@alum.mit.edu</a> </dd>
<dd><span>Frederick Hirsch</span>, <a href="mailto:frederick.hirsch@nokia.com">frederick.hirsch@nokia.com</a>  ( 2nd edition, 1.1 )</dd>
<dd><span>Magnus Nyström</span>, <a href="mailto:mnystrom@microsoft.com">mnystrom@microsoft.com</a>  ( 1.1 )</dd>
<dd><span>Thomas Roessler</span>, <a href="mailto:tlr@w3.org">tlr@w3.org</a>  ( 2nd edition, 1.1 )</dd>
<dd><span>Kelvin Yiu</span>, <a href="mailto:kelviny@microsoft.com">kelviny@microsoft.com</a>  ( 1.1 )</dd>
<dt>Authors:</dt><dd><span>Mark Bartel</span>, <a href="mailto:mbartel@adobe.com">mbartel@adobe.com</a> </dd>
<dd><span>John Boyer</span>, <a href="mailto:boyerj@ca.ibm.com">boyerj@ca.ibm.com</a> </dd>
<dd><span>Barb Fox</span>, <a href="mailto:bfox@Exchange.Microsoft.com">bfox@Exchange.Microsoft.com</a> </dd>
<dd><span>Brian LaMacchia</span>, <a href="mailto:bal@microsoft.com">bal@microsoft.com</a> </dd>
<dd><span>Ed Simon</span>, <a href="mailto:edsimon@xmlsec.com">edsimon@xmlsec.com</a> </dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://trustee.ietf.org/">The IETF Trust</a> &amp; <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
    <div id="abstract" class="introductory section"><h2>Abstract</h2>
  <p>This document specifies XML digital signature processing rules 
  and syntax. XML Signatures provide <a href="#def-Integrity" class="link-def">integrity</a>, <a href="#def-AuthenticationMessage" class="link-def">message authentication</a>, and/or <a href="#def-AuthenticationSigner" class="link-def">signer 
  authentication</a> services for data of any type, whether located within the 
  XML that includes the signature or elsewhere.</p>
    </div><div id="sotd" class="introductory section"><h2>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/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
	
  <p>At the time of this publication, the most recent W3C
  Recommendation of XML Signature 1 is the 
  <a href="http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/">10
  June 2008 XML Signature (Second 
  Edition) Recommendation</a>.   Please
  review <a href="Overview_diff.html">differences between the previous
  Last Call Working Draft
  and this Candidate Recommendation</a> ,
  and <a href="Overview-diff-rec.html">differences between the
  previous XML Signature Recommendation and this Candidate Recommendation</a>; a
  detailed  <a href="explain.html">explanation of changes</a> since
  the last Recommendation is also
  available.</p>
  <p> Changes since the previous Last Call include updated
  References, editorial updates and corrections related to 
  references to sections within referenced documents, addition of a
  security consideration, editorial updates to refer to 1.1 
  elements showing the dsig11 prefixes, editorial revisions for
  uniformity when indicating whether comments are omitted in
  canonicalization, and addition of an editor.</p>  
  
  <p>Conformance-affecting changes against this previous
  recommendation mainly affect the set of 
  mandatory to implement cryptographic algorithms, including Elliptic
  Curve DSA (and mark-up for 
  corresponding key material), and additional hash algorithms.  This Candidate Recommendation includes
  the <code>ECDSAwithSHA256</code> signature algorithm, which is ECDSA
  over the P-256 prime curve specified in Section D.2.3 of FIPS 186-3
  [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>] (and using the SHA-256 hash algorithm), as a
  mandatory to implement algorithm.</p>

<p><strong>Patent disclosures on this specification.</strong> W3C
has received several patent disclosures regarding this
specification and its use of Elliptic Curve cryptography. In accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exception">section
7 of the W3C Patent Policy</a>, the staff has launched a <a href="http://www.w3.org/2011/xmlsec-pag/Overview.html">Patent
Advisory Group (PAG)</a> to address them. Please refer to the 
<a href="http://www.w3.org/2011/02/xmlsec-pag-charter.html">PAG charter</a> for more details.</p>

  <p>The Working Group is, in parallel to this work, developing requirements and designs for a more
  radically different version 2 of XML Signature. For more
  information see the working group <a href="http://www.w3.org/2008/xmlsec/wiki/PublicationStatus#20">publications status page</a>.</p>
<p>This document was published by the <a href="http://www.w3.org/2008/xmlsec/">XML Security Working Group</a> as a Candidate Recommendation. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-xmlsec@w3.org">public-xmlsec@w3.org</a> (<a href="mailto:public-xmlsec-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-xmlsec/">archives</a>). W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 01 June 2011. All feedback is welcome.</p><p>Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/42458/status" rel="disclosure">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">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#sec-Introduction" class="tocxref"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#sec-Editorial" class="tocxref"><span class="secno">1.1 </span>Editorial and Conformance Conventions</a></li><li class="tocline"><a href="#sec-Design" class="tocxref"><span class="secno">1.2 </span>Design Philosophy</a></li><li class="tocline"><a href="#sec-Versions" class="tocxref"><span class="secno">1.3 </span>Versions Namespaces and Identifiers</a></li><li class="tocline"><a href="#sec-Acknowledgements" class="tocxref"><span class="secno">1.4 </span> Acknowledgements</a></li></ul></li><li class="tocline"><a href="#sec-Overview" class="tocxref"><span class="secno">2. </span> Signature Overview and Examples</a><ul class="toc"><li class="tocline"><a href="#sec-o-Simple" class="tocxref"><span class="secno">2.1 </span> Simple Example (<code>Signature</code>,
  <code>SignedInfo</code>, <code>Methods</code>, and
  <code>Reference</code>s)</a><ul class="toc"><li class="tocline"><a href="#sec-o-Reference" class="tocxref"><span class="secno">2.1.1 </span>More on <code>Reference</code></a></li></ul></li><li class="tocline"><a href="#sec-o-SignatureProperty" class="tocxref"><span class="secno">2.2 </span>Extended Example (<code>Object</code> and <code>SignatureProperty</code>)</a></li><li class="tocline"><a href="#sec-o-Manifest" class="tocxref"><span class="secno">2.3 </span>Extended Example (<code>Object</code> and <code>Manifest</code>)</a></li></ul></li><li class="tocline"><a href="#sec-Processing" class="tocxref"><span class="secno">3. </span>Processing Rules</a><ul class="toc"><li class="tocline"><a href="#sec-CoreGeneration" class="tocxref"><span class="secno">3.1 </span>Signature Generation</a><ul class="toc"><li class="tocline"><a href="#sec-ReferenceGeneration" class="tocxref"><span class="secno">3.1.1 </span>Reference Generation</a></li><li class="tocline"><a href="#sec-SignatureGeneration" class="tocxref"><span class="secno">3.1.2 </span>Signature Generation</a></li></ul></li><li class="tocline"><a href="#sec-CoreValidation" class="tocxref"><span class="secno">3.2 </span>Core Validation</a><ul class="toc"><li class="tocline"><a href="#sec-ReferenceValidation" class="tocxref"><span class="secno">3.2.1 </span>Reference Validation</a></li><li class="tocline"><a href="#sec-SignatureValidation" class="tocxref"><span class="secno">3.2.2 </span>Signature Validation</a></li></ul></li></ul></li><li class="tocline"><a href="#sec-CoreSyntax" class="tocxref"><span class="secno">4. </span>Core Signature Syntax</a><ul class="toc"><li class="tocline"><a href="#sec-CryptoBinary" class="tocxref"><span class="secno">4.1 </span>The <code>ds:CryptoBinary</code> Simple Type</a></li><li class="tocline"><a href="#sec-Signature" class="tocxref"><span class="secno">4.2 </span>The <code>Signature</code> element</a></li><li class="tocline"><a href="#sec-SignatureValue" class="tocxref"><span class="secno">4.3 </span>The <code>SignatureValue</code> Element</a></li><li class="tocline"><a href="#sec-SignedInfo" class="tocxref"><span class="secno">4.4 </span>The <code>SignedInfo</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-CanonicalizationMethod" class="tocxref"><span class="secno">4.4.1 </span>The <code>CanonicalizationMethod</code> Element</a></li><li class="tocline"><a href="#sec-SignatureMethod" class="tocxref"><span class="secno">4.4.2 </span>The <code>SignatureMethod</code> Element</a></li><li class="tocline"><a href="#sec-Reference" class="tocxref"><span class="secno">4.4.3 </span>The <code>Reference</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-URI" class="tocxref"><span class="secno">4.4.3.1 </span>The <code>URI</code> Attribute</a></li><li class="tocline"><a href="#sec-ReferenceProcessingModel" class="tocxref"><span class="secno">4.4.3.2 </span>The Reference Processing Model</a></li><li class="tocline"><a href="#sec-Same-Document" class="tocxref"><span class="secno">4.4.3.3 </span>Same-Document URI-References</a></li><li class="tocline"><a href="#sec-Transforms" class="tocxref"><span class="secno">4.4.3.4 </span>The <code>Transforms</code> Element</a></li><li class="tocline"><a href="#sec-DigestMethod" class="tocxref"><span class="secno">4.4.3.5 </span>The <code>DigestMethod</code> Element</a></li><li class="tocline"><a href="#sec-DigestValue" class="tocxref"><span class="secno">4.4.3.6 </span>The <code>DigestValue</code> Element</a></li></ul></li></ul></li><li class="tocline"><a href="#sec-KeyInfo" class="tocxref"><span class="secno">4.5 </span>The <code>KeyInfo</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-KeyName" class="tocxref"><span class="secno">4.5.1 </span>The <code>KeyName</code> Element</a></li><li class="tocline"><a href="#sec-KeyValue" class="tocxref"><span class="secno">4.5.2 </span>The <code>KeyValue</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-DSAKeyValue" class="tocxref"><span class="secno">4.5.2.1 </span>The <code>DSAKeyValue</code> Element</a></li><li class="tocline"><a href="#sec-RSAKeyValue" class="tocxref"><span class="secno">4.5.2.2 </span>The <code>RSAKeyValue</code> Element</a></li><li class="tocline"><a href="#sec-ECKeyValue" class="tocxref"><span class="secno">4.5.2.3 </span>The <code>ECKeyValue</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-ECParameters" class="tocxref"><span class="secno">4.5.2.3.1 </span>Explicit Curve Parameters </a></li><li class="tocline"><a href="#sec-RFC4050Compat" class="tocxref"><span class="secno">4.5.2.3.2 </span>Compatibility with RFC 4050</a></li></ul></li></ul></li><li class="tocline"><a href="#sec-RetrievalMethod" class="tocxref"><span class="secno">4.5.3 </span>The <code>RetrievalMethod</code> Element</a></li><li class="tocline"><a href="#sec-X509Data" class="tocxref"><span class="secno">4.5.4 </span>The <code>X509Data</code> Element</a><ul class="toc"><li class="tocline"><a href="#dname-encrules" class="tocxref"><span class="secno">4.5.4.1 </span>Distinguished Name Encoding Rules</a></li></ul></li><li class="tocline"><a href="#sec-PGPData" class="tocxref"><span class="secno">4.5.5 </span>The <code>PGPData</code> Element</a></li><li class="tocline"><a href="#sec-SPKIData" class="tocxref"><span class="secno">4.5.6 </span>The <code>SPKIData</code> Element</a></li><li class="tocline"><a href="#sec-MgmtData" class="tocxref"><span class="secno">4.5.7 </span>The <code>MgmtData</code> Element</a></li><li class="tocline"><a href="#sec-keyconvenance" class="tocxref"><span class="secno">4.5.8 </span>XML Encryption <code>EncryptedKey</code>
and <code>DerivedKey</code> Elements</a></li><li class="tocline"><a href="#sec-DEREncodedKeyValue" class="tocxref"><span class="secno">4.5.9 </span>The <code>DEREncodedKeyValue</code> Element</a></li><li class="tocline"><a href="#sec-KeyInfoReference" class="tocxref"><span class="secno">4.5.10 </span>The <code>KeyInfoReference</code> Element</a></li></ul></li><li class="tocline"><a href="#sec-Object" class="tocxref"><span class="secno">4.6 </span>The <code>Object</code> Element</a></li></ul></li><li class="tocline"><a href="#sec-AdditionalSyntax" class="tocxref"><span class="secno">5. </span>Additional Signature Syntax</a><ul class="toc"><li class="tocline"><a href="#sec-Manifest" class="tocxref"><span class="secno">5.1 </span>The <code>Manifest</code> Element</a></li><li class="tocline"><a href="#sec-SignatureProperties" class="tocxref"><span class="secno">5.2 </span>The <code>SignatureProperties</code> Element</a></li><li class="tocline"><a href="#sec-PI" class="tocxref"><span class="secno">5.3 </span>Processing Instructions in Signature Elements</a></li><li class="tocline"><a href="#sec-comments" class="tocxref"><span class="secno">5.4 </span>Comments in Signature Elements</a></li></ul></li><li class="tocline"><a href="#sec-Algorithms" class="tocxref"><span class="secno">6. </span>Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-AlgID" class="tocxref"><span class="secno">6.1 </span>Algorithm Identifiers and Implementation Requirements</a></li><li class="tocline"><a href="#sec-MessageDigests" class="tocxref"><span class="secno">6.2 </span>Message Digests</a><ul class="toc"><li class="tocline"><a href="#sec-SHA-1" class="tocxref"><span class="secno">6.2.1 </span>SHA-1</a></li><li class="tocline"><a href="#sec-SHA-256" class="tocxref"><span class="secno">6.2.2 </span>SHA-256</a></li><li class="tocline"><a href="#sec-SHA-384" class="tocxref"><span class="secno">6.2.3 </span>SHA-384</a></li><li class="tocline"><a href="#sec-SHA-512" class="tocxref"><span class="secno">6.2.4 </span>SHA-512</a></li></ul></li><li class="tocline"><a href="#sec-MACs" class="tocxref"><span class="secno">6.3 </span>Message Authentication 
  Codes</a><ul class="toc"><li class="tocline"><a href="#sec-HMAC" class="tocxref"><span class="secno">6.3.1 </span>HMAC</a></li></ul></li><li class="tocline"><a href="#sec-SignatureAlg" class="tocxref"><span class="secno">6.4 </span>Signature Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-DSA" class="tocxref"><span class="secno">6.4.1 </span>DSA</a></li><li class="tocline"><a href="#sec-PKCS1" class="tocxref"><span class="secno">6.4.2 </span>RSA (PKCS#1 v1.5)</a></li><li class="tocline"><a href="#sec-ECDSA" class="tocxref"><span class="secno">6.4.3 </span>ECDSA</a></li></ul></li><li class="tocline"><a href="#sec-c14nAlg" class="tocxref"><span class="secno">6.5 </span>Canonicalization Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-Canonical" class="tocxref"><span class="secno">6.5.1 </span>Canonical XML 1.0</a></li><li class="tocline"><a href="#sec-Canonical11" class="tocxref"><span class="secno">6.5.2 </span>Canonical XML 1.1</a></li><li class="tocline"><a href="#sec-ExcC14N10" class="tocxref"><span class="secno">6.5.3 </span>Exclusive XML Canonicalization 1.0</a></li></ul></li><li class="tocline"><a href="#sec-TransformAlg" class="tocxref"><span class="secno">6.6 </span><code>Transform</code> Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-Canonicalization" class="tocxref"><span class="secno">6.6.1 </span>Canonicalization</a></li><li class="tocline"><a href="#sec-Base-64" class="tocxref"><span class="secno">6.6.2 </span>Base64</a></li><li class="tocline"><a href="#sec-XPath" class="tocxref"><span class="secno">6.6.3 </span>XPath Filtering</a></li><li class="tocline"><a href="#sec-EnvelopedSignature" class="tocxref"><span class="secno">6.6.4 </span>Enveloped Signature Transform</a></li><li class="tocline"><a href="#sec-XSLT" class="tocxref"><span class="secno">6.6.5 </span>XSLT Transform</a></li></ul></li></ul></li><li class="tocline"><a href="#sec-XML-Canonicalization" class="tocxref"><span class="secno">7. </span>XML Canonicalization and Syntax Constraint Considerations</a><ul class="toc"><li class="tocline"><a href="#sec-XML-1" class="tocxref"><span class="secno">7.1 </span>XML 1.0 Syntax Constraints, and Canonicalization</a></li><li class="tocline"><a href="#sec-DOM-SAX" class="tocxref"><span class="secno">7.2 </span>DOM/SAX Processing and Canonicalization</a></li><li class="tocline"><a href="#sec-NamespaceContext" class="tocxref"><span class="secno">7.3 </span>Namespace Context and Portable Signatures</a></li></ul></li><li class="tocline"><a href="#sec-Security" class="tocxref"><span class="secno">8. </span>Security Considerations</a><ul class="toc"><li class="tocline"><a href="#sec-Security-Transforms" class="tocxref"><span class="secno">8.1 </span>Transforms</a><ul class="toc"><li class="tocline"><a href="#sec-Secure" class="tocxref"><span class="secno">8.1.1 </span>Only What is Signed is Secure</a></li><li class="tocline"><a href="#sec-Seen" class="tocxref"><span class="secno">8.1.2 </span>Only What is "Seen" Should be Signed</a></li><li class="tocline"><a href="#sec-See" class="tocxref"><span class="secno">8.1.3 </span>"See" What is Signed</a></li></ul></li><li class="tocline"><a href="#sec-Check" class="tocxref"><span class="secno">8.2 </span>Check the Security Model</a></li><li class="tocline"><a href="#sec-KeyLength" class="tocxref"><span class="secno">8.3 </span>Algorithms, Key Lengths, Certificates, Etc.</a></li><li class="tocline"><a href="#sec-Errors" class="tocxref"><span class="secno">8.4 </span>Error Messages</a></li></ul></li><li class="tocline"><a href="#sec-Schema" class="tocxref"><span class="secno">9. </span>Schema</a><ul class="toc"><li class="tocline"><a href="#sec-xsdSchema" class="tocxref"><span class="secno">9.1 </span>XSD Schema</a></li><li class="tocline"><a href="#sec-rngSchema" class="tocxref"><span class="secno">9.2 </span>RNG Schema</a></li></ul></li><li class="tocline"><a href="#sec-Definitions" class="tocxref"><span class="secno">10. </span>Definitions</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">A. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">A.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">A.2 </span>Informative references</a></li></ul></li></ul></div>

    
    <div id="sec-Introduction" class="section">
      <!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>
      <p>
  </p><p>This document specifies XML syntax and processing rules for creating and 
  representing digital signatures. XML Signatures can be applied to any <a href="#def-DataObject" class="link-def">digital content (data object)</a>, including XML. An XML 
  Signature may be applied to the content of one or more resources. <a href="#def-SignatureEnveloped" class="link-def">Enveloped</a> or <a href="#def-SignatureEnveloping" class="link-def">enveloping</a> signatures are over data within 
  the same XML document as the signature; <a href="#def-SignatureDetached" class="link-def">detached</a> signatures are over data&nbsp;external to the signature 
  element. More specifically, this specification defines an XML signature 
  element type and an <a href="#def-SignatureApplication" class="link-def">XML signature 
  application</a>; conformance requirements for each are specified by way of 
  schema definitions and prose respectively. This specification also includes 
  other useful types that identify methods for referencing collections of 
  resources, algorithms, and keying and management information.</p>

  <p>The XML Signature is a method of associating a key with referenced data 
  (octets); it does not normatively specify how keys are associated with persons 
  or institutions, nor the meaning of the data being referenced and signed. 
  Consequently, while this specification is an important component of secure XML 
  applications, it itself is not sufficient to address all application 
  security/trust concerns, particularly with respect to using signed XML (or 
  other data formats) as a basis of human-to-human communication and agreement. 
  Such an application must specify additional key, algorithm, processing and 
  rendering requirements. For further information, please see
  see <a href="#sec-Security" class="sectionRef">section 8. Security Considerations</a>.
</p>

    <div id="sec-Editorial" class="section">
      <h3><span class="secno">1.1 </span>Editorial 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" class="sectionRef">section 8.2 Check the Security Model</a>.)</p>

  <p>This specification provides a normative XML Schema
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>], [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>]. The full normative grammar is
  defined by the XSD schema and the normative text in this
  specification. The standalone XSD schema file is authoritative in
  case there is any disagreement between it and the XSD schema
  portions in this specification. </p>

  <p>The key words "<em class="rfc2119" title="must">must</em>", "<em class="rfc2119" title="must not">must not</em>", "<em class="rfc2119" title="required">required</em>", "<em class="rfc2119" title="shall">shall</em>", "<em class="rfc2119" title="shall not">shall not</em>", 
  "<em class="rfc2119" title="should">should</em>", "<em class="rfc2119" title="should not">should not</em>", "<em class="rfc2119" title="recommended">recommended</em>", "<em class="rfc2119" title="may">may</em>", and "<em class="rfc2119" title="optional">optional</em>" in this 
  specification are to be interpreted as described in [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">RFC2119</a></cite>].</p>

  <blockquote>
    <p>"They <em class="rfc2119" title="must">must</em> 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>] is described as "<em class="rfc2119" title="required">required</em>."</p>
    </div>

    <div id="sec-Design" class="section">
<h3><span class="secno">1.2 </span>Design Philosophy</h3>
  <p>The design philosophy and requirements of this specification are addressed 
  in the original XML-Signature Requirements document
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-REQUIREMENTS">XMLDSIG-REQUIREMENTS</a></cite>] and the XML Security 1.1 Requirements
  document [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSEC11-REQS">XMLSEC11-REQS</a></cite>].</p> 

    </div>
    <div id="sec-Versions" class="section">
<h3><span class="secno">1.3 </span>Versions Namespaces and Identifiers</h3>

  <p>This specification makes use of XML namespaces, and uses Uniform
  Resource Identifiers [<cite><a class="bibref" rel="biblioentry" href="#bib-URI">URI</a></cite>] to identify resources, algorithms, and
  semantics.</p> 
  
  <p>Implementations of this specification <em class="rfc2119" title="must">must</em> use the following XML
  namespace URIs:</p> 
  
  <table class="namespaces">
    <thead>
      <tr><th>URI</th><th>namespace prefix</th><th>XML internal entity</th></tr>
    </thead>
    <tbody>
      <tr><td><code>http://www.w3.org/2000/09/xmldsig#</code></td><td><i>default namespace</i>,
      <code>ds:</code>, <code>dsig:</code></td><td><code>&lt;!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#"&gt;</code></td></tr>
      <tr><td><code>http://www.w3.org/2009/xmldsig11#</code></td><td><code>dsig11:</code></td><td><code>&lt;!ENTITY dsig11 "http://www.w3.org/2009/xmldsig11#"&gt;</code></td></tr>
    </tbody>
  </table>
  
  <p>While implementations <em class="rfc2119" title="must">must</em> support XML and XML namespaces, and while use of the above namespace
  URIs is <em class="rfc2119" title="required">required</em>, the namespace prefixes and entity declarations
  given are merely editorial 
  conventions used in this document.  Their use by implementations is <em class="rfc2119" title="optional">optional</em>.</p>
  
  <p>These namespace URIs are also used as the prefix for algorithm identifiers that are under
  control of this specification.  For resources not under the control of this specification, we use
  the designated Uniform Resource Names [<cite><a class="bibref" rel="biblioentry" href="#bib-URN">URN</a></cite>], [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3406">RFC3406</a></cite>]
  or Uniform 
  Resource Identifiers [<cite><a class="bibref" rel="biblioentry" href="#bib-URI">URI</a></cite>] defined by the relevant normative
  external specification.</p>
  
    <p>For instance:</p>

  <dl>
    <dt style="font-weight: normal;"><code>SignatureProperties</code> is identified and defined by the <code>disg:</code>
    namespace</dt>
    <dd><code>http://www.w3.org/2000/09/xmldsig#SignatureProperties</code></dd>
    
    <dt style="font-weight: normal;"><code>ECKeyValue</code> is identified and defined by the
    <code>dsig11:</code> namespace</dt>
    <dd><code>http://www.w3.org/2009/xmldsig11#ECKeyValue</code></dd>
    
    <dt style="font-weight: normal;">XSLT is identified and defined by an external URI</dt>
    <dd><code>http://www.w3.org/TR/1999/REC-xslt-19991116</code></dd>

    <dt style="font-weight: normal;">SHA1 is identified via this
    specification's namespace and defined via a normative reference [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-180-3">FIPS-180-3</a></cite>]</dt>
    <dd>http://www.w3.org/2001/04/xmlenc#sha256</dd>
    <dd>FIPS PUB 180-3. <em>Secure Hash Standard.</em> U.S. Department of 
        Commerce/National Institute of Standards and Technology.</dd>
  </dl>

  
  <p>The <code>http://www.w3.org/2000/09/xmldsig#</code> (<code>dsig:</code>) namespace was
  introduced in the first edition of this specification.  This version does not coin any new
  elements or algorithm identifiers in that namespace; instead, the
<code>http://www.w3.org/2009/xmldsig11#</code> (<code>dsig11:</code>)
  namespace 
  is used.</p>
  
  <p>No provision is made for an explicit version number in this syntax.  If a future version of
  this specification requires explicit versioning of the document format, a different namespace will
  be used.</p>
      </div>

<div id="sec-Acknowledgements" class="section"> 
<h3><span class="secno">1.4 </span> Acknowledgements</h3>

  <p>The contributions of the members of the XML Signature Working
  Group to the first edition specification are 
  gratefully acknowledged: Mark Bartel, Adobe, was Accelio (Author); John Boyer, IBM (Author);
  Mariano P. Consens, University of Waterloo; John Cowan, Reuters Health; Donald Eastlake 3rd,
  Motorola&nbsp; (Chair, Author/Editor); Barb Fox, Microsoft (Author); Christian Geuer-Pollmann,
  University Siegen; Tom Gindin, IBM; Phillip Hallam-Baker, VeriSign Inc; Richard Himes, US Courts;
  Merlin Hughes, Baltimore; Gregor Karlinger, IAIK TU Graz; Brian LaMacchia, Microsoft (Author);
  Peter Lipp, IAIK TU Graz; Joseph Reagle, NYU, was W3C (Chair, Author/Editor); Ed Simon, XMLsec
  (Author); David Solo, Citigroup (Author/Editor); Petteri Stenius, Capslock; Raghavan Srinivas,
  Sun; Kent Tamura, IBM; Winchel Todd Vincent III, GSU; Carl Wallace, Corsec Security, Inc.; Greg
  Whitehead, Signio Inc.</p>

  <p>As are the first edition Last Call comments from the following:</p>

  <ul>
    <li>Dan Connolly, W3C</li>

    <li>Paul Biron, Kaiser Permanente, on behalf of the <a href="http://www.w3.org/XML/Schema.html">XML Schema WG</a>.</li>

    <li>Martin J. Duerst, W3C; and Masahiro Sekiguchi, Fujitsu; on behalf of the <a href="http://www.w3.org/International/">Internationalization WG/IG</a>.</li>

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

  <p>The following members of the XML Security Specification Maintenance Working Group contributed
  to the second edition: Juan Carlos Cruellas, Universitat Politècnica de Catalunya; Pratik
  Datta, Oracle Corporation; Phillip Hallam-Baker, VeriSign, Inc.; Frederick Hirsch, Nokia, (Chair,
  Editor); Konrad Lanz, Applied Information processing and Kommunications (IAIK); Hal Lockhart, BEA
  Systems, Inc.; Robert Miller, MITRE Corporation; Sean Mullan, Sun Microsystems, Inc.; Bruce Rich,
  IBM Corporation; Thomas Roessler, W3C/ERCIM, (Staff contact, Editor); Ed Simon, W3C Invited
  Expert; Greg Whitehead, HP.</p>

  
  <p>Contributions for version 1.1 were received from the members of the XML Security Working Group:
  Scott Cantor, Juan Carlos Cruellas, Pratik Datta, Gerald Edgar, Ken Graf, Phillip Hallam-Baker,
  Brad Hill, Frederick Hirsch (Chair,
  Editor), Brian LaMacchia, Konrad Lanz, Hal Lockhart, Cynthia Martin, Rob
  Miller, Sean Mullan, Shivaram Mysore, Magnus Nyström, Bruce Rich, Thomas Roessler (Staff contact, Editor), Ed Simon, Chris
  Solc, John Wray, Kelvin Yiu (Editor).</p>
<p>The Working Group thanks Makoto Murata for assistance with the
  RELAX NG schemas.</p> 
      </div>
</div>
<div id="sec-Overview" class="section"> 
  <!--OddPage--><h2><span class="secno">2. </span> Signature Overview and Examples</h2>

  <p>This section provides an overview and examples of XML digital signature 
  syntax. The specific processing is given in 
 <a href="#sec-Processing" class="sectionRef">section 3. Processing Rules</a>.
 The formal 
syntax is found in <a href="#sec-CoreSyntax" class="sectionRef">section 4. Core Signature Syntax</a>
and <a href="#sec-AdditionalSyntax" class="sectionRef">section 5. Additional Signature Syntax</a>.</p>

  <p>In this section, an&nbsp;informal representation and examples are used to 
  describe the structure of the XML signature syntax. This representation and 
  examples may omit attributes, details and potential features that are fully 
  explained later.</p>

  <p>XML Signatures are applied to arbitrary <a href="#def-DataObject" class="link-def">digital content (data objects)</a> 
  via an indirection. Data objects are digested, the resulting value is placed 
  in an element (with other information) and that element is then digested and 
  cryptographically signed. XML digital signatures are represented by the <code>
  Signature</code> element which has the following structure (where "?" denotes 
  zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes 
  zero or more occurrences):</p>
  <pre class="xml-example">  &lt;Signature ID?&gt; 
     &lt;SignedInfo&gt;
       &lt;CanonicalizationMethod/&gt;
       &lt;SignatureMethod/&gt;
       (&lt;Reference URI? &gt;
         (&lt;Transforms&gt;)?
         &lt;DigestMethod&gt;
         &lt;DigestValue&gt;
       &lt;/Reference&gt;)+
     &lt;/SignedInfo&gt;
     &lt;SignatureValue&gt; 
    (&lt;KeyInfo&gt;)?
    (&lt;Object ID?&gt;)*
   &lt;/Signature&gt;
</pre>

  <p>Signatures are related to <a href="#def-DataObject" class="link-def">data objects</a> via URIs [<cite><a class="bibref" rel="biblioentry" href="#bib-URI">URI</a></cite>]. Within an XML document, signatures are 
  related to local data objects via fragment identifiers. Such local data can be 
  included within an <a href="#def-SignatureEnveloping" class="link-def">enveloping</a> signature or can enclose an <a href="#def-SignatureEnveloped" class="link-def">enveloped</a> signature. <a href="#def-SignatureDetached" class="link-def">Detached signatures</a> are over external 
  network resources or local data objects that reside within the same XML 
  document as sibling elements; in this case, the signature is neither 
  enveloping (signature is parent) nor enveloped (signature is child). Since a <code>
  Signature</code>
  element (and its <code>Id</code> attribute value/name) may co-exist or be 
  combined with other elements (and their IDs) within a single XML document, 
  care should be taken in choosing names such that there are no subsequent 
  collisions that violate the <a href="http://www.w3.org/TR/REC-xml/#id">
  ID uniqueness validity constraint</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>].</p>

<div id="sec-o-Simple" class="section"> 
  <h3><span class="secno">2.1 </span> Simple Example (<code>Signature</code>,
  <code>SignedInfo</code>, <code>Methods</code>, and
  <code>Reference</code>s)</h3>

  <p>The following example is a detached signature of the content of the HTML4 
  in XML specification.</p>
  <pre class="xml-example">   [s01] &lt;Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"&gt; 
   [s02]   &lt;SignedInfo&gt;  
   [s03]   &lt;CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"/&gt; 
   [s04]   &lt;SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/&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/2001/04/xmlenc#sha256"/&gt; 
   [s10]     &lt;DigestValue&gt;dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...&lt;/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">Core validation</a> of <code>
  SignedInfo</code> consists of two mandatory processes: <a href="#def-ValidationSignature" class="link-def">validation of the signature</a> over
  <code>SignedInfo</code> and <a href="#def-ValidationReference" class="link-def">validation of each
  <code>Reference</code></a> digest within
  <code>SignedInfo</code>. Note that  
  the algorithms used in calculating the
  <code>SignatureValue</code> are also included in the signed information while 
  the <code>SignatureValue</code> element is outside <code>SignedInfo</code>.</p>

  <p><code>[s03]</code> The <code>CanonicalizationMethod</code> is the algorithm 
  that is used to canonicalize the
  <code>SignedInfo</code> element before it is digested as part of the signature 
  operation. 
Note that this example is not in canonical form. (None of the examples in this
  specification are 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 <em class="rfc2119" title="must">must</em> be implemented, though their use is at the discretion of the 
  signature creator. We specify additional algorithms as <em class="rfc2119" title="recommended">recommended</em> or <em class="rfc2119" title="optional">optional</em> 
  for implementation; the design also permits arbitrary user specified 
  algorithms.</p>

  <p><code>[s05-11]</code> Each <code>Reference</code> element includes the 
  digest method and resulting digest value calculated over the identified data 
  object. It also may include transformations that produced the input to the 
  digest operation. A data object is signed by computing its digest value and a 
  signature over that value. The signature is later checked via
  <a href="#def-ValidationReference" class="link-def">reference</a> and <a href="#def-ValidationSignature" class="link-def">signature validation</a>.</p>

  <p><code>[s14-16]</code> <code>KeyInfo</code> indicates the key to be used to 
  validate the signature. Possible forms for identification include 
  certificates, key names, and key agreement algorithms and information -- we 
  define only a few.
  <code>KeyInfo</code> is optional for two reasons. First, the signer may not 
  wish to reveal key information to all document processing parties. Second, the 
  information may be known within the application's context and need not be 
  represented explicitly. Since <code>KeyInfo</code> is outside of <code>
  SignedInfo</code>, if the signer wishes to bind the keying information to the 
  signature, a <code>Reference</code> can easily identify and include the <code>
  KeyInfo</code> as part of the signature.
Use of <code>KeyInfo</code> is optional, however note that senders and receivers
must agree on how it will be used through a mechanism out of scope for
this specification. 
</p>

<div id="sec-o-Reference" class="section">
  <h4><span class="secno">2.1.1 </span>More on <code>Reference</code></h4>
  <pre class="xml-example">   [s05]   &lt;Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"&gt; 
   [s06]     &lt;Transforms&gt; 
   [s07]       &lt;Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/&gt; 
   [s08]     &lt;/Transforms&gt; 
   [s09]     &lt;DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/&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 the content of a resource to
  the signer's  
  key.</p>
    </div>  
</div>
<div id="sec-o-SignatureProperty" class="section">
  <h3><span class="secno">2.2 </span>Extended Example (<code>Object</code> and <code>SignatureProperty</code>)</h3>

  <p>This specification does not address mechanisms for making statements or 
  assertions. Instead, this document defines what it means for something to be 
  signed by an XML Signature (<a href="#def-Integrity" class="link-def">integrity</a>,
  <a href="#def-AuthenticationMessage" class="link-def">message authentication</a>, and/or <a href="#def-AuthenticationSigner" class="link-def">signer 
  authentication</a>). Applications that wish to represent other semantics must 
  rely upon other technologies, such as [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>], [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-PRIMER">RDF-PRIMER</a></cite>]. For
  instance, an application might use a 
  <code>foo:assuredby</code> attribute within its own markup to reference a <code>
  Signature</code> element. Consequently, it's the application that must 
  understand and know how to make trust decisions given the validity of the 
  signature and the meaning of
  <code>assuredby</code> syntax. We also define a
  <code>SignatureProperties</code> element type for the inclusion of assertions 
  about the signature itself (e.g., signature semantics, the time of signing or 
  the serial number of hardware used in cryptographic processes). Such 
  assertions may be signed by including a <code>Reference</code> for the
  <code>SignatureProperties</code> in <code>SignedInfo</code>. While the signing 
  application should be very careful about what it signs (it should understand 
  what is in the
  <code>SignatureProperty</code>) a receiving application has no obligation to 
  understand that semantic (though its parent trust engine may wish to). Any 
  content about the signature generation may be located within the <code>
  SignatureProperty</code> element. The mandatory <code>Target</code> attribute 
  references the
  <code>Signature</code> element to which the property applies.</p>

  <p>Consider the preceding example with an additional reference to a local <code>
  Object</code> that includes a
  <code>SignatureProperty</code> element. (Such a signature would not only be <a href="#def-SignatureDetached" class="link-def">detached</a> <code>[p02]</code> but <a href="#def-SignatureEnveloping" class="link-def">enveloping</a> <code>[p03]</code>.)</p>
  <pre class="xml-example">   [   ]  &lt;Signature Id="MySecondSignature" ...&gt;
   [p01]  &lt;SignedInfo&gt;  
   [   ]   ...  
   [p02]   &lt;Reference URI="http://www.w3.org/TR/xml-stylesheet/"&gt;   
   [   ]   ... 
   [p03]   &lt;Reference URI="#AMadeUpTimeStamp"  
   [p04]         Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"&gt;
   [p05]    &lt;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/2001/04/xmlenc#sha256"/&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 <em class="rfc2119" title="should">should</em> 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, <em class="rfc2119" title="should">should</em> 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>
    </div>  

<div id="sec-o-Manifest" class="section">
  <h3><span class="secno">2.3 </span>Extended Example (<code>Object</code> and <code>Manifest</code>)</h3>

  <p>The <code>Manifest</code> element is provided to meet additional 
  requirements not directly addressed by the mandatory parts of this 
  specification. Two requirements and the way the
  <code>Manifest</code> satisfies them follow.</p>

  <p>First, applications frequently need to efficiently sign multiple data 
  objects even where the signature operation itself is an expensive public key 
  signature. This requirement can be met by including multiple <code>Reference</code> 
  elements within
  <code>SignedInfo</code> since the inclusion of each digest secures the data 
  digested. However, some applications may not want the <a href="#def-ValidationCore" class="link-def">core validation</a> behavior associated with this approach because it 
  requires every <code>Reference</code> within
  <code>SignedInfo</code> to undergo <a href="#def-ValidationReference" class="link-def">reference validation</a> -- the <code>DigestValue</code>
  elements are checked. These applications may wish to reserve reference 
  validation decision logic to themselves. For example, an application might 
  receive a <a href="#def-ValidationSignature" class="link-def">signature valid</a>
  <code>SignedInfo</code> element that includes three
  <code>Reference</code> elements. If a single
  <code>Reference</code> fails (the identified data object when digested does 
  not yield the specified <code>DigestValue</code>) the signature would fail <a href="#def-ValidationCore" class="link-def">core validation</a>. However, the application may wish 
  to treat the signature over the two valid
  <code>Reference</code> elements as valid or take different actions depending 
  on which fails.&nbsp; To accomplish this,
  <code>SignedInfo</code> would reference a <code>Manifest</code>
  element that contains one or more <code>Reference</code> elements (with the 
  same structure as those in <code>SignedInfo</code>). Then, reference 
  validation of the <code>Manifest</code> is under application control.</p>

  <p>Second, consider an application where many signatures (using different 
  keys) are applied to a large number of documents. An inefficient solution is 
  to have a separate signature (per key) repeatedly applied to a large <code>
  SignedInfo</code> element (with many <code>Reference</code>s); this is 
  wasteful and redundant. A more efficient solution is to include many 
  references in a single <code>Manifest</code> that is then referenced from 
  multiple <code>Signature</code> elements.</p>

  <p>The example below includes a <code>Reference</code> that signs a <code>
  Manifest</code> found within the <code>Object</code>
  element.</p>
  <pre class="xml-example">   [   ] ...
   [m01]   &lt;Reference URI="#MyFirstManifest"
   [m02]     Type="http://www.w3.org/2000/09/xmldsig#Manifest"&gt;
   [m03]     &lt;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/2001/04/xmlenc#sha256"/&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>
    </div>  
    </div>  

<div id="sec-Processing" class="section">
  <!--OddPage--><h2><span class="secno">3. </span>Processing Rules</h2>

  <p>The sections below describe the operations to be performed as part of 
  signature generation and validation.</p>

<div id="sec-CoreGeneration" class="section">
  <h3><span class="secno">3.1 </span>Signature Generation</h3>

  <p>The <em class="rfc2119" title="required">required</em> steps include the generation of
  <code>Reference</code> elements and the
  <code>SignatureValue</code> over <code>SignedInfo</code>.</p>

<div id="sec-ReferenceGeneration" class="section">
  <h4><span class="secno">3.1.1 </span>Reference Generation</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
<a href="#sec-SignatureGeneration" class="sectionRef">section 3.1.2 Signature Generation</a> and
validated in
<a href="#sec-ReferenceValidation" class="sectionRef">section 3.2.1 Reference Validation</a>.)</li>
  </ol>
The Reference Processing Model
  (<a href="#sec-ReferenceProcessingModel" class="sectionRef">section 4.4.3.2 The Reference Processing Model</a>) 
  requires use of  
  Canonical XML 1.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>] 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N11">XML-C14N11</a></cite>] be used.<!--  
<ins>
<p class="discuss">< 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>
-->
    </div>

<div id="sec-SignatureGeneration" class="section">
  <h4><span class="secno">3.1.2 </span>Signature Generation</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, 
          [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>] or [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>], [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>] 
          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>
    </div>
</div>
<div id="sec-CoreValidation" class="section">
  <h3><span class="secno">3.2 </span>Core Validation</h3>

  <p>The <em class="rfc2119" title="required">required</em> steps of <a href="#def-ValidationCore" class="link-def">core validation</a> include (1) <a href="#def-ValidationReference" class="link-def">reference validation</a>, the verification of the digest contained in 
  each <code>Reference</code> in
  <code>SignedInfo</code>, and (2) the cryptographic <a href="#def-ValidationSignature" class="link-def">signature validation</a> of the signature calculated over
  <code>SignedInfo</code>.</p>

  <p>Note, there may be valid signatures that some signature applications are 
  unable to validate. Reasons for this include failure to implement optional 
  parts of this specification, inability or unwillingness to execute specified 
  algorithms, or inability or unwillingness to dereference specified URIs (some 
  URI schemes may cause undesirable side effects), etc.</p>

  <p>Comparison of each value in reference and signature validation is
  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>

<div id="sec-ReferenceValidation" class="section">
  <h4><span class="secno">3.2.1 </span>Reference Validation</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 <code>CanonicalizationMethod</code> has no
  dangerous side effects,  
  such as rewriting URIs, (see
  <a href="#sec-CanonicalizationMethod-NOTE">note on Canonicalization Method</a>
) and that it <a href="#sec-See">
  Sees What is Signed</a>, which is the canonical form.</p>

<p>Note, After a <code>Signature</code> element has been created in
Signature
Generation for a signature with a same document reference, an  
implementation can serialize the XML content with variations in that  
serialization. This means that Reference Validation needs to  
canonicalize the XML document before digesting in step 1 to avoid  
issues related to variations in serialization.
</p>
    </div>

<div id="sec-SignatureValidation" class="section">
  <h4><span class="secno">3.2.2 </span>Signature Validation</h4>

  <ol>
    <li>Obtain the keying information from <code><a href="#sec-KeyInfo">KeyInfo</a></code> or from an external source.</li>

    <li>Obtain the canonical form of the
    <code>SignatureMethod</code> using the
    <code>CanonicalizationMethod</code> and use the&nbsp;result (and previously 
        obtained <code>KeyInfo</code>) to confirm the
    <code>SignatureValue</code> over the <code>SignedInfo</code>
    element.</li>
  </ol>

  <p>Note, <code><a href="#sec-KeyInfo">KeyInfo</a></code> (or some transformed version thereof) may be signed 
  via a <code>Reference</code> element. Transformation and validation of this 
  reference (3.2.1) is orthogonal to Signature Validation which uses the
  <code>KeyInfo</code> as parsed.</p>

  <p>Additionally, the <code>SignatureMethod</code> URI may have been altered by 
  the canonicalization of <code>SignedInfo</code>
  (e.g., absolutization of relative URIs) and it is the canonical form that <em class="rfc2119" title="must">must</em> 
  be used. However, the required canonicalization [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>] 
  of this specification does not change URIs.</p>
    </div>
    </div>
    </div>

<div id="sec-CoreSyntax" class="section">
  <!--OddPage--><h2><span class="secno">4. </span>Core Signature Syntax</h2>

  <p>The general structure of an XML signature is described in
  <a href="#sec-Overview" class="sectionRef">section 2.  Signature Overview and Examples</a>. This section
  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 an [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>][<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>] with the following XML preamble, declaration, and 
  internal entity.</p>
  <pre class="xml-dtd">   Schema Definition:

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

   &lt;schema xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
           targetNamespace="http://www.w3.org/2000/09/xmldsig#"
           version="0.1" elementFormDefault="qualified"&gt;
</pre>
  <p>Additional markup defined in version 1.1 of this specification uses the <code>dsig11:</code>
  namespace.  The syntax is defined in an XML schema with the following preamble:</p>
  
  <pre class="xml-dtd">   &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;!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'&gt;
      &lt;!ENTITY dsig11 'http://www.w3.org/2009/xmldsig11#'&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#"
           xmlns:dsig11="http://www.w3.org/2009/xmldsig11#"
           targetNamespace="http://www.w3.org/2009/xmldsig11#"
           version="0.1" elementFormDefault="qualified"&gt;
    
</pre>
<div id="sec-CryptoBinary" class="section">
  <h3><span class="secno">4.1 </span>The <code>ds:CryptoBinary</code> Simple Type</h3>

  <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 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>] encoded. (The 
  conversion from integer to octet string is equivalent to IEEE 1363's
  I2OSP
[<cite><a class="bibref" rel="biblioentry" href="#bib-IEEE1363">IEEE1363</a></cite>]
 with minimal length).</p>

  <p>This type is used by "bignum" values such as
  <code>RSAKeyValue</code> and <code>DSAKeyValue</code>. If a value can be of 
  type <code>base64Binary</code> or
  <code>ds:CryptoBinary</code> they are defined as <a href="http://www.w3.org/TR/xmlschema-2/#base64Binary"><code>base64Binary</code></a>. For example, if the signature algorithm 
  is RSA or DSA then
  <code>SignatureValue</code> represents a bignum and could be
  <code>ds:CryptoBinary</code>. However, if HMAC-SHA1 is the signature algorithm 
  then <code>SignatureValue</code> could have leading zero octets that must be 
  preserved. Thus
  <code>SignatureValue</code> is generically defined as of type
  <code>base64Binary</code>.</p>
  <pre class="xml-dtd">   Schema Definition:

   &lt;simpleType name="CryptoBinary"&gt;
     &lt;restriction base="base64Binary"&gt;
     &lt;/restriction&gt;
   &lt;/simpleType&gt;
</pre>
    </div>

<div id="sec-Signature" class="section">
  <h3><span class="secno">4.2 </span>The <code>Signature</code> element</h3>

  <p>The <code>Signature</code> element is the root element of an XML
  Signature.  
  Implementation <em class="rfc2119" title="must">must</em> generate 
<a href="http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#cvc-elt-lax">laxly
  schema valid</a>

 [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>][<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>] 
<code>Signature</code> elements as specified by 
  the following schema:</p>
  <pre class="xml-dtd">   Schema Definition:

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

<div id="sec-SignatureValue" class="section">
  <h3><span class="secno">4.3 </span>The <code>SignatureValue</code> Element</h3>

  <p>The <code>SignatureValue</code> element contains the actual value of the 
  digital signature; it is always encoded using base64 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>]. 
</p> 
  <pre class="xml-dtd">   Schema Definition:

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

<div id="sec-SignedInfo" class="section">
  <h3><span class="secno">4.4 </span>The <code>SignedInfo</code> Element</h3>

  <p>The structure of <code>SignedInfo</code> includes the canonicalization 
  algorithm, a signature algorithm, and one or more references. The <code>
  SignedInfo</code> element may contain an optional ID attribute that will allow 
  it to be referenced by other signatures and objects.</p>

  <p><code>SignedInfo</code> does not include explicit signature or digest 
  properties (such as calculation time, cryptographic device serial number, 
  etc.). If an application needs to associate properties with the signature or 
  digest, it may include such information in a <code>SignatureProperties</code> 
  element within an <code>Object</code> element.</p>
  <pre class="xml-dtd">   Schema Definition:

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

<div id="sec-CanonicalizationMethod" class="section">
  <h4><span class="secno">4.4.1 </span>The <code>CanonicalizationMethod</code> 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" class="sectionRef">section 6.1 Algorithm Identifiers and Implementation Requirements</a>. 
Implementations <em class="rfc2119" title="must">must</em> support the <em class="rfc2119" title="required">required</em> <a href="#sec-c14nAlg">canonicalization algorithms</a>.</p>

  <p>Alternatives to the <em class="rfc2119" title="required">required</em> <a href="#sec-c14nAlg">canonicalization algorithms</a> (section 6.5), such as
  <a href="#sec-Canonical">Canonical XML with Comments</a> (section 
  6.5.1) or a minimal canonicalization (such as CRLF and charset
  normalization)
, 
  may be explicitly specified but are <em class="rfc2119" title="not required">not required</em>. Consequently, their use may 
  not interoperate with other applications that do not support the specified 
  algorithm (see <a href="#sec-XML-Canonicalization">XML Canonicalization and Syntax Constraint Considerations</a>, 
  section 7). Security issues may also arise in the treatment of entity 
  processing and comments if non-XML aware canonicalization algorithms are not 
  properly constrained (see section 8.1.2: <a href="#sec-Seen">Only 
  What is "Seen" Should be Signed</a>).</p>

  <p>The way in which the <code>SignedInfo</code> element is presented to the 
  canonicalization method is dependent on that method. The following applies to 
  algorithms which process XML as nodes or characters:</p>

  <ul>
    <li>XML based canonicalization implementations <em class="rfc2119" title="must">must</em> be provided
        with an [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>]  
        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 <code>SignedInfo</code> 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 <code>SignedInfo</code>
        element as well as all  
        descendant <a href="http://www.w3.org/TR/1998/REC-xml-19980210#syntax">markup and character data</a> (i.e., the <a href="http://www.w3.org/TR/1998/REC-xml-19980210#dt-text">text</a>) between those tags. Use of text based canonicalization of 
        <code>SignedInfo</code> is <em class="rfc2119" title="not recommended">not recommended</em>.</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 
  <em class="rfc2119" title="should">should</em> (at least) generate
  <a href="http://www.w3.org/TR/REC-xml/#sec-rmd">standalone</a> XML
  instances [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>].</p> 

  <p><strong><a id="sec-CanonicalizationMethod-NOTE">Note</a>:</strong> The signature 
  application must exercise great care in accepting and executing an arbitrary <code>
  CanonicalizationMethod</code>. For example, the canonicalization method could 
  rewrite the URIs of the <code>Reference</code>s being validated. Or, the 
  method could massively transform <code>SignedInfo</code> so that validation 
  would always succeed (i.e., converting it to a trivial signature with a known 
  key over trivial data). Since
  <code>CanonicalizationMethod</code> is inside
  <code>SignedInfo</code>, in the resulting canonical form it could erase itself 
  from <code>SignedInfo</code> or modify the
  <code>SignedInfo</code> element so that it appears that a different 
  canonicalization function was used! Thus a
  <code>Signature</code> which appears to authenticate the desired data with the 
  desired key, <code>DigestMethod</code>, and
  <code>SignatureMethod</code>, can be meaningless if a capricious
  <code>CanonicalizationMethod</code> is used.</p>
  <pre class="xml-dtd">   Schema Definition:

   &lt;element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/&gt; 
   &lt;complexType name="CanonicalizationMethodType" mixed="true"&gt;
     &lt;sequence&gt;
       &lt;any namespace="##any" minOccurs="0" maxOccurs="unbounded"/&gt;
       &lt;!-- (0,unbounded) elements from (1,1) namespace --&gt;
     &lt;/sequence&gt;
     &lt;attribute name="Algorithm" type="anyURI" use="required"/&gt; 
   &lt;/complexType&gt;
</pre>
    </div>
<div id="sec-SignatureMethod" class="section">
  <h4><span class="secno">4.4.2 </span>The <code>SignatureMethod</code> 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 
    <a href="#sec-AlgID" class="sectionRef">section 6.1 Algorithm Identifiers and Implementation Requirements</a>.
    While there is a single identifier, that identifier may 
  specify a format containing multiple distinct signature values.</p>
  <pre class="xml-dtd">   Schema Definition:

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

<p>The <code>ds:HMACOutputLength</code> parameter is used for HMAC [<cite><a class="bibref" rel="biblioentry" href="#bib-HMAC">HMAC</a></cite>] algorithms.  The
parameter specifies a truncation length in bits.  If this parameter is trusted without further
verification, then this can lead to a security bypass
[<cite><a class="bibref" rel="biblioentry" href="#bib-CVE-2009-0217">CVE-2009-0217</a></cite>].  
Signatures <em class="rfc2119" title="must">must</em> be deemed invalid if the truncation length is below
the larger of (a) half the underlying hash algorithm's output length,
and (b) 80 bits.
Note that some implementations are known to not
accept truncation lengths that are lower than the underlying hash algorithm's output length.</p>
    </div>

<div id="sec-Reference" class="section">
  <h4><span class="secno">4.4.3 </span>The <code>Reference</code> Element</h4>

  <p><code>Reference</code> is an element that may occur one or more times. It 
  specifies a digest algorithm and digest value, and optionally an identifier of 
  the object being signed, the type of the object, and/or a list of transforms 
  to be applied prior to digesting. The identification (URI) and transforms 
  describe how the digested content (i.e., the input to the digest method) was 
  created. The <code>Type</code> attribute facilitates the processing of 
  referenced data. For example, while this specification makes no requirements 
  over external data, an application may wish to signal that the referent is a
  <code>Manifest</code>. An optional ID attribute permits a
  <code>Reference</code> to be referenced from elsewhere.</p>
  <pre class="xml-dtd">   Schema Definition:

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

<div id="sec-URI" class="section">
  <h5><span class="secno">4.4.3.1 </span>The <code>URI</code> Attribute</h5>

  <p>The <code>URI</code> attribute identifies a data object using a 
  URI-Reference [<cite><a class="bibref" rel="biblioentry" href="#bib-URI">URI</a></cite>].</p>

  <p>The mapping from this attribute's value to a URI reference <em class="rfc2119" title="must">must</em> be 
  performed as specified in section 3.2.17 of 
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].
  Additionally: Some existing implementations are known to verify the value of 
  the <code>URI</code> attribute against the grammar in [<cite><a class="bibref" rel="biblioentry" href="#bib-URI">URI</a></cite>]. 
  It is therefore safest to perform any necessary escaping while generating the 
  <code>URI</code> attribute.</p>

  <p>We RECOMMEND XML Signature applications be able to dereference URIs in the 
  HTTP scheme. Dereferencing a URI in the HTTP scheme <em class="rfc2119" title="must">must</em> comply with the <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4">Status Code Definitions</a> of [<cite><a class="bibref" rel="biblioentry" href="#bib-HTTP11">HTTP11</a></cite>] (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 
  <a href="#sec-CoreValidation" class="sectionRef">section 3.2 Core Validation</a> for 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">"http://www.w3.org/2000/09/xmldsig#Object"</a><br>
  Type=<a href="http://www.w3.org/2000/09/xmldsig#Manifest">"http://www.w3.org/2000/09/xmldsig#Manifest"</a></code></p>

  <p>The <code>Type</code> 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 <code>Type</code> attribute is advisory. No validation of the 
  type information is required by this specification.</p>
    </div>

<div id="sec-ReferenceProcessingModel" class="section">
  <h5><span class="secno">4.4.3.2 </span>The Reference Processing Model</h5>

  <p class="comment"><strong><a id="Note-Xpath">Note</a>:</strong> XPath is <em class="rfc2119" title="recommended">recommended</em>. Signature applications need not conform 
  to [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>] specification in order to 
  conform to this specification. However, the XPath data model, definitions 
  (e.g., <a href="http://www.w3.org/TR/xpath#node-sets">node-sets</a>) and syntax is used within this document in order to 
  describe functionality for those that want to process XML-as-XML (instead of 
  octets) as part of signature generation. For those that want to use these 
  features, a conformant [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>] 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 <em class="rfc2119" title="required">required</em> 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 <em class="rfc2119" title="must">must</em> attempt to parse the octets 
        yielding the required node-set via [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>]
        well-formed processing.</li>

    <li>If the data object is a node-set and the next transform requires octets, 
        the signature application <em class="rfc2119" title="must">must</em> attempt to convert the node-set to an octet 
        stream using Canonical XML [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>].</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" class="sectionRef">section 3.1.1 Reference Generation</a>
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 [<cite><a class="bibref" rel="biblioentry" href="#bib-URI">URI</a></cite>].</p>

  <p>Unless the URI-Reference is such a 'same-document' reference , the result 
  of dereferencing the URI-Reference <em class="rfc2119" title="must">must</em> be an octet stream. In particular, an 
  XML document identified by URI is not parsed by the signature application 
  unless the URI is a same-document reference or unless a transform that 
  requires XML parsing is applied. (See <a href="#sec-Transforms">Transforms</a> (section 4.4.3.4).)</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 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>]. 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">XPath Transform</a> 
  or XPath Filter 2 Transform [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-XPATH-FILTER2">XMLDSIG-XPATH-FILTER2</a></cite>].</p> 

  <p>When a fragment is not preceded by a URI in the URI-Reference, XML 
  Signature applications <em class="rfc2119" title="must">must</em> support the null URI and shortname XPointer [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-FRAMEWORK">XPTR-FRAMEWORK</a></cite>]. 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">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">Same-Document URI-References</a> (section 4.4.3.3).) All other support 
  for XPointers is <em class="rfc2119" title="optional">optional</em>, 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>' <em class="rfc2119" title="must">must</em> be interpreted to identify the
  root node [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>]  
  of the document that contains the <code>URI</code> attribute.</p> 

  <p>'<code>#xpointer(id('<em>ID</em>'))</code>' <em class="rfc2119" title="must">must</em> be interpreted
  to identify  
  the element node identified by '<code>#element(<em>ID</em>)</code>' 
 [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-ELEMENT">XPTR-ELEMENT</a></cite>] when evaluated with 
  respect to the document that contains the
  <code>URI</code> attribute.</p>

  <p>The original edition of this specification [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-CORE">XMLDSIG-CORE</a></cite>]
  referenced the XPointer  
  Candidate Recommendation [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-XPOINTER-CR2001">XPTR-XPOINTER-CR2001</a></cite>]
 and some implementations support it optionally. 
  That Candidate Recommendation has been superseded by the
[<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-FRAMEWORK">XPTR-FRAMEWORK</a></cite>], [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-XMLNS">XPTR-XMLNS</a></cite>] and [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-ELEMENT">XPTR-ELEMENT</a></cite>] Recommendations, 
  and -- at the time of this edition -- the
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-XPOINTER">XPTR-XPOINTER</a></cite>]
 Working Draft. Therefore, the use of
  the <code> 
  xpointer()</code> scheme [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-XPOINTER">XPTR-XPOINTER</a></cite>] 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 
        <em class="rfc2119" title="required">required</em> 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>
</div>
  <div id="sec-Same-Document" class="section">
    <h5><span class="secno">4.4.3.3 </span>Same-Document URI-References</h5>

  <p>Dereferencing a same-document reference <em class="rfc2119" title="must">must</em> result in an XPath node-set 
  suitable for use by Canonical XML [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>]. Specifically, dereferencing a null 
  URI (<code>URI=""</code>) <em class="rfc2119" title="must">must</em> 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-FRAMEWORK">XPTR-FRAMEWORK</a></cite>]. When processing an XPointer, the application 
  <em class="rfc2119" title="must">must</em> behave as if the XPointer was evaluated with respect to the XML document 
  containing the <code>URI</code>
  attribute . The application <em class="rfc2119" title="must">must</em> behave as if the result of XPointer 
  processing [<cite><a class="bibref" rel="biblioentry" href="#bib-XPTR-FRAMEWORK">XPTR-FRAMEWORK</a></cite>] 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>] or [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N11">XML-C14N11</a></cite>] 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">The Reference Processing Model</a> 
  (section 4.4.3.2).</p>
    </div>

<div id="sec-Transforms" class="section">
  <h5><span class="secno">4.4.3.4 </span>The <code>Transforms</code> Element</h5>

  <p>The optional <code>Transforms</code> element contains an ordered list of <code>
  Transform</code> elements; these describe how the signer obtained the data 
  object that was digested. The output of each <code>Transform</code> serves as 
  input to the next
  <code>Transform</code>. The input to the first
  <code>Transform</code> is the result of dereferencing the
  <code>URI</code> attribute of the <code>Reference</code> element. The output 
  from the last <code>Transform</code> is the input for the <code>DigestMethod</code> 
  algorithm. When transforms are applied the signer is not signing the native 
  (original) document but the resulting (transformed) document. (See <a href="#sec-Secure">Only What is Signed is Secure</a>
  (section 8.1.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" class="sectionRef">section 6.1 Algorithm Identifiers and Implementation Requirements</a>)</p>
  <p>As described in <a href="#sec-ReferenceProcessingModel">The Reference Processing Model</a> (section&nbsp; 4.4.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 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>],
  canonicalization [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>], XPath filtering [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>], and XSLT [<cite><a class="bibref" rel="biblioentry" href="#bib-XSLT">XSLT</a></cite>]. 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">Transform Algorithms</a>
  (section 6.6) defines the list of standard transformations.</p>
  <pre class="xml-dtd">   Schema Definition:

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

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

<div id="sec-DigestMethod" class="section">
  <h5><span class="secno">4.4.3.5 </span>The <code>DigestMethod</code> Element</h5>

  <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" class="sectionRef">section 6.1 Algorithm Identifiers and Implementation Requirements</a>.</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" class="sectionRef">section 4.4.3.2 The Reference Processing Model</a>. If
  the result of URI dereference and application of transforms is an octet 
  stream, then no conversion occurs (comments might be present if the Canonical 
  XML with Comments was specified in the Transforms). The digest algorithm is 
  applied to the data octets of the resulting octet stream.</p>
  <pre class="xml-dtd">   Schema Definition:

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

<div id="sec-DigestValue" class="section">
  <h5><span class="secno">4.4.3.6 </span>The <code>DigestValue</code> Element</h5>

  <p>DigestValue is an element that contains the encoded value of the digest. 
  The digest is always encoded using base64 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>].</p>
  <pre class="xml-dtd">   Schema Definition:

   &lt;element name="DigestValue" type="ds:DigestValueType"/&gt;
   &lt;simpleType name="DigestValueType"&gt;
     &lt;restriction base="base64Binary"/&gt;
   &lt;/simpleType&gt;
</pre>
    </div>
    </div>
    </div>

<div id="sec-KeyInfo" class="section">
  <h3><span class="secno">4.5 </span>The <code>KeyInfo</code> 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>].
  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 <em class="rfc2119" title="must">must</em>
  implement <code>KeyValue</code> (<a href="#sec-KeyValue" class="sectionRef">section 4.5.2 The KeyValue Element</a>)  and  
  <em class="rfc2119" title="should">should</em> implement <code>RetrievalMethod</code>
  (<a href="#sec-RetrievalMethod" class="sectionRef">section 4.5.3 The RetrievalMethod Element</a>).</p>
  <p>The schema specification 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, <em class="rfc2119" title="must">must</em> 
  be a child of <code>KeyInfo</code>. For example, should a complete XML-PGP 
  standard be defined, its root element <em class="rfc2119" title="must">must</em> be a child of <code>KeyInfo</code>. 
  (Of course, new structures from external namespaces can incorporate elements 
  from the <code>dsig:</code> namespace via features of the type definition 
  language. For instance, they can create a schema that permits, includes,
  imports, or derives new types based on <code>dsig:</code> elements.)</p>

  <p>The following list summarizes the <code>KeyInfo</code> types that are 
  allocated an identifier in the <code>dsig:</code>
  namespace; these can be used within the
  <code>RetrievalMethod</code> <code>Type</code> attribute to describe a remote <code>
  KeyInfo</code> structure.</p>

  <ul>
    <li><a href="http://www.w3.org/2000/09/xmldsig#DSAKeyValue">http://www.w3.org/2000/09/xmldsig#DSAKeyValue</a></li>

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

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

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

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

    <li><a href="http://www.w3.org/2000/09/xmldsig#MgmtData">http://www.w3.org/2000/09/xmldsig#MgmtData</a></li>
  </ul>

  <p>The following list summarizes the additional <code>KeyInfo</code>
  types that are allocated an identifier in the <code>dsig11:</code>
  namespace.</p>

  <ul>
    <li><a href="http://www.w3.org/2009/xmldsig11#ECKeyValue">http://www.w3.org/2009/xmldsig11#ECKeyValue</a></li>

    <li><a href="http://www.w3.org/2009/xmldsig11#DEREncodedKeyValue">http://www.w3.org/2009/xmldsig11#DEREncodedKeyValue</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 id="rawX509Certificate">binary (ASN.1 DER) 
  X.509 Certificate</a>.</p>

  <ul>
    <li><a href="http://www.w3.org/2000/09/xmldsig#rawX509Certificate">http://www.w3.org/2000/09/xmldsig#rawX509Certificate</a></li>
  </ul>
  <pre class="xml-dtd">   Schema Definition:

   &lt;element name="KeyInfo" type="ds:KeyInfoType"/&gt; 
   &lt;complexType name="KeyInfoType" mixed="true"&gt;
     &lt;choice maxOccurs="unbounded"&gt;     
       &lt;element ref="ds:KeyName"/&gt; 
       &lt;element ref="ds:KeyValue"/&gt; 
       &lt;element ref="ds:RetrievalMethod"/&gt; 
       &lt;element ref="ds:X509Data"/&gt; 
       &lt;element ref="ds:PGPData"/&gt; 
       &lt;element ref="ds:SPKIData"/&gt;
       &lt;element ref="ds:MgmtData"/&gt;
       &lt;!-- &lt;element ref="dsig11:DEREncodedKeyValue"/&gt; --&gt;
       &lt;!-- DEREncodedKeyValue (XMLDsig 1.1) will use the any element --&gt;
       &lt;!-- &lt;element ref="dsig11:KeyInfoReference"/&gt; --&gt;
       &lt;!-- KeyInfoReference (XMLDsig 1.1) will use the any element --&gt;
       &lt;!-- &lt;element ref="xenc:EncryptedKey"/&gt; --&gt;
       &lt;!-- EncryptedKey (XMLEnc) will use the any element --&gt;
       &lt;!-- &lt;element ref="xenc:Agreement"/&gt; --&gt;
       &lt;!-- Agreement (XMLEnc) will use the any element --&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>

<div id="sec-KeyName" class="section">
  <h4><span class="secno">4.5.1 </span>The <code>KeyName</code> Element</h4>

  <p>The <code>KeyName</code> element contains a string value (in which white 
  space is significant) which may be used by the signer to communicate a key 
  identifier to the recipient. Typically,
  <code>KeyName</code> contains an identifier related to the key pair used to 
  sign the message, but it may contain other protocol-related information that 
  indirectly identifies a key pair. (Common uses of <code>KeyName</code> include 
  simple string names for keys, a key index, a distinguished name (DN), an email 
  address, etc.)</p>
  <pre class="xml-dtd">   Schema Definition:

   &lt;element name="KeyName" type="string"/&gt;
</pre>
    </div>

<div id="sec-KeyValue" class="section">
  <h4><span class="secno">4.5.2 </span>The <code>KeyValue</code> 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 
  (<em class="rfc2119" title="required">required</em>), RSA (<em class="rfc2119" title="required">required</em>) and ECDSA (<em class="rfc2119" title="required">required</em>) public keys are
  defined in
 <a href="#sec-SignatureAlg" class="sectionRef">section 6.4 Signature Algorithms</a>.
The
  <code>KeyValue</code> element may include externally defined public keys 
  values represented as PCDATA or element types from an external namespace.</p>
  <pre class="xml-dtd">   Schema Definition:

   &lt;element name="KeyValue" type="ds:KeyValueType"/&gt; 
   &lt;complexType name="KeyValueType" mixed="true"&gt;
    &lt;choice&gt;
      &lt;element ref="ds:DSAKeyValue"/&gt;
      &lt;element ref="ds:RSAKeyValue"/&gt;
      &lt;!-- &lt;element ref="dsig11:ECKeyValue"/&gt; --&gt;
      &lt;!-- ECC keys (XMLDsig 1.1) will use the any element --&gt;
      &lt;any namespace="##other" processContents="lax"/&gt;
    &lt;/choice&gt;
   &lt;/complexType&gt;
</pre>

<div id="sec-DSAKeyValue" class="section">
  <h5><span class="secno">4.5.2.1 </span>The <code>DSAKeyValue</code> Element</h5>

  <dl>
    <dt>Identifier</dt>

    <dd><code>Type="<a id="DSAKeyValue" href="http://www.w3.org/2000/09/xmldsig#DSAKeyValue">http://www.w3.org/2000/09/xmldsig#DSAKeyValue</a>"<br>
    </code> (this can be used within a <code>RetrievalMethod</code>
    or <code>Reference</code> element to identify the referent's type)</dd>
  </dl>

  <p>DSA keys and the DSA signature algorithm are specified in
  [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>]. DSA public  
  key values can have the following fields:</p>

  <dl>
    <dt><code>P</code></dt>

    <dd>a prime modulus meeting the [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>] 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 <code>J</code> is available for inclusion solely for
  efficiency as it is  
  calculatable from <code>P</code>
  and <code>Q</code>. Parameters <code>seed</code> 
  and <code>pgenCounter</code> are used in the DSA  
  prime number generation algorithm specified in [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>]. 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 <code>P</code> and <code>Q</code>
  value. Parameters <code>P</code>, <code>Q</code>, and <code>G</code> can  
  be public  
  and common to a group of users. They might be known from application context. 
  As such, they are optional but <code>P</code> and <code>Q</code>
  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
[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>]
  values.</p>

  <p>Arbitrary-length integers (e.g. "bignums" such as RSA moduli) are 
  represented in XML as octet strings as defined by the
  <a href="#sec-CryptoBinary"><code>ds:CryptoBinary</code> type</a>.</p>
  <pre class="xml-dtd">   <code>Schema Definition:</code>

   &lt;element name="DSAKeyValue" type="ds:DSAKeyValueType"/&gt; 
   &lt;complexType name="DSAKeyValueType"&gt; 
     &lt;sequence&gt;
       &lt;sequence minOccurs="0"&gt;
         &lt;element name="P" type="ds:CryptoBinary"/&gt; 
         &lt;element name="Q" type="ds:CryptoBinary"/&gt;
       &lt;/sequence&gt;
       &lt;element name="G" type="ds:CryptoBinary" minOccurs="0"/&gt; 
       &lt;element name="Y" type="ds:CryptoBinary"/&gt; 
       &lt;element name="J" type="ds:CryptoBinary" minOccurs="0"/&gt;
       &lt;sequence minOccurs="0"&gt;
         &lt;element name="Seed" type="ds:CryptoBinary"/&gt; 
         &lt;element name="PgenCounter" type="ds:CryptoBinary"/&gt; 
       &lt;/sequence&gt;
     &lt;/sequence&gt;
   &lt;/complexType&gt;
</pre>
    </div>

<div id="sec-RSAKeyValue" class="section">
  <h5><span class="secno">4.5.2.2 </span>The <code>RSAKeyValue</code> Element</h5>

  <dl>
    <dt>Identifier</dt>

    <dd><code>Type="<a id="RSAKeyValue" href="http://www.w3.org/2000/09/xmldsig#RSAKeyValue">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a>"<br>
    </code> (this can be used within a <code>RetrievalMethod</code>
    or <code>Reference</code> element to identify the referent's type)</dd>
  </dl>

  <p>RSA key values have two fields: <code>Modulus</code>
  and <code>Exponent</code>.</p> 
  <pre class="xml-example">   &lt;RSAKeyValue&gt;
     &lt;Modulus&gt;xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
      jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
      5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
     &lt;/Modulus&gt;
     &lt;Exponent&gt;AQAB&lt;/Exponent&gt;
   &lt;/RSAKeyValue&gt;
</pre>

  <p>Arbitrary-length integers (e.g. "bignums" such as RSA moduli) are 
  represented in XML as octet strings as defined by the
  <a href="#sec-CryptoBinary"><code>ds:CryptoBinary</code> type</a>.</p>
  <pre class="xml-dtd">   <code>Schema Definition:</code>

   &lt;element name="RSAKeyValue" type="ds:RSAKeyValueType"/&gt;
   &lt;complexType name="RSAKeyValueType"&gt;
     &lt;sequence&gt;
       &lt;element name="Modulus" type="ds:CryptoBinary"/&gt; 
       &lt;element name="Exponent" type="ds:CryptoBinary"/&gt;
     &lt;/sequence&gt;
   &lt;/complexType&gt;
</pre>
    </div>

<div id="sec-ECKeyValue" class="section">
  <h5><span class="secno">4.5.2.3 </span>The <code>ECKeyValue</code> Element</h5>

  <dl>
    <dt>Identifier</dt>
    <dd><code>Type="<a id="ECKeyValue" href="http://www.w3.org/2009/xmldsig11#ECKeyValue">http://www.w3.org/2009/xmldsig11#ECKeyValue</a>"<br></code>(this can be used within a <code>RetrievalMethod</code> 
    or <code>Reference</code> element to identify the referent's type)</dd>
  </dl>
  
 
  <p>The <code>ECKeyValue</code> element is defined in the 
  http://www.w3.org/2009/xmldsig11# namespace. </p>
  <p>EC public key values consists of two sub components: Domain parameters and 
  <code>PublicKey</code>. </p>
  <pre class="xml-example">    &lt;ECKeyValue xmlns="http://www.w3.org/2009/xmldsig11#"&gt;
      &lt;NamedCurve URI="urn:oid:1.2.840.10045.3.1.7" /&gt;
      &lt;PublicKey&gt;
         vWccUP6Jp3pcaMCGIcAh3YOev4gaa2ukOANC7Ufg
Cf8KDO7AtTOsGJK7/TA8IC3vZoCy9I5oPjRhyTBulBnj7Y
      &lt;/PublicKey&gt;
    &lt;/ECKeyValue&gt;
  </pre>
  <p>Note - A line break has been added to the <code>PublicKey</code>
content to preserve printed page width.</p> 

  <p>Domain parameters can be encoded explicitly using
  the <code>dsig11:ECParameters</code>  element 
  or by reference using the <code>dsig11:NamedCurve</code> element. A named
  curve is specified  
  through the <code>URI</code> attribute. For named curves that are
  identified by  
  OIDs, such as those defined in [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3279">RFC3279</a></cite>] and [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4055">RFC4055</a></cite>],   
  the OID <em class="rfc2119" title="should">should</em> be encoded 
  according to [<cite><a class="bibref" rel="biblioentry" href="#bib-URN-OID">URN-OID</a></cite>]. Conformant 
  applications <em class="rfc2119" title="must">must</em> support the <code>dsig11:NamedCurve</code> element and
  the 256-bit prime field  
  curve as identified by the OID <code>1.2.840.10045.3.1.7</code>.</p> 

  <p>The <code>PublicKey</code> element contains a Base64 encoding of
  a binary representation  
  of the x and y coordinates of the point. Its value is computed as 
  follows:</p>
  <ol>
    <li>Convert the elliptic curve point (x,y) to an octet string 
by first converting the field elements x and y to octet strings as
      specified in Section 6.2 of [<cite><a class="bibref" rel="biblioentry" href="#bib-ECC-ALGS">ECC-ALGS</a></cite>], and then prepend the
      concatenated result of the conversion with 0x04. Support for
      Elliptic-Curve-Point-to-Octet-String conversion without point
      compression is <em class="rfc2119" title="required">required</em>. 
    </li>
    <li>Base64 encode the octet string resulting from the
        conversion in Step 1.</li> 
  </ol>

  <pre class="xml-dtd">    <code>Schema Definition:</code>
    
    &lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;
    
    &lt;element name="ECKeyValue" type="dsig11:ECKeyValueType"/&gt;
    &lt;complexType name="ECKeyValueType"&gt;
      &lt;sequence&gt;
        &lt;choice&gt;
          &lt;element name="ECParameters" type="dsig11:ECParametersType"/&gt;
          &lt;element name="NamedCurve" type="dsig11:NamedCurveType"/&gt;
        &lt;/choice&gt;
        &lt;element name="PublicKey" type="dsig11:ECPointType"/&gt;
      &lt;/sequence&gt;
      &lt;attribute name="Id" type="ID" use="optional"/&gt;
    &lt;/complexType&gt;
    
    &lt;complexType name="NamedCurveType"&gt;
      &lt;attribute name="URI" type="anyURI" use="required"/&gt;
    &lt;/complexType&gt;
      
    &lt;simpleType name="ECPointType"&gt;
      &lt;restriction base="ds:CryptoBinary"/&gt;
    &lt;/simpleType&gt;
  </pre>
  
<div id="sec-ECParameters" class="section">
  <h6><span class="secno">4.5.2.3.1 </span>Explicit Curve Parameters </h6>

  <p>The <code>ECParameters</code> element consists of the following
  subelements. Note these  
  definitions are based on the those described in [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3279">RFC3279</a></cite>].</p>
  <ol>
    <li>The <code>FieldID</code> element identifies the finite field
    over which the elliptic  
        curve is defined. Additional details on the structures for
        defining prime  
        and characteristic two fields is provided below.</li> 
    <li>The <code>dsig11:Curve</code> element specifies the coefficients a
        and b of the elliptic  
        curve E. Each coefficient is first converted from a field
        element to an  
        octet string as specified in section 6.2 of [<cite><a class="bibref" rel="biblioentry" href="#bib-ECC-ALGS">ECC-ALGS</a></cite>], then
        the resultant octet string is encoded in  
        base64.</li>
    <li>The <code>Base</code> element specifies the base point P on
    the elliptic curve. The  
        base point is represented as a value of type <code>ECPointType</code>.</li>
    <li>The <code>Order</code> element specifies the order n of the base point and is encoded 
        as a positiveInteger.</li>
    <li>The <code>Cofactor</code> element is an optional element that
    specifies the integer h  
        = #E(Fq)/n. The cofactor is not required to support ECDSA, except in 
        parameter validation. The cofactor <em class="rfc2119" title="may">may</em> be included to support parameter 
        validation for ECDSA keys. Parameter validation is not required by this 
        specification. The cofactor is required in ECDH public key parameters.</li>
    <li>The <code>dsig11:ValidationData</code> element is an optional
  element that 
  specifies the hash algorithm used to generate the elliptic curve E
  and the base point G verifiably at random. It also specifies the
  seed that was used to generate the curve and the base point. 
    </li>
  </ol>

  <pre class="xml-dtd"><code>Schema Definition:</code>
  
    &lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;

    &lt;complexType name="ECParametersType"&gt;
      &lt;sequence&gt;
        &lt;element name="FieldID" type="dsig11:FieldIDType"/&gt;
        &lt;element name="Curve" type="dsig11:CurveType"/&gt;
        &lt;element name="Base" type="dsig11:ECPointType"/&gt;
        &lt;element name="Order" type="ds:CryptoBinary"/&gt;
        &lt;element name="CoFactor" type="integer" minOccurs="0"/&gt;
        &lt;element name="ValidationData" type="dsig11:ECValidationDataType" minOccurs="0"/&gt;
      &lt;/sequence&gt;
    &lt;/complexType&gt;
    
    &lt;complexType name="FieldIDType"&gt;
      &lt;choice&gt;
        &lt;element ref="dsig11:Prime"/&gt;
        &lt;element ref="dsig11:TnB"/&gt;
        &lt;element ref="dsig11:PnB"/&gt;
        &lt;element ref="dsig11:GnB"/&gt;
        &lt;any namespace="##other" processContents="lax"/&gt;
      &lt;/choice&gt;
    &lt;/complexType&gt;

    &lt;complexType name="CurveType"&gt;
      &lt;sequence&gt;
        &lt;element name="A" type="ds:CryptoBinary"/&gt;
        &lt;element name="B" type="ds:CryptoBinary"/&gt;
      &lt;/sequence&gt;
    &lt;/complexType&gt;

  &lt;complexType name="ECValidationDataType"&gt;
    &lt;sequence&gt;
      &lt;element name="seed" type="ds:CryptoBinary"/&gt;
    &lt;/sequence&gt;
    &lt;attribute name="hashAlgorithm" type="anyURI" use="required"/&gt;
  &lt;/complexType&gt;
  </pre>

  <p>Prime fields are described by a single subelement <code>P</code>,
  which represents the  
  field size in bits. It is encoded as a positiveInteger.</p>
  <pre class="xml-dtd"><code>Schema Definition:</code>
  
   &lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;
  
    &lt;element name="Prime" type="dsig11:PrimeFieldParamsType"/&gt;
    &lt;complexType name="PrimeFieldParamsType"&gt;
      &lt;sequence&gt;
        &lt;element name="P" type="ds:CryptoBinary"/&gt;
      &lt;/sequence&gt;
    &lt;/complexType&gt;
  </pre>

  <p>Structures are defined for three types of characteristic two fields: 
  gaussian normal basis, pentanomial basis and trinomial basis. </p>

  <pre class="xml-dtd"><code>Schema Definition:</code>
  
   &lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;
  
    &lt;element name="GnB" type="dsig11:CharTwoFieldParamsType"/&gt;
    &lt;complexType name="CharTwoFieldParamsType"&gt;
      &lt;sequence&gt;
        &lt;element name="M" type="positiveInteger"/&gt;
      &lt;/sequence&gt;
    &lt;/complexType&gt;
    
    &lt;element name="TnB" type="dsig11:TnBFieldParamsType"/&gt;
    &lt;complexType name="TnBFieldParamsType"&gt;
      &lt;complexContent&gt;
        &lt;extension base="dsig11:CharTwoFieldParamsType"&gt;
          &lt;sequence&gt;
            &lt;element name="K" type="positiveInteger"/&gt;
          &lt;/sequence&gt;
        &lt;/extension&gt;
      &lt;/complexContent&gt;
    &lt;/complexType&gt;

    &lt;element name="PnB" type="dsig11:PnBFieldParamsType"/&gt;
    &lt;complexType name="PnBFieldParamsType"&gt;
      &lt;complexContent&gt;
        &lt;extension base="dsig11:CharTwoFieldParamsType"&gt;
          &lt;sequence&gt;
            &lt;element name="K1" type="positiveInteger"/&gt;
            &lt;element name="K2" type="positiveInteger"/&gt;
            &lt;element name="K3" type="positiveInteger"/&gt;
          &lt;/sequence&gt;
        &lt;/extension&gt;
      &lt;/complexContent&gt;
    &lt;/complexType&gt;
  </pre>
    </div>

<div id="sec-RFC4050Compat" class="section">
  <h6><span class="secno">4.5.2.3.2 </span>Compatibility with RFC 4050</h6>
  <p>Implementations that need to support the [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4050">RFC4050</a></cite>] 
  format for ECDSA keys can avoid known interoperability problems with that 
  specification by adhering to the following profile:</p>
  
  <ol>
    <li>Avoid validating the <code>ECDSAKeyValue</code> element against the [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4050">RFC4050</a></cite>] 
        schema. XML schema validators may not support integer types with decimal data 
        exceeding 18 decimal digits.
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>][<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].</li>
    <li>Support only the <code>NamedCurve</code> element.</li>
    <li>Support the 256-bit prime field curve, as identified by the URN 
    <code>urn:oid:1.2.840.10045.3.1.7</code>.</li>
  </ol>
  <p>The following is an example of a <code>ECDSAKeyValue</code> element that meets the 
  profile described in this section.</p>
  <pre class="xml-example">      &lt;ECDSAKeyValue xmlns="http://www.w3.org/2001/04/xmldsig-more#"&gt;
        &lt;DomainParameters&gt;
          &lt;NamedCurve URN="urn:oid:1.2.840.10045.3.1.7" /&gt;
        &lt;/DomainParameters&gt;
        &lt;PublicKey&gt;
            &lt;X Value="5851106065380174439324917904648283332
0204931884267326155134056258624064349885"&gt;
            &lt;Y Value="1024033521368277752409102672177795083
59028642524881540878079119895764161434936"&gt;
        &lt;/PublicKey&gt;
      &lt;/ECDSAKeyValue&gt;
  </pre>
  <p>Note - A line break has been added to the <code>X</code>
and <code>Y</code> <code>Value</code> attribute values to preserve
    printed page width.</p>  

    </div>
    </div>
    </div>
<div id="sec-RetrievalMethod" class="section">
  <h4><span class="secno">4.5.3 </span>The <code>RetrievalMethod</code> 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 the <code>Reference</code> URI attribute (<a href="#sec-URI" class="sectionRef">section 4.4.3.1 The URI Attribute</a>)  and 
the  <a href="#sec-ReferenceProcessingModel">Reference Processing Model</a>
 except that there are 
  no <code>DigestMethod</code>  
  or <code>DigestValue</code>
  child elements and presence of the <code>URI</code> attribute 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">Reference</a></code> for all <a href="#sec-KeyInfo"><code>KeyInfo</code> types defined by this 
  specification</a>
( <a href="#sec-KeyInfo" class="sectionRef">section 4.5 The KeyInfo Element</a>)
    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>
<p>
Note that when referencing one of the
defined <code>KeyInfo</code> types within the same document, or some remote documents, at
least one <code>Transform</code> is required to turn an ID-based
reference to a <code>KeyInfo</code> 
element into a child element located inside it. This is due to the lack of
an XML ID attribute on the defined <code>KeyInfo</code> types.
In such cases, use of <code>KeyInfoReference</code> is
encouraged instead, see 
<a href="#sec-KeyInfoReference" class="sectionRef">section 4.5.10 The KeyInfoReference Element</a>.</p>
  <pre class="xml-dtd">   Schema Definition

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

  <p><strong>Note:</strong> The schema for the <code>URI</code>
  attribute of RetrievalMethod erroneously omitted the attribute:
  <code>use="required"</code>. However, this error only results in a
  more lax schema  
  which permits all valid <code>RetrievalMethod</code>
  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>
    </div>

<div id="sec-X509Data" class="section">
  <h4><span class="secno">4.5.4 </span>The <code>X509Data</code> Element</h4>

  <dl>
    <dt>Identifier</dt>

    <dd><code>Type="<a id="X509Data" href="http://www.w3.org/2000/09/xmldsig#X509Data">http://www.w3.org/2000/09/xmldsig#X509Data</a></code>
    "<br>
    (this can be used within a <code>RetrievalMethod</code> or
    <code>Reference</code> element to identify the referent's type)</dd>
  </dl>

  <p>An <code>X509Data</code> element within <code>KeyInfo</code>
  contains one or more identifiers of keys or X509 certificates (or 
  certificates' identifiers or a revocation list). The content of
  <code>X509Data</code> is 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:</p>

  <ul>
      <li>The deprecated <code>X509IssuerSerial</code> element, which contains an X.509 
      issuer distinguished name/serial number pair. The distinguished name 
      <em class="rfc2119" title="should">should</em> be represented as a string that complies with section 3 of 
      RFC4514 [<cite><a class="bibref" rel="biblioentry" href="#bib-LDAP-DN">LDAP-DN</a></cite>], to be generated according to the
      <a href="#dname-encrules">Distinguished Name Encoding Rules</a> 
      section below,</li>
        
      <li>The <code>X509SubjectName</code> element, which contains an X.509 
      subject distinguished name that <em class="rfc2119" title="should">should</em> be represented as a string that 
      complies with section 3 of RFC4514 [<cite><a class="bibref" rel="biblioentry" href="#bib-LDAP-DN">LDAP-DN</a></cite>], to be generated according to the
      <a href="#dname-encrules">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 [<cite><a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a></cite>] certificate, and</li>

      <li>The <code>X509CRL</code> element, which contains a base64-encoded 
      certificate revocation list (CRL) [<cite><a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a></cite>].</li>

      <li>The <code>dsig11:X509Digest</code> element contains a base64-encoded
      digest of a certificate. The digest algorithm URI is identified with a
      required <code>Algorithm</code> attribute. The input to the digest <em class="rfc2119" title="must">must</em>
      be the raw octets that would be base64-encoded were the same certificate
      to appear in the X509Certificate element.</li>

      <li>The <code>dsig11:OCSPResponse</code> element contains a base64-encoded OCSP response in
      DER encoding. [<cite><a class="bibref" rel="biblioentry" href="#bib-OCSP">OCSP</a></cite>].</li>

      <li>Elements from an external namespace which accompanies/complements 
      any of the elements above.</li>
    </ul>
    
  <p>Any <code>X509IssuerSerial</code>, <code>X509SKI</code>, <code>X509SubjectName</code>,
  and <code>dsig11:X509Digest</code> elements that appear <em class="rfc2119" title="must">must</em> refer to the 
  certificate or certificates containing the validation key. All such elements 
  that refer to a particular individual certificate <em class="rfc2119" title="must">must</em> be grouped inside a 
  single <code>X509Data</code> element and if the certificate to which they refer
  appears, it <em class="rfc2119" title="must">must</em> also be in that <code>X509Data</code> element.</p>

  <p>Any <code>X509IssuerSerial</code>, <code>X509SKI</code>, <code>X509SubjectName</code>,
  and <code>dsig11:X509Digest</code> elements that relate to the same key but 
  different certificates <em class="rfc2119" title="must">must</em> be grouped within a single <code>KeyInfo</code>
  but <em class="rfc2119" title="may">may</em> occur in multiple <code>X509Data</code> elements.</p>

  <p>Note that if <code>X509Data</code> child elements are used to identify a
  trusted certificate (rather than solely as an untrusted hint supplemented by
  validation by policy), the complete set of such elements that are intended to
  identify a certificate <em class="rfc2119" title="should">should</em> be integrity protected, typically by signing an
  entire <code>X509Data</code> or <code>KeyInfo</code> element.</p>

  <p>All certificates appearing in an <code>X509Data</code> element <em class="rfc2119" title="must">must</em> relate 
  to the validation key by either containing it or being part of a certification 
  chain that terminates in a certificate containing the validation key.</p>

  <p>No ordering is implied by the above constraints. The comments in the 
  following instance demonstrate these constraints:</p>
  <pre class="xml-example">   &lt;KeyInfo&gt;
     &lt;X509Data&gt; &lt;!-- two pointers to certificate-A --&gt;
       &lt;X509IssuerSerial&gt; 
         &lt;X509IssuerName&gt;<span class="tx">CN=TAMURA Kent, OU=TRL, O=IBM, 
           L=Yamato-shi, ST=Kanagawa, C=JP</span>&lt;/X509IssuerName&gt;
         &lt;X509SerialNumber&gt;12345678&lt;/X509SerialNumber&gt;
       &lt;/X509IssuerSerial&gt;
       &lt;X509SKI&gt;31d97bd7&lt;/X509SKI&gt; 
     &lt;/X509Data&gt;
     &lt;X509Data&gt;&lt;!-- single pointer to certificate-B --&gt;
       &lt;X509SubjectName&gt;Subject of Certificate B&lt;/X509SubjectName&gt;
     &lt;/X509Data&gt;
     &lt;X509Data&gt; &lt;!-- certificate chain --&gt;
       &lt;!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4--&gt;
       &lt;X509Certificate&gt;MIICXTCCA..&lt;/X509Certificate&gt;
       &lt;!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US 
            issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US --&gt;
       &lt;X509Certificate&gt;MIICPzCCA...&lt;/X509Certificate&gt;
       &lt;!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US --&gt;
       &lt;X509Certificate&gt;MIICSTCCA...&lt;/X509Certificate&gt;
     &lt;/X509Data&gt;
   &lt;/KeyInfo&gt;
</pre>

  <p>Note, there is no direct provision for a PKCS#7 encoded "bag" of 
  certificates or CRLs. However, a set of certificates and CRLs can occur within 
  an <code>X509Data</code> element and multiple
  <code>X509Data</code> elements can occur in a
  <code>KeyInfo</code>. Whenever multiple certificates occur in an
  <code>X509Data</code> element, at least one such certificate must contain the 
  public key which verifies the signature.</p>

  <p>While in principle many certificate encodings are possible, it is <em class="rfc2119" title="recommended">recommended</em> 
  that certificates appearing in an
  <code>X509Certificate</code> element be limited to an encoding of BER or its DER 
  subset, allowing that within the certificate other content may be present. The 
  use of other encodings may lead to interoperability issues. In any case, XML 
  Signature implementations <em class="rfc2119" title="should not">should not</em> alter or re-encode certificates, as doing 
  so could invalidate their signatures.</p>

  <p>The <code>X509IssuerSerial</code> element has been deprecated in favor of the
  newly-introduced <code>dsig11:X509Digest</code> element. The XML Schema type of
  the serial number was defined to be an integer, and XML Schema validators may not
  support integer types with decimal data exceeding 18 decimal digits [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].
  This has proven insufficient, because many Certificate Authorities issue
  certificates with large, random serial numbers that exceed this limit.
  As a result, deployments that do make use of this element should take care
  if schema validation is involved. New deployments <em class="rfc2119" title="should">should</em> avoid use of the element.</p>

<div id="dname-encrules" class="section">
  <h5><span class="secno">4.5.4.1 </span>Distinguished Name Encoding Rules</h5>

  <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 [<cite><a class="bibref" rel="biblioentry" href="#bib-LDAP-DN">LDAP-DN</a></cite>] <em class="rfc2119" title="should">should</em> be applied, except that the character escaping 
  rules in section 2.4 of RFC 4514 [<cite><a class="bibref" rel="biblioentry" href="#bib-LDAP-DN">LDAP-DN</a></cite>] <em class="rfc2119" title="may">may</em> 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 an 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">   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;!-- &lt;element ref="dsig11:OCSPResponse"/&gt; --&gt;
         &lt;!-- &lt;element ref="dsig11:X509Digest"/&gt; --&gt;
         &lt;!-- OCSPResponse and X509Digest elements (XMLDsig 1.1) will use the any element --&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;

   &lt;!-- Note, this schema permits X509Data to be empty; this is 
   precluded by the text in 
<a href="#sec-KeyInfo" class="sectionRef">section 4.5 The KeyInfo Element</a> 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>
<pre class="xml-dtd">  &lt;!-- targetNameSpace="http://www.w3.org/2009/xmldsig11#" --&gt;
  
  &lt;element name="OCSPResponse" type="base64Binary" /&gt;

  &lt;element name="X509Digest" type="dsig11:X509DigestType"/&gt;
  &lt;complexType name="X509DigestType"&gt;
    &lt;simpleContent&gt;
      &lt;extension base="base64Binary"&gt;
        &lt;attribute name="Algorithm" type="anyURI" use="required"/&gt;
      &lt;/extension&gt;
    &lt;/simpleContent&gt;
  &lt;/complexType&gt;
</pre>
      </div>
      </div>
<div id="sec-PGPData" class="section">
  <h4><span class="secno">4.5.5 </span>The <code>PGPData</code> Element</h4>

  <dl>
    <dt>Identifier</dt>

    <dd><code>Type="<a id="PGPData" href="http://www.w3.org/2000/09/xmldsig#PGPData">http://www.w3.org/2000/09/xmldsig#PGPData</a></code>
    "<br>
    (this can be used within a <code>RetrievalMethod</code> or
    <code>Reference</code> element to identify the referent's type)</dd>
  </dl>

  <p>The <code>PGPData</code> element within <code>KeyInfo</code>
  is used to convey information related to PGP public key pairs and signatures 
  on such keys. The <code>PGPKeyID</code>'s value is a base64Binary sequence 
  containing a standard PGP public key identifier as defined in [<cite><a class="bibref" rel="biblioentry" href="#bib-PGP">PGP</a></cite>] section 11.2]. The <code>PGPKeyPacket</code>
  contains a base64-encoded Key Material Packet as defined in [<cite><a class="bibref" rel="biblioentry" href="#bib-PGP">PGP</a></cite>] 
  section 5.5]. These children element types can be complemented/extended by 
  siblings from an external namespace within <code>PGPData</code>, or
  <code>PGPData</code> can be replaced all together with an alternative PGP XML 
  structure as a child of <code>KeyInfo</code>.
  <code>PGPData</code> must contain one <code>PGPKeyID</code>
  and/or one <code>PGPKeyPacket</code> and 0 or more elements from an external 
  namespace.</p>
  <pre class="xml-dtd">   Schema Definition:

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

<div id="sec-SPKIData" class="section">
  <h4><span class="secno">4.5.6 </span>The <code>SPKIData</code> Element</h4>

  <dl>
    <dt>Identifier</dt>

    <dd><code>Type="<a id="SPKIData" href="http://www.w3.org/2000/09/xmldsig#SPKIData">http://www.w3.org/2000/09/xmldsig#SPKIData</a></code>
    "<br>
    (this can be used within a <code>RetrievalMethod</code> or
    <code>Reference</code> element to identify the referent's type)</dd>
  </dl>

  <p>The <code>SPKIData</code> element within <code>KeyInfo</code>
  is used to convey information related to SPKI public key pairs, certificates 
  and other SPKI data. <code>SPKISexp</code> is the base64 encoding of a SPKI 
  canonical S-expression.
  <code>SPKIData</code> must have at least one
  <code>SPKISexp</code>; <code>SPKISexp</code> can be complemented/extended by 
  siblings from an external namespace within <code>SPKIData</code>, or <code>
  SPKIData</code> can be entirely replaced with an alternative SPKI XML 
  structure as a child of <code>KeyInfo</code>.</p>
  <pre class="xml-dtd">   Schema Definition:

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

<div id="sec-MgmtData" class="section">
  <h4><span class="secno">4.5.7 </span>The <code>MgmtData</code> Element</h4>

  <dl>
    <dt>Identifier</dt>

    <dd><code>Type="<a id="MgmtData" href="http://www.w3.org/2000/09/xmldsig#MgmtData">http://www.w3.org/2000/09/xmldsig#MgmtData</a></code> 
    "<br>
      (this can be used within a <code>RetrievalMethod</code> or
      <code>Reference</code> element to identify the referent's type)</dd>
  </dl>
The <code>MgmtData</code> element within <code>KeyInfo</code> is a
  string value used to convey 
  in-band key distribution or agreement data. However, use of this
  element is <em class="rfc2119" title="not recommended">not recommended</em> and <em class="rfc2119" title="should not">should not</em> be used. 
The
 <a href="#sec-keyconvenance" class="sectionRef">section 4.5.8 XML Encryption EncryptedKey
and DerivedKey Elements</a> describes
 new <code>KeyInfo</code> types for conveying key information. 
  <pre class="xml-dtd">   Schema Definition:

   &lt;element name="MgmtData" type="string"/&gt;
  </pre>
    </div>
<div id="sec-keyconvenance" class="section">
<h4><span class="secno">4.5.8 </span>XML Encryption <code>EncryptedKey</code>
and <code>DerivedKey</code> Elements</h4>
The <code>&lt;xenc:EncryptedKey&gt;</code>
and <code>&lt;xenc:DerivedKey&gt;</code> elements defined in 
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLENC-CORE1">XMLENC-CORE1</a></cite>] as children of <code>ds:KeyInfo</code> can be used
to convey in-band 
encrypted or derived key material. In particular, the
<code>xenc:DerivedKey</code>&gt; element may be present when the key used in
calculating a Message Authentication Code is derived from a shared
secret.
</div>

<div id="sec-DEREncodedKeyValue" class="section">
  <h4><span class="secno">4.5.9 </span>The <code>DEREncodedKeyValue</code> Element</h4>
  
  <dl>
    <dt>Identifier</dt>
    
    <dd><code>Type="<a id="DEREncodedKeyValue" href="http://www.w3.org/2009/xmldsig11#DEREncodedKeyValue">http://www.w3.org/2009/xmldsig11#DEREncodedKeyValue</a>"<br></code>(this can be used within a <code>RetrievalMethod</code> 
    or <code>Reference</code> element to identify the referent's type)
    </dd>
  </dl>
    
  <p>The public key algorithm and value are DER-encoded in accordance with the
  value that would be used in the Subject Public Key Info field of an X.509
  certificate, per section 4.1.2.7 of [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC5280">RFC5280</a></cite>].
  The DER-encoded value is then base64-encoded.</p>
  
  <p>For the key value types supported in this specification, refer to the
  following for normative references on the format of Subject Public Key Info
  and the relevant OID values that identify the key/algorithm type:</p>
  
  <dl>
    <dt>RSA</dt>
    <dd>See section 2.3.1 of [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3279">RFC3279</a></cite>]</dd>
    <dt>DSA</dt>
    <dd>See section 2.3.2 of [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3279">RFC3279</a></cite>]</dd>
    <dt>EC</dt>
    <dd>See section 2 of [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC5480">RFC5480</a></cite>]</dd>
  </dl>
  
  <p>Specifications that define additional key types should provide such
  a normative reference for their own key types where possible.</p>
  
  <pre class="xml-dtd">   Schema Definition:

   &lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;

  &lt;element name="DEREncodedKeyValue" type="dsig11:DEREncodedKeyValueType"/&gt;
  &lt;complexType name="DEREncodedKeyValueType"&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>
<p>
Historical note: The <code>DEREncodedKeyValue</code> element was added
to XML Signature 1.1 in order to support certain interoperability
scenarios where at least one of signer and/or verifier are not able to
serialize keys in the XML formats described in 
<a href="#sec-KeyValue" class="sectionRef">section 4.5.2 The KeyValue Element</a> 
above. The <code>KeyValue</code> element is to be used for
"bare" XML key 
representations (not XML wrappings around other binary encodings like
ASN.1 DER); for this reason the <code>DEREncodedKeyValue</code>
element is not a 
child of <code>KeyValue</code>. 
The <code>DEREncodedKeyValue</code> element is also not a child of the
<code>X509Data</code> element, as the keys represented
by <code>DEREncodedKeyValue</code>  may
not have X.509 certificates associated with them (a requirement for
<code>X509Data</code>). </p>
   </div>

<div id="sec-KeyInfoReference" class="section">
  <h4><span class="secno">4.5.10 </span>The <code>KeyInfoReference</code> Element</h4>
  <p>
A <code>KeyInfoReference</code> element within <code>KeyInfo</code> is
        used to 
        convey a reference to a 
<code>KeyInfo</code> element at another location in the same or
different document. 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>KeyInfoReference</code> element instead of including the
entire chain with a 
sequence of <code>X509Certificate</code> elements repeated in multiple
places. 
</p>
<p>
<code>KeyInfoReference</code> uses the same syntax and dereferencing
behavior as 
<code>Reference</code>'s <code>URI</code> (
<a href="#sec-URI" class="sectionRef">section 4.4.3.1 The URI Attribute</a>) and the Reference
Processing Model 
(<a href="#sec-ReferenceProcessingModel" class="sectionRef">section 4.4.3.2 The Reference Processing Model</a>)
except that there are no child elements and the
presence 
of the <code>URI</code> attribute is mandatory. 
</p>
<p>

The result of dereferencing a <code>KeyInfoReference</code> <em class="rfc2119" title="must">must</em> be
a <code>KeyInfo</code> element, or 
an XML document with a <code>KeyInfo</code> element as the root. 
</p>
<p>
<strong>Note:</strong> The <code>KeyInfoReference</code> element is a desirable
alternative to the use of 
<code>RetrievalMethod</code> when the data being referred to is
a <code>KeyInfo</code> element and the 
use of <code>RetrievalMethod</code> would require one or
more <code>Transform</code> child elements, 
which introduce security risk and implementation challenges.
</p>
<pre class="xml-dtd">Schema Definition

   &lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;

   &lt;element name="KeyInfoReference" type="dsig11:KeyInfoReferenceType"/&gt; 
   &lt;complexType name="KeyInfoReferenceType"&gt;
     &lt;attribute name="URI" type="anyURI" use="required"/&gt;
     &lt;attribute name="Id" type="ID" use="optional"/&gt;
   &lt;/complexType&gt;
</pre>

</div>    
</div>

<div id="sec-Object" class="section">
  <h3><span class="secno">4.6 </span>The <code>Object</code> Element</h3>

  <dl>
    <dt>Identifier</dt>

    <dd><code>Type=<a id="Object" href="http://www.w3.org/2000/09/xmldsig#Object">"http://www.w3.org/2000/09/xmldsig#Object"</a><br></code> (this can be used within a
    <code>Reference</code> element to identify the referent's type)</dd>
  </dl>

  <p><code>Object</code> is an optional element that may occur one or more 
  times. When present, this element may contain any data. The <code>Object</code> 
  element may include optional MIME type, ID, and encoding attributes.</p>

  <p>The <code>Object</code>'s <code>Encoding</code> attributed may be used to 
  provide a URI that identifies the method by which the object is encoded (e.g., 
  a binary file).</p>

  <p>The <code>MimeType</code> attribute is an optional attribute which 
  describes the data within the <code>Object</code>
  (independent of its encoding). This is a string with values defined
  by [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>].
  For example, if the <code>Object</code> contains base64 encoded
  <a href="http://www.w3.org/Graphics/PNG/">PNG</a>, the <code>
  Encoding</code> may be specified as '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">Transforms</a></code> with well defined resulting types and/or 
  encodings.</p>

  <p>The <code>Object</code>'s <code>Id</code> is commonly referenced from a <code>
  Reference</code> in
  <code>SignedInfo</code>, or <code>Manifest</code>. This element is typically 
  used for <a href="#def-SignatureEnveloping" class="link-def">enveloping signatures</a> where the object being 
  signed is to be included in the signature element. The digest is calculated 
  over the entire <code>Object</code>
  element including start and end tags.</p>

  <p>Note, if the application wishes to exclude the
  <code>&lt;Object&gt;</code> tags from the digest calculation the
  <code>Reference</code> must identify the actual data object (easy for XML 
  documents) or a transform must be used to remove the
  <code>Object</code> tags (likely where the data object is non-XML). Exclusion 
  of the object tags may be desired for cases where one wants the signature to 
  remain valid if the data object is moved from inside a signature to outside 
  the signature (or vice versa), or where the content of the <code>Object</code> 
  is an encoding of an original binary document and it is desired to extract and 
  decode so as to sign the original bitwise representation.</p>
  <pre class="xml-dtd">   Schema Definition:

   &lt;element name="Object" type="ds:ObjectType"/&gt; 
   &lt;complexType name="ObjectType" mixed="true"&gt;
     &lt;sequence minOccurs="0" maxOccurs="unbounded"&gt;
       &lt;any namespace="##any" processContents="lax"/&gt;
     &lt;/sequence&gt;
     &lt;attribute name="Id" type="ID" use="optional"/&gt; 
     &lt;attribute name="MimeType" type="string" use="optional"/&gt;
     &lt;attribute name="Encoding" type="anyURI" use="optional"/&gt; 
   &lt;/complexType&gt;
</pre>
    </div>
    </div>
<div id="sec-AdditionalSyntax" class="section">
  <!--OddPage--><h2><span class="secno">5. </span>Additional Signature Syntax</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>

<div id="sec-Manifest" class="section">
  <h3><span class="secno">5.1 </span>The <code>Manifest</code> Element</h3>

  <dl>
    <dt>Identifier</dt>

    <dd><code>Type=<a id="Manifest" href="http://www.w3.org/2000/09/xmldsig#Manifest">"http://www.w3.org/2000/09/xmldsig#Manifest"</a><br>
    </code> (this can be used within a <code>Reference</code>
    element to identify the referent's type)</dd>
  </dl>

  <p>The <code>Manifest</code> element provides a list of
  <code>Reference</code>s. The difference from the list in
  <code>SignedInfo</code> is that it is application defined which, if any, of 
  the digests are actually checked against the objects referenced and what to do 
  if the object is inaccessible or the digest compare fails. If a <code>Manifest</code> 
  is pointed to from <code>SignedInfo</code>, the digest over the
  <code>Manifest</code> itself will be checked by the core signature validation 
  behavior. The digests within such a
  <code>Manifest</code> are checked at the application's discretion. If a <code>
  Manifest</code> is referenced from another
  <code>Manifest</code>, even the overall digest of this two level deep <code>
  Manifest</code> might not be checked.</p>
  <pre class="xml-dtd">   Schema Definition:

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

<div id="sec-SignatureProperties" class="section">
  <h3><span class="secno">5.2 </span>The <code>SignatureProperties</code> Element</h3>

  <dl>
    <dt>&nbsp;</dt>

    <dt>Identifier</dt>

    <dd><code>Type="<a id="SignatureProperties" href="http://www.w3.org/2000/09/xmldsig#SignatureProperties">http://www.w3.org/2000/09/xmldsig#SignatureProperties</a>"<br>
    </code> (this can be used within a <code>Reference</code>
    element to identify the referent's type)</dd>
  </dl>

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

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

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

    </div>
<div id="sec-PI" class="section">
  <h3><span class="secno">5.3 </span>Processing Instructions 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>
    </div>
<div id="sec-comments" class="section">
  <h3><span class="secno">5.4 </span>Comments 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>] 
  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
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>], is specified.</p> 
    </div>
    </div>
<div id="sec-Algorithms" class="section">
  <!--OddPage--><h2><span class="secno">6. </span>Algorithms</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>

<div id="sec-AlgID" class="section">
  <h3><span class="secno">6.1 </span>Algorithm Identifiers and Implementation Requirements</h3>
  
  <div class="note">
   The Working Group may request <a href="http://www.w3.org/2005/10/Process-20051014/tr.html#cfi">transition to Candidate Recommendation</a> with mandatory support for <code>ECDSAwithSHA256</code> marked as "at risk". If issues about deployment of this feature are raised during Candidate Recommendation, the group may elect to make this feature optional.
  </div>
  
  <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 <em class="rfc2119" title="must">must</em> 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><strong>Required</strong></dd>

    <dd>
      <ol>
        <li>SHA1 (Use is DISCOURAGED; see <a href="#sec-MessageDigests">SHA-1 Warning</a>)<br>
        <a href="http://www.w3.org/2000/09/xmldsig#sha1">http://www.w3.org/2000/09/xmldsig#sha1</a></li>
        
        <li>SHA256<br>
        <a href="http://www.w3.org/2001/04/xmlenc#sha256">http://www.w3.org/2001/04/xmlenc#sha256</a></li>
        
      </ol>
    </dd>
    <dd><strong>Optional</strong>
   
          <ol>
        <li>SHA384<br>
        <a href="http://www.w3.org/2001/04/xmldsig-more#sha384">http://www.w3.org/2001/04/xmldsig-more#sha384</a></li>
        <li>SHA512<br>
        <a href="http://www.w3.org/2001/04/xmlenc#sha512">http://www.w3.org/2001/04/xmlenc#sha512</a></li>
        
      </ol>
    </dd>
    
    <dt>Encoding</dt>
<dd><strong>Required</strong></dd>
    <dd>
      <ol>
        <li>base64 (<a href="#base64note">*note</a>)<br>
        <a href="http://www.w3.org/2000/09/xmldsig#base64"><span style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span>base64</a></li>
      </ol>
    </dd>

    <dt>MAC</dt>
<dd><strong>Required</strong></dd>
    <dd>
      <ol>
        <li>HMAC-SHA1 (Use is
        DISCOURAGED; see <a href="#sec-MessageDigests">SHA-1 Warning</a>)<br>
        <a href="http://www.w3.org/2000/09/xmldsig#hmac-sha1">http://www.w3.org/2000/09/xmldsig#hmac-sha1</a></li>
        <li>HMAC-SHA256<br>
        <a href="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256">http://www.w3.org/2001/04/xmldsig-more#hmac-sha256</a></li>
      </ol>
    </dd>
<dd><strong>Recommended</strong></dd>  
        <dd><ol>
        <li>HMAC-SHA384<br>
        <a href="http://www.w3.org/2001/04/xmldsig-more#hmac-sha384">http://www.w3.org/2001/04/xmldsig-more#hmac-sha384</a></li>
        <li>HMAC-SHA512<br>
        <a href="http://www.w3.org/2001/04/xmldsig-more#hmac-sha512">http://www.w3.org/2001/04/xmldsig-more#hmac-sha512</a></li>
        
      </ol>
    </dd>

    <dt>Signature</dt>

<dd><strong>Required</strong></dd>
    <dd>
      <ol>
                <li>RSAwithSHA256<br>
        <a href="http://www.ietf.org/rfc/rfc4051.txt">
        <span style="font-weight: normal">
                http://www.w3.org/2001/04/xmldsig-more#rsa-sha256</span></a>[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4051">RFC4051</a></cite>]</li>

        <li>ECDSAwithSHA256<br>
        <a href="http://www.ietf.org/rfc/rfc4051.txt">
        <span style="font-weight: normal">
                http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256</span></a> [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4051">RFC4051</a></cite>]</li>
        
        <li>DSAwithSHA1<br>
                (<strong>signature verification</strong>)<br>
                <a href="http://www.w3.org/2000/09/xmldsig#dsa-sha1">http://www.w3.org/2000/09/xmldsig#dsa-sha1</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4051">RFC4051</a></cite>]</li>

</ol></dd>
<dd><strong>Recommended</strong></dd>
<dd><ol>
        <li>RSAwithSHA1<br>
                (<strong>signature verification</strong>; use for
		signature generation is DISCOURAGED;
                see <a href="#sec-MessageDigests">SHA-1 Warning</a>)<br>
        <a href="http://www.w3.org/2000/09/xmldsig#rsa-sha1"><span style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span>rsa-sha1</a></li>
        </ol></dd>
        
<dd><strong>Optional</strong></dd>
<dd><ol>       
        <li>RSAwithSHA384<br>
        <a href="http://www.ietf.org/rfc/rfc4051.txt">
        <span style="font-weight: normal">
                http://www.w3.org/2001/04/xmldsig-more#rsa-sha384</span></a> [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4051">RFC4051</a></cite>]</li>
        
        <li>RSAwithSHA512<br>
        <a href="http://www.ietf.org/rfc/rfc4051.txt">
        <span style="font-weight: normal">
                http://www.w3.org/2001/04/xmldsig-more#rsa-sha512</span></a> </li>
        
        <li>ECDSAwithSHA1 (Use is DISCOURAGED; see <a href="#sec-MessageDigests">SHA-1 Warning</a>)<br>
        <a href="http://www.ietf.org/rfc/rfc4051.txt">
        <span style="font-weight: normal">
                http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1</span></a> [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4051">RFC4051</a></cite>]</li>

        <li>ECDSAwithSHA384<br>
        <a href="http://www.ietf.org/rfc/rfc4051.txt">
        <span style="font-weight: normal">
                http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384</span></a> [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4051">RFC4051</a></cite>]</li>
        <li>ECDSAwithSHA512<br>
        <a href="http://www.ietf.org/rfc/rfc4051.txt">
        <span style="font-weight: normal">
                http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512</span></a> [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4051">RFC4051</a></cite>]</li>
        
        <li>DSAwithSHA1<br>
                (<strong>signature generation</strong>)<br>
                <a href="http://www.w3.org/2000/09/xmldsig#dsa-sha1">
                <span style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#dsa-sha1</span></a> </li>
        <li>DSAwithSHA256<br>
                <a href="http://www.w3.org/2009/xmldsig11#dsa-sha256">
                <span style="font-weight: normal">
		http://www.w3.org/2009/xmldsig11#dsa-sha256</span></a> </li>
      </ol>
    </dd>

    <dt>Canonicalization</dt>

<dd><strong>Required</strong></dd>
    <dd>
      <ol>
        <li>Canonical XML 1.0 (omit comments)<br>
        <a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a></li>

        <li>Canonical XML 1.1 (omit comments)<br>
        <a href="http://www.w3.org/2006/12/xml-c14n11">http://www.w3.org/2006/12/xml-c14n11</a></li>

        <li>Exclusive XML Canonicalization 1.0 (omit comments)<br>
          <a href="http://www.w3.org/2001/10/xml-exc-c14n#">
        http://www.w3.org/2001/10/xml-exc-c14n#</a></li>

</ol></dd>

<dd><strong>Recommended</strong></dd>
<dd><ol>
        <li>Canonical XML 1.0 (with comments)<br>
        <a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments">http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments</a></li>

        <li>Canonical XML 1.1 (with comments)<br>
        <a href="http://www.w3.org/2006/12/xml-c14n11#WithComments">http://www.w3.org/2006/12/xml-c14n11#WithComments</a></li>

        
        <li>Exclusive XML Canonicalization 1.0 (with comments)<br>
        <a href="http://www.w3.org/2001/10/xml-exc-c14n#WithComments">http://www.w3.org/2001/10/xml-exc-c14n#WithComments</a></li>
      </ol>
    </dd>

    <dt>Transform</dt>

<dd><strong>Required</strong></dd>
<dd>
  <ol>
        <li>base64 (<a href="#base64note">*note</a>)<br>
          <a href="http://www.w3.org/2000/09/xmldsig#base64"><span style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span>base64</a></li>
        <li>Enveloped Signature (<a href="#esignote">**note</a>)<br>
          <a href="http://www.w3.org/2000/09/xmldsig#enveloped-signature">http://www.w3.org/2000/09/xmldsig#enveloped-signature</a></li>
  </ol>
</dd>
<dd><strong>Recommended</strong></dd>
<dd><ol>
        <li>XPath<br>
                <a href="http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/TR/1999/REC-xpath-19991116</a></li>
                
                <li>XPath Filter 2.0<br>
                <a href="http://www.w3.org/2002/06/xmldsig-filter2">http://www.w3.org/2002/06/xmldsig-filter2</a></li>

</ol></dd>

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

<div id="base64note">
  <p>*note: Note that
  the same URI is used to identify base64 both in "encoding"
  context (e.g. within the <code>Object</code> element) as well as in
  "transform" context (when identifying a base64
  transform).</p>
</div>
<div id="esignote">
<p>**note: 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 <em class="rfc2119" title="may">may</em> be 
    implemented via the XPath specification specified in 6.6.4: <a href="#sec-EnvelopedSignature">Enveloped Signature Transform</a>; it 
    <em class="rfc2119" title="must">must</em> have the same effect as that specified by the 
    XPath Transform.</p>
  <p>&nbsp;</p><p>When using transforms, we RECOMMEND selecting the least expressive choice that still
  accomplishes the needs of the use case at hand: Use of XPath filter 2.0 is recommended over use of
  XPath filter. Use of XPath filter is recommended over use of XSLT.</p>
  
  <p><strong>Note:</strong> Implementation requirements for the XPath transform may be downgraded to
  <em class="rfc2119" title="optional">optional</em> in a future version of this specification.</p>
    </div></div>   

<div id="sec-MessageDigests" class="section">
  <h3><span class="secno">6.2 </span>Message Digests</h3>

  <p>This specification defines several possible digest algorithms for
  the DigestMethod element, including <em class="rfc2119" title="required">required</em> algorithm SHA-256. Use
  of SHA-256 is strongly recommended over SHA-1 because recent
  advances in cryptanalysis (see e.g. [<cite><a class="bibref" rel="biblioentry" href="#bib-SHA-1-Analysis">SHA-1-Analysis</a></cite>]) have cast doubt on the long-term
  collision resistance of SHA-1.  Therefore, SHA-1 support is <em class="rfc2119" title="required">required</em>
  in this specification only for backwards-compatibility reasons.
  </p>

  <p>Digest algorithms that are known not to be collision resistant <em class="rfc2119" title="should not">should not</em> be 
  used in DigestMethod elements.  For example, the <a href="http://www.ietf.org/rfc/rfc1321.txt">MD5</a> message digest algorithm 
  <em class="rfc2119" title="should not">should not</em> be used as specific collisions have been demonstrated for that 
  algorithm.</p>

<div id="sec-SHA-1" class="section">
  <h4><span class="secno">6.2.1 </span>SHA-1</h4>
  <dl>
    <dt>Identifier:</dt>

    <dd><a id="sha1" href="http://www.w3.org/2000/09/xmldsig#sha1">http://www.w3.org/2000/09/xmldsig#sha1</a></dd>
  </dl>
<p>
<strong>Note:</strong> Use
  of SHA-256 is strongly recommended over SHA-1 because recent
  advances in cryptanalysis (see e.g. [<cite><a class="bibref" rel="biblioentry" href="#bib-SHA-1-Analysis">SHA-1-Analysis</a></cite>],
  [<cite><a class="bibref" rel="biblioentry" href="#bib-SHA-1-Collisions">SHA-1-Collisions</a></cite>] ) have cast doubt on the long-term 
  collision resistance of SHA-1.
</p>
  <p>The <a href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">SHA-1</a> algorithm [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>] takes no explicit parameters. An example of an SHA-1 
  DigestAlg element is:</p>
  <pre class="xml-example"><code>&lt;DigestMethod Algorithm="</code><span style="font-weight: normal">http://www.w3.org/2000/09/xmldsig#</span><code>sha1"/&gt;</code>
</pre>

  <p>A SHA-1 digest is a 160-bit string. The content of the DigestValue element 
  shall be the base64 encoding of this bit string viewed as a 20-octet octet 
  stream. For example, the DigestValue element for the message digest:</p>
  <pre class="xml-example">   A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
</pre>

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

<div id="sec-SHA-256" class="section">
  <h4><span class="secno">6.2.2 </span>SHA-256</h4>
  <dl>
    <dt>Identifier:</dt>
    <dd><a id="sha-256" href="http://www.w3.org/2001/04/xmlenc#sha256">http://www.w3.org/2001/04/xmlenc#sha256</a></dd>
  </dl>
  <p>The <a href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">SHA-256</a> algorithm [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-180-3">FIPS-180-3</a></cite>] takes no explicit
  parameters. A SHA-256 digest is a  
  256-bit string. The content of the DigestValue element shall be the base64 
  encoding of this bit string viewed as a 32-octet octet stream.</p>

</div>  
<div id="sec-SHA-384" class="section">
  <h4><span class="secno">6.2.3 </span>SHA-384</h4>
  <dl>
    <dt>Identifier:</dt>
    <dd><a id="sha-384" href="http://www.w3.org/2001/04/xmldsig-more#sha384">http://www.w3.org/2001/04/xmldsig-more#sha384</a></dd>
  </dl>
  <p>The <a href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">SHA-384</a> algorithm [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-180-3">FIPS-180-3</a></cite>]
 takes no explicit parameters. A SHA-384 digest is a 
  384-bit string. The content of the DigestValue element shall be the base64 
  encoding of this bit string viewed as a 48-octet octet stream.</p>
</div>  
<div id="sec-SHA-512" class="section">
  <h4><span class="secno">6.2.4 </span>SHA-512</h4>
  <dl>
    <dt>Identifier:</dt>
    <dd><a id="sha-512" href="http://www.w3.org/2001/04/xmlenc#sha512">http://www.w3.org/2001/04/xmlenc#sha512</a></dd>
  </dl>
  <p>The <a href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">SHA-512</a> algorithm  [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-180-3">FIPS-180-3</a></cite>]
takes no explicit parameters. A SHA-512 digest is a 
  512-bit string. The content of the DigestValue element shall be the base64 
  encoding of this bit string viewed as a 64-octet octet stream.</p>
</div>  
</div>  
<div id="sec-MACs" class="section">
  <h3><span class="secno">6.3 </span>Message Authentication 
  Codes</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>

<div id="sec-HMAC" class="section">
  <h4><span class="secno">6.3.1 </span>HMAC</h4>
  <dl>
    <dt>Identifier:</dt>

    <dd><a id="hmac-sha1" href="http://www.w3.org/2000/09/xmldsig#hmac-sha1">http://www.w3.org/2000/09/xmldsig#hmac-sha1</a></dd>
    
    <dd><a id="hmac-sha256" href="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256">http://www.w3.org/2001/04/xmldsig-more#hmac-sha256</a></dd> 
    
    <dd><a id="hmac-sha384" href="http://www.w3.org/2001/04/xmldsig-more#hmac-sha384">http://www.w3.org/2001/04/xmldsig-more#hmac-sha384</a></dd>
    
    <dd><a id="hmac-sha512" href="http://www.w3.org/2001/04/xmldsig-more#hmac-sha512">http://www.w3.org/2001/04/xmldsig-more#hmac-sha512</a></dd>
  </dl>

  <p>The <a href="http://www.ietf.org/rfc/rfc2104.txt">HMAC</a>
  algorithm (RFC2104 [<cite><a class="bibref" rel="biblioentry" href="#bib-HMAC">HMAC</a></cite>]) takes the output
  (truncation) length in bits  as a 
  parameter;  
  this specification REQUIRES that the truncation length be a multiple of 8 
  (i.e. fall on a byte boundary) because Base64 encoding operates on full bytes.&nbsp; 
  If the truncation parameter is not specified then all the bits of the hash are output.
  Any signature with a truncation length that is less than half the output length of the underlying
  hash algorithm <em class="rfc2119" title="must">must</em> be deemed invalid.
  An example of an HMAC <code>SignatureMethod</code> element:</p>
  <pre class="xml-example">   &lt;SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"&gt;
      &lt;HMACOutputLength&gt;128&lt;/HMACOutputLength&gt;
   &lt;/SignatureMethod&gt;
</pre>

  <p>The output of the HMAC algorithm is ultimately the output (possibly 
  truncated) of the chosen digest algorithm. This value shall be base64 encoded 
  in the same straightforward fashion as the output of the digest algorithms. 
  Example: the <code>SignatureValue</code> element for the HMAC-SHA1 digest</p>
  <pre class="xml-example">   9294727A 3638BB1C 13F48EF8 158BFC9D
</pre>

  <p>from the test vectors in [<cite><a class="bibref" rel="biblioentry" href="#bib-HMAC">HMAC</a></cite>] would be</p>
  <pre class="xml-example">   &lt;SignatureValue&gt;kpRyejY4uxwT9I74FYv8nQ==&lt;/SignatureValue&gt;
</pre>
  <pre class="xml-dtd">   Schema Definition:

   &lt;simpleType name="HMACOutputLengthType"&gt;
     &lt;restriction base="integer"/&gt;
   &lt;/simpleType&gt;
</pre>
</div>
</div>
<div id="sec-SignatureAlg" class="section">
  <h3><span class="secno">6.4 </span>Signature Algorithms</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>

<div id="sec-DSA" class="section">
  <h4><span class="secno">6.4.1 </span>DSA</h4>

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

    <dd><a id="dsa-sha1" href="http://www.w3.org/2000/09/xmldsig#dsa-sha1">http://www.w3.org/2000/09/xmldsig#dsa-sha1</a></dd>
    <dd><a id="dsa-sha256" href="http://www.w3.org/2009/xmldsig11#dsa-sha256">http://www.w3.org/2009/xmldsig11#dsa-sha256</a></dd>
  </dl>

  <p>The DSA family of algorithms is defined in FIPS 186-3 [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>].&nbsp; 
  FIPS 186-3 defines DSA in terms of two security parameters L and N where L = 
  |p|, N = |q|, p is the prime modulus, q is a prime divisor of (p-1).&nbsp; 
  FIPS 186-3 defines four valid pairs of (L, N); they are: (1024, 160), (2048, 
  224), (2048, 256) and (3072, 256).&nbsp; The pair (1024, 160) corresponds to 
  the algorithm DSAwithSHA1, which is identified in this specification by the 
  URI 
  <a href="http://www.w3.org/2000/09/xmldsig#dsa-sha1">http://www.w3.org/2000/09/xmldsig#dsa-sha1</a>.&nbsp; The pairs (2048, 256) 
  and (3072, 256) correspond to the algorithm DSAwithSHA256, which is identified 
  in this specification by the URI
  <a href="http://www.w3.org/2009/xmldsig11#dsa-sha256">
  http://www.w3.org/2009/xmldsig11#dsa-sha256</a>.&nbsp; This specification does 
  not use the (2048, 224) instance of DSA (which corresponds to DSAwithSHA224).</p>
  <p>&nbsp;DSA takes no explicit 
  parameters; an example of a DSA
  <code>SignatureMethod</code> element is:</p>
  <pre class="xml-example">   <code>&lt;SignatureMethod Algorithm="http://www.w3.org/2009/xmldsig11#dsa-sha256"/&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/rfc3447.txt">RFC 3447</a>
  [<cite><a class="bibref" rel="biblioentry" href="#bib-PKCS1">PKCS1</a></cite>] specification with a <code>l</code> 
  parameter equal to 20. For example, the <code>SignatureValue</code>
  element for a DSA  
  signature (<code>r</code>,
  <code>s</code>) with values specified in hexadecimal:</p>
  <pre class="xml-example">   <code>r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0</code>
   <code>s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8</code>
</pre>

  <p>from the example in Appendix 5 of the DSS standard would be</p>
  <pre class="xml-example">   <code>&lt;SignatureValue&gt;</code>
   <code>i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==&lt;/SignatureValue&gt;</code>
</pre>

<h5 id="security-considerations-regarding-dsa-key-sizes">Security considerations regarding DSA key sizes</h5>

<p>
Per FIPS 186-3 [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>], the DSA security parameter L is 
defined to be 1024, 2048 or 3072 bits and the corresponding DSA q
value is defined to  
be 160, 224/256 and 256 bits respectively. Special Publication SP
800-57 Part 1 [<cite><a class="bibref" rel="biblioentry" href="#bib-SP800-57">SP800-57</a></cite>],  
NIST recommends using at least at 2048-bit public keys for securing information 
beyond 2010 (and 3072-bit keys for securing information beyond 2030).
</p>

<p>Since XML Signature 1.0 requires implementations to support
DSA-based digital  
signatures, this XML Signature 1.1 revision REQUIRES signature verifiers to 
implement DSA only for keys of 1024 bits in order to guarantee interoperability 
with XML Signature 1.0 generators. XML Signature 1.1 implementations <em class="rfc2119" title="may">may</em> but are 
<em class="rfc2119" title="not required">not required</em> to support DSA-based signature generation, and given the short key 
size and the SP800-57 guidelines, DSA with 1024-bit prime moduli <em class="rfc2119" title="should not">should not</em> be 
used for signatures that will be verified beyond 2010.
</p>
    </div>   

<div id="sec-PKCS1" class="section">
  <h4><span class="secno">6.4.2 </span>RSA (PKCS#1 v1.5)</h4>

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

    <dd><a id="rsa-sha1" href="http://www.w3.org/2000/09/xmldsig#rsa-sha1">http://www.w3.org/2000/09/xmldsig#rsa-sha1</a></dd>
    
    <dd><a id="rsa-sha256" href="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256">http://www.w3.org/2001/04/xmldsig-more#rsa-sha256</a></dd>
    
    <dd><a id="rsa-sha384" href="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384">http://www.w3.org/2001/04/xmldsig-more#rsa-sha384</a></dd>
    
    <dd><a id="rsa-sha512" href="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512">http://www.w3.org/2001/04/xmldsig-more#rsa-sha512</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/rfc3447.txt">RFC 3447</a>
  [<cite><a class="bibref" rel="biblioentry" href="#bib-PKCS1">PKCS1</a></cite>]. The RSA algorithm takes no 
  explicit parameters. An example of an RSA SignatureMethod element is:</p>
  <pre class="xml-example">   <code>&lt;SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/&gt;</code>
</pre>

  <p>The <code>SignatureValue</code> content for an RSA signature is the base64 
[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>] encoding of the octet string 
  computed as per <a href="http://www.ietf.org/rfc/rfc3447.txt">RFC 3447</a>
  [<cite><a class="bibref" rel="biblioentry" href="#bib-PKCS1">PKCS1</a></cite>], section 8.2.1: Signature 
  generation for the RSASSA-PKCS1-v1_5 signature scheme].
  Computation of the signature will require concatenation of the hash value and a constant string
  determined by RFC 3447. Signature computation and verification does not require implementation of an
  ASN.1 parser.</p>
  
  <!--
  
  As specified in the 
  EMSA-PKCS1-V1_5-ENCODE function <a href=
  "http://www.ietf.org/rfc/rfc3447.txt" >RFC 3447</a>
[[!PKCS1]], section 9.2.1], the value input 
  to the signature function MUST contain a pre-pended algorithm object 
  identifier for the hash function, but the availability of an ASN.1 parser and 
  recognition of OIDs is not required of a signature verifier. The PKCS#1 v1.5 
  representation appears as:</p>
  <pre class="xml-example">
   CRYPT (PAD (ASN.1 (OID, DIGEST (data))))
</pre>

  <p>Note that the padded ASN.1 will be of the following form:</p>
  <pre class="xml-example">
   01 | FF* | 00 | prefix | hash
</pre>

  <p>where "|" is concatenation, "01", "FF", and "00" are fixed octets of the 
  corresponding hexadecimal value, "hash" is the SHA1 digest of the data, and 
  "prefix" is the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 
  [RFC 3447], that is,</p>
  <pre class="xml-example">
   hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
</pre>

  <p>This prefix is included to make it easier to use standard cryptographic 
  libraries. The FF octet MUST be repeated the maximum number of times such that 
  the value of the quantity being CRYPTed is one octet shorter than the RSA 
  modulus.</p> -->

  <p>The resulting base64 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>]
string is the value of the child text node of the 
  SignatureValue element, e.g.</p>
  <pre class="xml-example">&lt;SignatureValue&gt;
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
&lt;/SignatureValue&gt;
</pre>
<h5 id="security-considerations-regarding-rsa-key-sizes">Security considerations regarding RSA key sizes</h5>

<p>In Special Publication SP 800-57 Part 1 [<cite><a class="bibref" rel="biblioentry" href="#bib-SP800-57">SP800-57</a></cite>], NIST recommends
  using at least 2048-bit public keys for securing information beyond
  2010 (and 3072-bit keys for securing information beyond 2030).  All
  conforming implementations 
of
  XML Signature 1.1 <em class="rfc2119" title="must">must</em> support RSA signature generation and
  verification with public 
  keys at least 2048 bits in length.  RSA public keys of 1024 bits or
  less <em class="rfc2119" title="should not">should not</em> be used for signatures that will be verified beyond
  2010.  XML Signature 1.1 implementations <em class="rfc2119" title="should">should</em> use at least 2048-bit
  keys for all signatures, and <em class="rfc2119" title="should">should</em> use at least 3072-bit keys for
  signatures that will be verified beyond 2030. 
</p>
</div>    

<div id="sec-ECDSA" class="section">
  <h4><span class="secno">6.4.3 </span>ECDSA</h4>
  <dl>
    <dt>Identifiers:</dt>
    <dd><a id="ecdsa-sha1" href="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1">http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1</a></dd>
    <dd><a id="ecdsa-sha256" href="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256">http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256</a></dd>
    <dd><a id="ecdsa-sha384" href="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384">http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384</a></dd>
    <dd><a id="ecdsa-sha512" href="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512">http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512</a></dd>
  </dl>
  <p>The ECDSA algorithm [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>] takes no explicit parameters. An example of a ECDSA 
  <code>SignatureMethod </code>element is:</p>
  <pre class="xml-example">      <code>
    &lt;SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/&gt;
  </code></pre>
  <p>The output of the ECDSA 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/rfc3447.txt">RFC 3447</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-PKCS1">PKCS1</a></cite>] specification with the <code>l</code> parameter equal to the size of the 
  base point order of the curve in bytes (e.g. 32 for the P-256 curve and 66 for 
  the P-521 curve). 
  </p>

  <p>This specification REQUIRES implementations to support the
  ECDSAwithSHA256 signature algorithm, which is ECDSA over the P-256
  prime curve specified in Section D.2.3 of FIPS 186-3 [<cite><a class="bibref" rel="biblioentry" href="#bib-FIPS-186-3">FIPS-186-3</a></cite>] (and using the SHA-256 hash
  algorithm).  It is further <em class="rfc2119" title="recommended">recommended</em> that implementations also
  support ECDSA over the P-384 and P-521 prime curves; these curves are
  defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively.
  </p>
    </div>   
    </div>
<div id="sec-c14nAlg" class="section">
  <h3><span class="secno">6.5 </span>Canonicalization Algorithms</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, [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-MEDIA-TYPES">XML-MEDIA-TYPES</a></cite>] 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
  [<cite><a class="bibref" rel="biblioentry" href="#bib-UTF-8">UTF-8</a></cite>]. The algorithms below understand at least [<cite><a class="bibref" rel="biblioentry" href="#bib-UTF-8">UTF-8</a></cite>] and
  [<cite><a class="bibref" rel="biblioentry" href="#bib-UTF-16">UTF-16</a></cite>] as input encodings. We RECOMMEND that externally specified  
  algorithms do the same. Knowledge of other encodings is <em class="rfc2119" title="optional">optional</em>.</p>

  <p>Various canonicalization algorithms transcode from a non-Unicode encoding 
  to Unicode.
The output of these algorithms will be in NFC
  [<cite><a class="bibref" rel="biblioentry" href="#bib-NFC">NFC</a></cite>].
 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 Note
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-Japanese">XML-Japanese</a></cite>].)</p> 

  <p>This specification REQUIRES implementation of Canonical XML 1.0
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>],  
  Canonical XML 1.1 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N11">XML-C14N11</a></cite>]] and Exclusive XML Canonicalization [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-EXC-C14N">XML-EXC-C14N</a></cite>].
  We RECOMMEND that applications that generate 
signatures choose Canonical XML 1.1 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N11">XML-C14N11</a></cite>] when inclusive canonicalization
  is desired.</p>

  <p><b>Note</b>: Canonical XML 1.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>] and Canonical XML 1.1 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N11">XML-C14N11</a></cite>] 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-EXC-C14N">XML-EXC-C14N</a></cite>] may be used to address requirements resulting from 
  scenarios where a subdocument is moved between contexts.</p>

<div id="sec-Canonical" class="section">
  <h4><span class="secno">6.5.1 </span>Canonical XML 1.0</h4>

  <dl>
    <dt>Identifier for <em class="rfc2119" title="required">required</em> Canonical XML 1.0 (omits comments):</dt>

    <dd><a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a></dd>
    <dt>Identifier for Canonical XML 1.0 with Comments:</dt>

    <dd><a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments">http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments</a></dd>
    <dt>Input:</dt><dd>octet-stream, node-set</dd>
    <dt>Output:</dt><dd>octet-stream</dd>
  </dl>

  <p>An example of an XML canonicalization element is:</p>
  <pre class="xml-example">   <code>&lt;CanonicalizationMethod Algorithm="</code>http://www.w3.org/TR/2001/REC-xml-c14n-20010315<code>"/&gt;</code>
</pre>

  <p>The normative specification of Canonical XML1.0 is [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>]. 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>
    </div>   
 
<div id="sec-Canonical11" class="section">
<h4><span class="secno">6.5.2 </span>Canonical XML 1.1</h4>

  <dl>
    <dt>Identifier for <em class="rfc2119" title="required">required</em> Canonical XML 1.1 (omits comments):</dt>

    <dd><a href="http://www.w3.org/2006/12/xml-c14n11">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">http://www.w3.org/2006/12/xml-c14n11#WithComments</a></dd>
    <dt>Input:</dt><dd>octet-stream, node-set</dd>
    <dt>Output:</dt><dd>octet-stream</dd>
  </dl>

  <p>The normative specification of Canonical XML 1.1 is [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N11">XML-C14N11</a></cite>]. 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>
    </div>   

<div id="sec-ExcC14N10" class="section">
  <h4><span class="secno">6.5.3 </span>Exclusive XML Canonicalization 1.0</h4>

  <dl>
    <dt>Identifier for Exclusive XML Canonicalization 1.0 (omits comments):</dt>

    <dd><a href="http://www.w3.org/2001/10/xml-exc-c14n#">http://www.w3.org/2001/10/xml-exc-c14n#</a></dd>

    <dt>Identifier for Exclusive XML Canonicalization 1.0 with Comments:</dt>
    <dd><a href="http://www.w3.org/2001/10/xml-exc-c14n#WithComments">
    http://www.w3.org/2001/10/xml-exc-c14n#WithComments</a></dd>
    <dt>Input:</dt><dd>octet-stream, node-set</dd>
    <dt>Output:</dt><dd>octet-stream</dd>
  </dl>

  <p>The normative specification of Exclusive XML Canonicalization 1.0 is [XML-EXC-C14N]].</p>
    </div>   
    </div>
<div id="sec-TransformAlg" class="section">
  <h3><span class="secno">6.6 </span><code>Transform</code> 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>For implementation requirements, please see <a href="#sec-AlgID">Algorithm Identifiers and
  Implementation Requirements</a>.  Application developers are strongly encouraged to support all
  transforms that are listed as <em class="rfc2119" title="recommended">recommended</em> 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> 
<div id="sec-Canonicalization" class="section">
  <h4><span class="secno">6.6.1 </span>Canonicalization</h4>

  <p>Any canonicalization algorithm that can be used for
  <code>CanonicalizationMethod</code> (such as those in&nbsp;
  <a href="#sec-c14nAlg">Canonicalization Algorithms</a> (section 
  6.5)) can be used as a
  <code>Transform</code>.</p>
    </div>   

<div id="sec-Base-64" class="section">
  <h4><span class="secno">6.6.2 </span>Base64</h4>

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

    <dd><a id="base64" href="http://www.w3.org/2000/09/xmldsig#base64">http://www.w3.org/2000/09/xmldsig#base64</a></dd>
    <dt>Input:</dt><dd>octet-stream, node-set</dd>
    <dt>Output:</dt><dd>octet-stream</dd>
  </dl>

  <p>The normative specification for base64 decoding transforms is [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2045">RFC2045</a></cite>]. 
  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 accepts either an octet-stream or a node-set as input.  If an octet-string is
  given as input, then this octet-stream is processed directly. 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>
  </div>   

<div id="sec-XPath" class="section">
  <h4><span class="secno">6.6.3 </span>XPath Filtering</h4>

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

    <dd><a href="http://www.w3.org/TR/1999/REC-xpath-19991116">http://www.w3.org/TR/1999/REC-xpath-19991116</a></dd>
    <dt>Input:</dt><dd>octet-stream, node-set</dd>
    <dt>Output:</dt><dd>node-set</dd>
  </dl>

  <p>The normative specification for XPath expression evaluation is [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>]. 
  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 or an octet-stream. 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 <em class="rfc2119" title="must">must</em> convert the octet stream 
  to an XPath node-set suitable for use by Canonical XML with Comments. (A 
  subsequent application of the <em class="rfc2119" title="required">required</em> 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 always 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
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-XPATH-FILTER2">XMLDSIG-XPATH-FILTER2</a></cite>] may be used for this purpose. That
  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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>] a function named <strong><a href="#function-here">here</a></strong>.</li>

    <li>A set of variable bindings. No means for initializing these is
        defined.  
        Thus, the set of variable bindings used when evaluating the
        XPath expression  
        is empty, and use of a variable reference in the XPath
        expression results in  
        an error.</li>

    <li>The set of namespace declarations in scope for the XPath
    expression.</li> 
  </ul>

  <p>As a result of the context node setting, the XPath expressions
  appearing in  
  this transform will be quite similar to those used in used in
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XSLT">XSLT</a></cite>],  
  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 id="function-here"><strong>Function:</strong> <em>node-set</em> 
  <strong>here</strong>()</a></p>

  <p>The <strong><a href="#function-here">here</a></strong> function returns a node-set containing the attribute 
  or processing instruction node or the parent element of the text node that 
  directly bears the XPath expression.&nbsp; This expression results in an error 
  if the containing XPath expression does not appear in the same XML document 
  against which the XPath expression is being evaluated.</p>

  <p>As an example, consider creating an enveloped signature (a
  <code>Signature</code> element that is a descendant of an element being 
  signed). Although the signed content should not be changed after signing, the 
  elements within the <code>Signature</code>
  element are changing (e.g. the digest value must be put inside the <code>
  DigestValue</code> and the <code>SignatureValue</code>
  must be subsequently calculated). One way to prevent these changes from 
  invalidating the digest value in
  <code>DigestValue</code> is to add an XPath
  <code>Transform</code> that omits all <code>Signature</code>
  elements and their descendants. For example,</p>
  <pre class="xml-example">   &lt;Document&gt;
   ...   
   &lt;Signature xmlns="http://www.w3.org/2000/09/xmldsig#"&gt;
     &lt;SignedInfo&gt;
      ...
       &lt;Reference URI=""&gt;
         &lt;Transforms&gt;
           &lt;Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"&gt;
             &lt;XPath xmlns:dsig="&amp;dsig;"&gt;
             not(ancestor-or-self::dsig:Signature)
             &lt;/XPath&gt;
           &lt;/Transform&gt;
         &lt;/Transforms&gt;
         &lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt;
         &lt;DigestValue&gt;&lt;/DigestValue&gt;
       &lt;/Reference&gt;
     &lt;/SignedInfo&gt;
     &lt;SignatureValue&gt;&lt;/SignatureValue&gt;
    &lt;/Signature&gt;
    ...
   &lt;/Document&gt;
</pre>

  <p>Due to the null <code>Reference</code> URI in this example, the XPath 
  transform input node-set contains all nodes in the entire parse tree starting 
  at the root node (except the comment nodes). For each node in this node-set, 
  the node is included in the output node-set except if the node or one of its 
  ancestors has a tag of <code>Signature</code> that is in the namespace given 
  by the replacement text for the entity
  <code>&amp;dsig;</code>.</p>

  <p>A more elegant solution uses the <strong><a href="#function-here">here</a></strong> function to omit only the <code>
  Signature</code> containing the XPath Transform, thus allowing enveloped 
  signatures to sign other signatures. In the example above, use the <code>XPath</code> 
  element:</p>
  <pre class="xml-example">   &lt;XPath xmlns:dsig="&amp;dsig;"&gt;
   count(ancestor-or-self::dsig:Signature |
   here()/ancestor::dsig:Signature[1]) &gt;
   count(ancestor-or-self::dsig:Signature)&lt;/XPath&gt;
</pre>

  <p>Since the XPath equality operator converts node sets to string values 
  before comparison, we must instead use the XPath union operator (|). For each 
  node of the document, the predicate expression is true if and only if the 
  node-set containing the node and its <code>Signature</code> element ancestors 
  does not include the enveloped <code>Signature</code> element containing the 
  XPath expression (the union does not produce a larger set if the enveloped <code>
  Signature</code> element is in the node-set given by <code>
  ancestor-or-self::Signature</code>).</p>
    </div>   
<div id="sec-EnvelopedSignature" class="section">
  <h4><span class="secno">6.6.4 </span>Enveloped Signature Transform</h4>

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

    <dd><a href="http://www.w3.org/2000/09/xmldsig#enveloped-signature" id="enveloped-signature">http://www.w3.org/2000/09/xmldsig#enveloped-signature</a></dd>
    <dt>Input:</dt><dd>node-set</dd>
    <dt>Output:</dt><dd>node-set</dd>
  </dl>

  <p>An enveloped signature transform <strong><em>T</em></strong>
  removes the whole <code>Signature</code> element containing
  <strong><em>T</em></strong> from the digest calculation of the
  <code>Reference</code> element containing
  <strong><em>T</em></strong>. The entire string of characters used by an XML 
  processor to match the <code>Signature</code> with the XML production <code>
  element</code> is removed. The output of the transform is equivalent to the 
  output that would result from replacing <strong><em>T</em></strong> with an 
  XPath transform containing the following <code>XPath</code> parameter element:</p>
  <pre class="xml-example">   &lt;XPath xmlns:dsig="&amp;dsig;"&gt;
   count(ancestor-or-self::dsig:Signature |
   here()/ancestor::dsig:Signature[1]) &gt;
   count(ancestor-or-self::dsig:Signature)&lt;/XPath&gt;
</pre>

  <p>The input and output requirements of this transform are identical to those 
  of the XPath transform, but may only be applied to a node-set from its parent 
  XML document. Note that it is not necessary to use an XPath expression 
  evaluator to create this transform. However, this transform <em class="rfc2119" title="must">must</em> produce 
  output in exactly the same manner as the XPath transform parameterized by the 
  XPath expression above.</p>
    </div>   
<div id="sec-XSLT" class="section">
  <h4><span class="secno">6.6.5 </span>XSLT Transform</h4>

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

    <dd><a href="http://www.w3.org/TR/1999/REC-xslt-19991116">http://www.w3.org/TR/1999/REC-xslt-19991116</a></dd>
    <dt>Input:</dt>
    <dd>octet-stream</dd>
    <dt>Output:</dt>
    <dd>octet-stream</dd>
  </dl>

  <p>The normative specification for XSL Transformations is [<cite><a class="bibref" rel="biblioentry" href="#bib-XSLT">XSLT</a></cite>]. 
  Specification of a namespace-qualified stylesheet element, which <em class="rfc2119" title="must">must</em> be the 
  sole child of the <code>Transform</code> element, indicates that the specified 
  style sheet should be used. Whether this instantiates in-line processing of 
  local XSLT declarations within the resource is determined by the XSLT 
  processing model; the ordered application of multiple stylesheet may require 
  multiple
  <code>Transforms</code>. No special provision is made for the identification 
  of a remote stylesheet at a given URI because it can be communicated via an <a href="http://www.w3.org/TR/1999/REC-xslt-19991116#section-Combining-Stylesheets"><code>xsl:include</code></a> or <a href="http://www.w3.org/TR/1999/REC-xslt-19991116#section-Combining-Stylesheets"><code>xsl:import</code></a> within the
  <code>stylesheet</code> child of the <code>Transform</code>.</p>

  <p>This transform requires an octet stream as input.</p>
  
  <!--  <p>If the actual input is an 
  XPath node-set, then the signature application should attempt to convert it to 
  octets (apply <a href=
  "#sec-Canonical" >Canonical XML</a>]) as described in
  <a href="#sec-ReferenceProcessingModel" >the Reference Processing 
  Model</a> (section 4.3.3.2).</p> -->

  <p>The output of this transform is an octet stream. The processing rules for 
  the XSL style sheet [<cite><a class="bibref" rel="biblioentry" href="#bib-XSL10">XSL10</a></cite>] or transform element are stated in the XSLT specification 
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XSLT">XSLT</a></cite>].</p>
  
  <p>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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XHTML10">XHTML10</a></cite>].</p> 
    </div>   
    </div>   
    </div>   

<div id="sec-XML-Canonicalization" class="section">
  <!--OddPage--><h2><span class="secno">7. </span>XML Canonicalization 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
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>],  
  as described in 7.1 below. There are those related to
  [<cite><a class="bibref" rel="biblioentry" href="#bib-DOM-LEVEL-1">DOM-LEVEL-1</a></cite>], 
  [<cite><a class="bibref" rel="biblioentry" href="#bib-SAX">SAX</a></cite>], 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;  
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>] compliant processors are required to support,  
  which is described in the paragraph immediately below. And, fourth, there are 
  changes that related to namespace declaration and XML namespace attribute 
  context as described in 7.3 below.</p>

  <p>Any canonicalization algorithm should yield output in a specific fixed 
  coded character set. All canonicalization <a href="#sec-c14nAlg">algorithms</a> identified in this document use 
  UTF-8 (without a byte order mark (BOM)) and do not provide character 
  normalization. We RECOMMEND that signature applications create XML
  content (<code>Signature</code>  
  elements and their descendants/content) in 
    Normalization Form C [<cite><a class="bibref" rel="biblioentry" href="#bib-NFC">NFC</a></cite>]
    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>

<div id="sec-XML-1" class="section">
  <h3><span class="secno">7.1 </span>XML 1.0 Syntax Constraints, and Canonicalization</h3> 

  <p>XML 1.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>]] defines an interface 
  where a conformant application reading XML is given certain information from 
  that XML and not other information. In particular,</p>

  <ol>
    <li>line endings are normalized to the single character #xA by dropping #xD 
        characters if they are immediately followed by a #xA and replacing them with 
        #xA in all other cases,</li>

    <li>missing attributes declared to have default values are provided to the 
        application as if present with the default value,&nbsp;</li>

    <li>character references are replaced with the corresponding character,</li>

    <li>entity references are replaced with the corresponding declared entity,</li>

    <li>attribute values are normalized by

      <ol>
        <li>replacing character and entity references as above,</li>

        <li>replacing occurrences of #x9, #xA, and #xD with #x20 (space) except 
                that the sequence #xD#xA is replaced by a single space, and</li>

        <li>if the attribute is not declared to be CDATA, stripping all leading 
                and trailing spaces and replacing all interior runs of spaces with a 
                single space.</li>
      </ol>
    </li>
  </ol>

  <p>Note that items (2), (4), and (5.3) depend on the presence of a schema, DTD 
  or similar declarations. The <code>Signature</code>
  element type is <a href="http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#cvc-elt-lax">laxly schema valid</a> 
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>][<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>], 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>
</div>

<div id="sec-DOM-SAX" class="section">
  <h3><span class="secno">7.2 </span>DOM/SAX Processing and Canonicalization</h3>

  <p>In addition to the canonicalization and syntax constraints discussed above, 
  many XML applications use the Document Object Model [<cite><a class="bibref" rel="biblioentry" href="#bib-DOM-LEVEL-1">DOM-LEVEL-1</a></cite>] 
  or the Simple API for XML&nbsp; [<cite><a class="bibref" rel="biblioentry" href="#bib-SAX">SAX</a></cite>]. 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>], 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
  XML 1.0 syntax constraints given in the <a href="#sec-XML-1" class="sectionRef">section 7.1 XML 1.0 Syntax Constraints, and Canonicalization</a>
be followed but 
  an appropriate XML canonicalization <em class="rfc2119" title="must">must</em> be specified so that the verifier can 
  re-serialize DOM/SAX mediated input into the same octet stream that was 
  signed.</p>
</div>

<div id="sec-NamespaceContext" class="section">
  <h3><span class="secno">7.3 </span>Namespace Context and Portable Signatures</h3>

  <p>In [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>] 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>." [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>]</p>
  </blockquote>

  <p>When serializing a <code>Signature</code> element or signed XML data that's 
  the child of other elements using these data models, that <code>Signature</code> 
  element and its children, may contain namespace declarations from its ancestor 
  context. In addition, the Canonical XML and Canonical XML with Comments 
  algorithms import all XML namespace attributes (such as
  <code>xml:lang</code>) from the nearest ancestor in which they are declared to 
  the apex node of canonicalized XML unless they are already declared at that 
  node. This may frustrate the intent of the signer to create a signature in one 
  context which remains valid in another. For example, given a signature which 
  is a child of <code>B</code> and a grandchild of <code>A</code>:</p>
  <pre class="xml-example">   &lt;A xmlns:n1="&amp;foo;"&gt;
     &lt;B xmlns:n2="&amp;bar;"&gt;
       &lt;Signature xmlns="&amp;dsig;"&gt;   ...
         &lt;Reference URI="#signme"/&gt; ...
       &lt;/Signature&gt;
       &lt;C ID="signme" xmlns="&amp;baz;"/&gt;
     &lt;/B&gt;
   &lt;/A&gt;
</pre>

  <p>when either the element <code>B</code> or the signed element
  <code>C</code> is moved into a [<cite><a class="bibref" rel="biblioentry" href="#bib-SOAP12-PART1">SOAP12-PART1</a></cite>] envelope for transport:</p>
  <pre class="xml-example">   &lt;SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"&gt;
     ...
     &lt;SOAP:Body&gt;
       &lt;B xmlns:n2="&amp;bar;"&gt;
         &lt;Signature xmlns="&amp;dsig;"&gt;
           ...
         &lt;/Signature&gt;
         &lt;C ID="signme" xmlns="&amp;baz;"/&gt;
       &lt;/B&gt;
     &lt;/SOAP:Body&gt;
   &lt;/SOAP:Envelope&gt;
</pre>

  <p>The canonical form of the signature in this context will contain new 
  namespace declarations from the
  <code>SOAP:Envelope</code> context, invalidating the signature. Also, the 
  canonical form will lack namespace declarations it may have originally had 
  from element <code>A</code>'s context, also invalidating the signature. To 
  avoid these problems, the application may:</p>

  <ol>
    <li>Rely upon the enveloping application to properly divorce its body (the 
        signature payload) from the context (the envelope) before the signature is 
        validated. Or,</li>

    <li>Use a canonicalization method that "repels/excludes" instead of 
        "attracts" ancestor context. [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>] purposefully attracts such 
        context.</li>
  </ol>
</div>
</div>
<div id="sec-Security" class="section">
  <!--OddPage--><h2><span class="secno">8. </span>Security Considerations</h2>

  <p>The XML Signature specification provides a very flexible digital signature 
  mechanism. Implementers must give consideration to their application threat 
  models and to the following factors. For additional security
  considerations in implementation and deployment of this
  specification, see
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-BESTPRACTICES">XMLDSIG-BESTPRACTICES</a></cite>]. </p>

<div id="sec-Security-Transforms" class="section">
  <h3><span class="secno">8.1 </span>Transforms</h3> 

  <p>A requirement of this specification is to permit signatures to "apply to&nbsp;a 
  part or totality of a XML document." (See 
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-REQUIREMENTS">XMLDSIG-REQUIREMENTS</a></cite>], 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XPATH">XPATH</a></cite>] to exclude those portions 
  the user needs to change. <code>Transforms</code> may be arbitrarily specified 
  and may include encoding transforms, canonicalization instructions or even 
  XSLT transformations. Three cautions are raised with respect to this feature 
  in the following sections.</p>

  <p>Note, <a class="link-def" href="#def-ValidationCore">core validation</a> behavior does not confirm that the signed data was 
  obtained by applying each step of the indicated transforms. (Though it does 
  check that the digest of the resulting content matches that specified in the 
  signature.)&nbsp; For example, some applications may be satisfied with 
  verifying an XML signature over a cached copy of already transformed data. 
  Other applications might require that content be freshly dereferenced and 
  transformed.</p>

<div id="sec-Secure" class="section">
  <h4><span class="secno">8.1.1 </span>Only What is Signed is Secure</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 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N">XML-C14N</a></cite>] 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) <em class="rfc2119" title="should not">should not</em> use internal entities and <em class="rfc2119" title="should">should</em> 
  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>
</div>

<div id="sec-Seen" class="section">
  <h4><span class="secno">8.1.2 </span>Only What is "Seen" Should be Signed</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>
</div>

<div id="sec-See" class="section">
  <h4><span class="secno">8.1.3 </span>"See" What is Signed</h4>

  <p>Just as a user should only sign what he or she "sees," persons and 
  automated mechanism that trust the validity of a transformed document on the 
  basis of a valid signature should operate over the data that was transformed 
  (including canonicalization) and signed, not the original pre-transformed 
  data. This recommendation applies to transforms specified within the signature 
  as well as those included as part of the document itself. For instance, if an 
  XML document includes an <a href="http://www.w3.org/TR/xslt#section-Creating-Processing-Instructions">embedded style sheet</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-XSLT">XSLT</a></cite>] 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 <em class="rfc2119" title="must">must</em> 
        be in [<cite><a class="bibref" rel="biblioentry" href="#bib-NFC">NFC</a></cite>] (otherwise intermediate processors might 
        unintentionally break the signature)</li>

    <li>Encoding normalizations <em class="rfc2119" title="should not">should not</em> be done as part of a signature 
        transform, or (to state it another way) if normalization does occur, the 
        application <em class="rfc2119" title="should">should</em> always "see" (operate over) the normalized form.</li>
  </ul>
</div>
</div>

<div id="sec-Check" class="section">
  <h3><span class="secno">8.2 </span>Check the Security Model</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>
</div>

<div id="sec-KeyLength" class="section">
  <h3><span class="secno">8.3 </span>Algorithms, Key Lengths, 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-RANDOM">RANDOM</a></cite>] 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>
</div>

<div id="sec-Errors" class="section">
  <h3><span class="secno">8.4 </span>Error Messages</h3> 
<p>
Implementations <em class="rfc2119" title="should not">should not</em> provide detailed error responses related to
security algorithm processing. Error messages should be limited to a
generic error message to avoid providing information to a potential
attacker related to the specifics of the algorithm implementation. For
example, if an error occurs in signature verification processing the error
response should be a generic message providing no
specifics on the details of the processing error.
</p>

</div>
</div>
<div id="sec-Schema" class="section">
  <!--OddPage--><h2><span class="secno">9. </span>Schema</h2>
<div id="sec-xsdSchema" class="section">
  <h3><span class="secno">9.1 </span>XSD Schema</h3>

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

    <dd><a href="http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core-schema.xsd">xmldsig-core-schema.xsd</a></dd>

    <dd>Valid XML schema instance based on 
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>][<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].</dd>
    
    <dt>XML Signature 1.1 Schema Instance</dt>
    <dd><a href="xmldsig11-schema.xsd">xmldsig11-schema.xsd</a></dd>
    <dd>This schema document defines the additional elements defined in this version of the XML
    Signature specification.</dd>
    <dt>XML Signature 1.1 Schema Driver</dt>
    <dd><a href="xmldsig1-schema.xsd">xmldsig1-schema.xsd</a></dd>
    <dd>This schema instance binds together the XML Signature Core Schema Instance and the XML
    Signature 1.1 Schema Instance</dd>
  </dl>
</div>
<div id="sec-rngSchema" class="informative section">
  <h3><span class="secno">9.2 </span>RNG Schema</h3><p><em>This section is non-normative.</em></p>
Non-normative RELAX NG schema [<cite><a class="bibref" rel="biblioentry" href="#bib-RELAXNG-SCHEMA">RELAXNG-SCHEMA</a></cite>] information is
  available in a separate document [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSEC-RELAXNG">XMLSEC-RELAXNG</a></cite>].
</div>
</div>

<div id="sec-Definitions" class="section">
  <!--OddPage--><h2><span class="secno">10. </span>Definitions</h2>

  <dl>
    <dt><a id="def-AuthenticationCode">Authentication Code</a>
    (<a id="def-ProtectedChecksum">Protected Checksum</a>)</dt>

    <dd>A value generated from the application of a shared key to a message via 
        a cryptographic algorithm such that it has the properties of <a href="#def-AuthenticationMessage" class="link-def">message authentication</a> (and
    <a href="#def-Integrity" class="link-def">integrity</a>) but not <a href="#def-AuthenticationSigner" class="link-def">signer authentication</a>. Equivalent to <em>protected checksum</em>, 
        "A checksum that is computed for a data object by means that protect against 
        active attacks that would attempt to change the checksum to make it match 
        changes made to the data object."&nbsp; [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4949">RFC4949</a></cite>]</dd>

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

    <dd>The property, given an <a href="#def-AuthenticationCode" class="link-def">authentication code</a>/<a href="#def-ProtectedChecksum" class="link-def">protected checksum</a>, that tampering with both the data and 
        checksum, so as to introduce changes while seemingly preserving <a href="#def-Integrity" class="link-def">integrity</a>, are still detected. "A signature should identify what 
        is signed, making it impracticable to falsify or alter either the signed 
        matter or the signature without detection." [<cite><a class="bibref" rel="biblioentry" href="#bib-ABA-DSIG-GUIDELINES">ABA-DSIG-GUIDELINES</a></cite>].</dd>

    <dt><a id="def-AuthenticationSigner">Authentication, Signer</a></dt>

    <dd>The property that the identity of the signer is as claimed. "A signature 
        should indicate who signed a document, message or record, and should be 
        difficult for another person to produce without
        authorization."  [<cite><a class="bibref" rel="biblioentry" href="#bib-ABA-DSIG-GUIDELINES">ABA-DSIG-GUIDELINES</a></cite>]
 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 id="def-Checksum">Checksum</a></dt>

    <dd>"A value that (a) is computed by a function that is dependent on the 
        contents of a data object and (b) is stored or transmitted together with the 
        object, for the purpose of detecting changes in the data."&nbsp; [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4949">RFC4949</a></cite>]</dd>

    <dt><a id="def-Core">Core</a></dt>

    <dd>The syntax and processing defined by this specification, including <a href="#def-ValidationCore" class="link-def">core validation</a>. We use this term to distinguish other markup, 
        processing, and applications semantics from our own.</dd>

    <dt><a id="def-DataObject">Data Object</a> (Content/Document)</dt>

    <dd>The actual binary/octet data being operated on (transformed, digested, 
        or signed) by an application -- frequently an <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7">HTTP entity</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-HTTP11">HTTP11</a></cite>]. Note that the proper
        noun <code>Object</code> 
    designates a specific XML element. Occasionally we refer to a data object as 
        a <em>document</em> or as a <em><a href="#def-Resource" class="link-def">resource</a>'s content</em>. 
        The term <em>element content</em> is used to describe the data between XML 
        start and end tags [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>]. The term <em>XML document</em> is used to 
        describe data objects which conform to the XML specification [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>].</dd>

    <dt><a id="def-Integrity">Integrity</a></dt>

    <dd>"The property that data has not been changed, destroyed, or lost in an 
        unauthorized or accidental manner." [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC4949">RFC4949</a></cite>] A simple <a href="#def-Checksum" class="link-def">checksum</a> can provide 
        integrity from incidental changes in the data; <a href="#def-AuthenticationMessage" class="link-def">message authentication</a> is similar but also protects against an 
        active attack to alter the data whereby a change in the checksum is 
        introduced so as to match the change in the data.&nbsp;</dd>

    <dt><a id="def-Object">Object</a></dt>

    <dd>An XML Signature element wherein arbitrary (non-<a href="#def-Core" class="link-def">core</a>) data may be placed. An <code>
        Object</code> element is merely one type of digital data (or document) that 
        can be signed via a
    <code>Reference</code>.</dd>

    <dt><a id="def-Resource">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." [<cite><a class="bibref" rel="biblioentry" href="#bib-URI">URI</a></cite>] 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">Signature</a></dt>

    <dd>Formally speaking, a value generated from the application of a private 
        key to a message via a cryptographic algorithm such that it has the 
        properties of <a href="#def-Integrity" class="link-def">integrity</a>, <a href="#def-AuthenticationMessage" class="link-def">message authentication</a> and/or <a href="#def-AuthenticationSigner" class="link-def">signer authentication</a>. (However, we sometimes use the term 
        signature generically such that it encompasses
    <a href="#def-AuthenticationCode" class="link-def">Authentication Code</a> values as well, but we are careful to make 
        the distinction when the property of <a href="#def-AuthenticationSigner" class="link-def">signer authentication</a> is relevant to the exposition.) A signature 
        may be (non-exclusively) described as
    <a href="#def-SignatureDetached" class="link-def">detached</a>, <a href="#def-SignatureEnveloping" class="link-def">enveloping</a>, or <a href="#def-SignatureEnveloped" class="link-def">enveloped</a>.</dd>

    <dt><a id="def-SignatureApplication">Signature, Application</a></dt>

    <dd>An application that implements the MANDATORY (<em class="rfc2119" title="required">required</em>/<em class="rfc2119" title="must">must</em>) 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">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">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">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">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">Validation, Core</a></dt>

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

    <dt><a id="def-ValidationReference">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">Validation, Signature</a></dt>

    <dd>The <code>SignatureValue</code> matches the result of processing <code>
        SignedInfo</code> with&nbsp;
    <code>CanonicalizationMethod</code> and
    <code>SignatureMethod</code> as specified in <a href="#sec-CoreValidation">Core Validation</a> (section 3.2).</dd>

    <dt><a id="def-ValidationTrustApplication">Validation, Trust/Application</a></dt>

    <dd>The application determines that the semantics associated with a 
        signature are valid. For example, an application may validate the time 
        stamps or the integrity of the signer key -- though this behavior is 
        external to this <a href="#def-ValidationCore" class="link-def">core</a>
    specification.</dd>
  </dl>
</div>


<div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">A. </span>References</h2><p>Dated references below are to the latest known or appropriate edition of the referenced work.  The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which  editions are supported.</p><div id="normative-references" class="section"><h3><span class="secno">A.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-ECC-ALGS">[ECC-ALGS]</dt><dd>D. McGrew, K. Igoe, M. Salter. <a href="http://www.rfc-editor.org/rfc/rfc6090.txt"><cite>RFC 6090: Fundamental Elliptic Curve Cryptography Algorithms</cite></a>, IETF Informational RFC,  February 2011, URL: <a href="http://www.rfc-editor.org/rfc/rfc6090.txt">http://www.rfc-editor.org/rfc/rfc6090.txt</a>
</dd><dt id="bib-FIPS-180-3">[FIPS-180-3]</dt><dd><a href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf"><cite>FIPS PUB 180-3 Secure Hash Standard</cite></a>.  U.S. Department of Commerce/National Institute of Standards and Technology. <a href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf"> http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf</a>
</dd><dt id="bib-FIPS-186-3">[FIPS-186-3]</dt><dd><a href="http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf"><cite>FIPS PUB 186-3:  Digital Signature Standard (DSS)</cite></a>. June 2009. U.S. Department of Commerce/National Institute of Standards and Technology. URL: <a href="http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf">http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf</a>
</dd><dt id="bib-HMAC">[HMAC]</dt><dd>H. Krawczyk, M. Bellare, R. Canetti. <a href="http://www.ietf.org/rfc/rfc2104.txt"><cite>HMAC: Keyed-Hashing for Message Authentication</cite></a>. February 1997. IETF RFC 2104.  URL: <a href="http://www.ietf.org/rfc/rfc2104.txt">http://www.ietf.org/rfc/rfc2104.txt</a>
</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd>R. Fielding; et al. <a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext Transfer Protocol - HTTP/1.1.</cite></a> June 1999. Internet RFC 2616. URL: <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a> 
</dd><dt id="bib-LDAP-DN">[LDAP-DN]</dt><dd>K. Zeilenga. <a href="http://www.ietf.org/rfc/rfc4514.txt"><cite>Lightweight Directory Access Protocol : String Representation of Distinguished Names</cite></a>. June 2006. IETF RFC 4514. URL: <a href="http://www.ietf.org/rfc/rfc4514.txt">http://www.ietf.org/rfc/rfc4514.txt</a>
</dd><dt id="bib-NFC">[NFC]</dt><dd>M. Davis, Ken Whistler. <a href="http://www.unicode.org/reports/tr15/"><cite>TR15, Unicode Normalization Forms.</cite></a>. 17 September 2010, URL: <a href="http://www.unicode.org/reports/tr15/">http://www.unicode.org/reports/tr15/</a>
</dd><dt id="bib-OCSP">[OCSP]</dt><dd>M. Myers, R. Ankney, A. Malpani, S. Galperin, <a href="http://www.ietf.org/rfc/rfc2560.txt"> <cite>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</cite> </a>.  C. Adams. IETF RFC 2560. June 1999. URL: <a href="http://www.ietf.org/rfc/rfc2560.txt">http://www.ietf.org/rfc/rfc2560.txt</a>
</dd><dt id="bib-PGP">[PGP]</dt><dd>J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer. <a href="http://www.ietf.org/rfc/rfc2440.txt"><cite>OpenPGP Message Format.</cite></a>. IETF RFC 4880. November 2007. URL: <a href="http://www.ietf.org/rfc/rfc4880.txt">http://www.ietf.org/rfc/rfc4880.txt</a>
</dd><dt id="bib-PKCS1">[PKCS1]</dt><dd>J. Jonsson and B. Kaliski. <a href="http://www.ietf.org/rfc/rfc3447.txt"><cite>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications  Version 2.1.</cite></a> RFC 3447 (Informational), February  2003. URL: <a href="http://www.ietf.org/rfc/rfc3447.txt">http://www.ietf.org/rfc/rfc3447.txt</a> 
</dd><dt id="bib-RFC2045">[RFC2045]</dt><dd>N. Freed and N. Borenstein. <a href="http://www.ietf.org/rfc/rfc2045.txt"><cite>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.</cite></a> November 1996. URL: <a href="http://www.ietf.org/rfc/rfc2045.txt">http://www.ietf.org/rfc/rfc2045.txt</a> 
</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119.  URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a> 
</dd><dt id="bib-RFC3279">[RFC3279]</dt><dd>W. Polk, R. Housley, L. Bassham. <a href="http://www.ietf.org/rfc/rfc3279.txt"><cite>Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</cite></a>. April 2002. Internet RFC 3279. URL: <a href="http://www.ietf.org/rfc/rfc3279.txt">http://www.ietf.org/rfc/rfc3279.txt</a>
</dd><dt id="bib-RFC3406">[RFC3406]</dt><dd>L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. <a href="http://www.ietf.org/rfc/rfc3406.txt"><cite> URN Namespace Definition Mechanisms.</cite></a>. IETF RFC 3406 October 2002. URL: <a href="http://www.ietf.org/rfc/rfc3406.txt"> http://www.ietf.org/rfc/rfc3406.txt</a>
</dd><dt id="bib-RFC4051">[RFC4051]</dt><dd>D. Eastlake 3rd. <a href="http://www.ietf.org/rfc/rfc4051.txt"><cite>Additional XML Security Uniform Resource Identifiers</cite></a>. RFC 4051 April 2005. URL: <a href="http://www.ietf.org/rfc/rfc4051.txt">http://www.ietf.org/rfc/rfc4051.txt</a>
</dd><dt id="bib-RFC4055">[RFC4055]</dt><dd>J. Schaad, B. Kaliski, R. Housley. <a href="http://www.ietf.org/rfc/rfc4055.txt"><cite>Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</cite></a>.  June 2005. IETF RFC 4055. <a href="http://www.ietf.org/rfc/rfc4055.txt">http://www.ietf.org/rfc/rfc4055.txt
</a></dd><dt id="bib-RFC5280">[RFC5280]</dt><dd>D. Cooper, et. al. <a href="http://www.ietf.org/rfc/rfc5280.txt"><cite> Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. </cite></a>. IETF RFC 5280 May 2008. URL: <a href="http://www.ietf.org/rfc/rfc5280.txt">http://www.ietf.org/rfc/rfc5280.txt</a>
</dd><dt id="bib-RFC5480">[RFC5480]</dt><dd>S. Turner, et. al. <a href="http://www.ietf.org/rfc/rfc5480.txt"><cite> Elliptic Curve Cryptography Subject Public Key Information.</cite></a>. IETF RFC 5480 March 2009. URL: <a href="http://www.ietf.org/rfc/rfc5480.txt">http://www.ietf.org/rfc/rfc5480.txt</a>
</dd><dt id="bib-SP800-57">[SP800-57]</dt><dd><a href="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf"><cite> Recommendation for Key Management – Part 1: General (Revised).</cite></a> SP800-57. U.S. Department of Commerce/National Institute of Standards and Technology. URL: <a href="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf"> http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf</a>
</dd><dt id="bib-URI">[URI]</dt><dd>T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifiers (URI): generic syntax.</cite></a> January 2005. Internet RFC 3986. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a> 
</dd><dt id="bib-URN">[URN]</dt><dd>R. Moats. <a href="http://www.ietf.org/rfc/rfc2141.txt"><cite>URN Syntax.</cite></a> IETF RFC 2141. May 1997.  URL: <a href="http://www.ietf.org/rfc/rfc2141.txt">http://www.ietf.org/rfc/rfc2141.txt</a>
</dd><dt id="bib-URN-OID">[URN-OID]</dt><dd>M. Mealling. <a href="http://www.ietf.org/rfc/rfc3061.txt"><cite>A URN Namespace of Object Identifiers. </cite></a>. IETF RFC 3061. February 2001. URL: <a href="http://www.ietf.org/rfc/rfc3061.txt">http://www.ietf.org/rfc/rfc3061.txt</a>
</dd><dt id="bib-UTF-8">[UTF-8]</dt><dd>F. Yergeau. <a href="http://www.ietf.org/rfc/rfc3629.txt"><cite>UTF-8, a transformation format of ISO 10646</cite></a>. IETF RFC 3629. November 2003. URL: <a href="http://www.ietf.org/rfc/rfc3629.txt">http://www.ietf.org/rfc/rfc3629.txt</a>
</dd><dt id="bib-X509V3">[X509V3]</dt><dd><cite>ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework"&nbsp; ISO/IEC 9594-8:1997</cite>.
</dd><dt id="bib-XML-C14N">[XML-C14N]</dt><dd>John Boyer. <a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"><cite>Canonical XML Version 1.0.</cite></a> 15 March 2001. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a> 
</dd><dt id="bib-XML-C14N11">[XML-C14N11]</dt><dd>John Boyer, Glenn Marcy. <a href="http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/"><cite>Canonical XML Version 1.1.</cite></a> 2 May 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/">http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/</a> 
</dd><dt id="bib-XML-EXC-C14N">[XML-EXC-C14N]</dt><dd>Donald E. Eastlake 3rd; Joseph Reagle; John Boyer. <a href="http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/"><cite>Exclusive XML Canonicalization Version 1.0.</cite></a> 18 July 2002. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/">http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/</a> 
</dd><dt id="bib-XML-MEDIA-TYPES">[XML-MEDIA-TYPES]</dt><dd>Ümit Yalçınalp; Anish Karmarkar. <a href="http://www.w3.org/TR/2005/NOTE-xml-media-types-20050504/"><cite>Describing Media Content of Binary Data in XML.</cite></a> 4 May 2005. W3C Note. URL: <a href="http://www.w3.org/TR/2005/NOTE-xml-media-types-20050504/">http://www.w3.org/TR/2005/NOTE-xml-media-types-20050504/</a> 
</dd><dt id="bib-XML-NAMES">[XML-NAMES]</dt><dd>Richard Tobin; et al. <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/"><cite>Namespaces in XML 1.0 (Third Edition).</cite></a> 8 December 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/">http://www.w3.org/TR/2009/REC-xml-names-20091208/</a> 
</dd><dt id="bib-XML10">[XML10]</dt><dd>C. M. Sperberg-McQueen; et al. <a href="http://www.w3.org/TR/2008/REC-xml-20081126/"><cite>Extensible Markup Language (XML) 1.0 (Fifth Edition).</cite></a> 26 November 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2008/REC-xml-20081126/">http://www.w3.org/TR/2008/REC-xml-20081126/</a> 
</dd><dt id="bib-XMLDSIG-XPATH-FILTER2">[XMLDSIG-XPATH-FILTER2]</dt><dd>Merlin Hughes; John Boyer; Joseph Reagle. <a href="http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/"><cite>XML-Signature XPath Filter 2.0.</cite></a> 8 November 2002. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/">http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/</a> 
</dd><dt id="bib-XMLENC-CORE1">[XMLENC-CORE1]</dt><dd>J. Reagle; D. Eastlake, F. Hirsch, T. Roessler <a href="http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303/"><cite>XML Encryption Syntax and Processing Version 1.1.</cite></a> 3 March 2011. W3C Candidate Recommendation. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303/">http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303/</a> 
</dd><dt id="bib-XMLSCHEMA-1">[XMLSCHEMA-1]</dt><dd>Henry S. Thompson; et al. <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>XML Schema Part 1: Structures Second Edition.</cite></a> 28 October 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/</a> 
</dd><dt id="bib-XMLSCHEMA-2">[XMLSCHEMA-2]</dt><dd>Paul V. Biron; Ashok Malhotra. <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2: Datatypes Second Edition.</cite></a> 28 October 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/</a> 
</dd><dt id="bib-XPATH">[XPATH]</dt><dd>James Clark; Steven DeRose. <a href="http://www.w3.org/TR/1999/REC-xpath-19991116/"><cite>XML Path Language (XPath) Version 1.0.</cite></a> 16 November 1999. W3C Recommendation. URL: <a href="http://www.w3.org/TR/1999/REC-xpath-19991116/">http://www.w3.org/TR/1999/REC-xpath-19991116/</a> 
</dd><dt id="bib-XPTR-ELEMENT">[XPTR-ELEMENT]</dt><dd>Norman Walsh; et al. <a href="http://www.w3.org/TR/2003/REC-xptr-element-20030325/"><cite>XPointer element() Scheme.</cite></a> 25 March 2003. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2003/REC-xptr-element-20030325/">http://www.w3.org/TR/2003/REC-xptr-element-20030325/</a> 
</dd><dt id="bib-XPTR-FRAMEWORK">[XPTR-FRAMEWORK]</dt><dd>Paul Grosso; et al. <a href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/"><cite>XPointer Framework.</cite></a> 25 March 2003. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/">http://www.w3.org/TR/2003/REC-xptr-framework-20030325/</a> 
</dd><dt id="bib-XSL10">[XSL10]</dt><dd>Jeremy Richman; et al. <a href="http://www.w3.org/TR/2001/REC-xsl-20011015/"><cite>Extensible Stylesheet Language (XSL) Version 1.0.</cite></a> 15 October 2001. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2001/REC-xsl-20011015/">http://www.w3.org/TR/2001/REC-xsl-20011015/</a> 
</dd><dt id="bib-XSLT">[XSLT]</dt><dd>James Clark. <a href="http://www.w3.org/TR/1999/REC-xslt-19991116"><cite>XSL Transformations (XSLT) Version 1.0.</cite></a> 16 November 1999. W3C Recommendation. URL: <a href="http://www.w3.org/TR/1999/REC-xslt-19991116">http://www.w3.org/TR/1999/REC-xslt-19991116</a> 
</dd></dl></div><div id="informative-references" class="section"><h3><span class="secno">A.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-ABA-DSIG-GUIDELINES">[ABA-DSIG-GUIDELINES]</dt><dd><a href="http://www.abanet.org/scitech/ec/isc/dsgfree.html"><cite>Digital Signature Guidelines.</cite></a> URL: <a href="http://www.abanet.org/scitech/ec/isc/dsgfree.html">http://www.abanet.org/scitech/ec/isc/dsgfree.html</a>
</dd><dt id="bib-CVE-2009-0217">[CVE-2009-0217]</dt><dd><a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0217"><cite>Common Vulnerabilities and Exposures List, CVE-2009-0217</cite></a> URL: <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0217"> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0217</a>
</dd><dt id="bib-DOM-LEVEL-1">[DOM-LEVEL-1]</dt><dd>Vidur Apparao; et al. <a href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/"><cite>Document Object Model (DOM) Level 1.</cite></a> 1 October 1998. W3C Recommendation. URL: <a href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/">http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/</a> 
</dd><dt id="bib-IEEE1363">[IEEE1363]</dt><dd><a href="http://grouper.ieee.org/groups/1363/"><cite>IEEE 1363: Standard Specifications for Public Key Cryptography</cite></a>. August 2000.  URL: <a href="http://grouper.ieee.org/groups/1363/">http://grouper.ieee.org/groups/1363/</a>
</dd><dt id="bib-RANDOM">[RANDOM]</dt><dd>D.  Eastlake, S. Crocker, J. Schiller. <a href="http://www.ietf.org/rfc/rfc4086.txt"><cite>Randomness Recommendations for Security.</cite></a>. IETF RFC 4086. June 2005. URL: <a href="http://www.ietf.org/rfc/rfc4086.txt">http://www.ietf.org/rfc/rfc4086.txt</a>
</dd><dt id="bib-RDF-PRIMER">[RDF-PRIMER]</dt><dd>Frank Manola; Eric Miller. <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/"><cite>RDF Primer.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/</a> 
</dd><dt id="bib-RELAXNG-SCHEMA">[RELAXNG-SCHEMA]</dt><dd><a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip"><cite>Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG</cite></a>. ISO/IEC 19757-2:2008. URI: <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip</a>
</dd><dt id="bib-RFC4050">[RFC4050]</dt><dd>S. Blake-Wilson, G. Karlinger, T. Kobayashi, Y. Wang.     <a href="http://www.ietf.org/rfc/rfc4050.txt"><cite>Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures.</cite></a> IETF RFC 4050. April 2005. URL: <a href="http://www.ietf.org/rfc/rfc4050.txt">http://www.ietf.org/rfc/rfc4050.txt</a>
</dd><dt id="bib-RFC4949">[RFC4949]</dt><dd>R. Shirey. <a href="http://www.ietf.org/rfc/rfc4949.txt"><cite>Internet Security Glossary, Version 2.</cite></a>. IETF RFC 4949. August 2007. URL: <a href="http://www.ietf.org/rfc/rfc4949.txt">http://www.ietf.org/rfc/rfc4949.txt</a>
</dd><dt id="bib-SAX">[SAX]</dt><dd>D. Megginson, et al. <a href="http://www.megginson.com/downloads/SAX/"><cite>SAX: The Simple API for XML</cite></a>. May 1998. URL: <a href="http://www.megginson.com/downloads/SAX/"> http://www.megginson.com/downloads/SAX/</a>
</dd><dt id="bib-SHA-1-Analysis">[SHA-1-Analysis]</dt><dd>McDonald, C., Hawkes, P., and J. Pieprzyk. <a href="http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf"><cite>SHA-1 collisions now 2<sup>52</sup> </cite></a>, EuroCrypt 2009 Rump session. URL: <a href="http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf">http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf</a>
</dd><dt id="bib-SHA-1-Collisions">[SHA-1-Collisions]</dt><dd>X. Wang, Y.L. Yin, H. Yu. <a href="http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf"><cite>Finding Collisions in the Full SHA-1</cite></a>. In Shoup, V., editor, Advances in Cryptology - CRYPTO 2005, 25th Annual International Cryptology Conference, Santa Barbara, California, USA, August 14-18, 2005, Proceedings, volume 3621 of LNCS, pages 17–36. Springer, 2005. URL: <a href="http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf">http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf</a> (also published in <a href="http://www.springerlink.com/content/26vljj3xhc28ux5m/">http://www.springerlink.com/content/26vljj3xhc28ux5m/</a>)
</dd><dt id="bib-SOAP12-PART1">[SOAP12-PART1]</dt><dd>Noah Mendelsohn; et al. <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/"><cite>SOAP Version 1.2 Part 1: Messaging Framework (Second Edition).</cite></a> 27 April 2007. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/">http://www.w3.org/TR/2007/REC-soap12-part1-20070427/</a> 
</dd><dt id="bib-UTF-16">[UTF-16]</dt><dd>P. Hoffman , F. Yergeau. <a href="http://www.ietf.org/rfc/rfc2781.txt"><cite>UTF-16, an encoding of ISO 10646.</cite></a> IETF RFC 2781. February 2000.    URL: <a href="http://www.ietf.org/rfc/rfc2781.txt">http://www.ietf.org/rfc/rfc2781.txt</a>
</dd><dt id="bib-XHTML10">[XHTML10]</dt><dd>Steven Pemberton. <a href="http://www.w3.org/TR/2002/REC-xhtml1-20020801/"><cite>XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition).</cite></a> 1 August 2002. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2002/REC-xhtml1-20020801/">http://www.w3.org/TR/2002/REC-xhtml1-20020801/</a> 
</dd><dt id="bib-XML-Japanese">[XML-Japanese]</dt><dd>M. Murata. <a href="http://www.w3.org/Submission/2005/SUBM-japanese-xml-20050324/">XML Japanese Profile (2nd Edition)</a>. W3C Member Submission. March 2005 URL: <a href="http://www.w3.org/Submission/2005/SUBM-japanese-xml-20050324/"> http://www.w3.org/Submission/2005/SUBM-japanese-xml-20050324/</a>
</dd><dt id="bib-XMLDSIG-BESTPRACTICES">[XMLDSIG-BESTPRACTICES]</dt><dd>Pratik Datta; Frederick Hirsch. <a href="http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100204/"><cite>XML Signature Best Practices.</cite></a> 4 February 2010. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100204/">http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100204/</a> 
</dd><dt id="bib-XMLDSIG-CORE">[XMLDSIG-CORE]</dt><dd>Joseph Reagle; et al. <a href="http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/"><cite>XML Signature Syntax and Processing (Second Edition).</cite></a> 10 June 2008. W3C Recommendation. URL: <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 id="bib-XMLDSIG-REQUIREMENTS">[XMLDSIG-REQUIREMENTS]</dt><dd>Joseph Reagle Jr. <a href="http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014"><cite>XML-Signature Requirements.</cite></a> 14 October 1999. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014">http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014</a> 
</dd><dt id="bib-XMLSEC-RELAXNG">[XMLSEC-RELAXNG]</dt><dd>Makoto Murata, Frederick Hirsch. <a href="http://www.w3.org/TR/2011/WD-xmlsec-rngschema-20110303/"><cite>XML Security RELAX NG Schemas.</cite></a> 3 March 2011. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/WD-xmlsec-rngschema-20110303/">http://www.w3.org/TR/2011/WD-xmlsec-rngschema-20110303/</a>
</dd><dt id="bib-XMLSEC11-REQS">[XMLSEC11-REQS]</dt><dd>Frederick Hirsch, Thomas Roessler. <a href="http://www.w3.org/TR/2011/WD-xmlsec-reqs-20110303/"><cite>XML Security 1.1 Requirements and Design Considerations.</cite></a> 3 March 2011. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/WD-xmlsec-reqs-20110303/">http://www.w3.org/TR/2011/WD-xmlsec-reqs-20110303/</a> 
</dd><dt id="bib-XPTR-XMLNS">[XPTR-XMLNS]</dt><dd>Jonathan Marsh; et al. <a href="http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/"><cite>XPointer xmlns() Scheme.</cite></a> 25 March 2003. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/">http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/</a> 
</dd><dt id="bib-XPTR-XPOINTER">[XPTR-XPOINTER]</dt><dd>Ron Daniel Jr.; Eve Maler; Steven DeRose. <a href="http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/"><cite>XPointer xpointer() Scheme.</cite></a> 19 December 2002. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/">http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/</a> 
</dd><dt id="bib-XPTR-XPOINTER-CR2001">[XPTR-XPOINTER-CR2001]</dt><dd>Ron Daniel Jr.; Eve Maler; Steven DeRose. <a href="http://www.w3.org/TR/2001/CR-xptr-20010911/"><cite>XPointer xpointer() Scheme.</cite></a> September 2001. W3C Candidate Recommendation. (Work in progress.) URL: <a href="http://www.w3.org/TR/2001/CR-xptr-20010911/">http://www.w3.org/TR/2001/CR-xptr-20010911/</a> 
</dd></dl></div></div></body></html>