discontinued / server · Files

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

<p>At the time of this publication, the XML Security WG is also
producing "XML Signature Version 1.1". The most recent XML Signature
Recommendation is the <a href="http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/">10 
June 2008 XML Signature (Second Edition) Recommendation</a>.</p>

<p>An updated version of
Canonical XML [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>] is published as a companion document.</p>

<p>A <a href="Overview-pub-diff.html">diff-marked version</a> of this 
 specification that highlights changes against  the <a href="http://www.w3.org/TR/2010/WD-xmldsig-core2-20100831/">previous
    version</a> is available. Major changes in this version:</p>

    <ul>
      <li>Restructured document, consolidating compatibility mode
      material in appendix.</li>

      <li> Added conformance sections.</li>

      <li>Added new section on 2.0 Transform.</li>

      <li>Added detail related to Canonical XML 2.0  [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>].</li>

      <li>Substantial revisions related to referencing and verifying
      content. Revised and clarified selection process. Clarified use
      of 
      <code>ds:Reference</code> 
      <code>URI</code> attribute. Removed <code>EnvelopedSignature</code>
      parameter 
      from XML selection. Revised schema and discussion related to 
      <code>dsig2:Verifications</code> element.
      </li> 

      <li>Added clarifications related to the use of id references versus
      XPath.</li> 

      <li>Note that  xml:space, etc is no longer required in c14n
      interface.</li> 

      <li>Added examples specific to 2.0.</li>

      <li>Added clarifications for compatibility processing.</li>

      <li>Incorporated <code>X509Data</code> element into 2.0 schema
      and document.</li> 
      
      <li>Incorporated change from 1.1 to clarify use of base64 both for
      encoding and as a compatibility  mode transform.</li>

      <li>Updated references and other editorial changes including
      formatting, spelling and validation updates.</li> 
    </ul>
<p>This document was published by the <a href="http://www.w3.org/2008/xmlsec/">XML Security Working Group</a> as a Last Call Working Draft. 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>). The Last Call period ends 31 May 2011. All feedback is welcome.</p><p>Publication as a Working Draft 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 is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.</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-20-modes" class="tocxref"><span class="secno">1.1 </span>XML Signature 2.0 and 1.x compatibility</a></li><li class="tocline"><a href="#sec-Editorial" class="tocxref"><span class="secno">1.2 </span>Editorial and Conformance Conventions</a></li><li class="tocline"><a href="#sec-Design" class="tocxref"><span class="secno">1.3 </span>Design Philosophy</a></li><li class="tocline"><a href="#sec-Versions" class="tocxref"><span class="secno">1.4 </span>Versions Namespaces and Identifiers</a></li><li class="tocline"><a href="#sec-Acknowledgements" class="tocxref"><span class="secno">1.5 </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-2.0" class="tocxref"><span class="secno">2.1 </span>Simple XML Signature 2.0 Example</a></li><li class="tocline"><a href="#sec-DetailedIdExample-2.0" class="tocxref"><span class="secno">2.2 </span>Detailed XML Signature 2.0 Example Using Ids</a></li><li class="tocline"><a href="#sec-DetailedXPathExample-2.0" class="tocxref"><span class="secno">2.3 </span>Detailed XML Signature 2.0 Example using XPath</a></li></ul></li><li class="tocline"><a href="#sec-Conformance" class="tocxref"><span class="secno">3. </span>Conformance</a><ul class="toc"><li class="tocline"><a href="#sec-Common-Conformance" class="tocxref"><span class="secno">3.1 </span>Common Conformance Requirements</a><ul class="toc"><li class="tocline"><a href="#sec-Algorithm-All-Mode-Conformance" class="tocxref"><span class="secno">3.1.1 </span>General Algorithm Identifier and Implementation Requirements</a></li></ul></li><li class="tocline"><a href="#sec-2-0-Conformance" class="tocxref"><span class="secno">3.2 </span>XML Signature 2.0 Conformance</a><ul class="toc"><li class="tocline"><a href="#sec-Algorithm-2-0-Mode-Conformance" class="tocxref"><span class="secno">3.2.1 </span>XML Signature 2.0 Algorithm Identifiers and Implementation Requirements</a></li></ul></li><li class="tocline"><a href="#sec-Compatibility-Mode-Conformance" class="tocxref"><span class="secno">3.3 </span>Compatibility Mode  Conformance</a><ul class="toc"><li class="tocline"><a href="#sec-Algorithm-Compatibility-Mode-Conformance" class="tocxref"><span class="secno">3.3.1 </span>Compatibility Mode Algorithm Identifiers and Implementation Requirements</a></li></ul></li></ul></li><li class="tocline"><a href="#sec-Processing" class="tocxref"><span class="secno">4. </span>Processing Rules</a><ul class="toc"><li class="tocline"><a href="#sec-SignatureGeneration" class="tocxref"><span class="secno">4.1 </span>Signature Generation</a></li><li class="tocline"><a href="#sec-ReferenceGeneration-2.0" class="tocxref"><span class="secno">4.2 </span>Reference Generation</a></li><li class="tocline"><a href="#sec-CoreValidation" class="tocxref"><span class="secno">4.3 </span>Core Validation</a></li><li class="tocline"><a href="#sec-ReferenceCheck-2.0" class="tocxref"><span class="secno">4.4 </span>Reference Check</a></li><li class="tocline"><a href="#sec-ReferenceValidation-2.0" class="tocxref"><span class="secno">4.5 </span>Reference Validation</a></li><li class="tocline"><a href="#sec-SignatureValidation-20" class="tocxref"><span class="secno">4.6 </span>Signature Validation</a></li></ul></li><li class="tocline"><a href="#sec-CoreSyntax" class="tocxref"><span class="secno">5. </span>Core Signature Syntax</a><ul class="toc"><li class="tocline"><a href="#sec-CryptoBinary" class="tocxref"><span class="secno">5.1 </span>The <code>ds:CryptoBinary</code> Simple Type</a></li><li class="tocline"><a href="#sec-Signature" class="tocxref"><span class="secno">5.2 </span>The <code>Signature</code> element</a></li><li class="tocline"><a href="#sec-SignatureValue" class="tocxref"><span class="secno">5.3 </span>The <code>SignatureValue</code> Element</a></li><li class="tocline"><a href="#sec-SignedInfo" class="tocxref"><span class="secno">5.4 </span>The <code>SignedInfo</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-CanonicalizationMethod" class="tocxref"><span class="secno">5.4.1 </span>The <code>CanonicalizationMethod</code> Element</a></li><li class="tocline"><a href="#sec-SignatureMethod" class="tocxref"><span class="secno">5.4.2 </span>The <code>SignatureMethod</code> Element</a></li><li class="tocline"><a href="#sec-DigestMethod" class="tocxref"><span class="secno">5.4.3 </span>The <code>DigestMethod</code> Element</a></li><li class="tocline"><a href="#sec-DigestValue" class="tocxref"><span class="secno">5.4.4 </span>The <code>DigestValue</code> Element</a></li></ul></li></ul></li><li class="tocline"><a href="#sec-ReferenceProcessing" class="tocxref"><span class="secno">6. </span>Referencing Content</a><ul class="toc"><li class="tocline"><a href="#sec-Reference" class="tocxref"><span class="secno">6.1 </span>The <code>Reference</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-URI-20" class="tocxref"><span class="secno">6.1.1 </span>The <code>URI</code> Attribute</a></li></ul></li><li class="tocline"><a href="#sec-Transforms" class="tocxref"><span class="secno">6.2 </span>The  <code>Transforms</code> Element</a></li><li class="tocline"><a href="#sec-Selection" class="tocxref"><span class="secno">6.3 </span>The <code>dsig2:Selection</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-subtrees-with-exclusions" class="tocxref"><span class="secno">6.3.1 </span>Subtrees with Optional Exclusions</a></li></ul></li><li class="tocline"><a href="#sec-Verifications" class="tocxref"><span class="secno">6.4 </span>The <code>dsig2:Verifications</code> Element</a></li></ul></li><li class="tocline"><a href="#sec-KeyInfo" class="tocxref"><span class="secno">7. </span>The <code>KeyInfo</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-KeyName" class="tocxref"><span class="secno">7.1 </span>The <code>KeyName</code> Element</a></li><li class="tocline"><a href="#sec-KeyValue" class="tocxref"><span class="secno">7.2 </span>The <code>KeyValue</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-DSAKeyValue" class="tocxref"><span class="secno">7.2.1 </span>The <code>DSAKeyValue</code> Element</a></li><li class="tocline"><a href="#sec-RSAKeyValue" class="tocxref"><span class="secno">7.2.2 </span>The <code>RSAKeyValue</code> Element</a></li><li class="tocline"><a href="#sec-ECKeyValue" class="tocxref"><span class="secno">7.2.3 </span>The <code>dsig11:ECKeyValue</code> Element</a><ul class="toc"><li class="tocline"><a href="#sec-ECParameters" class="tocxref"><span class="secno">7.2.3.1 </span>Explicit Curve Parameters </a></li><li class="tocline"><a href="#sec-RFC4050Compat" class="tocxref"><span class="secno">7.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">7.3 </span>The <code>RetrievalMethod</code> Element</a></li><li class="tocline"><a href="#sec-X509Data" class="tocxref"><span class="secno">7.4 </span>The <code>X509Data</code> Element</a><ul class="toc"><li class="tocline"><a href="#dname-encrules" class="tocxref"><span class="secno">7.4.1 </span>Distinguished Name Encoding Rules</a></li></ul></li><li class="tocline"><a href="#sec-PGPData" class="tocxref"><span class="secno">7.5 </span>The <code>PGPData</code> Element</a></li><li class="tocline"><a href="#sec-SPKIData" class="tocxref"><span class="secno">7.6 </span>The <code>SPKIData</code> Element</a></li><li class="tocline"><a href="#sec-MgmtData" class="tocxref"><span class="secno">7.7 </span>The <code>MgmtData</code> Element</a></li><li class="tocline"><a href="#sec-keyconvenance" class="tocxref"><span class="secno">7.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">7.9 </span>The <code>dsig11:DEREncodedKeyValue</code> Element</a></li><li class="tocline"><a href="#sec-KeyInfoReference" class="tocxref"><span class="secno">7.10 </span>The <code>dsig11:KeyInfoReference</code> Element</a></li></ul></li><li class="tocline"><a href="#sec-Object" class="tocxref"><span class="secno">8. </span>The <code>Object</code> Element</a></li><li class="tocline"><a href="#sec-AdditionalSyntax" class="tocxref"><span class="secno">9. </span>Additional Signature Syntax</a><ul class="toc"><li class="tocline"><a href="#sec-Manifest" class="tocxref"><span class="secno">9.1 </span>The <code>Manifest</code> Element</a></li><li class="tocline"><a href="#sec-SignatureProperties" class="tocxref"><span class="secno">9.2 </span>The <code>SignatureProperties</code> Element</a></li><li class="tocline"><a href="#sec-PI" class="tocxref"><span class="secno">9.3 </span>Processing Instructions in Signature Elements</a></li><li class="tocline"><a href="#sec-comments" class="tocxref"><span class="secno">9.4 </span>Comments in Signature Elements</a></li></ul></li><li class="tocline"><a href="#sec-Algorithms" class="tocxref"><span class="secno">10. </span>Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-MessageDigests" class="tocxref"><span class="secno">10.1 </span>Message Digests</a><ul class="toc"><li class="tocline"><a href="#sec-SHA-1" class="tocxref"><span class="secno">10.1.1 </span>SHA-1</a></li><li class="tocline"><a href="#sec-SHA-256" class="tocxref"><span class="secno">10.1.2 </span>SHA-256</a></li><li class="tocline"><a href="#sec-SHA-384" class="tocxref"><span class="secno">10.1.3 </span>SHA-384</a></li><li class="tocline"><a href="#sec-SHA-512" class="tocxref"><span class="secno">10.1.4 </span>SHA-512</a></li></ul></li><li class="tocline"><a href="#sec-MACs" class="tocxref"><span class="secno">10.2 </span>Message Authentication Codes</a><ul class="toc"><li class="tocline"><a href="#sec-HMAC" class="tocxref"><span class="secno">10.2.1 </span>HMAC</a></li></ul></li><li class="tocline"><a href="#sec-SignatureAlg" class="tocxref"><span class="secno">10.3 </span>Signature Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-DSA" class="tocxref"><span class="secno">10.3.1 </span>DSA</a></li><li class="tocline"><a href="#sec-PKCS1" class="tocxref"><span class="secno">10.3.2 </span>RSA (PKCS#1 v1.5)</a></li><li class="tocline"><a href="#sec-ECDSA" class="tocxref"><span class="secno">10.3.3 </span>ECDSA</a></li></ul></li><li class="tocline"><a href="#sec-c14nAlg-2.0" class="tocxref"><span class="secno">10.4 </span>Canonicalization Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-c14nAlg2" class="tocxref"><span class="secno">10.4.1 </span>Canonical XML 2.0</a></li></ul></li><li class="tocline"><a href="#sec-Transforms-2.0" class="tocxref"><span class="secno">10.5 </span>The <code>Transform</code> Algorithm</a></li><li class="tocline"><a href="#sec-SelectionAlgorithms" class="tocxref"><span class="secno">10.6 </span><code>dsig2:Selection</code> Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-Type-xml" class="tocxref"><span class="secno">10.6.1 </span>Selection of XML Documents or Fragments</a><ul class="toc"><li class="tocline"><a href="#sec-IncludedXPath" class="tocxref"><span class="secno">10.6.1.1 </span>The <code>dsig2:IncludedXPath</code> Element</a></li><li class="tocline"><a href="#sec-ExcludedXPath" class="tocxref"><span class="secno">10.6.1.2 </span>The <code>dsig2:ExcludedXPath</code> Element</a></li><li class="tocline"><a href="#sec-ByteRange" class="tocxref"><span class="secno">10.6.1.3 </span>The <code>dsig2:ByteRange</code> Element</a></li></ul></li><li class="tocline"><a href="#sec-Type-Binary-fromURI" class="tocxref"><span class="secno">10.6.2 </span>Selection of External Binary Data</a></li><li class="tocline"><a href="#sec-Type-Binary-fromBase64Node" class="tocxref"><span class="secno">10.6.3 </span>Selection of Binary Data within XML</a></li></ul></li><li class="tocline"><a href="#sec-VerificationTypes" class="tocxref"><span class="secno">10.7 </span>The <code>dsig2:Verification</code> Types</a><ul class="toc"><li class="tocline"><a href="#sec-Verification-DigestDataLength" class="tocxref"><span class="secno">10.7.1 </span>DigestDataLength</a></li><li class="tocline"><a href="#sec-Verification-PositionAssertion" class="tocxref"><span class="secno">10.7.2 </span>PositionAssertion</a></li><li class="tocline"><a href="#sec-Verification-IDAttrs" class="tocxref"><span class="secno">10.7.3 </span>IDAttributes</a></li></ul></li></ul></li><li class="tocline"><a href="#sec-XML-Canonicalization" class="tocxref"><span class="secno">11. </span>XML Canonicalization and Syntax Constraint Considerations</a><ul class="toc"><li class="tocline"><a href="#sec-XML-1" class="tocxref"><span class="secno">11.1 </span>XML 1.0 Syntax Constraints, and Canonicalization</a></li><li class="tocline"><a href="#sec-DOM-SAX" class="tocxref"><span class="secno">11.2 </span>DOM/SAX Processing and Canonicalization</a></li><li class="tocline"><a href="#sec-NamespaceContext" class="tocxref"><span class="secno">11.3 </span>Namespace Context and Portable Signatures</a></li></ul></li><li class="tocline"><a href="#sec-Security" class="tocxref"><span class="secno">12. </span>Security Considerations</a><ul class="toc"><li class="tocline"><a href="#sec-Security-Transforms" class="tocxref"><span class="secno">12.1 </span>Transforms</a><ul class="toc"><li class="tocline"><a href="#sec-Secure" class="tocxref"><span class="secno">12.1.1 </span>Only What is Signed is Secure</a></li><li class="tocline"><a href="#sec-Seen" class="tocxref"><span class="secno">12.1.2 </span>Only What is "Seen" Should be Signed</a></li><li class="tocline"><a href="#sec-See" class="tocxref"><span class="secno">12.1.3 </span>"See" What is Signed</a></li></ul></li><li class="tocline"><a href="#sec-Check" class="tocxref"><span class="secno">12.2 </span>Check the Security Model</a></li><li class="tocline"><a href="#sec-KeyLength" class="tocxref"><span class="secno">12.3 </span>Algorithms, Key Lengths, Certificates, Etc.</a></li></ul></li><li class="tocline"><a href="#sec-Schema" class="tocxref"><span class="secno">13. </span>Schema</a><ul class="toc"><li class="tocline"><a href="#sec-xsdSchema" class="tocxref"><span class="secno">13.1 </span>XSD Schema</a></li></ul></li><li class="tocline"><a href="#sec-Definitions" class="tocxref"><span class="secno">A. </span>Definitions</a></li><li class="tocline"><a href="#sec-Compatibility-Mode" class="tocxref"><span class="secno">B. </span>Compatibility Mode</a><ul class="toc"><li class="tocline"><a href="#sec-Compatibility-Mode-Examples" class="tocxref"><span class="secno">B.1 </span>"Compatibility Mode" Examples</a><ul class="toc"><li class="tocline"><a href="#sec-o-Simple-Compat" class="tocxref"><span class="secno">B.1.1 </span>Simple Example in "Compatibility Mode"</a></li><li class="tocline"><a href="#sec-o-Reference" class="tocxref"><span class="secno">B.1.2 </span>More on <code>Reference</code></a></li><li class="tocline"><a href="#sec-o-SignatureProperty" class="tocxref"><span class="secno">B.1.3 </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">B.1.4 </span>Extended Example (<code>Object</code> and <code>Manifest</code>)</a></li></ul></li><li class="tocline"><a href="#sec-compatible-processing" class="tocxref"><span class="secno">B.2 </span>Compatibility Mode Processing</a><ul class="toc"><li class="tocline"><a href="#sec-ReferenceGeneration" class="tocxref"><span class="secno">B.2.1 </span>Reference Generation in "Compatibility Mode"</a></li><li class="tocline"><a href="#sec-ReferenceCheck" class="tocxref"><span class="secno">B.2.2 </span>Reference check in "Compatibility Mode"</a></li><li class="tocline"><a href="#sec-SignatureValidationCompat" class="tocxref"><span class="secno">B.2.3 </span>Signature Validation in "Compatibility Mode"</a></li><li class="tocline"><a href="#sec-ReferenceValidation" class="tocxref"><span class="secno">B.2.4 </span>Reference Validation in "Compatibility Mode"</a></li></ul></li><li class="tocline"><a href="#sec-CanonicalizationMethod-Compat" class="tocxref"><span class="secno">B.3 </span>Use of <code>CanonicalizationMethod</code> in "Compatibility Mode"</a></li><li class="tocline"><a href="#sec-URI" class="tocxref"><span class="secno">B.4 </span>The <code>URI</code> Attribute in "Compatibility Mode"</a><ul class="toc"><li class="tocline"><a href="#sec-ReferenceProcessingModel" class="tocxref"><span class="secno">B.4.1 </span>The "Compatibility Mode" Reference Processing Model</a></li><li class="tocline"><a href="#sec-Same-Document" class="tocxref"><span class="secno">B.4.2 </span>"Compatibility Mode" Same-Document URI-References</a></li></ul></li><li class="tocline"><a href="#sec-TransformsProcessingModel" class="tocxref"><span class="secno">B.5 </span> "Compatibility Mode" Transforms and Processing Model</a></li><li class="tocline"><a href="#sec-c14nAlg" class="tocxref"><span class="secno">B.6 </span>"Compatibility Mode" Canonicalization Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-Canonical" class="tocxref"><span class="secno">B.6.1 </span>Canonical XML 1.0</a></li><li class="tocline"><a href="#sec-Canonical11" class="tocxref"><span class="secno">B.6.2 </span>Canonical XML 1.1</a></li><li class="tocline"><a href="#sec-ExcC14N10" class="tocxref"><span class="secno">B.6.3 </span>Exclusive XML Canonicalization 1.0</a></li></ul></li><li class="tocline"><a href="#sec-TransformAlg" class="tocxref"><span class="secno">B.7 </span>"Compatibility Mode" <code>Transform</code> Algorithms</a><ul class="toc"><li class="tocline"><a href="#sec-Canonicalization" class="tocxref"><span class="secno">B.7.1 </span>Canonicalization</a></li><li class="tocline"><a href="#sec-Base-64" class="tocxref"><span class="secno">B.7.2 </span>Base64</a></li><li class="tocline"><a href="#sec-XPath" class="tocxref"><span class="secno">B.7.3 </span>XPath Filtering</a></li><li class="tocline"><a href="#sec-EnvelopedSignature" class="tocxref"><span class="secno">B.7.4 </span>Signature Transform</a></li><li class="tocline"><a href="#sec-XSLT" class="tocxref"><span class="secno">B.7.5 </span>XSLT Transform</a></li></ul></li></ul></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></div>
 

<div id="sec-Introduction" class="informative section">
<!--OddPage--><h2><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></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 external to the signature element. More specifically, this
specification defines an XML signature element type and an <a href="#def-SignatureApplication" class="link-def">XML signature
application</a>; conformance requirements for each are specified by way
of schema definitions and prose respectively. This specification also
includes other useful types that identify methods for referencing
collections of resources, algorithms, and keying and management
information.</p>

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

<p>XML Signature 2.0 includes a new Reference processing model
  designed to address additional requirements including performance,
  simplicity and streamability. This "2.0 mode" model is significantly
  different than the XML Signature 1.x  model in that it explicitly
  defines selection, canonicalization and verification steps for data
  processing and disallows generic transforms.  XML Signature 2.0 is
  designed to be backward compatible through the inclusion of a
  "Compatibility Mode" which enables the XML Signature 1.x model to be
  used where necessary. 
</p>

<div id="sec-20-modes" class="section">
<h3><span class="secno">1.1 </span>XML Signature 2.0 and 1.x compatibility</h3>
<p>This specification defines XML Signature 2.0 which differs from XML
  Signature 1.x in some specific areas, in particular the use of
  various transform algorithms versus a fixed 2.0 transform that implies the
  use of Selection and Verification steps in conjunction with
  <code>ds:Reference</code> processing, the corresponding disuse of
  the <code>URI</code> <code>ds:Reference</code> attribute, the use of
  Canonical XML 2.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>] in place of 
  other canonicalization algorithms, and updates to the required
  algorithms and other changes. 
</p>
<p>This specification defines a "Compatibility Mode" that supports an
  XML Signature 1.x mode of operation. Compliance and other aspects
  unique to "Compatibility Mode" are outlined in  
  <a href="#sec-Compatibility-Mode" class="sectionRef">section B. Compatibility Mode</a>.
</p>
<p>The body of the document refers to the syntax and processing model
  for the new 2.0 mode of operation, referred to as "XML Signature
  2.0" in the document. Use of the "Compatibility Mode" is noted
  explicitly when required.
</p>
</div>
<div id="sec-Editorial" class="section">
<h3><span class="secno">1.2 </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 12.2 Check the Security Model</a>.)</p>

<p>This specification provides normative XML Schemas [<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
schemas and the normative text in this specification. The standalone XSD
schema files are authoritative in case there is any disagreement between
them 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.3 </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>], the XML Security 1.1 Requirements document
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSEC11-REQS">XMLSEC11-REQS</a></cite>]
and  the XML Security 2.0 Requirements document [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSEC2-REQS">XMLSEC2-REQS</a></cite>].</p>
</div> 

<div id="sec-Versions" class="section">
<h3><span class="secno">1.4 </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>
    <tr>
      <td><code>http://www.w3.org/2010/xmldsig2#</code></td>
      <td><code>dsig2:</code></td>
      <td><code>&lt;!ENTITY dsig2
"http://www.w3.org/2010/xmldsig2#"&gt;</code></td>
    </tr>
  </tbody>
</table>

<!-- <p class="note"> The Namespace URI for dsig2, listed as
http://www.w3.org/2010/xmldsig2, is subject to change. </p> -->

<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>
  <dt style="font-weight: normal;"><code>Selection</code> is identified
and defined by the <code>dsig2:</code> namespace</dt>
  <dd><code>http://www.w3.org/2010/xmldsig2#Selection</code></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,
and <code>http://www.w3.org/2009/xmldsig11#</code> (<code>dsig11:</code>)
namespace was introduced in 1.1. This version does not coin any new
elements or algorithm identifiers in those namespaces; instead, the
<code>http://www.w3.org/2010/xmldsig2#</code> (<code>dsig2:</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.5 </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; (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, Ed Simon, Chris Solc, John
Wray, Kelvin Yiu.</p>
<!-- <p>The Working Group thanks Makoto Murata for assistance with the 
RelaxNG schemas.</p> -->
</div>
</div>

<div id="sec-Overview" class="informative section">
<!--OddPage--><h2><span class="secno">2. </span>Signature Overview and Examples</h2><p><em>This section is non-normative.</em></p>
<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 4. Processing Rules</a>. The formal
syntax is found in <a href="#sec-CoreSyntax" class="sectionRef">section 5. Core Signature Syntax</a>
and <a href="#sec-AdditionalSyntax" class="sectionRef">section 9. Additional Signature Syntax</a>.</p>

<p>In this section, an 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="sh_xml sh_sourceCode">  <span class="sh_keyword">&lt;Signature</span> <span class="sh_type">ID?</span><span class="sh_keyword">&gt;</span> 
     <span class="sh_keyword">&lt;SignedInfo&gt;</span>
       <span class="sh_keyword">&lt;CanonicalizationMethod/&gt;</span>
       <span class="sh_keyword">&lt;SignatureMethod/&gt;</span>
       (<span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI?</span><span class="sh_normal"> </span><span class="sh_keyword">&gt;</span>
         (<span class="sh_keyword">&lt;Transforms&gt;</span>)?
         <span class="sh_keyword">&lt;DigestMethod&gt;</span>
         <span class="sh_keyword">&lt;DigestValue&gt;</span>
       <span class="sh_keyword">&lt;/Reference&gt;</span>)+
     <span class="sh_keyword">&lt;/SignedInfo&gt;</span>
     <span class="sh_keyword">&lt;SignatureValue&gt;</span> 
    (<span class="sh_keyword">&lt;KeyInfo&gt;</span>)?
    (<span class="sh_keyword">&lt;Object</span> <span class="sh_type">ID?</span><span class="sh_keyword">&gt;</span>)*
   <span class="sh_keyword">&lt;/Signature&gt;</span>
</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-2.0" class="section">
<h3><span class="secno">2.1 </span>Simple XML Signature 2.0 Example</h3>

<p>This is the same example 
an <a href="#sec-o-Simple-Compat" class="link-def">as provided for
    the XML Signature 1.x</a>, but for 
  XML Signature 2.0. The only differences are
in the <code>CanonicalizationMethod</code> and <code>Reference</code>
portions. The line numbers in this example match up with the line numbers
in the "Compatibility Mode" example.</p>
<pre class="example sh_xml sh_sourceCode">[s01] <span class="sh_keyword">&lt;Signature</span> <span class="sh_type">Id</span><span class="sh_symbol">=</span><span class="sh_string">"MyFirstSignature"</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span><span class="sh_keyword">&gt;</span> 
[s02]   <span class="sh_keyword">&lt;SignedInfo&gt;</span>  
[s03]   <span class="sh_keyword">&lt;CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span><span class="sh_keyword">/&gt;</span> 
[s04]   <span class="sh_keyword">&lt;SignatureMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"</span><span class="sh_keyword">/&gt;</span> 
[s05]   <span class="sh_keyword">&lt;Reference&gt;</span> 
[s06]     <span class="sh_keyword">&lt;Transforms&gt;</span> 
[s07]       <span class="sh_keyword">&lt;Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#transform"</span><span class="sh_keyword">&gt;</span>
[s07a]        <span class="sh_keyword">&lt;dsig2:Selection</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#xml"</span> <span class="sh_type">xmlns:dsig2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#"</span>
<span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/TR/2000/REC-xhtml1-20000126"</span><span class="sh_keyword">&gt;</span>
&gt;
[s07b]        <span class="sh_keyword">&lt;/dsig2:Selection&gt;</span>
[s07c]        <span class="sh_keyword">&lt;CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span><span class="sh_keyword">/&gt;</span>
[s07d]      <span class="sh_keyword">&lt;/Transform&gt;</span> 
[s08]     <span class="sh_keyword">&lt;/Transforms&gt;</span> 
[s09]     <span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span> 
[s10]     <span class="sh_keyword">&lt;DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...<span class="sh_keyword">&lt;/DigestValue&gt;</span> 
[s11]   <span class="sh_keyword">&lt;/Reference&gt;</span> 
[s12] <span class="sh_keyword">&lt;/SignedInfo&gt;</span> 
[s13]   <span class="sh_keyword">&lt;SignatureValue&gt;</span>...<span class="sh_keyword">&lt;/SignatureValue&gt;</span> 
[s14]   <span class="sh_keyword">&lt;KeyInfo&gt;</span> 
[s15a]    <span class="sh_keyword">&lt;KeyValue&gt;</span>
[s15b]      <span class="sh_keyword">&lt;DSAKeyValue&gt;</span> 
[s15c]        <span class="sh_keyword">&lt;P&gt;</span>...<span class="sh_keyword">&lt;/P&gt;&lt;Q&gt;</span>...<span class="sh_keyword">&lt;/Q&gt;&lt;G&gt;</span>...<span class="sh_keyword">&lt;/G&gt;&lt;Y&gt;</span>...<span class="sh_keyword">&lt;/Y&gt;</span> 
[s15d]      <span class="sh_keyword">&lt;/DSAKeyValue&gt;</span> 
[s15e]    <span class="sh_keyword">&lt;/KeyValue&gt;</span> 
[s16]   <span class="sh_keyword">&lt;/KeyInfo&gt;</span> 
[s17] <span class="sh_keyword">&lt;/Signature&gt;</span></pre>

<p><code>[s03]</code> In XML Signature 2.0 the Canonicalization Method URI
should be Canonical XML 2.0 (or a later version) and all the parameters
for Canonical XML 2.0 should be present as subelements of this element
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>].</p>

<p><code>[s05-s08]</code> Note XML Signature 2.0 does not use various 
transforms, instead each reference object has two parts -
  a <code>dsig2:Selection</code> 
element to choose the data object to be signed, and
  a <code>Canonicalization</code> 
element to convert the data object to a canonicalized octet stream. To
fit in these two elements, without breaking backwards compatibility
with the 1.0 schema, these elements have been put inside a special <code>Transform</code>
with URI <code>http://www.w3.org/2010/xmldsig2#transform</code>.
In XML Signature 2.0 the <code>Transforms</code> element will contain only this
particular fixed <code>Transform</code>.</p>
<p><code>[s05]</code> In XML Signature 2.0, the <code>URI</code>
attribute is omitted from the <code>Reference</code>. Instead
it can be found in the <code>dsig2:Selection</code>.</p>

<p><code>[s07a-s07b]</code> The <code>dsig2:Selection</code> element
identifies the data object to be signed. This specification identifies only
two types, "xml" and "binary", but user specified types are also
possible. For example a new type "database-rows" could be defined to
select rows from a database for signing. Usually a URI and a few
other bits of information are used to identify the data object, but the
URI is not required; for example, the "xml" type can identify a local
document subset by using an XPath.</p>

<p> <code>[s07c] </code>The <code>CanonicalizationMethod</code>
element provides the mechanism to convert the data object into a
canonicalized octet stream. This specification addresses only
canonicalization for xml data. Other forms of canonicalization can be
defined - e.g. a scheme for signing mime attachments could define a
canonicalization for mime headers and data. The output of the
canonicalization is digested.</p>
</div>

<div id="sec-DetailedIdExample-2.0" class="section">
<h3><span class="secno">2.2 </span>Detailed XML Signature 2.0 Example Using Ids</h3>
<p>The followed detailed example shows XML Signature 2.0 in the
  context of Web Services Security [<cite><a class="bibref" rel="biblioentry" href="#bib-WS-SECURITY11">WS-SECURITY11</a></cite>], showing how the
  SOAP body can be 
  referenced using an Id in XML Signature 2.0.
This example shows more detail than the previous 
<a href="#sec-o-Simple-2.0" class="link-def">Simple XML Signature 2.0
  Example</a>.
</p>
<p><strong>Note:</strong> This example (and 
<a href="#sec-DetailedXPathExample-2.0" class="link-def">
the next example using XPath</a>) show the use of
  XML  Signature 2.0 in the context of Web Services Security. This is
  illustrative of how a 2.0 signature could be substituted for an 1.x
  Signature, but has not been standardized in Web Services Security
  so should only be considered illustrative.</p>

<pre class="example sh_xml sh_sourceCode">[ i01 ] <span class="sh_preproc">&lt;?xml</span> <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"1.0"</span> <span class="sh_type">encoding</span><span class="sh_symbol">=</span><span class="sh_string">"UTF-8"</span><span class="sh_preproc">?&gt;</span>
[ i02 ] <span class="sh_keyword">&lt;soap:Envelope</span> <span class="sh_type">xmlns:soap</span><span class="sh_symbol">=</span><span class="sh_string">"http://schemas.xmlsoap.org/soap/envelope/"</span> <span class="sh_type">xmlns:wsu</span><span class="sh_symbol">=</span><span class="sh_string">"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"</span><span class="sh_keyword">&gt;</span>
[ i03 ]   <span class="sh_keyword">&lt;soap:Header&gt;</span>
[ i04 ]     <span class="sh_keyword">&lt;wsse:Security</span> <span class="sh_type">xmlns:wsse</span><span class="sh_symbol">=</span><span class="sh_string">"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"</span><span class="sh_keyword">&gt;</span>
[ i05 ]       <span class="sh_keyword">&lt;wsse:BinarySecurityToken</span> <span class="sh_type">wsu:Id</span><span class="sh_symbol">=</span><span class="sh_string">"MyID"</span>   
<span class="sh_type">[</span><span class="sh_normal"> </span><span class="sh_type">i06</span><span class="sh_normal"> </span><span class="sh_type">]</span><span class="sh_normal"> </span><span class="sh_type">ValueType</span><span class="sh_symbol">=</span><span class="sh_string">"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"</span>	
<span class="sh_type">[</span><span class="sh_normal"> </span><span class="sh_type">i07</span><span class="sh_normal"> </span><span class="sh_type">]</span><span class="sh_normal"> </span><span class="sh_type">EncodingType</span><span class="sh_symbol">=</span><span class="sh_string">"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#Base64Binary"</span><span class="sh_keyword">&gt;</span>
[ i08 ]         MIIEZzCCA9CgAwIBAgIQEmtJZc0..
[ i09 ]       <span class="sh_keyword">&lt;/wsse:BinarySecurityToken&gt;</span>
[ i10 ]       <span class="sh_keyword">&lt;ds:Signature</span> <span class="sh_type">xmlns:ds</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span><span class="sh_keyword">&gt;</span>
[ i11 ]         <span class="sh_keyword">&lt;ds:SignedInfo&gt;</span>
[ i12 ]           <span class="sh_keyword">&lt;ds:CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span>     
<span class="sh_type">[</span><span class="sh_normal"> </span><span class="sh_type">i13</span><span class="sh_normal"> </span><span class="sh_type">]</span><span class="sh_normal"> </span><span class="sh_type">xmlns:c14n2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span><span class="sh_keyword">&gt;</span>
[ i14 ]             <span class="sh_keyword">&lt;c14n2:IgnoreComments&gt;</span>true<span class="sh_keyword">&lt;/c14n2:IgnoreComments&gt;</span>
[ i15 ]             <span class="sh_keyword">&lt;c14n2:TrimTextNodes&gt;</span>false<span class="sh_keyword">&lt;/c14n2:TrimTextNodes&gt;</span>
[ i16 ]             <span class="sh_keyword">&lt;c14n2:PrefixRewrite&gt;</span>none<span class="sh_keyword">&lt;/c14n2:PrefixRewrite&gt;</span>
[ i17 ]             <span class="sh_keyword">&lt;c14n2:QNameAware/&gt;</span>
[ i18 ]           <span class="sh_keyword">&lt;/ds:CanonicalizationMethod&gt;</span>
[ i19 ]           <span class="sh_keyword">&lt;ds:SignatureMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"</span><span class="sh_keyword">/&gt;</span>
[ i20 ]           <span class="sh_keyword">&lt;ds:Reference&gt;</span>
[ i21 ]             <span class="sh_keyword">&lt;ds:Transforms&gt;</span>
[ i22 ]               <span class="sh_keyword">&lt;ds:Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#newTransformModel"</span> <span class="sh_type">xmlns:dsig2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#"</span><span class="sh_keyword">&gt;</span>
[ i23 ]                 <span class="sh_keyword">&lt;dsig2:Selection</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#xml"</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#MsgBody"</span> <span class="sh_keyword">/&gt;</span>
[ i24 ]                 <span class="sh_keyword">&lt;dsig2:Canonicalization</span> <span class="sh_keyword">&gt;</span>
[ i25 ]                   <span class="sh_keyword">&lt;c14n2:IgnoreComments&gt;</span>true<span class="sh_keyword">&lt;/c14n2:IgnoreComments&gt;</span>
[ i26 ]                   <span class="sh_keyword">&lt;c14n2:TrimTextNodes&gt;</span>true<span class="sh_keyword">&lt;/c14n2:TrimTextNodes&gt;</span>
[ i27 ]                   <span class="sh_keyword">&lt;c14n2:PrefixRewrite&gt;</span>sequential<span class="sh_keyword">&lt;/c14n2:PrefixRewrite&gt;</span>
[ i28 ]                   <span class="sh_keyword">&lt;c14n2:QNameAware/&gt;</span>
[ i29 ]                 <span class="sh_keyword">&lt;/dsig2:Canonicalization&gt;</span>
[ i30 ]                 <span class="sh_keyword">&lt;dsig2:Verifications&gt;</span>
[ i31 ]                   <span class="sh_keyword">&lt;dsig2:Verification</span> <span class="sh_type">DigestDataLength</span><span class="sh_symbol">=</span><span class="sh_string">"308"</span><span class="sh_keyword">/&gt;</span>
[ i32 ]                 <span class="sh_keyword">&lt;/dsig2:Verifications&gt;</span>
[ i33 ]               <span class="sh_keyword">&lt;/ds:Transform&gt;</span>
[ i34 ]             <span class="sh_keyword">&lt;/ds:Transforms&gt;</span>
[ i35 ]             <span class="sh_keyword">&lt;ds:DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span>
[ i36 ]             <span class="sh_keyword">&lt;ds:DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...<span class="sh_keyword">&lt;/ds:DigestValue&gt;</span>
[ i37 ]           <span class="sh_keyword">&lt;/ds:Reference&gt;</span>
[ i38 ]         <span class="sh_keyword">&lt;/ds:SignedInfo&gt;</span>
[ i39 ]         <span class="sh_keyword">&lt;ds:SignatureValue&gt;</span>kdutrEsAEw56Sefgs34...<span class="sh_keyword">&lt;/ds:SignatureValue&gt;</span>
[ i40 ]         <span class="sh_keyword">&lt;ds:KeyInfo&gt;</span>
[ i41 ]           <span class="sh_keyword">&lt;ds:KeyValue&gt;</span>
[ i42 ]             <span class="sh_keyword">&lt;wsse:SecurityTokenReference&gt;</span>
[ i43 ]               <span class="sh_keyword">&lt;wsse:Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#MyID"</span><span class="sh_keyword">/&gt;</span>
[ i44 ]             <span class="sh_keyword">&lt;/wsse:SecurityTokenReference&gt;</span>
[ i45 ]           <span class="sh_keyword">&lt;/ds:KeyValue&gt;</span>
[ i46 ]         <span class="sh_keyword">&lt;/ds:KeyInfo&gt;</span>
[ i47 ]       <span class="sh_keyword">&lt;/ds:Signature&gt;</span>
[ i48 ]     <span class="sh_keyword">&lt;/wsse:Security&gt;</span>
[ i49 ]   <span class="sh_keyword">&lt;/soap:Header&gt;</span>
[ i50 ]   <span class="sh_keyword">&lt;soap:Body</span> <span class="sh_type">wsu:Id</span><span class="sh_symbol">=</span><span class="sh_string">"MsgBody"</span><span class="sh_keyword">&gt;</span>
[ i51 ]     <span class="sh_keyword">&lt;ex:operation</span> <span class="sh_type">xmlns:ex</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.example.com/"</span><span class="sh_keyword">&gt;</span>
[ i52 ]       <span class="sh_keyword">&lt;ex:param1&gt;</span>42<span class="sh_keyword">&lt;/ex:param1&gt;</span>
[ i53 ]       <span class="sh_keyword">&lt;ex:param2&gt;</span>43<span class="sh_keyword">&lt;/ex:param2&gt;</span>
[ i54 ]     <span class="sh_keyword">&lt;/ex:operation&gt;</span>
[ i55 ]   <span class="sh_keyword">&lt;/soap:Body&gt;</span>
[ i56 ] <span class="sh_keyword">&lt;/soap:Envelope&gt;</span></pre>
<p> <code>[ i05-i09 ] </code>
  The <code>wsse:BinarySecurityToken</code> is a Web Services Security
  mechanism to convey key information needed for signature processing,
  in this case an X.509v3 certificate. 
</p>
<p> <code>[ i12-i18 ] </code>This example shows explicit choices for
  parameters of the  <code>ds:CanonicalizationMethod</code> rather
  than relying on implicit defaults. These canonicalization choices
  are for the canonicalization of <code>ds:SignedInfo</code> using
  Canonical XML 2.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>].
</p>
<p> <code>[ i14 ] </code>The <code>c14n2:IgnoreComments</code> parameter
  is set to <code>true</code>, the default, meaning that comments will
  be ignored.
</p>
<p> <code>[ i15 ] </code>The <code>c14n2:TrimTextNodes</code> parameter
  is set to <code>false</code>, so white space will be preserved.
</p>
<p> <code>[ i16 ] </code>The <code>c14n2:PrefixRewrite</code> parameter
  is set to <code>none</code>, the default, meaning that 
no prefixes will be rewritten.
</p>
<p> <code>[ i17 ] </code>The <code>c14n2:QNameAware</code> parameter
  is set to the empty set, the default, meaning that no QNames require
  special processing.
</p>

<p> <code>[ i23 ] </code>The <code>dsig2:Selection</code> <code>URI</code> parameter
  is set to <code>#MsgBody</code> meaning that the element with the
  corresponding Id (in this case <code>wsu:Id</code>) will be
  selected.
</p>

<p> <code>[ i24-i29 ] </code>The <code>dsig2:Canonicalization</code>
  element again has parameters set explicitly
  for <code>ds:Reference</code> canonicalization.
</p>

<p> <code>[ i30-i33 ] </code>This example uses the new ability in XML
  Signature 2.0 for a verifier to receive constraint information that
  can be used to verify correctness of the information received, to
  mitigate against attacks. The  <code>dsig2:Verifications</code>
  element contains this verification information. In this case the
  length of the <code>ds:Reference</code> data that was digested is conveyed.
</p>

<p> <code>[ i42-i44 ] </code>Web Services Security uses
  its <code>SecurityTokenReference</code> mechanism to reference key
  information conveyed in tokens, such as an X.509 certificate. In
  this example this mechanism is used to reference the binary security
  token at <code></code> using the <code>MyID</code> Id.
</p>

<p> <code>[ i50 ] </code>The <code>soapBody</code> has
  a <code>wsu:Id</code> attribute which is used by
  the <code>ds:Reference</code> <code>URI</code> attribute to
  reference the element.
</p>

</div>

<div id="sec-DetailedXPathExample-2.0" class="section">
<h3><span class="secno">2.3 </span>Detailed XML Signature 2.0 Example using XPath</h3>
<p>The followed detailed example shows  use of XML Signature 2.0 in a Web
  Services Security example similar to the
<a href="#sec-o-Simple-2.0" class="link-def">
 previous example using an
  Id reference</a>, but here uses an XPath expression to help 
  mitigate the possibility of wrapping attacks.
  In this case the <code>soap:Body</code> is signed, but
  the <code>ex:param2</code> is omitted from the signature.
  This could correspond to a case where the 
  the first parameter is known to be
  invariant end-end while the second parameter might be expected to
  change as the SOAP message traverses SOAP intermediaries, so is omitted
  from the signature. 
</p>

<pre class="example sh_xml sh_sourceCode">[ p01 ] <span class="sh_preproc">&lt;?xml</span> <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"1.0"</span> <span class="sh_type">encoding</span><span class="sh_symbol">=</span><span class="sh_string">"UTF-8"</span><span class="sh_preproc">?&gt;</span>
[ p02 ] <span class="sh_keyword">&lt;soap:Envelope</span> <span class="sh_type">xmlns:soap</span><span class="sh_symbol">=</span><span class="sh_string">"http://schemas.xmlsoap.org/soap/envelope/"</span> <span class="sh_type">xmlns:ex</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.example.com/"</span><span class="sh_keyword">&gt;</span>
[ p03 ]   <span class="sh_keyword">&lt;soap:Header&gt;</span>
[ p04 ]     <span class="sh_keyword">&lt;wsse:Security</span> <span class="sh_type">xmlns:wsse</span><span class="sh_symbol">=</span><span class="sh_string">"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"</span>
<span class="sh_type">[</span><span class="sh_normal"> </span><span class="sh_type">p05</span><span class="sh_normal"> </span><span class="sh_type">]</span><span class="sh_normal"> </span><span class="sh_type">xmlns:wsu</span><span class="sh_symbol">=</span><span class="sh_string">"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"</span><span class="sh_keyword">&gt;</span>
[ p06 ]       <span class="sh_keyword">&lt;wsse:BinarySecurityToken</span> <span class="sh_type">wsu:Id</span><span class="sh_symbol">=</span><span class="sh_string">"MyID"</span>   
<span class="sh_type">[</span><span class="sh_normal"> </span><span class="sh_type">p07</span><span class="sh_normal"> </span><span class="sh_type">]</span><span class="sh_normal"> </span><span class="sh_type">ValueType</span><span class="sh_symbol">=</span><span class="sh_string">"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"</span>	
<span class="sh_type">[</span><span class="sh_normal"> </span><span class="sh_type">p08</span><span class="sh_normal"> </span><span class="sh_type">]</span><span class="sh_normal"> </span><span class="sh_type">EncodingType</span><span class="sh_symbol">=</span><span class="sh_string">"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#Base64Binary"</span><span class="sh_keyword">&gt;</span>
[ p09 ]         MIIEZzCCA9CgAwIBAgIQEmtJZc0..
[ p10 ]       <span class="sh_keyword">&lt;/wsse:BinarySecurityToken&gt;</span>
[ p11 ]       <span class="sh_keyword">&lt;ds:Signature</span> <span class="sh_type">xmlns:ds</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span><span class="sh_keyword">&gt;</span>
[ p12 ]         <span class="sh_keyword">&lt;ds:SignedInfo&gt;</span>
[ p13 ]           <span class="sh_keyword">&lt;ds:CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span>     
<span class="sh_type">[</span><span class="sh_normal"> </span><span class="sh_type">p14</span><span class="sh_normal"> </span><span class="sh_type">]</span><span class="sh_normal"> </span><span class="sh_type">xmlns:c14n2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span><span class="sh_keyword">&gt;</span>
[ p15 ]             <span class="sh_keyword">&lt;c14n2:IgnoreComments&gt;</span>true<span class="sh_keyword">&lt;/c14n2:IgnoreComments&gt;</span>
[ p16 ]             <span class="sh_keyword">&lt;c14n2:TrimTextNodes&gt;</span>false<span class="sh_keyword">&lt;/c14n2:TrimTextNodes&gt;</span>
[ p17 ]             <span class="sh_keyword">&lt;c14n2:PrefixRewrite&gt;</span>none<span class="sh_keyword">&lt;/c14n2:PrefixRewrite&gt;</span>
[ p18 ]             <span class="sh_keyword">&lt;c14n2:QNameAware/&gt;</span>
[ p19 ]           <span class="sh_keyword">&lt;/ds:CanonicalizationMethod&gt;</span>
[ p20 ]           <span class="sh_keyword">&lt;ds:SignatureMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"</span><span class="sh_keyword">/&gt;</span>
[ p21 ]           <span class="sh_keyword">&lt;ds:Reference&gt;</span>
[ p22 ]             <span class="sh_keyword">&lt;ds:Transforms&gt;</span>
[ p23 ]               <span class="sh_keyword">&lt;ds:Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#newTransformModel"</span> <span class="sh_type">xmlns:dsig2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#"</span><span class="sh_keyword">&gt;</span>
[ p24 ]                 <span class="sh_keyword">&lt;dsig2:Selection</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#xml"</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">""</span><span class="sh_keyword">&gt;</span>
[ p25 ]                   <span class="sh_keyword">&lt;dsig2:IncludedXPath&gt;</span>/soap:Envelope/soap:Body[1]<span class="sh_keyword">&lt;/dsig2:IncludedXPath&gt;</span>
[ p26 ]                   <span class="sh_keyword">&lt;dsig2:ExcludedXPath&gt;</span>
[ p27 ]                     /soap:Envelope/soap:Body[1]/ex:operation[1]/ex:param2[1]
[ p28 ]                   <span class="sh_keyword">&lt;/dsig2:ExcludedXPath&gt;</span>
[ p29 ]                 <span class="sh_keyword">&lt;/dsig2:Selection&gt;</span>
[ p30 ]                 <span class="sh_keyword">&lt;dsig2:Canonicalization</span> <span class="sh_keyword">&gt;</span>
[ p31 ]                   <span class="sh_keyword">&lt;c14n2:IgnoreComments&gt;</span>true<span class="sh_keyword">&lt;/c14n2:IgnoreComments&gt;</span>
[ p32 ]                   <span class="sh_keyword">&lt;c14n2:TrimTextNodes&gt;</span>true<span class="sh_keyword">&lt;/c14n2:TrimTextNodes&gt;</span>
[ p33 ]                   <span class="sh_keyword">&lt;c14n2:PrefixRewrite&gt;</span>sequential<span class="sh_keyword">&lt;/c14n2:PrefixRewrite&gt;</span>
[ p34 ]                   <span class="sh_keyword">&lt;c14n2:QNameAware/&gt;</span>
[ p35 ]                 <span class="sh_keyword">&lt;/dsig2:Canonicalization&gt;</span>
[ p36 ]                 <span class="sh_keyword">&lt;dsig2:Verifications&gt;</span>
[ p37 ]                   <span class="sh_keyword">&lt;dsig2:Verification</span> <span class="sh_type">DigestDataLength</span><span class="sh_symbol">=</span><span class="sh_string">"169"</span><span class="sh_keyword">/&gt;</span>
[ p38 ]                 <span class="sh_keyword">&lt;/dsig2:Verifications&gt;</span>
[ p39 ]               <span class="sh_keyword">&lt;/ds:Transform&gt;</span>
[ p40 ]             <span class="sh_keyword">&lt;/ds:Transforms&gt;</span>
[ p41 ]             <span class="sh_keyword">&lt;ds:DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span>
[ p42 ]             <span class="sh_keyword">&lt;ds:DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...<span class="sh_keyword">&lt;/ds:DigestValue&gt;</span>
[ p43 ]           <span class="sh_keyword">&lt;/ds:Reference&gt;</span>
[ p44 ]         <span class="sh_keyword">&lt;/ds:SignedInfo&gt;</span>
[ p45 ]         <span class="sh_keyword">&lt;ds:SignatureValue&gt;</span>kdutrEsAEw56Sefgs34...<span class="sh_keyword">&lt;/ds:SignatureValue&gt;</span>
[ p46 ]         <span class="sh_keyword">&lt;ds:KeyInfo&gt;</span>
[ p47 ]           <span class="sh_keyword">&lt;ds:KeyValue&gt;</span>
[ p48 ]             <span class="sh_keyword">&lt;wsse:SecurityTokenReference&gt;</span>
[ p49 ]               <span class="sh_keyword">&lt;wsse:Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#MyID"</span><span class="sh_keyword">/&gt;</span>
[ p50 ]             <span class="sh_keyword">&lt;/wsse:SecurityTokenReference&gt;</span>
[ p51 ]           <span class="sh_keyword">&lt;/ds:KeyValue&gt;</span>
[ p52 ]         <span class="sh_keyword">&lt;/ds:KeyInfo&gt;</span>
[ p53 ]       <span class="sh_keyword">&lt;/ds:Signature&gt;</span>
[ p54 ]     <span class="sh_keyword">&lt;/wsse:Security&gt;</span>
[ p55 ]   <span class="sh_keyword">&lt;/soap:Header&gt;</span>
[ p56 ]   <span class="sh_keyword">&lt;soap:Body&gt;</span>
[ p57 ]     <span class="sh_keyword">&lt;ex:operation&gt;</span>
[ p58 ]       <span class="sh_keyword">&lt;ex:param1&gt;</span>42<span class="sh_keyword">&lt;/ex:param1&gt;</span>
[ p59 ]       <span class="sh_keyword">&lt;ex:param2&gt;</span>43<span class="sh_keyword">&lt;/ex:param2&gt;</span>
[ p60 ]     <span class="sh_keyword">&lt;/ex:operation&gt;</span>
[ p61 ]   <span class="sh_keyword">&lt;/soap:Body&gt;</span>
[ p62 ] <span class="sh_keyword">&lt;/soap:Envelope&gt;</span></pre>
<p> <code>[ p24 ] </code>In this case the <code>URI</code> attribute
  of the
<code>Reference</code> element is <code>""</code> as XPath is used
rather than an Id based reference.</p>
<p> <code>[ p25 ] </code> The <code>dsig2:IncludedXPath</code> element
includes an XPath expression to reference the <code>soap:Body</code>
  element. Note 
  that this expression is written to reference the
  specific <code>soap:Body</code> 
to mitigate wrapping attacks. The XPath expression is an XML Security
  2.0 profile of  
  XPath 1.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-XPATH">XMLDSIG-XPATH</a></cite>].
</p>
<p> <code>[ p26 ] </code>The <code>dsig2:ExcludedXPath</code> element
specifies that the <code>ex:operation[1]/ex:param2[1]</code> child of 
the <code>soap:Body</code> not be included in the signature. The
                            XPath expression specifies the exact
                            instance to avoid wrapping attacks.
</p>
</div>
</div>
<div id="sec-Conformance" class="section">
<!--OddPage--><h2><span class="secno">3. </span>Conformance</h2>
<p>An implementation that conforms to this specification <em class="rfc2119" title="must">must</em> be
  conformant to XML Signature 2.0 mode, and 
<em class="rfc2119" title="may">may</em> be
  conformant to XML Signature 1.1 Compatibility Mode.
</p>
<div id="sec-Common-Conformance" class="section">
<h3><span class="secno">3.1 </span>Common Conformance Requirements</h3>
<p>The following conformance requirements must be met by
all implementations, including those in compatibility mode.</p>
<div id="sec-Algorithm-All-Mode-Conformance" class="section">
<h4><span class="secno">3.1.1 </span>General Algorithm Identifier and Implementation Requirements</h4>
<p>This section identifies algorithm conformance requirements
  applicable to both 2.0 and compatibility mode.</p>
<div class="note">
<p> There is currently no consensus on mandatory to implement
algorithms; the current draft text represents one possible outcome.
Positions of some Working Group members against the currently expressed
set of mandatory to implement algorithms include: </p>
<ul>
  <li>RSA and DSA are acceptable as a mandatory to implement signature
algorithms. Given limited support in parts of the industry, elliptic
curve DSA is not acceptable as a mandatory to implement algorithm, and
might lead to lack of implementation of this version of the
specification.</li>
  <li>There should be recommended algorithms, but no mandatory to
implement algorithms. The rationale is that this gives greater
flexibility to deployments. (Other WG members argued against this since
it could harm interoperability not having mandatory algorithms.)</li>
</ul>
<p> The opposing position is that, going forward, this specification
needs to have credible algorithm agility for both hash and public-key
algorithms: Should one set of algorithms prove weak, this would enable
a quick switch-over. Therefore, there should be two mandatory to
implement public-key algorithms from different families. At this time,
elliptic curve based algorithms are the only credible contenders. They
have the additional benefit of providing a reasonable balance between
key sizes and security level. As profiles built on top of XML Signature
that currently rely on DSA-SHA1 or RSA-SHA1 as the only supported
signature algorithm will need to be updated in the future, the
Signature core specification should outline a clear way forward in
terms of choice of algorithms. This choice should be Elliptic Curve
DSA. </p>
</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>)
        <a href="http://www.w3.org/2000/09/xmldsig#sha1">http://www.w3.org/2000/09/xmldsig#sha1</a></li>

      <li>SHA256
        <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

        <a href="http://www.w3.org/2001/04/xmldsig-more#sha384">http://www.w3.org/2001/04/xmldsig-more#sha384</a></li>
      <li>SHA512

        <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>)

        <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

        <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

        <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

        <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

        <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

        <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

(<strong>signature verification</strong>)

        <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

(<strong>signature verification</strong>; use for signature generation
is DISCOURAGED; see <a href="#sec-MessageDigests">SHA-1 Warning</a>)

        <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

        <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

        <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>)

        <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

        <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

        <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

(<strong>signature generation</strong>)

        <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

        <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>
</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>
</div>
<div id="sec-2-0-Conformance" class="section">
<h3><span class="secno">3.2 </span>XML Signature 2.0 Conformance</h3>
<p>An implementation that conforms to this specification <em class="rfc2119" title="must">must</em> support
XML Signature 2.0 operation and conform to the following 
features when not operating in compatibility mode:</p>
<ul>
<li><em class="rfc2119" title="must">must</em> support the required steps of Signature generation, including
  the generation of Reference elements and the SignatureValue over
  SignedInfo as outlined in 
<a href="#sec-SignatureGeneration" class="sectionRef">section 4.1 Signature Generation</a>.
</li>
<li><em class="rfc2119" title="must">must</em> support the required steps of core validation as outlined in
<a href="#sec-CoreValidation" class="sectionRef">section 4.3 Core Validation</a>.
</li>
<li><em class="rfc2119" title="must">must</em> support required  XML Signature 2.0 Reference generation as outlined in
<a href="#sec-ReferenceGeneration-2.0" class="sectionRef">section 4.2 Reference Generation</a>.
</li>
<li><em class="rfc2119" title="must">must</em> conform to the syntax as outlined in text of this
  specification</li>
<li><em class="rfc2119" title="must not">must not</em> have a <code>URI</code> attribute in a <code>Reference</code> element</li>
<li>Every <code>Reference</code> element <em class="rfc2119" title="must">must</em> have a single <code>Transforms</code> element and
  that element <em class="rfc2119" title="must">must</em> contain exactly one <code>Transform</code> element with an
  <code>Algorithm</code> of <code>"http://www.w3.org/2010/xmldsig2#transform"</code></li>
<li>The result of processing each <code>Reference</code> <em class="rfc2119" title="must">must</em> be an octet stream
  with the digest algorithm applied to the resulting data octets</li>
<li>Transforms <em class="rfc2119" title="must not">must not</em> be used in <code>RetrievalMethod</code>.
<code>dsig11:KeyInfoReference</code> <em class="rfc2119" title="should">should</em> be used for key referencing in such cases.</li>  
</ul>
<div id="sec-Algorithm-2-0-Mode-Conformance" class="section">
<h4><span class="secno">3.2.1 </span>XML Signature 2.0 Algorithm Identifiers and Implementation Requirements</h4>
<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>
<p>Note that the algorithms required for 2.0 conformance are fewer
  than for compatibility mode, and that some algorithms required or
  optional are disallowed in 2.0.
</p>
<dl>
  <dt>Canonicalization</dt>
  <dd><strong>Required</strong></dd>
  <dd>
    <ol>
      <li>Canonical XML 2.0</li>
    </ol>
  </dd>
  <dt>Transform</dt>

  <dd><strong>Required</strong></dd>
  <dd>
<ol><li>XML Signature 2.0 Transform - 
<a href="http://www.w3.org/2010/xmldsig2#transform">http://www.w3.org/2010/xmldsig2#transform</a></li>
</ol>
  </dd>

  <dt>Selection</dt>
  <dd><strong>Required</strong></dd>
  <dd>
<ol>
<li>XML Documents or Fragments -
<a href="http://www.w3.org/2010/xmldsig2#xml">http://www.w3.org/2010/xmldsig2#xml</a></li>
<li>External Binary Data -
<a href="http://www.w3.org/2010/xmldsig2#binaryExternal">http://www.w3.org/2010/xmldsig2#binaryExternal</a></li>
<li>Selection of Binary Data within XML -
<a href="http://www.w3.org/2010/xmldsig2#binaryfromBase64">http://www.w3.org/2010/xmldsig2#binaryfromBase64</a></li>
</ol>
  </dd>
  
  <dt>Verification</dt>
  <dd><strong>Optional</strong></dd>
  <dd>
<ol>
<li>DigestDataLength - 
<a href="http://www.w3.org/2010/xmldsig2#DigestDataLength">http://www.w3.org/2010/xmldsig2#DigestDataLength</a></li>
<li>PositionAssertion - 
<a href="http://www.w3.org/2010/xmldsig2#PositionAssertion">http://www.w3.org/2010/xmldsig2#PositionAssertion</a></li>
<li>IDAttributes - 
<a href="http://www.w3.org/2010/xmldsig2#IDAttributes">http://www.w3.org/2010/xmldsig2#IDAttributes</a></li>
</ol>
  </dd>
</dl>
</div>
</div>
<div id="sec-Compatibility-Mode-Conformance" class="section">
<h3><span class="secno">3.3 </span>Compatibility Mode  Conformance</h3>
<p>An implementation that conforms to this specification <em class="rfc2119" title="may">may</em> be
  conformant to Compatibility Mode. To conform to compatibility mode
 conformance with the following is  required as well as conformance to 
 common conformance requirements described in 
 <a href="#sec-Common-Conformance" class="sectionRef">section 3.1 Common Conformance Requirements</a>.
</p>
<div id="sec-Algorithm-Compatibility-Mode-Conformance" class="section">
<h4><span class="secno">3.3.1 </span>Compatibility Mode Algorithm Identifiers and Implementation Requirements</h4>
<p>The following algorithm support is required for compatibility mode
  (in addition to those required for all modes).</p>
<dl>
  <dt>Canonicalization</dt>
  <dd><strong>Required</strong></dd>
  <dd>
    <ol>
      <li>Canonical XML 1.0 (omits comments)

        <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 (omits comments)

        <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 (omits comments)

        <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

        <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

        <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

        <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

        <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

        <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

        <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="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>
</div>
<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>
<div id="sec-Processing" class="section">
<!--OddPage--><h2><span class="secno">4. </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-SignatureGeneration" class="section">
<h3><span class="secno">4.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>
<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>.
For XML Signature 2.0 signatures (i.e. not XML Signature 1.x or
    "Compatibility Mode" signatures), canonicalization in this step <em class="rfc2119" title="must">must</em>
    use a canonicalization 
algorithm designated as  compatible with XML Signature 2.0. This
    canonicalization  
algorithm <em class="rfc2119" title="should">should</em> be the same as that used for Reference canonicalization.</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 id="sec-ReferenceGeneration-2.0" class="section">
<h3><span class="secno">4.2 </span>Reference Generation</h3>
<p>For each Reference:</p>
<ol>
  <li>Decide how to represent the data object as a <code>dsig2:Selection</code>.</li>
  <li>Use <code>Canonicalization</code> to convert the data object
into an octet stream. This is not required for binary data.</li>
  <li>Calculate the digest value over the resulting data object.</li>
  <li>Create a <code>Reference</code> element, including the <code>dsig2:Selection</code>
element, <code>Canonicalization</code> element, 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 4.1 Signature Generation</a> and
validated in
<a href="#sec-ReferenceCheck-2.0" class="sectionRef">section 4.4 Reference Check</a>.)</li>
</ol>
<p>XML data objects <em class="rfc2119" title="must">must</em> be canonicalized using Canonical XML 2.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>] or an alternative
algorithm that is compliant with its interface.</p>
</div>
<div id="sec-CoreValidation" class="section">
<h3><span class="secno">4.3 </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 </p>
<ol>
  <li>establishing trust in the signing key mentioned in the <code>KeyInfo</code>.

(Note in some environments, the signing key is implicitly known, and <code>KeyInfo</code>
is not used at all).</li>
  <li> Checking each <code>Reference</code> to to see if the data
object matches with the expected data object.</li>
  <li> the cryptographic <a href="#def-ValidationSignature" class="link-def">signature validation</a> of the
signature calculated over <code>SignedInfo</code>.</li>
  <li><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>.</li>
</ol>
These steps are present in ascending order of complexity, which ensures
that the verifier rejects invalid signatures as quickly as possible.
<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> 
<div id="sec-ReferenceCheck-2.0" class="section">
<h3><span class="secno">4.4 </span>Reference Check</h3>
<p>The absence of arbitrary transforms makes reference checking simpler
in XML Signature 2.0. Implementations process the <code>dsig2:Selection</code>
in each <code>Reference</code> to return a list of data objects that
are included in the signature. For example each reference in a
signature may point to a different part of the same document. The
signature implementation should return all these parts (possibly as DOM
elements) to the calling application, which can then compare them against
its policy to make sure what was expected to be signed is actually
signed.</p>
</div>

<div id="sec-ReferenceValidation-2.0" class="section">
<h3><span class="secno">4.5 </span>Reference Validation</h3>
<p>Reference Validation is very similar to that in XML Signature 1.x,
  except that 
<code>SignedInfo</code> need not be canonicalized, there are no arbitrary
transforms to execute, and there is an optional <code>dsig2:Verifications</code>
step.</p>

  For each <code>Reference</code> in <code>SignedInfo</code>:
    <ol>
      <li>Obtain the data object to be digested using the <code>dsig2:Selection</code>.
      <ol>
      <li><i>Optional</i>: If the selection relies on an ID-based reference,
      and there is a <code>dsig2:Verification</code> element with
      <code>Type="http://www.w3.org/2010/xmldsig2#IDAttributes"</code>, then its content may
      assist in obtaining the intended data object by identifying an ID attribute that
      the verifier may not otherwise recognize.</li>
      <li><i>Optional</i>: If the selection relies on an ID-based reference,
      and there is a <code>dsig2:Verification</code> element with
      <code>Type="http://www.w3.org/2010/xmldsig2#PositionAssertion"</code>, then the verifier
      may confirm that the data object obtained is the same as that which would be obtained
      by resolving the XPath expression in the <code>PositionAssertion</code> attribute.</li>
      </ol>
      </li>
      <li>Perform the <code>Canonicalization</code> to compute an octet stream.
      <ol>
      <li><i>Optional</i>: If there is a <code>dsig2:Verification</code> element
      with <code>Type="http://www.w3.org/2010/xmldsig2#DigestDataLength"</code>, then
      verify that the length of the octet stream computed above is the same as the length
      specified in the <code>DigestDataLength</code> attribute.</li>
      </ol>
      </li>
      <li>Digest the resulting data object using the <code>DigestMethod</code>
      specified in its <code>Reference</code> specification. The canonicalization
      and digesting can be combined in one step for efficiency.</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>
</div>
<div id="sec-SignatureValidation-20" class="section">
<h3><span class="secno">4.6 </span>Signature Validation</h3>
<p>Signature Validation in XML Signature 2.0 is very similar to XML
  Signature 1.x, except that <code>KeyInfo</code> cannot contain any
  transforms, and 
the canonicalization of <code>SignatureMethod</code> is not required.
These are the steps. </p>
<ol>
  <li>Obtain the keying information from <code><a href="#sec-KeyInfo">KeyInfo</a></code>
or from an external source.</li>
  <li>Using the <code>CanonicalizationMethod</code>(which must be
Canonical XML 2.0 or an alternative algorithm that is compliant with its interface)
and use the result (and previously obtained <code>KeyInfo</code>)
to confirm the <code>SignatureValue</code> over the <code>SignedInfo</code>
element.</li>
</ol>
</div> 
</div>
<div id="sec-CoreSyntax" class="section">
<!--OddPage--><h2><span class="secno">5. </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
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 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>] with the following XML preamble,
declaration, and internal entity.</p>
<pre class="sh_xml sh_sourceCode">   Schema Definition:

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

   <span class="sh_keyword">&lt;schema</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/XMLSchema"</span>
           <span class="sh_type">xmlns:ds</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span>
           <span class="sh_type">targetNamespace</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span>
           <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"0.1"</span> <span class="sh_type">elementFormDefault</span><span class="sh_symbol">=</span><span class="sh_string">"qualified"</span><span class="sh_keyword">&gt;</span>
</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="sh_xml sh_sourceCode">   <span class="sh_preproc">&lt;?xml</span> <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"1.0"</span> <span class="sh_type">encoding</span><span class="sh_symbol">=</span><span class="sh_string">"utf-8"</span><span class="sh_preproc">?&gt;</span>
   <span class="sh_preproc">&lt;!DOCTYPE</span> <span class="sh_type">schema</span>
     <span class="sh_type">PUBLIC</span><span class="sh_normal"> </span><span class="sh_string">"-//W3C//DTD XMLSchema 200102//EN"</span> <span class="sh_string">"http://www.w3.org/2001/XMLSchema.dtd"</span>
     <span class="sh_type">[</span>
      <span class="sh_type">&lt;!ENTITY</span><span class="sh_normal"> </span><span class="sh_type">dsig</span><span class="sh_normal"> </span><span class="sh_type">'http://www.w3.org/2000/09/xmldsig#'</span><span class="sh_preproc">&gt;</span>
      &lt;!ENTITY dsig11 'http://www.w3.org/2009/xmldsig11#'&gt;
      &lt;!ENTITY % p ''&gt;
      &lt;!ENTITY % s ''&gt;
     ]&gt;

   <span class="sh_keyword">&lt;schema</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/XMLSchema"</span>
           <span class="sh_type">xmlns:ds</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span>
           <span class="sh_type">xmlns:dsig11</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2009/xmldsig11#"</span>
           <span class="sh_type">targetNamespace</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2009/xmldsig11#"</span>
           <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"0.1"</span> <span class="sh_type">elementFormDefault</span><span class="sh_symbol">=</span><span class="sh_string">"qualified"</span><span class="sh_keyword">&gt;</span>
    
</pre>
<p>Finally, markup defined by version 2.0 of this specification uses
the <code>dsig2:</code> namespace. The syntax is defined in an XML
schema with the following preamble:</p>
<pre class="sh_xml sh_sourceCode">   <span class="sh_preproc">&lt;?xml</span> <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"1.0"</span> <span class="sh_type">encoding</span><span class="sh_symbol">=</span><span class="sh_string">"utf-8"</span><span class="sh_preproc">?&gt;</span>
   <span class="sh_keyword">&lt;schema</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/XMLSchema"</span>
           <span class="sh_type">xmlns:ds</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span>
           <span class="sh_type">xmlns:dsig11</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2009/xmldsig11#"</span>
           <span class="sh_type">xmlns:dsig2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#"</span>
           <span class="sh_type">targetNamespace</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#"</span>
           <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"0.1"</span> <span class="sh_type">elementFormDefault</span><span class="sh_symbol">=</span><span class="sh_string">"qualified"</span><span class="sh_keyword">&gt;</span>
    
</pre>




<p>Notwithstanding the presence of a mixed content model (via mixed="true"
declarations) in the definitions of various elements that follow, use of
mixed content in conjunction with any elements defined by this specification
is <em class="rfc2119" title="not recommended">not recommended</em>.</p>

<p>When these elements are used in conjunction with XML Signature 2.0
  signatures, 
mixed content <em class="rfc2119" title="must not">must not</em> be used.</p>

<div id="sec-CryptoBinary" class="section">
<h3><span class="secno">5.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 <code>base64Binary</code>.
For example, if the signature algorithm is RSA or DSA then <code>SignatureValue</code>
represents a bignum and would 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="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;simpleType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"CryptoBinary"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;restriction</span> <span class="sh_type">base</span><span class="sh_symbol">=</span><span class="sh_string">"base64Binary"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;/restriction&gt;</span>
   <span class="sh_keyword">&lt;/simpleType&gt;</span>
</pre>
</div>

<div id="sec-Signature" class="section">
<h3><span class="secno">5.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="sh_xml sh_sourceCode">   Schema Definition:

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

<div id="sec-SignatureValue" class="section">
<h3><span class="secno">5.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="sh_xml sh_sourceCode">   Schema Definition:

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

<div id="sec-SignedInfo" class="section">
<h3><span class="secno">5.4 </span>The <code>SignedInfo</code> Element</h3>
<p>The structure of <code>SignedInfo</code> includes a
canonicalization algorithm, a signature algorithm, and one or more
references. Given the importance of reference processing, this is
  described separately in <a href="#sec-ReferenceProcessing" class="sectionRef">section 6. Referencing Content</a>. 
</p>
<p>
The <code> SignedInfo</code> element may contain an
optional ID attribute allowing 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="sh_xml sh_sourceCode">   Schema Definition:

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

<div id="sec-CanonicalizationMethod" class="section">
<h4><span class="secno">5.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-Algorithm-2-0-Mode-Conformance" class="sectionRef">section 3.2.1 XML Signature 2.0 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>

<pre class="sh_xml sh_sourceCode">   Schema Definition:

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

<p>In XML Signature 2.0, the <code>SignedInfo</code> element is presented as a
single subtree with no exclusions to the Canonicalization 2.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>]
algorithm. Parameters to that algorithm are represented as subelements of
the <code>Canonicalization</code> element.</p>

<p>XML Signature 2.0  signatures use
  the <code>CanonicalizationMethod</code> element 
to express the canonicalization of each <code>Reference</code>.</p>
</div>
<div id="sec-SignatureMethod" class="section">
<h4><span class="secno">5.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-Algorithm-2-0-Mode-Conformance" class="sectionRef">section 3.2.1 XML Signature 2.0 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="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"SignatureMethod"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:SignatureMethodType"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"SignatureMethodType"</span> <span class="sh_type">mixed</span><span class="sh_symbol">=</span><span class="sh_string">"true"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;sequence&gt;</span>
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"HMACOutputLength"</span> <span class="sh_type">minOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"0"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:HMACOutputLengthType"</span><span class="sh_keyword">/&gt;</span>
       <span class="sh_keyword">&lt;any</span> <span class="sh_type">namespace</span><span class="sh_symbol">=</span><span class="sh_string">"##other"</span> <span class="sh_type">minOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"0"</span> <span class="sh_type">maxOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"unbounded"</span><span class="sh_keyword">/&gt;</span>
       <span class="sh_comment">&lt;!-- (0,unbounded) elements from (1,1) external namespace --&gt;</span>
      <span class="sh_keyword">&lt;/sequence&gt;</span>
    <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Algorithm"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span> 
   <span class="sh_keyword">&lt;/complexType&gt;</span>
</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-DigestMethod" class="section">
<h4><span class="secno">5.4.3 </span>The <code>DigestMethod</code> Element</h4>

<p><code>DigestMethod</code> is a required element that identifies the
digest algorithm to be applied to the signed object. This element uses
the general structure here for algorithms specified in <a href="#sec-Algorithm-2-0-Mode-Conformance" class="sectionRef">section 3.2.1 XML Signature 2.0 Algorithm Identifiers and Implementation Requirements</a>.</p>

<p>For "Compatibility Mode" signatures, if the result of the URI
dereference and application of <code>Transforms</code> 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 B.4.1 The "Compatibility Mode" Reference Processing Model</a>. If the
  result of URI 
dereference and application of <code>Transforms</code> is an octet stream,
then no conversion occurs (comments might be present if Canonical XML
with Comments was specified in the <code>Transforms</code>). The digest
algorithm is applied to the data octets of the resulting octet stream.</p>

<p>For  XML Signature 2.0 signatures, the result of processing
  the <code>Reference</code> 
is an octet stream, and the digest algorithm is applied to the resulting data
octets.</p>

<pre class="sh_xml sh_sourceCode">   Schema Definition:

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

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

<p><code>DigestValue</code> 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="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"DigestValue"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:DigestValueType"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;simpleType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"DigestValueType"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;restriction</span> <span class="sh_type">base</span><span class="sh_symbol">=</span><span class="sh_string">"base64Binary"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;/simpleType&gt;</span>
</pre>
</div>
</div>
</div>

<div id="sec-ReferenceProcessing" class="section">
<!--OddPage--><h2><span class="secno">6. </span>Referencing Content</h2>
<p>The XML Signature 2.0 specification is designed to support a new,
simplified processing model while remaining backwardly-compatible with
the older 1.x processing model through optional support of a 
"Compatibility Mode" defined in a separate section of this document,
  <a href="#sec-Compatibility-Mode" class="sectionRef">section B. Compatibility Mode</a>.</p>

<p>A generic signature processor can determine the mode of a signature
by examining the <code>Reference</code> element's attributes and the child
element(s) of the <code>Transforms</code> element (if any). If the
<code>URI</code> attributes is present, "Compatibility Mode" can be assumed.
If the <code>URI</code> attribute is not present, <strong>and</strong> the
<code>Transforms</code> element contains exactly one <code>Transform</code>
element with an <code>Algorithm</code> of <code>"http://www.w3.org/2010/xmldsig2#transform"</code>,
then XML Signature 2.0 processing can be assumed. Otherwise,
"Compatibility Mode" is applied.</p> 

<p>All the references of a signature <em class="rfc2119" title="should">should</em> have the same mode;
i.e. all XML Signature 2.0, or all "Compatibility Mode".</p>

<div id="sec-Reference" class="section">
<h3><span class="secno">6.1 </span>The <code>Reference</code> Element</h3>
<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="sh_xml sh_sourceCode">   Schema Definition:

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

<div id="sec-URI-20" class="section">
<h4><span class="secno">6.1.1 </span>The <code>URI</code> Attribute</h4>
<p>The URI attribute <em class="rfc2119" title="must">must</em> be omitted for XML Signature 2.0 signatures. </p>
</div>
</div>
<div id="sec-Transforms" class="section">
<h3><span class="secno">6.2 </span>The  <code>Transforms</code> Element</h3>
<p>Each <code>Reference</code> <em class="rfc2119" title="must">must</em> contain the <code>Transforms</code> element,
and this <em class="rfc2119" title="must">must</em> contain one and only one <code>Transform</code> element with an
<code>Algorithm</code> of
<code>"http://www.w3.org/2010/xmldsig2#transform"</code>. This signals
the 2.0 syntax and processing (Compatibility mode transforms are 
described in <a href="#sec-TransformsProcessingModel" class="sectionRef">section B.5  "Compatibility Mode" Transforms and Processing Model</a>).</p> 
<pre class="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Transforms"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:TransformsType"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"TransformsType"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;sequence&gt;</span>
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:Transform"</span> <span class="sh_type">maxOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"unbounded"</span><span class="sh_keyword">/&gt;</span>  
     <span class="sh_keyword">&lt;/sequence&gt;</span>
   <span class="sh_keyword">&lt;/complexType&gt;</span>

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

<p>The semantics of the <code>Transform</code> element in XML
  Signature 2.0 is 
that its input is determined solely from within the <code>Transform</code>
itself rather than via the surrounding <code>Reference</code>. The output
is guaranteed to be an octet stream.</p>

<p>The detailed definition of the XML Signature 2.0 <code>Transform</code>
algorithm definitions can be found in 
<a href="#sec-Transforms-2.0" class="sectionRef">section 10.5 The Transform Algorithm</a>.</p>

<p>A difference from XML Signature 1.x (and the corresponding
  "Compatibility Mode") is that the use of
  extensible <code>Transform</code> algorithms is 
  replaced with an extensible syntax for reference
  and selection processing. This construct is modeled as a fixed Transform,
for compatibility with the original schema, and to ensure predictable failure
modes for older implementations.</p>
<p>Legacy implementations should react to this as an undefined <code>Transform</code>
and report failure in the fashion that is normal for them in such a case.</p>
</div>

<div id="sec-Selection" class="section">
<h3><span class="secno">6.3 </span>The <code>dsig2:Selection</code> Element</h3>

<p>The <code>dsig2:Selection</code> element describes the data being signed
for a "2.0 Mode" signature <code>Reference</code>. The content and processing
model for this element depends on the value of the required <code>Algorithm</code>
attribute, which identifies the selection algorithm/syntax in use. The required
<code>URI</code> attribute and any child elements are passed to that algorithm
as parameters to selection processing.</p>

<pre class="sh_xml sh_sourceCode">  Schema Definition:

  <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Selection"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:SelectionType"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;xs:complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:SelectionType"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;xs:sequence&gt;</span>
      <span class="sh_keyword">&lt;xs:any</span> <span class="sh_type">namespace</span><span class="sh_symbol">=</span><span class="sh_string">"##any"</span> <span class="sh_type">processContents</span><span class="sh_symbol">=</span><span class="sh_string">"lax"</span> <span class="sh_type">minOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"0"</span> <span class="sh_type">maxOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"unbounded"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;/xs:sequence&gt;</span>
    <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"URI"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Algorithm"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;/xs:complexType&gt;</span>
</pre>

<p>The <code>Algorithm</code> attribute is an extensibility point
enabling application-specific content selection approaches. Each
<code>Algorithm</code> must define the parameters expected, how
they are expressed within the <code>dsig2:Selection</code> element,
how to process the selection, what user-defined object the selection
produces, and what canonicalization algorithm(s) to allow for unambiguous
conversation of the data into an octet stream.</p>

<p>The result of processing the <code>dsig2:Selection</code> element
  <em class="rfc2119" title="must">must</em> be one of the following:</p> 
<ul>
<li>one or more subtrees with optional exclusions
(see <a href="#sec-subtrees-with-exclusions">Subtrees with Exclusions</a>)</li>
<li>an octet stream</li>
<li>any user-defined object</li>
</ul>

<p>In the first case, the current <code>Signature</code> node is implicitly
added as an exclusion, and then a "2.0 Mode" canonicalization algorithm
(one compatible with these inputs) <em class="rfc2119" title="must">must</em> be applied to produce an octet stream
for the digest algorithm. The contents of the sibling <code>CanonicalizationMethod</code>
element, if present, will specify the algorithm to use, and supply any non-default
parameters to that algorithm. If no sibling <code>CanonicalizationMethod</code>
element is present, then the XML Canonicalization 2.0 Algorithm [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>]
<em class="rfc2119" title="must">must</em> be applied with no non-default parameters.</p>

<p>For an octet stream, no further processing is applied, and the octets are
supplied directly to the digest algorithm.</p>

<p>For a user-defined object (the result of a user-defined selection process),
processing is subject to the definition of that process.</p>

<div id="sec-subtrees-with-exclusions" class="section">
<h4><span class="secno">6.3.1 </span>Subtrees with Optional Exclusions</h4>
<p>Signatures in "2.0 Mode" do not deal with XML content to be signed in terms
of an XPath nodeset. Instead, the following interface is used:</p>

<ul>
<li>An XML fragment to be signed is represented as one or more "inclusion" subtrees,
and a set of zero or more "exclusions" consisting of subtrees and/or attribute nodes.</li>
<li>Exclusions override inclusions; i.e., the selection contains all the nodes
in the inclusion subtrees minus all the nodes in the exclusion subtrees.</li>
<li>A "subtree" is the portion of an XML document consisting of all the descendants
of a particular element node (inclusive), or the document root node. The subtree is
identified by the element node/document root node.</li>
<li>If, in the inclusion list, one subtree is included in another, the included one
is effectively ignored (the two are simply unioned).</li>
<li>Each subtree (except when the subtree is of a complete document) must be accompanied
by the set of namespace declarations in scope (i.e., inherited from the ancestors
of the subtree).</li>
</ul>
</div>


</div>
<div id="sec-Verifications" class="section">
<h3><span class="secno">6.4 </span>The <code>dsig2:Verifications</code> Element</h3>
<p><code>dsig2:Verifications</code> is an optional element containing information
that aids in signature verification. It contains one or more <code>dsig2:Verification</code>
elements identifying the type(s) of verification information available.</p>

<p>Use of the <code>dsig2:Verifications</code> element by validators is optional,
even if the element is present. For example, validators may ignore a
<code>dsig2:Verification</code> element of <code>Type</code>
<code>"http://www.w3.org/2010/xmldsig2#PositionAssertion"</code>,
and rely on ID-based referencing (with the risk of being vulnerable
to signature wrapping attacks unless other steps are taken) for simplicity.</p>

<pre class="sh_xml sh_sourceCode">  Schema Definition:

  <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Verifications"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:VerificationsType"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;xs:complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"VerificationsType"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;xs:sequence&gt;</span>
      <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:Verification"</span> <span class="sh_type">maxOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"unbounded"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;/xs:sequence&gt;</span>
  <span class="sh_keyword">&lt;/xs:complexType&gt;</span>
  
  <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Verification"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:VerificationType"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;xs:complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"VerificationType"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;xs:choice</span> <span class="sh_type">minOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"0"</span> <span class="sh_type">maxOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"unbounded"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;xs:any</span> <span class="sh_type">namespace</span><span class="sh_symbol">=</span><span class="sh_string">"##other"</span> <span class="sh_type">processContents</span><span class="sh_symbol">=</span><span class="sh_string">"lax"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:QualifiedAttr"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:UnqualifiedAttr"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;xs:</span><span class="sh_type">/choice</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Type"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"DigestDataLength"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:nonNegativeInteger"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"PositionAssertion"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:string"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;xs:anyAttribute</span> <span class="sh_type">namespace</span><span class="sh_symbol">=</span><span class="sh_string">"##other"</span> <span class="sh_type">processContents</span><span class="sh_symbol">=</span><span class="sh_string">"lax"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;xs:</span><span class="sh_type">/complexType</span><span class="sh_keyword">&gt;</span>
</pre>
</div>
</div>

<div id="sec-KeyInfo" class="section">
<!--OddPage--><h2><span class="secno">7. </span>The <code>KeyInfo</code> Element</h2>
<p><code>KeyInfo</code> is an optional element that enables the
recipient(s) to obtain the key needed to validate the signature. <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 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 7.2 The KeyValue Element</a>) 
 and <em class="rfc2119" title="should">should</em> implement <code>RetrievalMethod</code> 
(<a href="#sec-RetrievalMethod" class="sectionRef">section 7.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="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"KeyInfo"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:KeyInfoType"</span><span class="sh_keyword">/&gt;</span> 
   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"KeyInfoType"</span> <span class="sh_type">mixed</span><span class="sh_symbol">=</span><span class="sh_string">"true"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;choice</span> <span class="sh_type">maxOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"unbounded"</span><span class="sh_keyword">&gt;</span>     
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:KeyName"</span><span class="sh_keyword">/&gt;</span> 
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:KeyValue"</span><span class="sh_keyword">/&gt;</span> 
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:RetrievalMethod"</span><span class="sh_keyword">/&gt;</span> 
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:X509Data"</span><span class="sh_keyword">/&gt;</span> 
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:PGPData"</span><span class="sh_keyword">/&gt;</span> 
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:SPKIData"</span><span class="sh_keyword">/&gt;</span>
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:MgmtData"</span><span class="sh_keyword">/&gt;</span>
       <span class="sh_comment">&lt;!-- &lt;element ref="dsig11:DEREncodedKeyValue"/&gt; --&gt;</span>
       <span class="sh_comment">&lt;!-- DEREncodedKeyValue (XMLDsig 1.1) will use the any element --&gt;</span>
       <span class="sh_comment">&lt;!-- &lt;element ref="dsig11:KeyInfoReference"/&gt; --&gt;</span>
       <span class="sh_comment">&lt;!-- KeyInfoReference (XMLDsig 1.1) will use the any element --&gt;</span>
       <span class="sh_comment">&lt;!-- &lt;element ref="xenc:EncryptedKey"/&gt; --&gt;</span>
       <span class="sh_comment">&lt;!-- EncryptedKey (XMLEnc) will use the any element --&gt;</span>
       <span class="sh_comment">&lt;!-- &lt;element ref="xenc:Agreement"/&gt; --&gt;</span>
       <span class="sh_comment">&lt;!-- Agreement (XMLEnc) will use the any element --&gt;</span>
       <span class="sh_keyword">&lt;any</span> <span class="sh_type">processContents</span><span class="sh_symbol">=</span><span class="sh_string">"lax"</span> <span class="sh_type">namespace</span><span class="sh_symbol">=</span><span class="sh_string">"##other"</span><span class="sh_keyword">/&gt;</span>
       <span class="sh_comment">&lt;!-- (1,1) elements from (0,unbounded) namespaces --&gt;</span>
     <span class="sh_keyword">&lt;/choice&gt;</span>
     <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Id"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ID"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"optional"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;/complexType&gt;</span>
</pre>
<div id="sec-KeyName" class="section">
<h3><span class="secno">7.1 </span>The <code>KeyName</code> Element</h3>
<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="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"KeyName"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"string"</span><span class="sh_keyword">/&gt;</span>
</pre>
</div>

<div id="sec-KeyValue" class="section">
<h3><span class="secno">7.2 </span>The <code>KeyValue</code> Element</h3>
<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 10.3 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="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"KeyValue"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:KeyValueType"</span><span class="sh_keyword">/&gt;</span> 
   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"KeyValueType"</span> <span class="sh_type">mixed</span><span class="sh_symbol">=</span><span class="sh_string">"true"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;choice&gt;</span>
      <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:DSAKeyValue"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:RSAKeyValue"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_comment">&lt;!-- &lt;element ref="dsig11:ECKeyValue"/&gt; --&gt;</span>
      <span class="sh_comment">&lt;!-- ECC keys (XMLDsig 1.1) will use the any element --&gt;</span>
      <span class="sh_keyword">&lt;any</span> <span class="sh_type">namespace</span><span class="sh_symbol">=</span><span class="sh_string">"##other"</span> <span class="sh_type">processContents</span><span class="sh_symbol">=</span><span class="sh_string">"lax"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;/choice&gt;</span>
   <span class="sh_keyword">&lt;/complexType&gt;</span>
</pre>
<div id="sec-DSAKeyValue" class="section">
<h4><span class="secno">7.2.1 </span>The <code>DSAKeyValue</code> Element</h4>
<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>"

    </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 J is available for inclusion solely for efficiency as it
can be calculated from P and Q. Parameters seed and pgenCounter 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 P and Q value. Parameters P, Q, and G can be public and common to a
group of users. They might be known from application context. As such,
they are optional but P and Q must either both appear or both be
absent. If all of <code>P</code>, <code>Q</code>, <code>seed</code>,
and <code>pgenCounter</code> are present, implementations are not
required to check if they are consistent and are free to use either <code>P</code>
and <code> Q</code> or <code>seed</code> and <code>pgenCounter</code>.
All parameters are encoded as base64
[<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="sh_xml sh_sourceCode">   <code>Schema Definition:</code>

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

<div id="sec-RSAKeyValue" class="section">
<h4><span class="secno">7.2.2 </span>The <code>RSAKeyValue</code> Element</h4>
<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>"

    </code> (this can be used within a <code>RetrievalMethod</code> or
    <code>Reference</code> element to identify the referent's type)</dd>
</dl>
<p>RSA key values have two fields: Modulus and Exponent.</p>
<pre class="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;RSAKeyValue&gt;</span>
  <span class="sh_keyword">&lt;Modulus&gt;</span>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
   jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
   5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
  <span class="sh_keyword">&lt;/Modulus&gt;</span>
  <span class="sh_keyword">&lt;Exponent&gt;</span>AQAB<span class="sh_keyword">&lt;/Exponent&gt;</span>
<span class="sh_keyword">&lt;/RSAKeyValue&gt;</span></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="sh_xml sh_sourceCode">   <code>Schema Definition:</code>

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"RSAKeyValue"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:RSAKeyValueType"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"RSAKeyValueType"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;sequence&gt;</span>
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Modulus"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:CryptoBinary"</span><span class="sh_keyword">/&gt;</span> 
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Exponent"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:CryptoBinary"</span><span class="sh_keyword">/&gt;</span>
     <span class="sh_keyword">&lt;/sequence&gt;</span>
   <span class="sh_keyword">&lt;/complexType&gt;</span>
</pre>
</div>

<div id="sec-ECKeyValue" class="section">
<h4><span class="secno">7.2.3 </span>The <code>dsig11:ECKeyValue</code> Element</h4>
<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>dsig11: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>dsig11:PublicKey</code>. </p>

<pre class="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;ECKeyValue</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2009/xmldsig11#"</span><span class="sh_keyword">&gt;</span>
  <span class="sh_keyword">&lt;NamedCurve</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"urn:oid:1.2.840.10045.3.1.7"</span> <span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;PublicKey&gt;</span>
     vWccUP6Jp3pcaMCGIcAh3YOev4gaa2ukOANC7Ufg
Cf8KDO7AtTOsGJK7/TA8IC3vZoCy9I5oPjRhyTBulBnj7Y
  <span class="sh_keyword">&lt;/PublicKey&gt;</span>
<span class="sh_keyword">&lt;/ECKeyValue&gt;</span></pre>

<p>Note - A line break has been added to the <code>dsig11: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>dsig11:PublicKey</code> element contains the 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="sh_xml sh_sourceCode">    <code>Schema Definition:</code>
    
    <span class="sh_comment">&lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;</span>
    
    <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ECKeyValue"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:ECKeyValueType"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ECKeyValueType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;sequence&gt;</span>
        <span class="sh_keyword">&lt;choice&gt;</span>
          <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ECParameters"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:ECParametersType"</span><span class="sh_keyword">/&gt;</span>
          <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"NamedCurve"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:NamedCurveType"</span><span class="sh_keyword">/&gt;</span>
        <span class="sh_keyword">&lt;/choice&gt;</span>
        <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"PublicKey"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:ECPointType"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;/sequence&gt;</span>
      <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Id"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ID"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"optional"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;/complexType&gt;</span>
    
    <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"NamedCurveType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"URI"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;/complexType&gt;</span>
      
    <span class="sh_keyword">&lt;simpleType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ECPointType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;restriction</span> <span class="sh_type">base</span><span class="sh_symbol">=</span><span class="sh_string">"ds:CryptoBinary"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;/simpleType&gt;</span>
  </pre>
  
<div id="sec-ECParameters" class="section">
<h5><span class="secno">7.2.3.1 </span>Explicit Curve Parameters </h5>
<p>The <code>dsig11: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>dsig11: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>dsig11:Base</code> element specifies the base point P on the elliptic
curve. The base point is represented as a value of type <code>dsig11:ECPointType</code>.</li>
  <li>The <code>dsig11:Order</code> element specifies the order n of the base point and is
encoded as a <code>positiveInteger</code>.</li>
  <li>The <code>dsig11: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="sh_xml sh_sourceCode"><code>Schema Definition:</code>
  
    <span class="sh_comment">&lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;</span>

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

    <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"CurveType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;sequence&gt;</span>
        <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"A"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:CryptoBinary"</span><span class="sh_keyword">/&gt;</span>
        <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"B"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:CryptoBinary"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;/sequence&gt;</span>
    <span class="sh_keyword">&lt;/complexType&gt;</span>

  <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ECValidationDataType"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;sequence&gt;</span>
      <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"seed"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:CryptoBinary"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;/sequence&gt;</span>
    <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"hashAlgorithm"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;/complexType&gt;</span>
  </pre>
  
<p><code>dsig11:Prime</code> fields are described by a single subelement <code>dsig11:P</code>,
which represents the field size in bits. It is encoded as a <code>positiveInteger</code>.</p>
<pre class="sh_xml sh_sourceCode"><code>Schema Definition:</code>
  
   <span class="sh_comment">&lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;</span>
  
    <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Prime"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:PrimeFieldParamsType"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"PrimeFieldParamsType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;sequence&gt;</span>
        <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"P"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:CryptoBinary"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;/sequence&gt;</span>
    <span class="sh_keyword">&lt;/complexType&gt;</span>
  </pre>
  
<p>Structures are defined for three types of characteristic two fields:
gaussian normal basis, pentanomial basis and trinomial basis.</p>
<pre class="sh_xml sh_sourceCode"><code>Schema Definition:</code>
  
   <span class="sh_comment">&lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;</span>
  
    <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"GnB"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:CharTwoFieldParamsType"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"CharTwoFieldParamsType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;sequence&gt;</span>
        <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"M"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"positiveInteger"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;/sequence&gt;</span>
    <span class="sh_keyword">&lt;/complexType&gt;</span>
    
    <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"TnB"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:TnBFieldParamsType"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"TnBFieldParamsType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;complexContent&gt;</span>
        <span class="sh_keyword">&lt;extension</span> <span class="sh_type">base</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:CharTwoFieldParamsType"</span><span class="sh_keyword">&gt;</span>
          <span class="sh_keyword">&lt;sequence&gt;</span>
            <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"K"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"positiveInteger"</span><span class="sh_keyword">/&gt;</span>
          <span class="sh_keyword">&lt;/sequence&gt;</span>
        <span class="sh_keyword">&lt;/extension&gt;</span>
      <span class="sh_keyword">&lt;/complexContent&gt;</span>
    <span class="sh_keyword">&lt;/complexType&gt;</span>

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

<div id="sec-RFC4050Compat" class="section">
<h5><span class="secno">7.2.3.2 </span>Compatibility with RFC 4050</h5>
<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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;ECDSAKeyValue</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmldsig-more#"</span><span class="sh_keyword">&gt;</span>
  <span class="sh_keyword">&lt;DomainParameters&gt;</span>
    <span class="sh_keyword">&lt;NamedCurve</span> <span class="sh_type">URN</span><span class="sh_symbol">=</span><span class="sh_string">"urn:oid:1.2.840.10045.3.1.7"</span> <span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;/DomainParameters&gt;</span>
  <span class="sh_keyword">&lt;PublicKey&gt;</span>
      <span class="sh_keyword">&lt;X</span> <span class="sh_type">Value</span><span class="sh_symbol">=</span><span class="sh_string">"5851106065380174439324917904648283332</span>
<span class="sh_string">0204931884267326155134056258624064349885"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;Y</span> <span class="sh_type">Value</span><span class="sh_symbol">=</span><span class="sh_string">"1024033521368277752409102672177795083</span>
<span class="sh_string">59028642524881540878079119895764161434936"</span><span class="sh_keyword">&gt;</span>
  <span class="sh_keyword">&lt;/PublicKey&gt;</span>
<span class="sh_keyword">&lt;/ECDSAKeyValue&gt;</span></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">
<h3><span class="secno">7.3 </span>The <code>RetrievalMethod</code> Element</h3>
<p>A <code>RetrievalMethod</code> element within <code>KeyInfo</code>
is used to convey a reference to <code>KeyInfo</code> information that
is stored at another location. For example, several signatures in a
document might use a key verified by an X.509v3 certificate chain
appearing once in the document or remotely outside the document; each
signature's <code>KeyInfo</code> can reference this chain using a
single <code>RetrievalMethod</code> element instead of including the
entire chain with a sequence of <code>X509Certificate</code> elements.</p>
<p><code>RetrievalMethod</code> uses the same syntax and dereferencing
behavior as <a href="#sec-URI" class="sectionRef">section B.4 The URI Attribute in "Compatibility Mode"</a>
  and <a href="#sec-ReferenceProcessingModel" class="sectionRef">section B.4.1 The "Compatibility Mode" 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 <code>KeyInfo</code> types defined by
this specification (<a href="#sec-KeyInfo" class="sectionRef">section 7. 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.
</p>
<p>Transforms in <code>RetrievalMethod</code> are more attack prone,
since they need to be evaluated in the first step of the
signature validation, where the trust in the key has not yet been
established, and the <code>SignedInfo</code> has not yet been
verified. As noted in the [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-BESTPRACTICES">XMLDSIG-BESTPRACTICES</a></cite>] an attacker can easily
causes a Denial of service, by adding a specially crafted transform in
the <code>RetrievalMethod</code> without even bothering to have the
key validate or the signature match. </p>

<p>In  XML Signature 2.0, <code>Transforms</code> are not allowed in <code>RetrievalMethod</code>.
Use of <code>dsig11:KeyInfoReference</code> is encouraged instead, see
<a href="#sec-KeyInfoReference" class="sectionRef">section 7.10 The dsig11:KeyInfoReference Element</a>.</p>

<pre class="sh_xml sh_sourceCode">   Schema Definition

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"RetrievalMethod"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:RetrievalMethodType"</span><span class="sh_keyword">/&gt;</span> 
   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"RetrievalMethodType"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;sequence&gt;</span>
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:Transforms"</span> <span class="sh_type">minOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"0"</span><span class="sh_keyword">/&gt;</span> 
     <span class="sh_keyword">&lt;/sequence&gt;</span>  
     <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"URI"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"anyURI"</span><span class="sh_keyword">/&gt;</span>
     <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Type"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"optional"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;/complexType&gt;</span>
</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">
  <h3><span class="secno">7.4 </span>The <code>X509Data</code> Element</h3>

  <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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;KeyInfo&gt;</span>
  <span class="sh_keyword">&lt;X509Data&gt;</span> <span class="sh_comment">&lt;!-- two pointers to certificate-A --&gt;</span>
    <span class="sh_keyword">&lt;X509IssuerSerial&gt;</span> 
      <span class="sh_keyword">&lt;X509IssuerName&gt;</span><span class="tx">CN=TAMURA Kent, OU=TRL, O=IBM, 
        L=Yamato-shi, ST=Kanagawa, C=JP</span><span class="sh_keyword">&lt;/X509IssuerName&gt;</span>
      <span class="sh_keyword">&lt;X509SerialNumber&gt;</span>12345678<span class="sh_keyword">&lt;/X509SerialNumber&gt;</span>
    <span class="sh_keyword">&lt;/X509IssuerSerial&gt;</span>
    <span class="sh_keyword">&lt;X509SKI&gt;</span>31d97bd7<span class="sh_keyword">&lt;/X509SKI&gt;</span> 
  <span class="sh_keyword">&lt;/X509Data&gt;</span>
  <span class="sh_keyword">&lt;X509Data&gt;</span><span class="sh_comment">&lt;!-- single pointer to certificate-B --&gt;</span>
    <span class="sh_keyword">&lt;X509SubjectName&gt;</span>Subject of Certificate B<span class="sh_keyword">&lt;/X509SubjectName&gt;</span>
  <span class="sh_keyword">&lt;/X509Data&gt;</span>
  <span class="sh_keyword">&lt;X509Data&gt;</span> <span class="sh_comment">&lt;!-- certificate chain --&gt;</span>
    <span class="sh_comment">&lt;!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4--&gt;</span>
    <span class="sh_keyword">&lt;X509Certificate&gt;</span>MIICXTCCA..<span class="sh_keyword">&lt;/X509Certificate&gt;</span>
    <span class="sh_comment">&lt;!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US </span>
<span class="sh_comment">         issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US --&gt;</span>
    <span class="sh_keyword">&lt;X509Certificate&gt;</span>MIICPzCCA...<span class="sh_keyword">&lt;/X509Certificate&gt;</span>
    <span class="sh_comment">&lt;!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US --&gt;</span>
    <span class="sh_keyword">&lt;X509Certificate&gt;</span>MIICSTCCA...<span class="sh_keyword">&lt;/X509Certificate&gt;</span>
  <span class="sh_keyword">&lt;/X509Data&gt;</span>
<span class="sh_keyword">&lt;/KeyInfo&gt;</span></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>Deployments that expect to make use of the <code>X509IssuerSerial</code> element should
be aware that many Certificate Authorities issue certificates with large,
random serial numbers. XML Schema validators may not support integer types
with decimal data exceeding 18 decimal digits [XML-schema]. Therefore such
deployments should avoid schema-validating the <code>X509IssuerSerial</code> element, or
make use of a local copy of the schema that adjusts the data type of the
<code>X509SerialNumber</code> child element from <code>"integer"</code> to <code>"string"</code>.</p>

<div id="dname-encrules" class="section">
<h4><span class="secno">7.4.1 </span>Distinguished Name Encoding Rules</h4>
<p>To encode a distinguished name (<code>X509IssuerSerial</code>,<code>X509SubjectName</code>,
and <code>KeyName</code> if appropriate), the encoding rules in
section 2 of RFC 4514 [<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="sh_xml sh_sourceCode">   Schema Definition

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509Data"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:X509DataType"</span><span class="sh_keyword">/&gt;</span> 
   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509DataType"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;sequence</span> <span class="sh_type">maxOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"unbounded"</span><span class="sh_keyword">&gt;</span>
       <span class="sh_keyword">&lt;choice&gt;</span>
         <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509IssuerSerial"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:X509IssuerSerialType"</span><span class="sh_keyword">/&gt;</span>
         <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509SKI"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"base64Binary"</span><span class="sh_keyword">/&gt;</span>
         <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509SubjectName"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"string"</span><span class="sh_keyword">/&gt;</span>
         <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509Certificate"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"base64Binary"</span><span class="sh_keyword">/&gt;</span>
         <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509CRL"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"base64Binary"</span><span class="sh_keyword">/&gt;</span>
         <span class="sh_comment">&lt;!-- &lt;element ref="dsig11:OCSPResponse"/&gt; --&gt;</span>
         <span class="sh_comment">&lt;!-- &lt;element ref="dsig11:X509Digest"/&gt; --&gt;</span>
         <span class="sh_comment">&lt;!-- OCSPResponse and X509Digest elements (XMLDsig 1.1) will use the any element --&gt;</span>
         <span class="sh_keyword">&lt;any</span> <span class="sh_type">namespace</span><span class="sh_symbol">=</span><span class="sh_string">"##other"</span> <span class="sh_type">processContents</span><span class="sh_symbol">=</span><span class="sh_string">"lax"</span><span class="sh_keyword">/&gt;</span>
       <span class="sh_keyword">&lt;/choice&gt;</span>
     <span class="sh_keyword">&lt;/sequence&gt;</span>
   <span class="sh_keyword">&lt;/complexType&gt;</span>

   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509IssuerSerialType"</span><span class="sh_keyword">&gt;</span> 
     <span class="sh_keyword">&lt;sequence&gt;</span> 
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509IssuerName"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"string"</span><span class="sh_keyword">/&gt;</span> 
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509SerialNumber"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"integer"</span><span class="sh_keyword">/&gt;</span> 
     <span class="sh_keyword">&lt;/sequence&gt;</span>
   <span class="sh_keyword">&lt;/complexType&gt;</span>

   <span class="sh_comment">&lt;!-- Note, this schema permits </span><code><span class="sh_comment">X509Data</span></code><span class="sh_comment"> to be empty; this is </span>
<span class="sh_comment">   precluded by the text in </span><a href="#sec-KeyInfo" class="sectionRef">section 7. The KeyInfo Element</a><span class="sh_comment"> which states </span>
<span class="sh_comment">   that at least one element from the dsig namespace should be present </span>
<span class="sh_comment">   in the PGP, SPKI, and X509 structures. This is easily expressed for </span>
<span class="sh_comment">   the other key types, but not for X509Data because of its rich </span>
<span class="sh_comment">   structure. --&gt;</span>
</pre>
<pre class="sh_xml sh_sourceCode">  <span class="sh_comment">&lt;!-- targetNameSpace="http://www.w3.org/2009/xmldsig11#" --&gt;</span>
  
  <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"OCSPResponse"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"base64Binary"</span> <span class="sh_keyword">/&gt;</span>
  
  <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509Digest"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:X509DigestType"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"X509DigestType"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;simpleContent&gt;</span>
      <span class="sh_keyword">&lt;extension</span> <span class="sh_type">base</span><span class="sh_symbol">=</span><span class="sh_string">"base64Binary"</span><span class="sh_keyword">&gt;</span>
        <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Algorithm"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;/extension&gt;</span>
    <span class="sh_keyword">&lt;/simpleContent&gt;</span>
  <span class="sh_keyword">&lt;/complexType&gt;</span>
</pre>
</div> </div>

<div id="sec-PGPData" class="section">
<h3><span class="secno">7.5 </span>The <code>PGPData</code> Element</h3>
<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>
"

(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="sh_xml sh_sourceCode">   Schema Definition:

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

<div id="sec-SPKIData" class="section">
<h3><span class="secno">7.6 </span>The <code>SPKIData</code> Element</h3>
<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>
"

(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="sh_xml sh_sourceCode">   Schema Definition:

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

<div id="sec-MgmtData" class="section">
<h3><span class="secno">7.7 </span>The <code>MgmtData</code> Element</h3>
<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>
"

(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 7.8 XML Encryption EncryptedKey
and DerivedKey Elements</a> describes
 new <code>KeyInfo</code> 
types for conveying key information.
<pre class="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"MgmtData"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"string"</span><span class="sh_keyword">/&gt;</span>
  </pre>
</div>

<div id="sec-keyconvenance" class="section">
<h3><span class="secno">7.8 </span>XML Encryption <code>EncryptedKey</code>
and <code>DerivedKey</code> Elements</h3>
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">
<h3><span class="secno">7.9 </span>The <code>dsig11:DEREncodedKeyValue</code> Element</h3>
<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="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_comment">&lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;</span>
  <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"DEREncodedKeyValue"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig11:DEREncodedKeyValueType"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"DEREncodedKeyValueType"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;simpleContent&gt;</span>
      <span class="sh_keyword">&lt;extension</span> <span class="sh_type">base</span><span class="sh_symbol">=</span><span class="sh_string">"base64Binary"</span><span class="sh_keyword">&gt;</span>
        <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Id"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ID"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"optional"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;/extension&gt;</span>
    <span class="sh_keyword">&lt;/simpleContent&gt;</span>
  <span class="sh_keyword">&lt;/complexType&gt;</span>
</pre>
<p>

Historical note: The <code>dsig11: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 7.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>dsig11:DEREncodedKeyValue</code>
element is not a child of <code>KeyValue</code>. The <code>dsig11:DEREncodedKeyValue</code>
element is also not a child of the
<code>X509Data</code> element, as the keys represented
by <code>dsig11: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">
<h3><span class="secno">7.10 </span>The <code>dsig11:KeyInfoReference</code> Element</h3>
<p>A <code>dsig11: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>dsig11:KeyInfoReference</code>
element instead of including the entire chain with a sequence of
<code>X509Certificate</code> elements repeated in multiple places.</p>

<p><code>dsig11:KeyInfoReference</code> uses the same syntax and dereferencing
behavior as <code>Reference</code>'s <code>URI</code> (
<a href="#sec-URI" class="sectionRef">section B.4 The URI Attribute in "Compatibility Mode"</a>) and the Reference
Processing Model 
(<a href="#sec-ReferenceProcessingModel" class="sectionRef">section B.4.1 The "Compatibility Mode" 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>dsig11: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>dsig11: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, and are precluded when
using XML Signature 2.0 signatures.</p>

<pre class="sh_xml sh_sourceCode">Schema Definition

   <span class="sh_comment">&lt;!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --&gt;</span>

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

</div>    
</div>

<div id="sec-Object" class="section">
<!--OddPage--><h2><span class="secno">8. </span>The <code>Object</code> Element</h2>
<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 that require normative type and encoding information for 
signature validation should rely on <code>Algorithm</code> in 
the <code><a href="#sec-Selection">dsig2:Selection</a></code> element ("2.0 Mode") 
or specify <code><a href="#sec-Transforms">Transforms</a></code>
with well defined resulting types and/or encodings ("Compatibility Mode").

</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 using standard Referencing mechanisms. e.g.</p>
<ul>
 <li>if the data object is a single XML subtree, then use an ID based reference to the data object.</li>
 <li>if the data object is multiple XML subtrees under the <code>&lt;Object&gt;</code> tag, 
 then use an <a href="#sec-XPath">XPath Transform</a> ("Compatibility Mode")
 or <code><a href="#sec-Type-xml">dsig2:IncludedXPath</a></code> ("2.0 Mode")
 to refer to these nodes. Note in "2.0 Mode" it is not possible to refer to non-element nodes.</li>
 <li>if the data object is base64 text, then use a Base64 transform 
 ("Compatibility Mode") or <code>dsig2:Selection</code> with a 
 <code><a href="#sec-Type-Binary-fromBase64Node">Algorithm="http://www.w3.org/2010/xmldsig2#binaryfromBase64"</a></code>
 ("2.0 Mode")</li> 
 <li>if the data is something else, then use a custom <code>Transform</code>
 ("Compatibility Mode") or <code>dsig2:Selection</code> ("2.0 Mode").</li>
</ul> 
<p>
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 Object 
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="sh_xml sh_sourceCode">   Schema Definition:

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

<div id="sec-AdditionalSyntax" class="section">
<!--OddPage--><h2><span class="secno">9. </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">9.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>

    </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="sh_xml sh_sourceCode">   Schema Definition:

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

<div id="sec-SignatureProperties" class="section">
<h3><span class="secno">9.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>"

    </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="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"SignatureProperties"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ds:SignaturePropertiesType"</span><span class="sh_keyword">/&gt;</span> 
   <span class="sh_keyword">&lt;complexType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"SignaturePropertiesType"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;sequence&gt;</span>
       <span class="sh_keyword">&lt;element</span> <span class="sh_type">ref</span><span class="sh_symbol">=</span><span class="sh_string">"ds:SignatureProperty"</span> <span class="sh_type">maxOccurs</span><span class="sh_symbol">=</span><span class="sh_string">"unbounded"</span><span class="sh_keyword">/&gt;</span> 
     <span class="sh_keyword">&lt;/sequence&gt;</span>
     <span class="sh_keyword">&lt;attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Id"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"ID"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"optional"</span><span class="sh_keyword">/&gt;</span> 
   <span class="sh_keyword">&lt;/complexType&gt;</span>

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

<div id="sec-PI" class="section">
<h3><span class="secno">9.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 canonicalization algorithms 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">9.4 </span>Comments in Signature Elements</h3>
<p>XML comments are not used by this specification.</p>
<p>Note that unless the <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">10. </span>Algorithms</h2>
<div id="sec-MessageDigests" class="section">
<h3><span class="secno">10.1 </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">10.1.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>
<div class="note">
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.
</div>
<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="example sh_xml sh_sourceCode"><code><span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"</span></code><span style="font-weight: normal;"><span class="sh_string">http://www.w3.org/2000/09/xmldsig#</span></span><code><span class="sh_string">sha1"</span><span class="sh_keyword">/&gt;</span></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="example sh_xml sh_sourceCode">A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D</pre>
<p>from Appendix A of the SHA-1 standard would be:</p>
<pre class="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;DigestValue&gt;</span>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=<span class="sh_keyword">&lt;/DigestValue&gt;</span></pre>
</div> <div id="sec-SHA-256" class="section">
<h4><span class="secno">10.1.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">10.1.3 </span>SHA-384</h4>
<dl>
  <dt>Identifier:</dt>
  <dd><a id="sha-384" href="http://www.w3.org/2000/09/xmldsig#sha384">http://www.w3.org/2000/09/xmldsig#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">10.1.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">10.2 </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">10.2.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. 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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;SignatureMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#hmac-sha1"</span><span class="sh_keyword">&gt;</span>
   <span class="sh_keyword">&lt;HMACOutputLength&gt;</span>128<span class="sh_keyword">&lt;/HMACOutputLength&gt;</span>
<span class="sh_keyword">&lt;/SignatureMethod&gt;</span></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="example sh_xml sh_sourceCode">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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;SignatureValue&gt;</span>kpRyejY4uxwT9I74FYv8nQ==<span class="sh_keyword">&lt;/SignatureValue&gt;</span></pre>
<pre class="sh_xml sh_sourceCode">   Schema Definition:

   <span class="sh_keyword">&lt;simpleType</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"HMACOutputLengthType"</span><span class="sh_keyword">&gt;</span>
     <span class="sh_keyword">&lt;restriction</span> <span class="sh_type">base</span><span class="sh_symbol">=</span><span class="sh_string">"integer"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;/simpleType&gt;</span>
</pre>
</div>
</div>

<div id="sec-SignatureAlg" class="section">
<h3><span class="secno">10.3 </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">10.3.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>]. 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). FIPS 186-3 defines four valid pairs of
(L, N); they are: (1024, 160), (2048, 224), (2048, 256) and (3072,
256). 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>.
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>. This
specification does not use the (2048, 224) instance of DSA (which
corresponds to DSAwithSHA224).</p>
<p>DSA takes no explicit parameters; an example of a DSA <code>SignatureMethod</code>
element is:</p>
<pre class="sh_xml sh_sourceCode">   <code><span class="sh_keyword">&lt;SignatureMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2009/xmldsig11#dsa-sha256"</span><span class="sh_keyword">/&gt;</span></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="example sh_xml sh_sourceCode"><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="example sh_xml sh_sourceCode"><code><span class="sh_keyword">&lt;SignatureValue&gt;</span></code>
<code>i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==<span class="sh_keyword">&lt;/SignatureValue&gt;</span></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">10.3.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="example sh_xml sh_sourceCode"><code><span class="sh_keyword">&lt;SignatureMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#rsa-sha1"</span><span class="sh_keyword">/&gt;</span></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="">

   CRYPT (PAD (ASN.1 (OID, DIGEST (data))))

</pre>



  <p>Note that the padded ASN.1 will be of the following form:</p>

  <pre class="">

   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="">

   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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;SignatureValue&gt;</span>
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
<span class="sh_keyword">&lt;/SignatureValue&gt;</span></pre>
<h5 id="security-considerations-regarding-rsa-key-sizes">Security considerations regarding RSA key sizes</h5>
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. </div> <div id="sec-ECDSA" class="section">
<h4><span class="secno">10.3.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="example sh_xml sh_sourceCode"><code>
    <span class="sh_keyword">&lt;SignatureMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"</span><span class="sh_keyword">/&gt;</span>
  </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-2.0" class="section">
<h3><span class="secno">10.4 </span>Canonicalization Algorithms</h3>

<p>The input to any canonicalization algorithm compatible with XML
  Signature 2.0 signatures 
is a set of document subtrees and exclusions in the form of subtrees
  or XML attributes. 
The actual representation of these inputs depends on the processing
  model and may be 
in terms of DOM nodes or representations suitable for streaming-based processing.
The output is an octet stream.</p>

<p><strong>Note:</strong> The input passed to "2.0 Mode" canonicalization algorithms
<em class="rfc2119" title="must">must</em> always exclude the current <code>Signature</code> element node (i.e., the <code>Signature</code>
<em class="rfc2119" title="must">must</em> be passed as one of the exclusion elements. This is equivalent to an implicit
Enveloped Signature Transform in "Compatibility Mode", and has no effect for
non-enveloped signatures.</p>

<p>This specification REQUIRES implementation of Canonical XML 2.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>].
Applications <em class="rfc2119" title="may">may</em> support other canonicalization algorithms with the same input model
(subtrees with exclusions). A <code>Reference</code> to non-XML data may not use
canonicalization at all, or may use a custom canonicalization algorithm with this
input model or a completely different one.</p>

<div id="sec-c14nAlg2" class="section">

<h4><span class="secno">10.4.1 </span>Canonical XML 2.0</h4>

<dl>
  <dt>Identifier for Canonical XML 2.0:</dt>
  <dd><a href="http://www.w3.org/2010/xml-c14n2">http://www.w3.org/2010/xml-c14n2</a></dd>
</dl>

<p>An example of a Canonical XML 2.0 element is:</p>
<pre class="example sh_xml sh_sourceCode"><code><span class="sh_keyword">&lt;CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span>
  <span class="sh_type">xmlns:c14n2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span><span class="sh_keyword">&gt;</span>
  <span class="sh_keyword">&lt;c14n2:PrefixRewrite&gt;</span>sequential<span class="sh_keyword">&lt;/c14n2:PrefixRewrite&gt;</span>
  <span class="sh_keyword">&lt;c14n2:TrimTextNodes&gt;</span>true<span class="sh_keyword">&lt;/c14n2:TrimTextNodes&gt;</span>
  <span class="sh_keyword">&lt;c14n2:QNameAware&gt;</span>
    <span class="sh_keyword">&lt;c14n2:QualifiedAttr</span> <span class="sh_type">Name</span><span class="sh_symbol">=</span><span class="sh_string">"type"</span> <span class="sh_type">NS</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/XMLSchema-instance"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;/c14n2:QNameAware&gt;</span>
<span class="sh_keyword">&lt;/CanonicalizationMethod&gt;</span>
</code></pre>

<p>There is no Canonical XML 2.0 <code>Transform</code>. Instead the same <code>CanonicalizationMethod</code>
element is reused within the <code>dsig2:Selection</code> element for specifying canonicalization of
referenced data,</p>

<p>The normative specification of Canonical XML 2.0 is [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-C14N20">XML-C14N20</a></cite>].</p>
</div>
</div>

<div id="sec-Transforms-2.0" class="section">
<h3><span class="secno">10.5 </span>The <code>Transform</code> Algorithm</h3>

<p>In XML Signature 2.0, the <code>Transforms</code> element contains
exactly one <code>Transform</code> element with an <code>Algorithm</code> of
<code>"http://www.w3.org/2010/xmldsig2#transform"</code>. This transform
encapsulates the process of selecting the content to sign, canonicalizing it,
and attaching optional material that may aid the verifier.</p>

<p>This fixed <code>Transform</code> element consists of a single required
<code>dsig2:Selection</code> element, followed by an optional
<code>CanonicalizationMethod</code> element, and an optional
<code>dsig2:Verifications</code> element.</p>
</div>

<div id="sec-SelectionAlgorithms" class="section">
<h3><span class="secno">10.6 </span><code>dsig2:Selection</code> Algorithms</h3>


<div id="sec-Type-xml" class="section">
<h4><span class="secno">10.6.1 </span>Selection of XML Documents or Fragments</h4>

<dl>
  <dt>Identifier:</dt>
  <dd><a id="xml" href="http://www.w3.org/2010/xmldsig2#xml">http://www.w3.org/2010/xmldsig2#xml</a></dd>
</dl>

<p>This <code>dsig2:Selection</code> algorithm allows the selection of XML documents
or fragments.</p>

<p>The required <code>URI</code> attribute can be an external or same-document reference.
External references are parsed into an XML document or event stream for the subsequent
selection process to operate upon. </p>
<ul>
 <li>Same-document references take the form of an empty
value (e.g <code>URI=""</code>) or a fragment (e.g <code>URI="#foo"</code>). The former refers
to the entire document, while the latter refers to a subtree rooted at the element with
the "ID" contained in the fragment.</li>
 <li>External references may be complete external documents (e.g. <code>URI="http://example.com/bar.xml"</code>)
or refer to fragments of external documents (e.g. <code>URI="http://example.com/bar.xml#chapter1"</code>).</li>
</ul>


<p>The differences between the processing, and allowed syntax, of this <code>URI</code>
attribute and that of a "Compatibility Mode" <code>Reference</code> <code>URI</code> are:</p>
<ul>
    <li>Dereferencing a same-document reference does not result in a XPath node set.</li>
    <li>The <code>xpointer</code> syntax is not permitted.</li>
    <li>There is no comment node removal during the dereferencing process.</li>
</ul>

<p>The <code>dsig2:IncludedXPath</code> <em class="rfc2119" title="must not">must not</em> be present, if the <code>URI</code> contains a fragment identifier.
The <code>dsig2:ExcludedXPath</code> maybe present even if there is a fragment identifier. I.e 
the <code>dsig2:Selection</code> <em class="rfc2119" title="must">must</em> have one of the following</p>
<ul>
  <li><code>URI</code> attribute with or without a fragment identifier. </li>
  <li><code>URI</code>  attribute with or without a fragment identifier, and one <code>dsig2:ExcludedXPath</code> parameter element. </li>
  <li>Non-fragment <code>URI</code> attribute and one <code>dsig2:IncludedXPath</code> parameter element. </li>
  <li>Non-fragment <code>URI</code> attribute, one <code>dsig2:IncludedXPath</code> parameter element and one <code>dsig2:ExcludedXPath</code> parameter element. </li>
</ul>
 
<p>Note: When an <code>IncludedXPath</code> or <code>ExcludedXPath</code> selects an element node, it 
implies that the whole subtree rooted at that element is included or excluded. </p>
 
<p>Processing of the selection and parameters is as follows:</p>
<ol>
<li>Remove the fragment part of the URI if present, and then dereference the URI into a XML document.</li>
<li>Do one of the following:
<ul>
<li>If there is a fragment identifier in the URI, search for an element with the ID in the fragment, and then add the element to the "inclusion" list.</li>
<li>OR If the <code>IncludedXPath</code> element is present, evaluate this XPath at the root of document 
to select element node(s),then add them to the "inclusion" list.</li>
<li>OR If neither the fragment identifier or IncludedXPath is present, then add the document node to the "inclusion" list.</li>
</ul></li>
<li>If the <code>dsig2:ExcludedXPath</code> is present,  
evaluate it at the root of the document to select element and or attribute nodes(s),
then add them to the "exclusion list".
</li>
<li>Add the current
<code>Signature</code> element under computation/evaluation to the "exclusion list".</li>
</ol>

<p>The result of the selection process is a set of one or more element nodes, 
and a set of zero or more exclusions
consisting of element and/or attribute nodes.</p>

<p>Note: In a "streaming mode" of evaluation, the XPath evaluation, the canonicalizaion and digesting need 
to happen in a pipeline. This is described in Section "2.1 Streaming for XPath Signatures" 
in [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-XPATH">XMLDSIG-XPATH</a></cite>].
</p>

<div id="sec-IncludedXPath" class="section">
<h5><span class="secno">10.6.1.1 </span>The <code>dsig2:IncludedXPath</code> Element</h5>

<p>The <code>dsig2:IncludedXPath</code> element is used in conjunction with XML-based
<code>dsig2:Selection</code> algorithms to specify the subtree(s) to include in a
selection. The element contains an XPath 1.0 expression that is evaluated in the context
of the root of the XML document.</p>

<p>For example, <code>"/Book/Chapter"</code> refers to the subtrees rooted
by all <code>Chapter</code> child elements of all <code>Book</code> child elements 
of the document root.</p>

<p>The XPath 1.0 expression <em class="rfc2119" title="must">must</em> evaluate only to element nodes, and <em class="rfc2119" title="must">must</em> conform to the
XML Signature Streaming Profile of XPath 1.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-XPATH">XMLDSIG-XPATH</a></cite>]. Implementations are not
required to use a streaming XPath processor, but the expressions used <em class="rfc2119" title="must">must</em> conform to the
streaming profile to ensure compatibility with implementations that do use a streaming
processor.</p>

<pre class="sh_xml sh_sourceCode">  Schema Definition:

  <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"IncludedXPath"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:string"</span><span class="sh_keyword">/&gt;</span>
</pre>
</div>

<div id="sec-ExcludedXPath" class="section">
<h5><span class="secno">10.6.1.2 </span>The <code>dsig2:ExcludedXPath</code> Element</h5>

<p>The <code>dsig2:ExcludedXPath</code> element is used in conjunction with XML-based
<code>dsig2:Selection</code> algorithms to specify subtree(s) and/or attributes
to exclude from a selection. The element contains an XPath 1.0 expression that is
evaluated in the context of the root of the XML document.</p>

<p>For example, <code>"/Book/Chapter"</code> refers to the subtrees rooted
by all <code>Chapter</code> child elements of all <code>Book</code> child elements 
of the document root.</p>

<p>The XPath 1.0 expression <em class="rfc2119" title="must">must</em> evaluate to element and/or attribute nodes, and <em class="rfc2119" title="must">must</em>
conform to the XML Signature Streaming Profile of XPath 1.0 [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-XPATH">XMLDSIG-XPATH</a></cite>].
Implementations are not required to use a streaming XPath processor, but the expressions
used <em class="rfc2119" title="must">must</em> conform to the streaming profile to ensure compatibility with implementations
that do use a streaming processor.</p>

<pre class="sh_xml sh_sourceCode">  Schema Definition:

  <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ExcludedXPath"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:string"</span><span class="sh_keyword">/&gt;</span>
</pre>
</div>

<div id="sec-ByteRange" class="section">
<h5><span class="secno">10.6.1.3 </span>The <code>dsig2:ByteRange</code> Element</h5>

<p>The <code>dsig2:ByteRange</code> element is used in conjunction with binary
<code>dsig2:Selection</code> algorithms to specify byte range subsets of the
originally selected octet stream to include.</p>

<p>The element value <em class="rfc2119" title="must">must</em> conform to the Byte Ranges syntax described in section
14.35.1 of [<cite><a class="bibref" rel="biblioentry" href="#bib-HTTP11">HTTP11</a></cite>].</p>

<p>For example, element content of <code>0-20,220-270,320-</code> indicates
that the first 21 bytes, then bytes 220 through 270, and finally bytes 320
through the rest of the stream are included.</p>

<pre class="sh_xml sh_sourceCode">  Schema Definition:

  <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ByteRange"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:string"</span><span class="sh_keyword">/&gt;</span>
</pre>
</div>

</div>

<div id="sec-Type-Binary-fromURI" class="section">
<h4><span class="secno">10.6.2 </span>Selection of External Binary Data</h4>

<dl>
  <dt>Identifier:</dt>
  <dd><a id="binaryExternal" href="http://www.w3.org/2010/xmldsig2#binaryExternal">http://www.w3.org/2010/xmldsig2#binaryExternal</a></dd>
</dl>

<p>This <code>dsig2:Selection</code> algorithm allows the selection of external binary data.</p>

<p>The required <code>URI</code> attribute <em class="rfc2119" title="must">must</em> be an external reference and the result
of dereferencing it is treated as an octet stream.</p>

<p>The <code>dsig2:Selection</code> element <em class="rfc2119" title="may">may</em> contain at most one
<code>dsig2:ByteRange</code> parameter element to modify the selection result.
If present, the range(s) indicated modify the resulting octet stream obtained from
the <code>URI</code>. The implementation <em class="rfc2119" title="may">may</em> incorporate the byte range into the
dereferencing process as an optimization.</p>

<p>The final result of the selection process is an octet stream.</p>
</div>

<div id="sec-Type-Binary-fromBase64Node" class="section">
<h4><span class="secno">10.6.3 </span>Selection of Binary Data within XML</h4>

<dl>
  <dt>Identifier:</dt>
  <dd><a id="binaryfromBase64" href="http://www.w3.org/2010/xmldsig2#binaryfromBase64">http://www.w3.org/2010/xmldsig2#binaryfromBase64</a></dd>
</dl>

<p>This <code>dsig2:Selection</code> algorithm allows the selection of
base64-encoded binary data from a Text node within an XML document.</p>

<p>The required <code>URI</code> attribute can be an external or same-document reference.
External references are parsed into an XML document or event stream for the subsequent
selection process to operate upon. </p>
<ul>
 <li>Same-document references take the form of an empty
value (e.g <code>URI=""</code>) or a fragment (e.g <code>URI="#foo"</code>). The former refers
to the entire document, while the latter refers to a subtree rooted at the element with
the "ID" contained in the fragment.</li>
 <li>External references may be complete external documents (e.g. <code>URI="http://example.com/bar.xml"</code>)
or refer to fragments of external documents (e.g. <code>URI="http://example.com/bar.xml#chapter1"</code>).</li>
</ul>

<p>The differences between the processing, and allowed syntax, of this <code>URI</code>
attribute and that of a "Compatibility Mode" <code>Reference</code> <code>URI</code> are:</p>
<ul>
    <li>Dereferencing a same-document reference does not result in a XPath node set.</li>
    <li>The <code>xpointer</code> syntax is not permitted.</li>
    <li>There is no comment node removal during the dereferencing process.</li>
</ul>

<p>The <code>dsig2:Selection</code> element <em class="rfc2119" title="may">may</em> contain at most one
<code>dsig2:IncludedXPath</code> and at most one <code>dsig2:ByteRange</code> parameter
element to modify the selection result. However <code>dsig2:IncludedXPath</code> <em class="rfc2119" title="must not">must not</em> be present, 
if the <code>URI</code> contains a fragment identifier.
</p>

<p>Processing of the selection and parameters is as follows:</p>
<ol>
<li>Remove the fragment part of the URI if present, and then dereference the URI into a XML document.</li>
<li>Do one of the following:
<ul>
<li>If there is a fragment identifier in the URI, search for an element with the ID in the fragment, and then select this element.</li>
<li>OR If the <code>IncludedXPath</code> element is present, evaluate this XPath at the root of document 
to select one element node. It is an error if the XPath returns more than one element node.</li>
<li>OR If neither the fragment identifier or IncludedXPath is present, then select the root element node
of the document.</li>
</ul></li>
<li>The selected element node <em class="rfc2119" title="must">must</em> contain only Text node children, or an error results.</li>
<li>Coalesce the selected element's Text node children  into a single string,
and base64-decode the result to obtain an octet stream.</li>
<li>If a <code>dsig2:ByteRange</code> parameter is present, use these range(s) to modify
the octet stream obtained in the previous step.</li>
</ol>

<p>The final result of the selection process is an octet stream.</p>
</div>

</div>

<div id="sec-VerificationTypes" class="section">
<h3><span class="secno">10.7 </span>The <code>dsig2:Verification</code> Types</h3>

<div id="sec-Verification-DigestDataLength" class="section">
<h4><span class="secno">10.7.1 </span>DigestDataLength</h4>

<dl>
  <dt>Identifier:</dt>
  <dd><a id="DigestDataLength" href="http://www.w3.org/2010/xmldsig2#DigestDataLength">http://www.w3.org/2010/xmldsig2#DigestDataLength</a></dd>
</dl>

<p>The DigestDataLength <code>dsig2:Verification</code> type contains an integer
that specifies the number of bytes that were digested for the containing <code>Reference</code>. This can be
used for multiple purposes:</p>
<ul>
<li>to debug digest verification failures</li>
<li>to indicate intentional signing of 0 bytes, such as if an XPath expression selects nothing</li>
<li>to bypass the expensive digest calculation if during verification the length of the byte array 
containing the canonicalized bytes doesn't match the value found in
  the message</li> 
</ul>

<p>The non-negative integer value is carried within a <code>DigestDataLength</code> attribute inside the
<code>dsig2:Verification</code> element.</p>
</div>

<div id="sec-Verification-PositionAssertion" class="section">
<h4><span class="secno">10.7.2 </span>PositionAssertion</h4>

<dl>
  <dt>Identifier:</dt>
  <dd><a id="PositionAssertion" href="http://www.w3.org/2010/xmldsig2#PositionAssertion">http://www.w3.org/2010/xmldsig2#PositionAssertion</a></dd>
</dl>

<p>The PositionAssertion <code>dsig2:Verification</code> type is used
to increase the resistance of ID-based referencing to signature wrapping attacks.
It contains an XPath expression that must match the referenced content's position
in the document. Thus, instead of "selecting" the referenced element via an XPath,
its position is verified by one (which enables flexibility in the actual use of XPath by
the signer or verifier). The actual selection process remains ID-based, which is simpler for many
implementers.</p>

<p>The XPath expression is carried within a <code>PositionAssertion</code> attribute inside the
<code>dsig2:Verification</code> element.</p>

<p>While using the PositionAssertion feature allows more flexibility in
accomodating XPath-unaware signers and verifiers, applications <em class="rfc2119" title="should">should</em>
favor the use of XPath-based selection via the <code>dsig2:IncludedXPath</code>
element over the use of this feature in most cases. Because verification
of the PositionAssertion is formally optional, verifiers may become subject
to positional wrapping attacks if they choose to ignore the assertion.
This feature is appropriate mainly in applications in which knowledge of the
verifier's support for the feature can be assured.</p>
</div>

<div id="sec-Verification-IDAttrs" class="section">
<h4><span class="secno">10.7.3 </span>IDAttributes</h4>

<dl>
  <dt>Identifier:</dt>
  <dd><a id="IDAttributes" href="http://www.w3.org/2010/xmldsig2#IDAttributes">http://www.w3.org/2010/xmldsig2#IDAttributes</a></dd>
</dl>

<p>The IDAttributes <code>dsig2:Verification</code> type is used
in conjunction with ID-based references, to specify the ID attribute node name
that the signer used. Ordinarily, ID attribute knowledge is imparted through a
variety of normative and informal means, including DTDs, XML Schemas, use of xml:id,
and application-specific content knowledge. A signer is not required to use this
mechanism to identify ID attributes, but <em class="rfc2119" title="may">may</em> do so to transfer its own ID knowledge
to the verifier through the signature itself. Verifiers <em class="rfc2119" title="may">may</em> incorporate this knowledge,
or use more traditional means of recognizing ID attributes.</p>

<p>The <code>dsig2:Verification</code> element specifies exactly one ID attribute node.
This <em class="rfc2119" title="must">must</em> be the name of the node involved in the containing <code>Reference</code>.</p>

<p>
The <code>dsig2:Verification</code> element <em class="rfc2119" title="must">must</em> contain one of the
following two child elements:</p> 
<dl>
 <dt><code>dsig2:QualifiedAttr</code></dt>
 <dd>Specifies a namespace-qualified ID attribute node, by means of <code>Name</code> and
 <code>NS</code> attributes.</dd>
 <dt><code>dsig2:UnqualifiedAttr</code></dt>
 <dd>Specifies an unqualified ID attribute node, by means of a required <code>Name</code> attribute,
 and required <code>ParentName</code> and optional <code>ParentNS</code> attributes to identify
 the owning element.</dd>
</dl>

<pre class="sh_xml sh_sourceCode">  Schema Definition:

   <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"QualifiedAttr"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:QualifiedAttrType"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;xs:complexType</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"QualifiedAttrType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Name"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:NCName"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"NS"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:anyURI"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;xs:</span><span class="sh_type">/complexType</span><span class="sh_keyword">&gt;</span>
   <span class="sh_keyword">&lt;xs:element</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"UnqualifiedAttr"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"dsig2:UnqualifiedAttrType"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;xs:complexType</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"UnqualifiedAttrType"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"Name"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:NCName"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ParentName"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:NCName"</span> <span class="sh_type">use</span><span class="sh_symbol">=</span><span class="sh_string">"required"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;xs:attribute</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"ParentNS"</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"xs:anyURI"</span><span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;xs:</span><span class="sh_type">/complexType</span><span class="sh_keyword">&gt;</span>
</pre>

  <p class="note">
  Without a DTD, there is technically no way to define IDness in an XML document.
  In practice, this typing was extended to documents validated by an XML Schema,
  and then to the creation of <code>xml:id</code>. Unfortunately, DTDs have mostly
  fallen out of use in many contexts, and schemas are expensive, rarely used in many
  runtime scenarios, and can't be relied on to be completely known by the verifier
  in the presence of extensible XML scenarios.
  <br>
  <code>xml:id</code> has not yet seen wide adoption, mainly because a lot of the
  standards that needed it (SAML, WS-Security) were completed prior to its invention.
  <br>
  The result is that applications that rely on ID-based references for signing have
  typically made insecure assumptions about the IDness of attributes based on their
  name (<code>ID</code>, <code>id</code>, <code>Id</code>, etc.), or have to provide
  APIs for applications to call before verification (which is also a problem in the
  face of extensibility). DOM Level 3, which is now fairly widely implemented, also
  provides the ability to identify attributes as an ID at runtime, although often
  without guaranteeing the uniqueness property.
  <br>
  The IDAttributes verification type provides a deterministic way of defining
  an ID attribute used during signing, that is independent of DTD, XML Schema, DOM 3
  or other application-specific mechanisms.</p>
  
</div>
</div>
</div>

<div id="sec-XML-Canonicalization" class="section">
<!--OddPage--><h2><span class="secno">11. </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 
[<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">11.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,</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">11.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 [<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
  XML 1.0 syntax constraints given in 
the <a href="#sec-XML-1" class="sectionRef">section 11.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">11.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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;A</span> <span class="sh_type">xmlns:n1</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;foo;"</span><span class="sh_keyword">&gt;</span>
  <span class="sh_keyword">&lt;B</span> <span class="sh_type">xmlns:n2</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;bar;"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;Signature</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;dsig;"</span><span class="sh_keyword">&gt;</span>   ...
      <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#signme"</span><span class="sh_keyword">/&gt;</span> ...
    <span class="sh_keyword">&lt;/Signature&gt;</span>
    <span class="sh_keyword">&lt;C</span> <span class="sh_type">ID</span><span class="sh_symbol">=</span><span class="sh_string">"signme"</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;baz;"</span><span class="sh_keyword">/&gt;</span>
  <span class="sh_keyword">&lt;/B&gt;</span>
<span class="sh_keyword">&lt;/A&gt;</span></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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;SOAP:Envelope</span> <span class="sh_type">xmlns:SOAP</span><span class="sh_symbol">=</span><span class="sh_string">"http://schemas.xmlsoap.org/soap/envelope/"</span><span class="sh_keyword">&gt;</span>
  ...
  <span class="sh_keyword">&lt;SOAP:Body&gt;</span>
    <span class="sh_keyword">&lt;B</span> <span class="sh_type">xmlns:n2</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;bar;"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;Signature</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;dsig;"</span><span class="sh_keyword">&gt;</span>
        ...
      <span class="sh_keyword">&lt;/Signature&gt;</span>
      <span class="sh_keyword">&lt;C</span> <span class="sh_type">ID</span><span class="sh_symbol">=</span><span class="sh_string">"signme"</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;baz;"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;/B&gt;</span>
  <span class="sh_keyword">&lt;/SOAP:Body&gt;</span>
<span class="sh_keyword">&lt;/SOAP:Envelope&gt;</span></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">12. </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">12.1 </span>Transforms</h3>
<p>A requirement of this specification is to permit signatures to
"apply to 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.) 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">12.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 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">12.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">12.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">12.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">12.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>

<div id="sec-Schema" class="section">
<!--OddPage--><h2><span class="secno">13. </span>Schema</h2>
<div id="sec-xsdSchema" class="section">
<h3><span class="secno">13.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="/TR/xmldsig-core1/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="/TR/xmldsig-core1/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>
<!--<section id="sec-rngSchema" class="informative">
<h3>RNG Schema</h3>
The following are RelaxNG schemas [[!RELAXNG-SCHEMA]].
<dl>
  <dt>XML Signature Core RelaxNG Schema Instance</dt>
  <dd><a href="../xmldsig-core-1/xmldsig-core-schema.rnc">xmldsig-core-schema.rnc</a></dd>
  <dt>XML Signature 1.1 RelaxNG Schema Instance</dt>
  <dd><a href="../xmldsig-core-1/xmldsig11-schema.rnc">xmldsig11-schema.rnc</a></dd>
  <dt>RelaxNG XML Signature 1.1 Top-Level Schema</dt>
  <dd><a href="../xmldsig-core-1/any-containing-xmldsig11.rnc">any-containing-xmldsig11.rnc</a></dd>
  <dd>Any correct use of XML Signature 1.1 schema is expected be valid
against this top-level schema. </dd>
</dl>
</section> -->
</div>
<div id="sec-Definitions" class="appendix section">
<!--OddPage--><h2><span class="secno">A. </span>Definitions</h2>
<p><em>This section is non-normative.</em></p>
<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." [<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." [<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.</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 <code>CanonicalizationMethod</code>
and <code>SignatureMethod</code> as specified in <a href="#sec-CoreValidation" class="sectionRef">section 4.3 Core Validation</a>.</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="sec-Compatibility-Mode" class="appendix section">
<!--OddPage--><h2><span class="secno">B. </span>Compatibility Mode</h2>
<p>Use of  the  "Compatibility Mode" described in this section enables
  the XML Signature 1.x model to be 
  used where necessary, to enable backward compatibility. 
</p>
<div id="sec-Compatibility-Mode-Examples" class="section">
<h3><span class="secno">B.1 </span>"Compatibility Mode" Examples</h3>
<p>The following examples are for a detached signature of the content of the
HTML4 in XML specification.</p>
<div id="sec-o-Simple-Compat" class="section">
<h4><span class="secno">B.1.1 </span>Simple Example in "Compatibility Mode"</h4>

<p>This example uses "Compatibility Mode".</p>
<pre class="example sh_xml sh_sourceCode">[s01] <span class="sh_keyword">&lt;Signature</span> <span class="sh_type">Id</span><span class="sh_symbol">=</span><span class="sh_string">"MyFirstSignature"</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span><span class="sh_keyword">&gt;</span> 
[s02]   <span class="sh_keyword">&lt;SignedInfo&gt;</span>  
[s03]   <span class="sh_keyword">&lt;CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2006/12/xml-c14n11"</span><span class="sh_keyword">/&gt;</span> 
[s04]   <span class="sh_keyword">&lt;SignatureMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"</span><span class="sh_keyword">/&gt;</span> 
[s05]   <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/TR/2000/REC-xhtml1-20000126/"</span><span class="sh_keyword">&gt;</span> 
[s06]     <span class="sh_keyword">&lt;Transforms&gt;</span> 
[s07]       <span class="sh_keyword">&lt;Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2006/12/xml-c14n11"</span><span class="sh_keyword">/&gt;</span> 
[s08]     <span class="sh_keyword">&lt;/Transforms&gt;</span> 
[s09]     <span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span> 
[s10]     <span class="sh_keyword">&lt;DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...<span class="sh_keyword">&lt;/DigestValue&gt;</span> 
[s11]   <span class="sh_keyword">&lt;/Reference&gt;</span> 
[s12] <span class="sh_keyword">&lt;/SignedInfo&gt;</span> 
[s13]   <span class="sh_keyword">&lt;SignatureValue&gt;</span>...<span class="sh_keyword">&lt;/SignatureValue&gt;</span> 
[s14]   <span class="sh_keyword">&lt;KeyInfo&gt;</span> 
[s15a]    <span class="sh_keyword">&lt;KeyValue&gt;</span>
[s15b]      <span class="sh_keyword">&lt;DSAKeyValue&gt;</span> 
[s15c]        <span class="sh_keyword">&lt;P&gt;</span>...<span class="sh_keyword">&lt;/P&gt;&lt;Q&gt;</span>...<span class="sh_keyword">&lt;/Q&gt;&lt;G&gt;</span>...<span class="sh_keyword">&lt;/G&gt;&lt;Y&gt;</span>...<span class="sh_keyword">&lt;/Y&gt;</span> 
[s15d]      <span class="sh_keyword">&lt;/DSAKeyValue&gt;</span> 
[s15e]    <span class="sh_keyword">&lt;/KeyValue&gt;</span> 
[s16]   <span class="sh_keyword">&lt;/KeyInfo&gt;</span> 
[s17] <span class="sh_keyword">&lt;/Signature&gt;</span></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>

<div id="sec-o-Reference" class="section">
<h4><span class="secno">B.1.2 </span>More on <code>Reference</code></h4>
<p>These section explaining the lines <code>[s05]</code> to <code>[s11]</code> of the previous example. This signature is in "compatibility mode". </p> 
<pre class="example sh_xml sh_sourceCode">[s05]   <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/TR/2000/REC-xhtml1-20000126/"</span><span class="sh_keyword">&gt;</span> 
[s06]     <span class="sh_keyword">&lt;Transforms&gt;</span> 
[s07]       <span class="sh_keyword">&lt;Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2006/12/xml-c14n11"</span><span class="sh_keyword">/&gt;</span> 
[s08]     <span class="sh_keyword">&lt;/Transforms&gt;</span> 
[s09]     <span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span> 
[s10]     <span class="sh_keyword">&lt;DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...<span class="sh_keyword">&lt;/DigestValue&gt;</span> 
[s11]   <span class="sh_keyword">&lt;/Reference&gt;</span></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 id="sec-o-SignatureProperty" class="section">
<h4><span class="secno">B.1.3 </span>Extended Example (<code>Object</code> and <code>SignatureProperty</code>)</h4>

<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 (in "Compatibility Mode") 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="example sh_xml sh_sourceCode">[   ]  <span class="sh_keyword">&lt;Signature</span> <span class="sh_type">Id</span><span class="sh_symbol">=</span><span class="sh_string">"MySecondSignature"</span> <span class="sh_type">...</span><span class="sh_keyword">&gt;</span>
[p01]  <span class="sh_keyword">&lt;SignedInfo&gt;</span>  
[   ]   ...  
[p02]   <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/TR/xml-stylesheet/"</span><span class="sh_keyword">&gt;</span>   
[   ]   ... 
[p03]   <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#AMadeUpTimeStamp"</span>  
<span class="sh_type">[p04]</span><span class="sh_normal">         </span><span class="sh_type">Type</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#SignatureProperties"</span><span class="sh_keyword">&gt;</span>
[p05]    <span class="sh_keyword">&lt;Transforms&gt;</span> 
[p06]      <span class="sh_keyword">&lt;Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2006/12/xml-c14n11"</span><span class="sh_keyword">/&gt;</span> 
[p07]    <span class="sh_keyword">&lt;/Transforms&gt;</span> 
[p08]    <span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span>    
[p09]    <span class="sh_keyword">&lt;DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...<span class="sh_keyword">&lt;/DigestValue&gt;</span>
[p10]   <span class="sh_keyword">&lt;/Reference&gt;</span>    
[p11]  <span class="sh_keyword">&lt;/SignedInfo&gt;</span>  
[p12]  ...  
[p13]  <span class="sh_keyword">&lt;Object&gt;</span> 
[p14]   <span class="sh_keyword">&lt;SignatureProperties&gt;</span> 
[p15]     <span class="sh_keyword">&lt;SignatureProperty</span> <span class="sh_type">Id</span><span class="sh_symbol">=</span><span class="sh_string">"AMadeUpTimeStamp"</span> <span class="sh_type">Target</span><span class="sh_symbol">=</span><span class="sh_string">"#MySecondSignature"</span><span class="sh_keyword">&gt;</span> 
[p16]        <span class="sh_keyword">&lt;timestamp</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.ietf.org/rfcXXXX.txt"</span><span class="sh_keyword">&gt;</span>
[p17]          <span class="sh_keyword">&lt;date&gt;</span>19990914<span class="sh_keyword">&lt;/date&gt;</span>  
[p18]          <span class="sh_keyword">&lt;time&gt;</span>14:34:34:34<span class="sh_keyword">&lt;/time&gt;</span>  
[p19]        <span class="sh_keyword">&lt;/timestamp&gt;</span>  
[p20]     <span class="sh_keyword">&lt;/SignatureProperty&gt;</span> 
[p21]   <span class="sh_keyword">&lt;/SignatureProperties&gt;</span> 
[p22]  <span class="sh_keyword">&lt;/Object&gt;</span>  
[p23]<span class="sh_keyword">&lt;/Signature&gt;</span></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>

<p>This is the same example in "2.0 Mode". Only the <code>Reference</code>
content is different.</p>

<pre class="example sh_xml sh_sourceCode">[   ]  ...
[p03]   <span class="sh_keyword">&lt;Reference&gt;</span>  
[p04]
[p05]    <span class="sh_keyword">&lt;Transforms&gt;</span> 
[p06]      <span class="sh_keyword">&lt;Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#transform"</span><span class="sh_keyword">&gt;</span>
[s06a]        <span class="sh_keyword">&lt;dsig2:Selection</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#xml"</span> <span class="sh_type">xmlns:dsig2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#"</span>
<span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#AMadeUpTimeStamp"</span>
<span class="sh_keyword">&gt;</span>
[p06b]        <span class="sh_keyword">&lt;/dsig2:Selection&gt;</span>
[p06c]        <span class="sh_keyword">&lt;CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span><span class="sh_keyword">/&gt;</span>
[p06d]     <span class="sh_keyword">&lt;/Transform&gt;</span> 
[p07]    <span class="sh_keyword">&lt;/Transforms&gt;</span> 
[p08]    <span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span>    
[p09]    <span class="sh_keyword">&lt;DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...<span class="sh_keyword">&lt;/DigestValue&gt;</span>
[p10]   <span class="sh_keyword">&lt;/Reference&gt;</span>    
[   ]   ...</pre>
</div> 

<div id="sec-o-Manifest" class="section">
<h4><span class="secno">B.1.4 </span>Extended Example (<code>Object</code> and <code>Manifest</code>)</h4>

<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. 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 (in "Compatibility Mode") below includes a <code>Reference</code>
that signs a <code> Manifest</code> found within the <code>Object</code>
element.</p>
<pre class="example sh_xml sh_sourceCode">[   ] ...
[m01]   <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#MyFirstManifest"</span>
<span class="sh_type">[m02]</span><span class="sh_normal">     </span><span class="sh_type">Type</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#Manifest"</span><span class="sh_keyword">&gt;</span>
[m03]     <span class="sh_keyword">&lt;Transforms&gt;</span> 
[m04]       <span class="sh_keyword">&lt;Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2006/12/xml-c14n11"</span><span class="sh_keyword">/&gt;</span> 
[m05]     <span class="sh_keyword">&lt;/Transforms&gt;</span> 
[m06]     <span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span> 
[m07]     <span class="sh_keyword">&lt;DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...=<span class="sh_keyword">&lt;/DigestValue&gt;</span> 
[m08]   <span class="sh_keyword">&lt;/Reference&gt;</span>  
[   ] ...
[m09] <span class="sh_keyword">&lt;Object&gt;</span>
[m10]   <span class="sh_keyword">&lt;Manifest</span> <span class="sh_type">Id</span><span class="sh_symbol">=</span><span class="sh_string">"MyFirstManifest"</span><span class="sh_keyword">&gt;</span>
[m11]     <span class="sh_keyword">&lt;Reference&gt;</span>
[m12]     ...
[m13]     <span class="sh_keyword">&lt;/Reference&gt;</span>   
[m14]     <span class="sh_keyword">&lt;Reference&gt;</span>
[m15]     ...
[m16]     <span class="sh_keyword">&lt;/Reference&gt;</span>
[m17]   <span class="sh_keyword">&lt;/Manifest&gt;</span>
[m18] <span class="sh_keyword">&lt;/Object&gt;</span></pre>

<p>Here is the modified <code>Reference</code> in "2.0 Mode"</p>

<pre class="example sh_xml sh_sourceCode">[m01]   <span class="sh_keyword">&lt;Reference</span>
<span class="sh_type">[m02]</span><span class="sh_normal">     </span><span class="sh_type">Type</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#Manifest"</span><span class="sh_keyword">&gt;</span>
[m03]     <span class="sh_keyword">&lt;Transforms&gt;</span> 
[m04]      <span class="sh_keyword">&lt;Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#transform"</span><span class="sh_keyword">&gt;</span>
[m04a]        <span class="sh_keyword">&lt;dsig2:Selection</span> <span class="sh_type">type</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#xml"</span> <span class="sh_type">xmlns:dsig2</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xmldsig2#"</span>
<span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#MyFirstManifest"</span><span class="sh_keyword">&gt;</span>
[m04b]        <span class="sh_keyword">&lt;/dsig2:Selection&gt;</span>
[m04c]        <span class="sh_keyword">&lt;CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2010/xml-c14n2"</span><span class="sh_keyword">/&gt;</span>
[m04d]     <span class="sh_keyword">&lt;/Transform&gt;</span> 
[m05]     <span class="sh_keyword">&lt;/Transforms&gt;</span> 
[m06]     <span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2001/04/xmlenc#sha256"</span><span class="sh_keyword">/&gt;</span> 
[m07]     <span class="sh_keyword">&lt;DigestValue&gt;</span>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...=<span class="sh_keyword">&lt;/DigestValue&gt;</span> 
[m08]   <span class="sh_keyword">&lt;/Reference&gt;</span>  </pre>
</div> 
</div>
<div id="sec-compatible-processing" class="section">
<h3><span class="secno">B.2 </span>Compatibility Mode Processing</h3>

<div id="sec-ReferenceGeneration" class="section">
<h4><span class="secno">B.2.1 </span>Reference Generation in "Compatibility Mode"</h4>
<p>For each data object being signed:</p>
<ol>
  <li>Apply the <code>Transforms</code>, as determined by the
application, to the data object.</li>
  <li>Calculate the digest value over the resulting data object.</li>
  <li>Create a <code>Reference</code> element, including the
(optional) identification of the data object, any (optional) transform
elements, the digest algorithm and the <code>DigestValue</code>.
(Note, it is the canonical form of these references that are signed in
3.1.3 and validated in 3.2.1 .)</li>
</ol>
The Reference Processing Model
(<a href="#sec-ReferenceProcessingModel" class="sectionRef">section B.4.1 The "Compatibility Mode" 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"><a name="Editors-Note-C14N11-AppendixA1" id="EdNote-C14N11-AppendixA1">

Editors Note</a>: There has been a correction to Appendix A of the C14N11 Candidate Recommendation. This

correction is available at 

<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html">

http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html</a>.

The XML Security Specifications Maintenance WG anticipates this change will be adopted as part of 

C14N11 CR review and will use this update to Appendix A for Interop testing.

</p>

</ins>

--> </div>
<div id="sec-ReferenceCheck" class="section">
<h4><span class="secno">B.2.2 </span>Reference check in "Compatibility Mode"</h4>
<p>It is very important to check that the <code>Reference</code> actually
includes the data that is expected to be signed. The [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-BESTPRACTICES">XMLDSIG-BESTPRACTICES</a></cite>] document
describes a number of attacks, where what is apparently being signed is not
actually signed.</p>
<p>One way to check the reference is to allow only certain combinations
of transforms. For example [<cite><a class="bibref" rel="biblioentry" href="#bib-SAML2-CORE">SAML2-CORE</a></cite>] and [<cite><a class="bibref" rel="biblioentry" href="#bib-EBXML-MSG">EBXML-MSG</a></cite>] follow this
approach. </p>
<p> Another option is for XML Signature libraries to return the pre-digest
data to the application, so that application can inspect it to verify what
is actually signed. This too may not be enough, for example in a Web
Services scenario, if the reference is pointing to a soap:Body, it is
not sufficient to just check the name of the "soap:Body" element, as it
can lead to wrapping attacks [<cite><a class="bibref" rel="biblioentry" href="#bib-MCINTOSH-WRAP">MCINTOSH-WRAP</a></cite>];Instead the application
should check if this soap:Body is in the correct position, i.e. as a
child of the top level soap:Envelope.</p>
</div>


<div id="sec-SignatureValidationCompat" class="section">
<h4><span class="secno">B.2.3 </span>Signature Validation in "Compatibility Mode"</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 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 id="sec-ReferenceValidation" class="section">
<h4><span class="secno">B.2.4 </span>Reference Validation in "Compatibility Mode"</h4>
<ol>
  <li>Canonicalize the <code>SignedInfo</code> element based on the
  <code>CanonicalizationMethod</code> in <code>SignedInfo</code>.</li>
  <li>For each <code>Reference</code> in <code>SignedInfo</code>:
    <ol>
      <li>Obtain the data object to be digested. (For example, the
signature application may dereference the <code>URI</code> and execute
        <code>Transforms</code> provided by the signer in the <code>Reference</code>
element, or it may obtain the content through other means such as a
local cache.)</li>
      <li>Digest the resulting data object using the <code>DigestMethod</code>
specified in its <code>Reference</code> specification.</li>
      <li>Compare the generated digest value against <code>DigestValue</code>
in the <code>SignedInfo</code> <code>Reference</code>; if there is
any mismatch, validation fails.</li>
    </ol>
  </li>
</ol>
<p>Note, <code>SignedInfo</code> is canonicalized in step 1. The
application must ensure that the CanonicalizationMethod has no
dangerous side effects, such as rewriting URIs, (see <code><a href="#sec-CanonicalizationMethod-NOTE">CanonicalizationMethod</a></code>
Note in <a href="#sec-CanonicalizationMethod-Compat" class="sectionRef">section B.3 Use of CanonicalizationMethod in "Compatibility Mode"</a>) and that it
    "Sees What is 
Signed", which is the canonical form (see <a href="#sec-See" class="sectionRef">section 12.1.3 "See" What is Signed</a> ).
</p>
<p>Note, After a <code>Signature</code> element has been created during
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>
<div id="sec-CanonicalizationMethod-Compat" class="section">
<h3><span class="secno">B.3 </span>Use of <code>CanonicalizationMethod</code> in "Compatibility Mode"</h3>

<p>Alternatives to the <em class="rfc2119" title="required">required</em> <a href="#sec-c14nAlg" class="sectionRef">section B.6 "Compatibility Mode" Canonicalization Algorithms</a>, such
  as <a href="#sec-Canonical" class="sectionRef">section B.6.1 Canonical XML 1.0</a> 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" class="sectionRef">section 11. XML Canonicalization and Syntax Constraint Considerations</a>.
Security issues may also arise in the treatment of entity processing
and comments if non-XML aware canonicalization algorithms are not
properly constrained (see <a href="#sec-Seen" class="sectionRef">section 12.1.2 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><a id="sec-CanonicalizationMethod-NOTE">NOTE</a>: The signature
application must exercise great care in accepting and executing an
arbitrary <code>CanonicalizationMethod</code>. For example, the
canonicalization method could rewrite the URIs of the <code>Reference</code>s
being validated. Or, the method could significantly 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>
</div>
<div id="sec-URI" class="section">
<h3><span class="secno">B.4 </span>The <code>URI</code> Attribute in "Compatibility Mode"</h3>
<p> If the <code>URI</code>
attribute is omitted for a "Compatibility Mode" signature, then 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.
</p>

<p>In "Compatibility Mode", at most one <code>Reference</code> element
without a <code>URI</code> attribute may be present in any particular
<code>SignedInfo</code>, or <code>Manifest</code>.</p>

<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 URI 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
URI attribute.</p>

<p>We RECOMMEND XML Signature applications be able to dereference URIs
in the HTTP scheme. Dereferencing a URI in the HTTP scheme <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 4.3 Core Validation</a> for further
  information on reference processing.)</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 id="sec-ReferenceProcessingModel" class="section">
<h4><span class="secno">B.4.1 </span>The "Compatibility Mode" Reference Processing Model</h4>
<p class="comment"><a id="Note-Xpath">Note</a>:
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 are 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 B.2.1 Reference Generation in "Compatibility Mode"</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" class="sectionRef">section 6.2 The  Transforms Element</a>.)</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> 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" class="sectionRef">section B.4.2 "Compatibility Mode" Same-Document URI-References</a>.) 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">
<h4><span class="secno">B.4.2 </span>"Compatibility Mode" Same-Document URI-References</h4>
<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" class="sectionRef">section B.4.1 The "Compatibility Mode" Reference Processing Model</a>.</p>
</div>
</div>
<div id="sec-TransformsProcessingModel" class="section">
<h3><span class="secno">B.5 </span> "Compatibility Mode" Transforms and Processing Model</h3>
<p>If the optional <code>Transforms</code> element is present and
  contains exactly one 
<code>Transform</code> element with an Algorithm
of <code>"http://www.w3.org/2010/xmldsig2#transform"</code> then 2.0
processing is performed as described in
 <a href="#sec-Transforms" class="sectionRef">section 6.2 The  Transforms Element</a> 
otherwise compatibility mode transform processing is
performed as described here.
</p>
<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. 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.</p>
<p>The <code>Transforms</code> element is optional and
its presence indicates that the signer is not signing the native
(original) document but the resulting (transformed) document. (See 
<a href="#sec-Secure" class="sectionRef">section 12.1.1 Only What is Signed is Secure</a>
).</p>

<p>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.</p>

<p>As described in <a href="#sec-ReferenceProcessingModel" class="sectionRef">section B.4.1 The "Compatibility Mode" Reference Processing Model</a>, 
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" class="sectionRef">section B.7 "Compatibility Mode" Transform Algorithms</a>
defines the list of standard "Compatibility Mode"
transformations.</p>
</div>
<div id="sec-c14nAlg" class="section">
<h3><span class="secno">B.6 </span>"Compatibility Mode" 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">B.6.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="example sh_xml sh_sourceCode"><code><span class="sh_keyword">&lt;CanonicalizationMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"</span></code><span class="sh_string">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</span><code><span class="sh_string">"</span><span class="sh_keyword">/&gt;</span></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">B.6.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>
<!--  

<ins>

<p class="discuss"><a name="Editors-Note-C14N11-AppendixA2" id="Editors-Note-C14N11-AppendixA2">

Editors Note</a>: There has been a correction to Appendix A of the C14N11 Candidate Recommendation. This

correction is available at 

<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html">

http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Jun/att-0050/Apendix_20060625.html</a>.

The XML Security Specifications Maintenance WG anticipates this change will be adopted as part of 

C14N11 CR review and will use this update to Appendix A for Interop testing.

</p>

</ins>

--> </div> <div id="sec-ExcC14N10" class="section">
<h4><span class="secno">B.6.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">B.7 </span>"Compatibility Mode" <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-Compatibility-Mode-Conformance" class="sectionRef">section 3.3 Compatibility Mode  Conformance</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">B.7.1 </span>Canonicalization</h4>
<p>Any canonicalization algorithm that can be used for <code>CanonicalizationMethod</code>
(such as those in <a href="#sec-c14nAlg" class="sectionRef">section B.6 "Compatibility Mode" Canonicalization Algorithms</a>) can
  be used as a <code>Transform</code>.</p> 
</div> <div id="sec-Base-64" class="section">
<h4><span class="secno">B.7.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">B.7.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. 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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;Document&gt;</span>
...   
<span class="sh_keyword">&lt;Signature</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#"</span><span class="sh_keyword">&gt;</span>
  <span class="sh_keyword">&lt;SignedInfo&gt;</span>
   ...
    <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">""</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;Transforms&gt;</span>
        <span class="sh_keyword">&lt;Transform</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/TR/1999/REC-xpath-19991116"</span><span class="sh_keyword">&gt;</span>
          <span class="sh_keyword">&lt;XPath</span> <span class="sh_type">xmlns:dsig</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;dsig;"</span><span class="sh_keyword">&gt;</span>
          not(ancestor-or-self::dsig:Signature)
          <span class="sh_keyword">&lt;/XPath&gt;</span>
        <span class="sh_keyword">&lt;/Transform&gt;</span>
      <span class="sh_keyword">&lt;/Transforms&gt;</span>
      <span class="sh_keyword">&lt;DigestMethod</span> <span class="sh_type">Algorithm</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2000/09/xmldsig#sha1"</span><span class="sh_keyword">/&gt;</span>
      <span class="sh_keyword">&lt;DigestValue&gt;&lt;/DigestValue&gt;</span>
    <span class="sh_keyword">&lt;/Reference&gt;</span>
  <span class="sh_keyword">&lt;/SignedInfo&gt;</span>
  <span class="sh_keyword">&lt;SignatureValue&gt;&lt;/SignatureValue&gt;</span>
 <span class="sh_keyword">&lt;/Signature&gt;</span>
 ...
<span class="sh_keyword">&lt;/Document&gt;</span></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="example sh_xml sh_sourceCode"><span class="sh_keyword">&lt;XPath</span> <span class="sh_type">xmlns:dsig</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;dsig;"</span><span class="sh_keyword">&gt;</span>
count(ancestor-or-self::dsig:Signature |
here()/ancestor::dsig:Signature[1]) &gt;
count(ancestor-or-self::dsig:Signature)<span class="sh_keyword">&lt;/XPath&gt;</span></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">B.7.4 </span>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="sh_xml sh_sourceCode">   <span class="sh_keyword">&lt;XPath</span> <span class="sh_type">xmlns:dsig</span><span class="sh_symbol">=</span><span class="sh_string">"&amp;dsig;"</span><span class="sh_keyword">&gt;</span>
   count(ancestor-or-self::dsig:Signature |
   here()/ancestor::dsig:Signature[1]) &gt;
   count(ancestor-or-self::dsig:Signature)<span class="sh_keyword">&lt;/XPath&gt;</span>
</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">B.7.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="references" class="appendix section"><!--OddPage--><h2><span class="secno">C. </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">C.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> February 2011. IETF Informational RFC. 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>. June 1999. IETF RFC 2560. 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. URL: <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-C14N20">[XML-C14N20]</dt><dd>John Boyer; Glen Marcy; Pratik Datta; Frederick Hirsch. <a href="http://www.w3.org/TR/2011/WD-xml-c14n2-20110421/"><cite>Canonical XML Version 2.0.</cite></a> 21 April 2011. W3C Last Call Working Draft. URL: <a href="http://www.w3.org/TR/2011/WD-xml-c14n2-20110421/">http://www.w3.org/TR/2011/WD-xml-c14n2-20110421/</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">[XMLDSIG-XPATH]</dt><dd>Pratik Datta. Frederick Hirsch, Meiko Jensen <a href="http://www.w3.org/TR/2011/WD-xmldsig-xpath-20110421/"><cite>XML Signature Streaming Profile of XPath 1.0</cite></a> 21 April 2011. W3C Last Call Working draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/WD-xmldsig-xpath-20110421/">http://www.w3.org/TR/2011/WD-xmldsig-xpath-20110421/</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">C.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-ABA-DSIG-GUIDELINES">[ABA-DSIG-GUIDELINES]</dt><dd><a href="http://www.signelec.com/content/download/digital_signature_guidelines.pdf"><cite>Digital Signature Guidelines.</cite></a> 1 August 1996. Information Security Committee, American Bar Association. URL: <a href="http://www.signelec.com/content/download/digital_signature_guidelines.pdf">http://www.signelec.com/content/download/digital_signature_guidelines.pdf</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-EBXML-MSG">[EBXML-MSG]</dt><dd>Ian Jones; Brian Gibb; David Fischer. <a href="http://www.oasis-open.org/committees/download.php/272/ebMS_v2_0.pdf"><cite> OASIS ebXML Message Service Specification</cite></a> 1 April 2002. URL: <a href="http://www.oasis-open.org/committees/download.php/272/ebMS_v2_0.pdf">http://www.oasis-open.org/committees/download.php/272/ebMS_v2_0.pdf</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-MCINTOSH-WRAP">[MCINTOSH-WRAP]</dt><dd> Michael McIntosh; Paula Austel. XML signature element wrapping attacks and countermeasures. In Workshop on Secure Web Services, 2005
</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-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-SAML2-CORE">[SAML2-CORE]</dt><dd>Scott Cantor; John Kemp; Rob Philpott; Eve Maler. <a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf"><cite>Assertions and Protocols for SAML V2.0</cite></a> 15 March 2005. URL: <a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf</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-WS-SECURITY11">[WS-SECURITY11]</dt><dd>A. Nadalin, C. Kaler, R. Monzillo, P. Hallam-Baker. <a href="http://www.oasis-open.org/specs/index.php#wssv1.1"><cite>Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)</cite></a>. OASIS Standard, 1 February 2006. URL: <a href="http://www.oasis-open.org/specs/index.php#wssv1.1">http://www.oasis-open.org/specs/index.php#wssv1.1</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/"><cite>XML Japanese Profile (2nd Edition)</cite></a>. March 2005. W3C Member Submission. 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-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-XMLSEC2-REQS">[XMLSEC2-REQS]</dt><dd>Frederick Hirsch, Pratik Datta. <a href="http://www.w3.org/TR/2011/WD-xmlsec-reqs2-20110421/"><cite>XML Security 2.0 Requirements and Design Considerations.</cite></a> 21 April 2011. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/WD-xmlsec-reqs2-20110421/">http://www.w3.org/TR/2011/WD-xmlsec-reqs2-20110421/</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>