discontinued / server · Files

index.html 115 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 
<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html lang="en" dir="ltr">
<head>
      <meta http-equiv="Content-Type" content="text/html;
                                               charset=UTF-8">
   
      <title>XML Signature Best
      Practices</title> 
       
      <!-- <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:  1px 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 Best Practices</h1><h2 id="w3c-working-draft-09-august-2011">W3C Working Draft 09 August 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2011/WD-xmldsig-bestpractices-20110809/">http://www.w3.org/TR/2011/WD-xmldsig-bestpractices-20110809/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/xmldsig-bestpractices/">http://www.w3.org/TR/xmldsig-bestpractices/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://www.w3.org/2008/xmlsec/Drafts/best-practices/Overview.html">http://www.w3.org/2008/xmlsec/Drafts/best-practices/Overview.html</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100831/">http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100831/</a></dd><dt>Editors:</dt><dd><span>Frederick Hirsch</span>, Nokia</dd>
<dd><span>Pratik Datta</span>, Oracle</dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <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 collects best practices for implementers and
            	users of the XML Signature specification [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-CORE1">XMLDSIG-CORE1</a></cite>].  Most of these 
            	best practices are related to improving security and
            	mitigating attacks, yet others are for best practices in the
            	practical use of XML Signature, such as signing XML that
            	doesn't use namespaces, for example.
         </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 document is expected to be further updated based on
            	both Working Group input and public comments.  The Working
            	Group anticipates to eventually publish a stabilized version
            	of this document as a W3C Working Group Note.
         </p>
         <p>
            The practices in this document have been found generally useful and  
            safe.  However, they do not constitute a normative update to the XML  
            Signature specification, and might not be applicable in certain  
            situations.
            
         </p>
<p>The changes to this document since the last publication on 31
  August 2010 are the following:</p> 
<ul>
<li><p>
Added new best practice and example, see <a href="#xpath-streaming-denial-of-service" class="sectionRef">section 2.1.4 Example: XPath selection that causes denial of service in streaming mode</a>.
</p>
</li>
<li><p>Added a new section containing a summary of the Best Practices, <a href="#bp-summary" class="sectionRef">section 3. Best Practices Summary</a>.</p>
</li>
<li><p>Editorial updates.
</p></li>
</ul>
<p>A <a href="Overview-pub-diff.html">diff-marked version</a> of this
specification which highlights changes 
against
  the <a href="http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100831/">previous version</a> is available.
</p>
      <p>This document was published by the <a href="http://www.w3.org/2008/xmlsec/">XML Security Working Group</a> as a Working Draft. 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>). 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 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>. The group does not expect this document to become a W3C Recommendation. 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="#Overview" class="tocxref"><span class="secno">1. </span>Overview</a></li><li class="tocline"><a href="#practices" class="tocxref"><span class="secno">2. </span>Best Practices</a><ul class="toc"><li class="tocline"><a href="#denial-of-service" class="tocxref"><span class="secno">2.1 </span>For Implementers: Reduce the opportunities for denial of service attacks</a><ul class="toc"><li class="tocline"><a href="#xslt-denial" class="tocxref"><span class="secno">2.1.1 </span>Example: XSLT transform that causes denial of service</a></li><li class="tocline"><a href="#avoid-xslt-extensions" class="tocxref"><span class="secno">2.1.2 </span>Example: XSLT transform that executes
                                      arbitrary code
               </a></li><li class="tocline"><a href="#xpath-filtering-denial" class="tocxref"><span class="secno">2.1.3 </span>Example: XPath Filtering transform that causes denial of service</a></li><li class="tocline"><a href="#xpath-streaming-denial-of-service" class="tocxref"><span class="secno">2.1.4 </span>Example: XPath selection that causes denial of service in streaming mode</a></li><li class="tocline"><a href="#retrieval-method-loop" class="tocxref"><span class="secno">2.1.5 </span>Example: Retrieval method that causes an infinite loop</a></li><li class="tocline"><a href="#problematic-external-references" class="tocxref"><span class="secno">2.1.6 </span>Example: Problematic external references</a></li><li class="tocline"><a href="#too-many-tranforms" class="tocxref"><span class="secno">2.1.7 </span>Example: Denial of service caused by too many transforms</a></li></ul></li><li class="tocline"><a href="#check-what-is-signed" class="tocxref"><span class="secno">2.2 </span>For Applications: Check what is signed</a><ul class="toc"><li class="tocline"><a href="#base-approval-example" class="tocxref"><span class="secno">2.2.1 </span>Base Approval example
                  					
               </a></li><li class="tocline"><a href="#modified-approval-example" class="tocxref"><span class="secno">2.2.2 </span>Modified Approval Example: XPath transform
                                      that causes nothing to be selected for
                                      signing
               </a></li><li class="tocline"><a href="#incorrect-xpath-syntax" class="tocxref"><span class="secno">2.2.3 </span>Modified Approval Example: Incorrect XPath
                                      syntax signals no error and results in nothing
                                      selected for signing
               </a></li><li class="tocline"><a href="#modified-approval-example-nothing-selected" class="tocxref"><span class="secno">2.2.4 </span>Modified Approval Example: XSLT transform that causes nothing to be selected for signing</a></li><li class="tocline"><a href="#modified-approval-example-wrapping-attack" class="tocxref"><span class="secno">2.2.5 </span>Modified Approval Example: Wrapping attack</a></li></ul></li><li class="tocline"><a href="#provide-what-is-signed-api" class="tocxref"><span class="secno">2.3 </span>For Implementers: provide a mechanism to determine what was signed</a><ul class="toc"><li class="tocline"><a href="#return-pre-digested-data" class="tocxref"><span class="secno">2.3.1 </span>Return pre digested data</a></li><li class="tocline"><a href="#return-pre-c14n-data" class="tocxref"><span class="secno">2.3.2 </span>Return pre C14N data</a></li></ul></li><li class="tocline"><a href="#prevent-replay-attacks" class="tocxref"><span class="secno">2.4 </span>For Applications: prevent replay attacks</a><ul class="toc"><li class="tocline"><a href="#sign-what-matters" class="tocxref"><span class="secno">2.4.1 </span>Sign what matters</a></li><li class="tocline"><a href="#datetime-and-nonces" class="tocxref"><span class="secno">2.4.2 </span>Make Effective use of signing time and Nonces to protect against
                    Replay Attacks
               </a></li></ul></li><li class="tocline"><a href="#timestamps" class="tocxref"><span class="secno">2.5 </span>Enable Long-Lived Signatures</a><ul class="toc"><li class="tocline"><a href="#timestamp-authorities" class="tocxref"><span class="secno">2.5.1 </span>Timestamp Authorities</a></li><li class="tocline"><a href="#long-lived-timestamp" class="tocxref"><span class="secno">2.5.2 </span>Include time of signing in Long-Lived Signatures</a></li></ul></li><li class="tocline"><a href="#signing-xml-without-namespaces" class="tocxref"><span class="secno">2.6 </span>Signing XML without namespace information
                               ("legacy XML")
            </a></li><li class="tocline"><a href="#external-unparsed-entities" class="tocxref"><span class="secno">2.7 </span>For Signers: Do not transmit external unparsed entity references</a></li><li class="tocline"><a href="#for-signers-and-verifiers--be-aware-of-schema-processing" class="tocxref"><span class="secno">2.8 </span>For signers and verifiers: Be aware of schema processing</a></li><li class="tocline"><a href="#certificate-encoding" class="tocxref"><span class="secno">2.9 </span>For Implementers: be aware of certificate encoding
               				issues
            </a></li><li class="tocline"><a href="#prefer-xpath-filter2" class="tocxref"><span class="secno">2.10 </span>For Applications: Prefer the XPath Filter 2
                 Transform to the XPath Filter Transform
                 
            </a></li></ul></li><li class="tocline"><a href="#bp-summary" class="tocxref"><span class="secno">3. </span>Best Practices Summary</a></li><li class="tocline"><a href="#thanks" class="tocxref"><span class="secno">4. </span>Acknowledgments</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">A. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">A.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">A.2 </span>Informative references</a></li></ul></li></ul></div>
      
      		
      <div id="Overview" class="section">
         <!--OddPage--><h2><span class="secno">1. </span>Overview</h2>
         <p>
            The XML Signature specification [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-CORE1">XMLDSIG-CORE1</a></cite>] 
            offers powerful and flexible mechanisms to support a variety of use
            cases.
            This flexibility has the downside of increasing the number of possible
            attacks.
            One countermeasure to the increased number of threats is to follow
            best practices, including a simplification of use of XML Signature
            where possible. This document outlines best practices
            noted by the <a href="http://www.w3.org/2007/xmlsec/">XML
            Security Specifications Maintenance Working Group</a>,
            the <a href="http://www.w3.org/2008/xmlsec/">XML Security
            Working Group</a>, as well as items brought to the 
            attention of the community in a Workshop on Next Steps for XML
            Security [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSEC-NEXTSTEPS-2007">XMLSEC-NEXTSTEPS-2007</a></cite>], [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-SEMANTICS">XMLDSIG-SEMANTICS</a></cite>],
            [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-COMPLEXITY">XMLDSIG-COMPLEXITY</a></cite>]. While most of these best
            practices are related to improving security and mitigating attacks, yet others are for best practices in the practical use
            of XML Signature, such as
            signing XML that doesn't use namespaces.
            
         </p>
      </div>
      		
      <div id="practices" class="section">
         <!--OddPage--><h2><span class="secno">2. </span>Best Practices</h2>
         <div id="denial-of-service" class="section">
            <h3><span class="secno">2.1 </span>For Implementers: Reduce the opportunities for denial of service attacks</h3>
            <p>XML Signature  may be used in application server
               systems, where multiple incoming messages are being
               processed simultaneously. In this situation incoming
               messages should be assumed to be possibly hostile with
               the concern that a single poison message could bring
               down an entire set of web applications and services. 
               				
            </p>
            <p>
               Implementation of the XML Signature specification should not always be
               literal. For example,  reference validation before signature
               validation is extremely susceptible to denial of service attacks in
               some scenarios. As will be seen below, certain kinds of transforms may
               require an enormous amount of processing time and certain external URI
               references can lead to possible security violations. One
               recommendation for implementing the XML Signature Recommendation is to
               first "authenticate" the signature, before running any of these
               dangerous operations. 
               				
            </p>
            <div class="practice">
               <p><span id="bp-authenticate-signature-first" class="practicelab">Best Practice 1: Mitigate
                                         denial of service attacks by 
                                         executing potentially dangerous operations only
                                         after successfully authenticating the signature. </span></p>
               <p class="practicedesc">
                  Validate the <code>ds:Reference</code> elements for a signature only after
                  establishing trust, for example by verifying the key and validating
                  <code>ds:SignedInfo</code> first.
                  
               </p>
            </div>
            <p>
               				 XML Signature operations should follow this order of operations:                
               				 
               </p><ol>
                  						
                  <li>
                     							
                     <p>
                        								<em>Step 1</em> fetch the
                        verification key and establish trust in
                        that key (see <a href="#bp-validate-signing-key">Best
                           Practice 2</a>).
                     </p> 
                     						
                  </li>
                  						
                  <li>
                     							
                     <p>
                        								<em>Step 2</em> validate <code>ds:SignedInfo</code> with that key
                     </p>
                     						
                  </li>
                  						
                  <li>
                     							
                     <p>
                        								<em>Step 3</em> validate the references
                     </p>
                     						
                  </li>
                  					
               </ol>
               				In step 1 and step 2 the message should be assumed to
               be untrusted, so no dangerous operations should be
               carried out. But by step 3, the entire <code>ds:SignedInfo</code> has
               been authenticated, and so all the URIs and transforms
               in the <code>ds:SignedInfo</code> can be attributed to a responsible
               party. However an implementation may still choose to
               disallow these operations even in step 3, if the party
               is not trusted to perform them. 
               
            <p></p>
            <p>In step 1, if the verification key is not known
               beforehand and needs to be fetched from <code>ds:KeyInfo</code>, the
               care should be taken in its
               processing. The <code>ds:KeyInfo</code> can contain a <code>ds:RetrievalMethod</code>
               child element, and this could contain dangerous
               transforms, insecure external references and infinite
               loops (see Best Practice #5 and examples below for
               more information).
            </p>
            <p>
               				Another potential security issue in step 1 is the handling of untrusted public keys in <code>ds:KeyInfo</code>.
               			    Just because an XML Signature validates mathematically
               with a public key in the <code>ds:KeyInfo</code> does not mean that
               the signature should be trusted.  
               The public key should be verified before validating the signature value.
               
            </p>
            <p>For example, keys may be exchanged out of band, allowing the use of a <code>ds:KeyValue</code> or <code>X509Certificate</code> element directly. Alternatively,
               certificate and path validation as described by RFC 5280 or some other specification can be applied to information in an <code>X509Data</code>
               element to validate the key bound to a certificate.
               					This usually includes verifying information in the certificate such as the expiration date, the purpose of the certificate,
               checking that it is not revoked, etc.
            </p>
            <p>Key Validation is typically more than a library
               implementation issue, and often involves the
               incorporation of application specific
               information. While there are no specific
               processing rules required by the XML Signature
               specification, it is critical that applications
               include key validation processing that is
               appropriate to their domain of use.
            </p>
            <div class="practice">
               <p>
                 <span id="bp-validate-signing-key" class="practicelab">Best Practice 2: Establish trust in the
                                         verification/validation key.</span></p>
               <p class="practicedesc">Establish appropriate trust in a key, validating X.509 certificates,
                  certificate chains and revocation status, for example.
                  
               </p>
            </div>
            <div id="xslt-denial" class="section">
               <h4><span class="secno">2.1.1 </span>Example: XSLT transform that causes denial of service</h4>
               <p>
                  						The following XSLT transform contains 4 levels
                  of nested loops, and for each loop it iterates
                  over all the nodes of the document. So if the
                  original document has 100 elements, this would
                  take 100^4 = 100 million operations. A
                  malicious message could include this transform
                  and cause an application server to spend hours
                  processing it. The scope of this denial of
                  service attack is greatly reduced when
                  following the best practices described above,
                  since  it is unlikely that an authenticated
                  user would include this kind of transform. 
                  XSLT transforms should only be
                  processed for References, and not for <code>ds:KeyInfo</code> <code>ds:RetrievalMethod</code>s, and
                  only after first authenticating the entire signature and establishing
                  an appropriate degree of trust in the originator of the message. 
                  
                  					
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example sh_xml sh_sourceCode"><a href="samples/dos_xslt.xml">dos_xslt.xml</a>
							

<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-xslt-19991116"</span><span class="sh_keyword">&gt;</span>
  <span class="sh_keyword">&lt;xsl:stylesheet</span> <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"1.0"</span> 
   <span class="sh_type">xmlns:xsl</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/1999/XSL/Transform"</span><span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;xsl:template</span> <span class="sh_type">match</span><span class="sh_symbol">=</span><span class="sh_string">"/"</span><span class="sh_keyword">&gt;</span>
      <span class="sh_keyword">&lt;xsl:for-each</span> <span class="sh_type">select</span><span class="sh_symbol">=</span><span class="sh_string">"//. | //@*"</span><span class="sh_keyword">&gt;</span>
        <span class="sh_keyword">&lt;xsl:for-each</span> <span class="sh_type">select</span><span class="sh_symbol">=</span><span class="sh_string">"//. | //@*"</span><span class="sh_keyword">&gt;</span>
          <span class="sh_keyword">&lt;xsl:for-each</span> <span class="sh_type">select</span><span class="sh_symbol">=</span><span class="sh_string">"//. | //@*"</span><span class="sh_keyword">&gt;</span>
            <span class="sh_keyword">&lt;foo/&gt;</span>
          <span class="sh_keyword">&lt;xsl:for-each&gt;</span>
      <span class="sh_keyword">&lt;xsl:for-each&gt;</span>
    <span class="sh_keyword">&lt;xsl:for-each&gt;</span>
  <span class="sh_keyword">&lt;/xsl:stylesheet&gt;</span>
<span class="sh_keyword">&lt;Transform&gt;</span> </pre></div>
                  					
               <p></p>
               <p> 
                  As discussed further, below, support for XSLT transforms may also
                  expose the signature processor or consumer to further risks in
                  regard to external references or modified approvals. An implementation
                  of XML Signature may choose not to support XSLT, may provide
                  interfaces to allow the application to optionally disable support for
                  it, or may otherwise mitigate risks associated with XSLT.   
                  
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-avoid-xslt" class="practicelab">Best Practice 3: Consider avoiding XSLT
                    Transforms</span></p> 
                  <p class="practicedesc">
                     Arbitrary XSLT processing might lead to denial of service or other
                     risks, so either do not allow XSLT transforms, only enable them for
                     trusted sources, or consider mitigation of the risks.
                     
                  </p>
               </div>
               <p>
                  Instead of using the XML Signature XSLT transform, deployments can
                  define a named transform of their own, by simply coining a URI in
                  their own domain that can be used as the Algorithm.  How that
                  transform is implemented is then out of scope for the signature
                  protocol - a named transform can very well be built in XSLT.
                  
               </p>
               <p>
                  Choosing to name a new transform rather than embedding an XSLT  
                  transform in the signature reference has the advantage
                  that the  semantic intent of the transform can be made clear and  
                  limited in scope, as opposed to a general XSLT transform, possibly  
                  reducing the attack surface and allowing alternate implementations.
                  
               </p>
               <p>
                  What may be lost is the general flexibility of using XSLT, requiring  
                  closer coordination between signer and verifiers since all will be  
                  required to understand the meaning of the new named transform.
                  
               </p>
            </div>
            <div id="avoid-xslt-extensions" class="section">
               <h4><span class="secno">2.1.2 </span>Example: XSLT transform that executes
                                      arbitrary code
               </h4>
               <p> 
                  The XSLT transform in the example below makes use of the user-defined
                  extension feature to execute arbitrary code when validating an XML
                  Signature.  The example syntax is specific to the Xalan XSLT engine,
                  but this approach is valid for most XSLT engines.  The example calls
                  "os:exec"  as a user-defined extension, which is mapped to the Java
                  lang.Runtime.exec() method which can execute any program the process
                  has the rights to run.   While the example calls the shutdown command,
                  one should expect more painful attacks if a series of attack
                  signatures are allowed. 
                  If an implementation of XML Signature allows XSLT processing it should
                  disable support for user-defined extensions. 
                  Changing the Transforms element does invalidate the signature.  XSLT
                  transforms should only be processed after first authenticating the
                  entire signature and establishing an appropriate degree of trust in
                  the originator of the message. 
                  Example: 
                  
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example sh_xml sh_sourceCode"><a href="samples/xslt_transform_extensions.xml">xslt_transform_extensions.xml</a> 
							

<span class="sh_keyword">&lt;Transforms</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>
 <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-xslt-19991116"</span><span class="sh_keyword">&gt;</span>
  <span class="sh_keyword">&lt;xsl:stylesheet</span> <span class="sh_type">version</span><span class="sh_symbol">=</span><span class="sh_string">"1.0"</span> 
       <span class="sh_type">xmlns:xsl</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/1999/XSL/Transform"</span> <span class="sh_type">xmlns:java</span><span class="sh_symbol">=</span><span class="sh_string">"java"</span><span class="sh_keyword">&gt;</span>
   <span class="sh_keyword">&lt;xsl:template</span> <span class="sh_type">match</span><span class="sh_symbol">=</span><span class="sh_string">"/"</span> <span class="sh_type">xmlns:os</span><span class="sh_symbol">=</span><span class="sh_string">"java:lang.Runtime"</span> <span class="sh_keyword">&gt;</span>
    <span class="sh_keyword">&lt;xsl:variable</span> <span class="sh_type">name</span><span class="sh_symbol">=</span><span class="sh_string">"runtime"</span> 
                  <span class="sh_type">select</span><span class="sh_symbol">=</span><span class="sh_string">"java:lang.Runtime.getRuntime()"</span><span class="sh_keyword">/&gt;</span>
    <span class="sh_keyword">&lt;xsl:value-of</span> <span class="sh_type">select</span><span class="sh_symbol">=</span><span class="sh_string">"os:exec($runtime, 'shutdown -i')"</span> <span class="sh_keyword">/&gt;</span>
   <span class="sh_keyword">&lt;/xsl:template&gt;</span>
  <span class="sh_keyword">&lt;/xsl:stylesheet&gt;</span>
 <span class="sh_keyword">&lt;/Transform&gt;</span>
<span class="sh_keyword">&lt;/Transforms&gt;</span></pre></div>
                  					
               <p></p>
               <p>
                  				
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-avoid-xslt-extensions" class="practicelab">Best Practice 4: When XSLT is required disallow the use of user-defined extensions</span></p>
                  <p class="practicedesc">
                     Arbitrary XSLT processing leads to a variety of serious risks, so if
                     the best practice of disallowing XSLT transforms cannot be followed,
                     ensure that user-defined extensions are disabled in your XSLT engine.
                  </p>
               </div>
            </div>
            <div id="xpath-filtering-denial" class="section">
               <h4><span class="secno">2.1.3 </span>Example: XPath Filtering transform that causes denial of service</h4>
               <p> The following XPath Transform has an expression that simply counts all the nodes in the document, but it is embedded in special
                  document that has a 100 namespaces ns0 to ns99 and a 100 &lt;e2&gt; elements. The XPath model expects namespace nodes for each in-scope
                  namespace to be attached to each element, and since in this special document all the 100 namespaces are in scope for each
                  of the 100 elements, the document ends up having 100x100 = 10,000 NamespaceNodes.Now in an XPath Filtering transform, the
                  XPath expression is evaluated for every node in the document. So it takes 10,000 x 10,000 = 100 million operations to evaluate
                  this document. Again the scope of this attack can be reduced by following the above best practices
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example sh_xml sh_sourceCode"><a href="samples/dos_xpath.xml">dos_xpath.xml</a>
							

     <span class="sh_keyword">&lt;dsig: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;dsig:XPath&gt;</span>count(//. | //@* | //namespace::*)<span class="sh_keyword">&lt;/dsig:XPath&gt;</span>
     <span class="sh_keyword">&lt;/dsig:Transform&gt;</span></pre></div>
                  					
               <p></p>
               <p>
                  An implementation of XML Signature may choose not to support the XPath
                  Filter Transform, may provide interfaces to allow the application to
                  optionally disable support for it, or otherwise mitigate risks
                  associated with it. Another option is to support a limited set of XPath expressions - which only use the ancestor or self
                  axes and do not compute string-value of elements.
                  					Yet another option is to use the XPath Filter 2.0 transform instead, because in this transform, the XPath expressions
                  are only evaluated once, not for every node of the transform.
                  				
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-avoid-xpath" class="practicelab">Best Practice 5: Try to avoid or limit XPath
                      transforms</span></p>
                  <p class="practicedesc">
                     Complex XPath expressions (or those constructed together with content
                     to produce expensive processing) might lead to a denial of service risk,
                     so either do not allow XPath transforms or take steps to mitigate the
                     risk of denial of service.
                     
                  </p>
               </div>
            </div>
            <div id="xpath-streaming-denial-of-service" class="section">
               <h4><span class="secno">2.1.4 </span>Example: XPath selection that causes denial of service in streaming mode</h4>
               <p>
When an XML Signature is to be verified in streaming mode, additional
denial of service attack vectors occur. As an example, consider the
following XPath expression that is conforming to the [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-XPATH">XMLDSIG-XPATH</a></cite>]: "//A//B". This XPath is intended to
select every occurrence of &lt;B&gt; elements in the document that have an &lt;A&gt;
element ancestor. Hence, on streaming parsing the document, every
occurrence of an &lt;A&gt; element will trigger a new search context for the
subsequent &lt;B&gt; element. Thus, an attacker may modify the XML document
itself to contain lots of nested &lt;A&gt; elements, i.e.
"&lt;A&gt;&lt;A&gt;&lt;A&gt;&lt;A&gt;&lt;A&gt;&lt;A&gt;&lt;A&gt;&lt;A&gt;&lt;A&gt;&lt;A&gt;....". This will result in n search
contexts, with n being the number of &lt;A&gt; elements in the document, and
hence in O(n^2) comparisons in total. Even worse, if an attacker also
manages to tamper the XPath expression used for selection itself, he can
trigger an even more rapid Denial of Service: an XPath of
"//A//A//A//A//A..." causes the number of search contexts to explode to
O(2^n).
</p>
<p>
Hence, besides following Best Practice 1, it is strongly recommended to
reduce the use of "wildcard" XPath axes (such as "descendant",
"following" etc.) in XML Signatures to a minimum.
</p>
               <div class="practice">
                  <p>
                    <span id="bp-streaming-xpath-limits" class="practicelab">Best Practice 6: Avoid
                      using the "descendant", "descendant-or-self", 
                      "following-sibling", and "following" axes when using streaming XPaths.
                  </span></p>
                  <p class="practicedesc">
The evaluation of such "wildcard" axes may cause an excessive number of
evaluation contexts being triggered concurrently when using a
streaming-based XPath evaluation engine. Since this may lead to Denial
of Service, it is essential that an attacker can not alter the XPaths
prior to evaluation (see Best Practice 1), and that the valid XPath
expressions reduce the use of these axes to a minimum.
                  </p>
               </div>
             </div>
            <div id="retrieval-method-loop" class="section">
               <h4><span class="secno">2.1.5 </span>Example: Retrieval method that causes an infinite loop</h4>
               <p>
                  					The <code>ds:KeyInfo</code> of a signature can contain a <code>ds:RetrievalMethod</code> child element, which can be used to reference a key somewhere
                  else in the document. <code>ds:RetrievalMethod</code> has legitimate uses; for example when there are multiple signatures in the same document,
                  these signatures can use a <code>ds:RetrievalMethod</code> to avoid duplicate <code>ds:KeyInfo</code> certificate entries. However, referencing a certificate
                  (or most other <code>ds:KeyInfo</code> child elements) requires at least one transform, because the reference URI can only refer to the <code>ds:KeyInfo</code>
                  element itself (only it carries an Id attribute). Also, there is nothing that prevents the <code>ds:RetrievalMethod</code> from pointing back
                  to itself directly or indirectly and forming a cyclic chain of references.
                  An implementation that must handle potentially hostile messages
                  should constrain 
                  the <code>ds:RetrievalMethod</code> elements that it processes - e.g.
                  				permitting only a same-document URI reference, and limiting the transforms allowed.
                  					
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example sh_xml sh_sourceCode"><a href="samples/dos_retrieval_loop1.xml">dos_retrieval_loop1.xml</a>
							

<span class="sh_keyword">&lt;RetrievalMethod</span> <span class="sh_type">xml:id</span><span class="sh_symbol">=</span><span class="sh_string">"r1"</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#r1"</span><span class="sh_keyword">/&gt;</span></pre></div>
                  					
               <p></p>
               <p>
                  						
                  </p><div class="example"><pre class="example sh_xml sh_sourceCode"><a href="samples/dos_retrieval_loop2.xml">dos_retrieval_loop2.xml</a>
							

<span class="sh_keyword">&lt;RetrievalMethod</span> <span class="sh_type">Id</span><span class="sh_symbol">=</span><span class="sh_string">"r1"</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#r2"</span><span class="sh_keyword">/&gt;</span>
<span class="sh_keyword">&lt;RetrievalMethod</span> <span class="sh_type">Id</span><span class="sh_symbol">=</span><span class="sh_string">"r2"</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"#r1"</span><span class="sh_keyword">/&gt;</span></pre></div>
                  					
               <p></p>
               <div class="practice">
                  <p>
                    <span id="bp-avoid-retrievalmethod" class="practicelab">Best Practice 7: Try to avoid or limit <code>ds:RetrievalMethod</code>
                      support with <code>ds:KeyInfo</code></span></p>
                  <p class="practicedesc">
                     <code>ds:RetrievalMethod</code> can cause security risks due to transforms, so
                     consider limiting support for it.
                     
                  </p>
               </div>
            </div>
            <div id="problematic-external-references" class="section">
               <h4><span class="secno">2.1.6 </span>Example: Problematic external references</h4>
               <p>
                  					An XML Signature message can use URIs to references keys or to reference data to be signed. Same document references
                  are fine, but external references to the file system or other web sites can cause exceptions or cross site attacks.  For example,
                  a message could have a URI reference to "file://etc/passwd" in its <code>ds:KeyInfo</code>. Obviously there is no key present in file://etc/passwd,
                  but if the xmlsec implementation blindly tries to resolve this URI, it will end up reading the /etc/passwd file. If this implementation
                  is running in a sandbox, where access to sensitive files is prohibited, it may be terminated by the container for trying to
                  access this file. 
                  					
               </p>
               <p>
                  URI references based on HTTP can cause a different kind of
                  damage since these URIs can have query parameters that can cause
                  some data to be submitted/modified in another web site. Suppose
                  there is a company internal HR website that is not accessible from
                  outside the company. If there is a web service exposed to the
                  outside world that accepts signed requests it may be possible to
                  inappropriately access the HR site. A malicious message from the
                  outside world can send a signature, with a reference URI like this
                  http://hrwebsite.example.com/addHoliday?date=May30. If the
                  XML Security implementation blindly tries to dereference this URI
                  when verifying the signature, it may unintentionally have the side
                  effect of adding an extra holiday.
                  
               </p>
               <p>When implementing XML Signature, it is recommended to take caution
                  in retrieving references with 
                  arbitrary URI schemes which may trigger unintended side-effects
                  and/or when retrieving references over the network. Care should
                  be taken to limit the size and timeout values for content retrieved
                  over the network in order to avoid denial of service conditions.
                  
               </p>
               <p>When implementing XML Signature, it is recommended to
                  follow the recommendations in section 2.3
                  to provide cached references to the verified content, as remote
                  references may change between the time they are retrieved for
                  verification and subsequent retrieval for use by the application.
                  Retrieval of remote references may also leak information about the
                  verifiers of a message, such as a "web bug" that causes access to the server, 
                  resulting in notification being provided to the server regarding the web page 
                  access. An example is an image that cannot be seen but results in a server 
                  access [<cite><a class="bibref" rel="biblioentry" href="#bib-WebBug-Wikipedia">WebBug-Wikipedia</a></cite>].
                  
               </p>
               <p>
                  When implementing XML Signature with support for XSLT transforms, it
                  can be useful 
                  to constrain outbound network connectivity from the XSLT
                  processor in order to avoid information disclosure risks as XSLT
                  instructions may be able to dynamically retrieve content from local
                  files and network resources and disclose this to other networks.
                  
               </p>
               <p>
                  					Some kinds of external references are perfectly acceptable, e.g. Web Services Security uses a "cid:" URL for referencing
                  data inside attachments, and this can be considered to be a same document reference.  Another legitimate example would be
                  to allow references to content in the same ZIP or other virtual file system package as a signature, but not to content outside
                  of the package.
                  					
               </p>
               <p>
                  					The scope of this attack is much reduced by following the above best practices, because with that only URIs inside a
                  validated <code>ds:SignedInfo</code> section will be accessed. But to totally eliminate this kind of attack, an implementation can choose
                  not to support external references at all.
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-control-external-references" class="practicelab">Best Practice 8: Control External References</span></p>
                  <p class="practicedesc">To reduce risks associated with <code>ds:Reference</code> URIs that access non
                     local content, it is recommended to be mitigate risks associated with
                     query parameters, unknown URI schemes, or attempts to access
                     inappropriate content.
                     
                  </p>
               </div>
            </div>
            <div id="too-many-tranforms" class="section">
               <h4><span class="secno">2.1.7 </span>Example: Denial of service caused by too many transforms</h4>
               <p>XML Signature spec does not limit the number of transforms, and a malicious message could come in with 10,000 C14N transforms.
                  C14N transforms involve lot of processing, and 10,000 transforms could starve all other messages.
               </p>
               <p> Again the scope of this attack is also reduced by following the above best practices, as now an unauthenticated user would
                  need to at first obtain a valid signing key and sign this <code>ds:SignedInfo</code> section with 10,000 C14N transform.
               </p>
               <p>This signature has a 1000 C14N and a 1000 XPath transforms, which makes it slow. This document has a 100 namespaces ns0 to
                  ns99 and a 100 &lt;e2&gt; elements, like in the XPath denial of service example. 
                  Since XPath expands all the namespaces for each element, it means that there are 100x100 = 10,000 NamespaceNodes
                  All of these are processed for every C14N and XPath transform, so total operations is 2000 x 10,000 = 20,000,000 operations.
                  Note some C14N implementations do not expand all the Namespace nodes but do shortcuts for performance, to thwart that this
                  example has an XPath before every C14N. 
                  					
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example sh_xml sh_sourceCode"><a href="samples/dos_toomanytranforms.xml">dos_toomanytranforms.xml</a>
							

     <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&gt;</span>1<span class="sh_keyword">&lt;/XPath&gt;</span>
     <span class="sh_keyword">&lt;/Transform&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/2001/REC-xml-c14n-20010315"</span><span class="sh_keyword">&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&gt;</span>1<span class="sh_keyword">&lt;/XPath&gt;</span>
     <span class="sh_keyword">&lt;/Transform&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/2001/REC-xml-c14n-20010315"</span><span class="sh_keyword">&gt;</span>

	... repeated 1000 times</pre></div>
                  					
               <p></p>
               <p>To totally eliminate this kind of attack, an implementation can choose to have an upper limit of the number of transforms
                  in each Reference.
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-limit-number-of-transforms" class="practicelab">Best Practice 9: Limit number of <code>ds:Reference</code> transforms allowed.</span></p>
                  <p class="practicedesc">
                     Too many transforms in a processing chain for a <code>ds:Reference</code> can
                     produce a denial of service effect, consider limiting the number of
                     transforms allowed in a transformation chain.
                  </p>
               </div>
            </div>
         </div>
         <div id="check-what-is-signed" class="section">
            <h3><span class="secno">2.2 </span>For Applications: Check what is signed</h3>
            <p>XML Signature offers many complex features, which
               can make it very difficult to keep track of what was
               really signed. 
               When implementing XML Signature it is important to understand what is
               provided by a signature verification library, and whether additional
               steps are required to allow a user to see what is being verified. 
               The examples below illustrate how an
               errant XSLT or XPath transform can change what was
               supposed to have been signed. So the application
               should inspect the signature and check all the
               references and the transforms, before accepting
               it. This is done much easier if the application sets
               up strict rules on what kinds of URI references and
               transforms are acceptable. Here are some sample
               rules. 
               				
            </p>
            <ul>
               					
               <li>
                  						
                  <p>
                     							<em>For simple disjoint signatures:</em> Reference URI must use local ID reference, and only one transform - C14N
                  </p>
                  					
               </li>
               					
               <li>
                  						
                  <p>
                     							<em>For simple enveloped signatures: </em>References URI must use local ID  reference, and two transforms - Enveloped Signature and C14N, in that order
                  </p>
                  					
               </li>
               					
               <li>
                  						
                  <p>
                     							<em>For signatures on base64 encoded binary content:</em> Reference URI must local ID references, and only one transform - Base64 decode.
                     						
                  </p>
                  					
               </li>
               				
            </ul>
            <p>
               These sample rules may need to be adjusted for the anticipated use.
               When used with web services WS-Security, for example, consider the
               STR Transform  in place of a C14N transform, and with SWA Attachment,
               Attachment Content/Complete transform could be used in place of a
               base64 transform. 
               
            </p>
            <p>
               					Sometimes ID references may not be acceptable, because the element to be signed may have a very closed schema, and adding
               an ID attributes would make it invalid. In that case the element should be identified with an XPath filter transform. Other
               choices are to use an XPath Filter 2 transform, or XPath in XPointer URI, but support for these are optional.
               					However XPath expressions can be very complicated, so using an XPath makes it very hard for the application to know exactly
               what was signed, but again the application could put in a strict rule about the kind of XPath expressions that are allowed,
               for example:
               				
            </p>
            <ul>
               					
               <li>
                  						
                  <p>
                     							<em>For XPath expressions</em> The expression must be of the farm : ancestor-or-self:elementName.  This expressions includes all elements whose name is
                     elementName. Choosing a specific element by name and position requires a very complex XPath, and that would be too hard for
                     the application to verify 
                  </p>
                  					
               </li>
               				
            </ul>
            <div class="practice">
               <p>
                 <span id="bp-inspect-reference-uri-and-transforms" class="practicelab">Best Practice 10: Enable
                     verifier to automate "see
                     what is signed" functionality.</span></p>
               <p class="practicedesc">
                  Enable the application to verify that what is signed is what was
                  expected to be signed, by providing access to id and transform
                  information.
                  
               </p>
            </div>
            <div id="base-approval-example" class="section">
               <h4><span class="secno">2.2.1 </span>Base Approval example
                  					
               </h4>
               <p>
                  				 Consider an application which is processing approvals, and expects a message of the following format where the where
                  the Approval is supposed to be signed
                  				
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example
 sh_xml sh_sourceCode">Expected message for approval verification
			
<span class="sh_keyword">&lt;Doc&gt;</span>
  <span class="sh_keyword">&lt;Approval</span> <span class="sh_type">xml:id</span><span class="sh_symbol">=</span><span class="sh_string">"ap"</span> <span class="sh_keyword">&gt;</span>...<span class="sh_keyword">&lt;/Approval&gt;</span>
  <span class="sh_keyword">&lt;Signature&gt;</span>
     ...
       <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"ap"</span><span class="sh_keyword">/&gt;</span>
    ...
  <span class="sh_keyword">&lt;/Signature&gt;</span> 
<span class="sh_keyword">&lt;/Doc&gt;</span> 	</pre></div>
                  					
               <p></p>
               <p>It is not sufficient for the application to
                  check if there is a URI in the reference and that
                  reference points to the Approval. Because there
                  may be some transforms in that reference which
                  modify what is really signed. 
                  				
               </p>
            </div>
            <div id="modified-approval-example" class="section">
               <h4><span class="secno">2.2.2 </span>Modified Approval Example: XPath transform
                                      that causes nothing to be selected for
                                      signing
               </h4>
               <p>In this case there is an XPath transform that
                  evaluates to zero or false for every node, so it
                  ends up selecting nothing.
               </p>
               <p>Whether this is an error or not needs to be determined by the
                  application. It is an error and the document should be rejected if the
                  application expected some content to be signed. There may be cases,
                  however, where this is not an error. For example, an application may
                  wish to ensure that every <em>price</em> element is signed,
                  without knowing how many there are. In some cases there might be none
                  in the signed document. This signature allows the application to detect added
                  <em>price</em> elements, so it is useful even if the were no
                  content in the initial signing.
                  					
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example
 sh_xml sh_sourceCode">Insecure Approval verification message
			
<span class="sh_keyword">&lt;Doc&gt;</span>
  <span class="sh_keyword">&lt;Approval</span> <span class="sh_type">xml:id</span><span class="sh_symbol">=</span><span class="sh_string">"ap"</span><span class="sh_keyword">&gt;</span>...<span class="sh_keyword">&lt;/Approval&gt;</span>
  <span class="sh_keyword">&lt;Signature&gt;</span>
     ...
       <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"ap"</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">"...XPath..."</span><span class="sh_keyword">&gt;</span>
				  <span class="sh_keyword">&lt;XPath&gt;</span>0<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;/Reference&gt;</span>
  <span class="sh_keyword">&lt;/Signature&gt;</span> 
<span class="sh_keyword">&lt;/Doc&gt;</span> 	</pre></div>
                  					
               <p></p>
            </div>
            <div id="incorrect-xpath-syntax" class="section">
               <h4><span class="secno">2.2.3 </span>Modified Approval Example: Incorrect XPath
                                      syntax signals no error and results in nothing
                                      selected for signing
               </h4>
               <p>
                  An XPath evaluation will not raise an
                  exception, nor give any other advice that the XPath selected nothing
                  if the XPath expression has incorrect syntax. This is due to the fact
                  that an XPath parser will 
                  interpret misspelled function names as regular XPath tokens,
                  leading to completely different semantics that do not match the
                  intended selection.
                  
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example sh_xml sh_sourceCode">Example: Incorrect XPath resulting in insecure Approval verification message
                          
			
<span class="sh_keyword">&lt;Doc</span> <span class="sh_type">xmlns</span><span class="sh_symbol">=</span><span class="sh_string">"http://any.ns"</span>
<span class="sh_type">xmlns:dsig-xpath</span><span class="sh_symbol">=</span><span class="sh_string">"http://www.w3.org/2002/06/xmldsig-filter2"</span><span class="sh_keyword">&gt;</span>
<span class="sh_keyword">&lt;Approval</span> <span class="sh_type">xml:id</span><span class="sh_symbol">=</span><span class="sh_string">"ap"</span><span class="sh_keyword">&gt;</span>...<span class="sh_keyword">&lt;/Approval&gt;</span>
<span class="sh_keyword">&lt;Signature&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">"...xmldsig-filter2"</span><span class="sh_keyword">&gt;</span>
<span class="sh_keyword">&lt;dsig-xpath:XPath</span> <span class="sh_type">Filter</span><span class="sh_symbol">=</span><span class="sh_string">"intersect"</span><span class="sh_keyword">&gt;</span>//*[localname="Approval" and
namespace-uri="http://any.ns"]<span class="sh_keyword">&lt;/dsig-xpath:XPath&gt;</span>
<span class="sh_keyword">&lt;/Transform&gt;</span>
<span class="sh_keyword">&lt;/Transforms&gt;</span> ...
<span class="sh_keyword">&lt;/Reference&gt;</span>
<span class="sh_keyword">&lt;/Signature&gt;</span>
<span class="sh_keyword">&lt;/Doc&gt;</span></pre></div>
                  					
               <p></p>
               <p>
                  In this case, the XPath filter looks like it is selecting the
                  <em>Approval</em> 
                  element 
                  of namespace <em>http://any.ns</em>. In reality it selects
                  nothing at all since the function should be spelled "local-name" instead of
                  "localname" and 
                  both function calls need brackets <em>()</em> in the correct
                  syntax. The correct XPath 
                  expression to match the intent is:
                  
               </p>
               <p>
                  <em>//*[local-name()="Approval" and
                     namespace-uri()="http://any.ns"]</em>.
                  
               </p>
               <p>
                  Since nothing is selected, the digital signature does not 
                  provide any data integrity properties. It also raises no exception
                  on either signature generation or on verification. Hence, when
                  applying XML Signatures using XPath it is recommended to always actively
                  verify that the signature protects the intended elements.
                  
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-verify-signed-vs-expected" class="practicelab">Best Practice 11: When
                        applying XML Signatures using XPath it is recommended to always actively
                        verify that the signature protects the intended elements and not more or
                        less.</span></p>
                  <p class="practicedesc">
                     Since incorrect XPath expressions can result in incorrect signing,
                     applications should verify that what is signed is what is expected to
                     be signed.
                     
                  </p>
               </div>
            </div>
            <div id="modified-approval-example-nothing-selected" class="section">
               <h4><span class="secno">2.2.4 </span>Modified Approval Example: XSLT transform that causes nothing to be selected for signing</h4>
               <p>Similar to the previous example, this one uses an XSLT transform which takes the incoming document, ignores it, and emits
                  a "&lt;foo/&gt;" . So the actual Approval isn't signed. Obviously this message needs to be rejected. 
                  					
               </p>
               <p>
                  						
                  </p><div class="example"><pre class="example sh_xml sh_sourceCode">Insecure Approval verification message
			
<span class="sh_keyword">&lt;Doc&gt;</span>
  <span class="sh_keyword">&lt;Approval</span> <span class="sh_type">xml:id</span><span class="sh_symbol">=</span><span class="sh_string">"ap"</span><span class="sh_keyword">&gt;</span>...<span class="sh_keyword">&lt;/Approval&gt;</span>
  <span class="sh_keyword">&lt;Signature&gt;</span>
     ...
       <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"ap"</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">"...xslt..."</span><span class="sh_keyword">&gt;</span>
              <span class="sh_keyword">&lt;xsl:stylesheet&gt;</span>
                    <span class="sh_keyword">&lt;xsl:template</span> <span class="sh_type">match</span><span class="sh_symbol">=</span><span class="sh_string">"/"</span><span class="sh_keyword">&gt;</span>
                      <span class="sh_keyword">&lt;foo/&gt;</span>
                    <span class="sh_keyword">&lt;/xsl:template&gt;</span>
                 <span class="sh_keyword">&lt;/xsl:stylesheet&gt;</span> 
              <span class="sh_keyword">&lt;/Transform&gt;</span>
           <span class="sh_keyword">&lt;/Transforms&gt;</span>     ...
       <span class="sh_keyword">&lt;/Reference&gt;</span>
  <span class="sh_keyword">&lt;/Signature&gt;</span> 
<span class="sh_keyword">&lt;/Doc&gt;</span> 	</pre></div>
                  					
               <p></p>
            </div>
            <div id="modified-approval-example-wrapping-attack" class="section">
               <h4><span class="secno">2.2.5 </span>Modified Approval Example: Wrapping attack</h4>
               <p>This one is a different kind of problem - a wrapping attack.There are no transforms here, but notice that Reference URI is
                  not "ap" but "ap2". And "ap2" points to another &lt;Approval&gt; element that is squirreled away in an Object element. An Object
                  element allows any content. The application will be fooled into thinking that the approval element is properly signed, it
                  just checks the name of what the element that the Reference points to. It should check both the name and the position of the
                  element.
                  					
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-inspect-reference-uri" class="practicelab">Best Practice 12: When checking a reference URI, don't
                                                just check the name of the element</span></p>
                  <p class="practicedesc">To mitigate attacks where the content that is present in the
                     document is not what was actually signed due to various
                     transformations, verifiers should check both the name and position of an
                     element as part of signature verification.
                     
                  </p>
               </div>
               <p>
                  						
                  </p><div class="example"><pre class="example
 sh_xml sh_sourceCode">Insecure Approval verification message
			
<span class="sh_keyword">&lt;Doc&gt;</span>
  <span class="sh_keyword">&lt;Approval</span> <span class="sh_type">xml:id</span><span class="sh_symbol">=</span><span class="sh_string">"ap"</span><span class="sh_keyword">&gt;</span>...<span class="sh_keyword">&lt;/Approval&gt;</span>
  <span class="sh_keyword">&lt;Signature&gt;</span>
     ...
       <span class="sh_keyword">&lt;Reference</span> <span class="sh_type">URI</span><span class="sh_symbol">=</span><span class="sh_string">"ap2"</span><span class="sh_keyword">/&gt;</span>
    ...
    <span class="sh_keyword">&lt;Object&gt;</span>
      <span class="sh_keyword">&lt;Approval</span> <span class="sh_type">xml:id</span><span class="sh_symbol">=</span><span class="sh_string">"ap2"</span><span class="sh_keyword">&gt;</span>...<span class="sh_keyword">&lt;/Approval&gt;</span>
    <span class="sh_keyword">&lt;/Object&gt;</span> 
  <span class="sh_keyword">&lt;/Signature&gt;</span> 
<span class="sh_keyword">&lt;/Doc&gt;</span> 	</pre></div>
                  					
               <p></p>
            </div>
         </div>
         <div id="provide-what-is-signed-api" class="section">
            <h3><span class="secno">2.3 </span>For Implementers: provide a mechanism to determine what was signed</h3>
            <p>As shown above, it is very hard for the application
               to know what was signed, especially if the signature
               uses complex XPath expressions to identify
               elements. 
               When implementing XML Signature some environments may require a means
               to provide a means to be able to return what was signed when
               inspecting a signature. 
               This is
               especially important when implementations allow
               references to content retrieved over the network, so
               that an application does not have to retrieve such
               references again.  A second dereference raises the
               risk that that is obtained is not the same -- avoiding
               this guarantees receiving the same information
               originally used to validate the signature. This
               section discusses two approaches for this.
            </p>
            <div id="return-pre-digested-data" class="section">
               <h4><span class="secno">2.3.1 </span>Return pre digested data</h4>
               <p>While doing reference validation, the implementation needs to run through the transforms for each reference, the output of
                  which is a byte array, and then digest this byte array. The implementation should provide a way to cache this byte array and
                  return it tot he application. This would let the application know exactly what was considered for signing This is the only
                  recommended approach for processors and applications that allow remote DTDs, as entity expansion during C14N may introduce
                  another opportunity for a malicious party to supply different content between signature validation and an application's subsequent
                  re-processing of the message.
               </p>
            </div>
            <div id="return-pre-c14n-data" class="section">
               <h4><span class="secno">2.3.2 </span>Return pre C14N data</h4>
               <p>While the above mechanism let the application
                  know exactly what was signed, it cannot be used by
                  application to programmatically compare with what
                  was expected to be signed. For programmatic
                  comparison the application needs another byte
                  array, and it is hard for the application to
                  generate a byte array that will match byte for
                  byte with the expected byte array.
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-see-sign-api" class="practicelab">Best Practice 13: Offer interfaces for application to learn what was
                        signed.
                        </span></p>
                  <p class="practicedesc">Returning pre-digested data and pre-C14N data may help an application
                     determine what was signed correctly.
                     
                  </p>
               </div>
               <p>A better but more complicated approach is to
                  return the pre-C14N data as a nodeset. 
                  This should include all the
                  transforms except the last C14N transform - the
                  output of this should be nodeset. If there are
                  multiple references in the signature,the result
                  should be a union of these nodesets. 
                  The application can
                  compare this nodeset with the expected
                  nodeset. The expected nodeset should be a subset
                  of the signed nodeset.
               </p>
               <p> DOM implementations usually provide a function to compare if two nodes are the same - in some DOM implementations just comparing
                  pointers or references is sufficient to know if they are the same, DOM3 specifies a "isSameNode()" function for node comparison.
                  					
               </p>
               <p> This approach only works for XML data, not for binary data. Also the transform list should follow these rules.
                  					
                  </p><ul>
                     						
                     <li>
                        <p>The C14N transform should be last transform in the list. Note if there no C14N transform, an inclusive C14N is implicitly
                           added
                        </p>
                        						
                     </li>
                     						
                     <li>
                        <p>There should be no transform which causes data to be converted to binary and then back to a nodeset. The reason is that this
                           would cause the nodeset to be from a completely different document, which cannot be compared with the expected nodeset. 
                        </p>
                     </li>
                     					
                  </ul>
                  					
               <p></p>
            </div>
         </div>
         <div id="prevent-replay-attacks" class="section">
            <h3><span class="secno">2.4 </span>For Applications: prevent replay attacks</h3>
            <div id="sign-what-matters" class="section">
               <h4><span class="secno">2.4.1 </span>Sign what matters</h4>
               <p>
                  By electing to only sign portions of a document this opens the
                  potential for substitution attacks.
                  
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-sign-everything" class="practicelab">Best Practice 14: Unless impractical, sign all parts of
                                                the document.</span></p>
                  <p class="practicedesc">Signing all parts of a document helps prevent substitution and
                     wrapping attacks.
                     
                  </p>
               </div>
               <p>
                  To give an example, consider the case where someone signed the action
                  part of 
                  the request, but didn't include the user name part.  In this
                  case  an
                  attacker can easily take the signed request as is, and just
                  change the user name and resubmit it.  These Replay attacks are
                  much easier when you are signing a small part of the
                  document. To prevent replay attacks, it is recommended to
                  include user names, keys, timestamps, etc into the signature.
                  
               </p>
               <p>
                  A second example is a "wrapping attack" [<cite><a class="bibref" rel="biblioentry" href="#bib-MCINTOSH-WRAP">MCINTOSH-WRAP</a></cite>]
                  where additional XML content is added to change what is signed.
                  An example is where only the amounts in a PurchaseOrder are signed
                  rather than the entire purchase order.
                  
               </p>
            </div>
            <div id="datetime-and-nonces" class="section">
               <h4><span class="secno">2.4.2 </span>Make Effective use of signing time and Nonces to protect against
                    Replay Attacks
               </h4>
               <div class="practice">
                  <p><span id="bp-nonce-plus-datetime" class="practicelab">Best Practice 15: Use a nonce in combination with signing
                                            time</span></p>
                  <p class="practicedesc">A nonce enables detection of duplicate signed items.
                     
                  </p>
               </div>
               <p>
                  In many cases replay detection is provided as a part of application
                  logic, often and a by product of normal processing. For example, if
                  purchase orders are required to have a unique serial number, duplicates
                  may be automatically discarded. In these cases, it is not strictly
                  necessary for the security mechanisms to provide replay detection.
                  However, since application logic may be unknown or change over time,
                  providing replay detection is the safest policy.
                  
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-not-app" class="practicelab">Best Practice 16: Do not rely on application logic to prevent
                                            replay attacks since
                                            applications may change.</span></p>
                  <p class="practicedesc">Supporting replay detection at the security processing layer removes a
                     requirement for application designers to be concerned about this
                     security issue and may prevent a risk if support for replay detection
                     is removed from the application processing for various other reasons.
                     
                  </p>
               </div>
               <p>
                  Nonces and passwords must fall under at least one signature to be
                  effective. In addition, the signature should include at least a critical
                  portion of the message payload, otherwise an attacker might be able to
                  discard the dateTime and its signature without arousing suspicion.
                  
               </p>
               <div class="practice">
                  <p>
                    <span id="bp-sign-nonce-dateTime" class="practicelab">Best Practice 17: Nonce and signing time must be signature
                                            protected.</span></p>
                  <p class="practicedesc">A signature must include the nonce and signing time in the signature
                     calculation for them to be effective, since otherwise an attacker
                     could change them without detection.
                     
                  </p>
               </div>
               <p>
                  Web Services Security [<cite><a class="bibref" rel="biblioentry" href="#bib-WS-SECURITY11">WS-SECURITY11</a></cite>]
 defines a
                  &lt;Timestamp&gt; element which can contain a Created dateTime value
                  and/or a Expires dateTime value. The Created value obviously represents an
                  observation 
                  made. The expires value is more problematic, as it represents a policy
                  choice which should belong to the receiver not the sender. Setting an
                  expiration date on a Token may reflect how long the data is expected to
                  be correct or how long the secret may remain uncompromised. However, the
                  semantics of a signature "expiring" is not clear.
                  
               </p>
               <p>
                  WSS provides for the use of a nonce in conjunction with hashed
                  passwords, but not for general use with asymmetric or symmetric
                  signatures.
                  
               </p>
               <p>
                  WSS sets a limit of one &lt;Timestamp&gt; element per Security header, but their can be
                  several signatures. In the typical case where all signatures are
                  generated at about the same time, this is not a problem, but SOAP
                  messages may pass through multiple intermediaries and be queued for a
                  time, so this limitation could possibly create problems. In general
                  Senders should ensure and receivers should assume that the &lt;Timestamp&gt;
                  represents the first (oldest) signature. It is not clear how if at all a
                  &lt;Timestamp&gt; relates to encrypted data.
                  
               </p>
            </div>
         </div>
         <div id="timestamps" class="section">
            <h3><span class="secno">2.5 </span>Enable Long-Lived Signatures</h3>
            <div id="timestamp-authorities" class="section">
               <h4><span class="secno">2.5.1 </span>Timestamp Authorities</h4>
               <div class="practice">
                  <p>
                    <span id="bp-timestamp-authorities-for-long-lived-sigs" class="practicelab">Best Practice 18: Use Timestamp tokens issued by Timestamp
                                            authorities for long lived signatures</span></p>
                  <p class="practicedesc">Such time-stamps prove that what was  
                     time-stamped actually existed at the time indicated, whereas any other  
                     time indication is only a claim by the signer and is less useful in  
                     dispute resolution.
                  </p>
               </div>
               <p>
                  The X.509 Public Key Infrastructure Time-Stamp Protocol,  RFC 3161
                  [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3161">RFC3161</a></cite>],   
                  describes the use of a time stamp authority to establish evidence that  
                  a signature existed before a given time, useful in applications where  
                  dispute resolution may be necessary.
               </p>
               <p class="note">
                 The IETF PKIX WG "ESSCertIDv2 update for RFC 3161"
                 should be consulted when referencing
                 RFC 3161 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3161-PKIX-UPDATE-9">RFC3161-PKIX-UPDATE-9</a></cite>]. 
               </p>
               <p>ETSI has produced TS 101 903: "XML Advanced
                  Electronic Signatures" [<cite><a class="bibref" rel="biblioentry" href="#bib-XADES">XADES</a></cite>],
                  which among other ones, deals with the issue of
                  long-term electronic signatures. It has defined a
                  standard way for incorporating time-stamps to XML
                  signatures. In addition to the signature
                  time-stamp, which should be generated soon after
                  the generation of the signature, other time-stamps
                  may be added to the signature structure protecting
                  the validation material used by the
                  verifier. Recurrent time-stamping (with stronger
                  algorithms and keys) on all these items, i.e., the
                  signature, the validation material and previous
                  time-stamps counters the revocation of validation
                  data and weaknesses of cryptographic algorithms
                  and keys. RFC 3161 and OASIS DSS time-stamps may
                  be incorporated in XAdES signatures.
               </p>
               <p>OASIS DSS core specifies a XML format for
                  time-stamps based in XML Sig. In addition DSS core
                  and profiles allow the generation and verification
                  of signatures, time-stamps, and time-stamped
                  signatures by a centralized server.
               </p>
               <p>The XAdES and DSS Timestamps should not be
                  confused with WSS Timestamps. Although they are
                  both called Timestamps, the WSS &lt;Timestamp&gt;
                  is just a xsd:dateTime value added by the signer
                  representing the claimed time of signing. XAdES
                  and DSS Timestamps are full fledged signatures
                  generated by a Time-stamp Authority (TSA) binding
                  together a the digest of what is being
                  time-stamped and a dateTime value. TSAs are
                  trusted third parties which operate under certain
                  rules on procedures, software and hardware
                  including time accuracy assurance mechanisms. 
               </p>
            </div>
            <div id="long-lived-timestamp" class="section">
               <h4><span class="secno">2.5.2 </span>Include time of signing in Long-Lived Signatures</h4>
               <div class="practice">
                  <p><span id="bp-use-timestamp" class="practicelab">Best Practice 19: Long lived signatures should include a xsd:dateTime field to indicate the time of
                        signing just as a handwritten signature does.</span></p>
                  <p class="practicedesc">The time of signing is an important consideration for use of
                     long-lived signatures and should be included.
                     
                  </p>
               </div>
               <p>
                  Note that in the absence
                  of a trusted time source, such a signing time should be viewed as
                  indicating a minimum, but not a maximum age. This is because we assume
                  that a time in the future would be noticed during processing. So if the
                  time does not indicate when the signature was computed it at least
                  indicates earliest time it might have been made available for
                  processing.
                  
               </p>
               <p>
                  It is considered desirable for ephemeral signature to be relatively
                  recently signed and not to be replayed. The signing time is useful for either
                  or both of these. The use for freshness is obvious. Signing time is not
                  ideal for preventing replay, since depending on the granularity,
                  duplicates are possible. 
                  
               </p>
               <p>
                  A better scheme is to use a nonce and a signing time The nonce is checked
                  to see if it duplicates a previously presented value. The signing time
                  allows receivers to limit how long nonces are retained (or how many are
                  retained).
                  
               </p>
            </div>
         </div>
         <div id="signing-xml-without-namespaces" class="section">
            <h3><span class="secno">2.6 </span>Signing XML without namespace information
                               ("legacy XML")
            </h3>
            <div class="practice">
               <p>
                 <span id="bp-namespace-inheritance" class="practicelab">Best Practice 20: When creating an enveloping signature over XML
                     without namespace information, take steps to avoid having that content
                     inherit the XML Signature namespace.</span></p>
               <p class="practicedesc">Avoid enveloped content from inheriting the XML Signature namespace by
                  either inserting an empty default namespace declaration or by defining
                  a namespace prefix for the Signature Namespace usage.
                  
               </p>
            </div>
            <p>
               When creating an enveloping 
               signature over XML without namespace information, it may inherit the XML 
               Signature namespace of the Object element, which is not the intended 
               behavior. There are two potential workarounds:
               
            </p>
            <ol>
               					
               <li>
                  						
                  <p>Insert an xmlns="" namespace definition in the legacy XML. However, 
                     this is not always practical.
                  </p>
                  					
               </li>
               					
               <li>
                  						
                  <p>Insulate it from the XML Signature namespace by defining a namespace 
                     prefix on the XML Signature (ex: "ds").
                     
                  </p>
                  					
               </li>
               				
            </ol>
            <p>This was also discussed in the OASIS Digital Signature Services
               technical committee, see <a href="http://lists.oasis-open.org/archives/dss/200504/msg00048.html">http://lists.oasis-open.org/archives/dss/200504/msg00048.html</a>.
               
            </p>
         </div>
         <div id="external-unparsed-entities" class="section">
            <h3><span class="secno">2.7 </span>For Signers: Do not transmit external unparsed entity references</h3>
            <p>
               			    Resolving external unparsed entity references can imply network access
               			    and can in certain circumstances be a security concern for signature
               			    verifiers. As a policy decision, signature verifiers may choose not to
               			    resolve such entities, leading to a loss of interoperability.
               			  
            </p>
            <div class="practice">
               <p>
                 <span id="unparsed-external-entity-refs" class="practicelab">Best Practice 21: Do not transmit unparsed external entity
               references.</span></p> 
               <p class="practicedesc">Do not transmit unparsed external entity references in signed
                  			    material.  Expand all entity references before creating the cleartext
                  			    that is transmitted.
               </p>
            </div>
         </div>
         <div id="for-signers-and-verifiers--be-aware-of-schema-processing" class="section">
            <h3><span class="secno">2.8 </span>For signers and verifiers: Be aware of schema processing</h3>
            <p>
               			    Part of the validation process defined by XML Schema includes the
               			    "normalization" of lexical values in a document into a "schema
               			    normalized value" that allows schema type validation to occur against a
               			    predictable form.
               			  
            </p>
            <p>
               			    Some implementations of validating parsers, particular early ones, often
               			    modified DOM information "in place" when performing this process. Unless
               			    the signer also performed a similar validation process on the input
               			    document, verification is likely to fail. Newer validating parsers
               			    generally include an option to disable type normalization, or take steps
               			    to avoid modifying the DOM, usually by storing normalized values
               			    internally alongside the original data.
               			  
            </p>
            <p>
               			    Verifiers should be aware of the effects of their chosen parser and
               			    adjust the order of operations or parser options accordingly. Signers
               			    might also choose to operate on the normalized form of an XML instance
               			    when possible.
               			  
            </p>
            <p>
               			    Additionally, validating processors will add default values taken from
               			    an XML schema to the DOM of an XML instance.
               			  
            </p>
            <div class="practice">
               <p>
                 <span id="consider-schema-processing" class="practicelab">Best Practice 22: Signers: Do not rely on a validating processor on the consumer's
                     			    end.</span></p>
               <p class="practicedesc">Do not rely on a validating processor on the consumer's end to normalize XML documents. Instead, explicitly include default attribute values, and use normalized attributes when possible. 
            </p></div>
            <div class="practice">
               <p><span id="avoid-destructive-validation" class="practicelab">Best Practice 23: Verifiers: Avoid destructive validation before signature validation.</span></p>
               <p class="practicedesc">Applications relying on validation should either consider verifying
                  			    signatures before schema validation, or select implementations that can
                  			    avoid destructive DOM changes while validating.
               </p>
            </div>
         </div>
         <div id="certificate-encoding" class="section">
            <h3><span class="secno">2.9 </span>For Implementers: be aware of certificate encoding
               				issues
            </h3>
            <div class="practice">
               <p>
                 <span id="bp-certificate-encoding" class="practicelab">Best Practice 24: Do not re-encode certificates, use DER when
                                         possible with the X509Certificate element.
                                         </span></p>
               <p class="practicedesc">Changing the encoding of a
                                      certificate can break the signature on the
                                      certificate if the encoding is not the same in
                                      each case. Using DER offers increased opportunity
                                      for interoperability.
               </p>
            </div>
            <p>
               Although X.509 certificates are meant to be encoded using DER before being
               signed, many implementations (particularly older ones) got various aspects
               of DER wrong, so that their certificates are encoded using BER, which is a
               less rigorous form of DER. Thus, following the X.509 specification to
               re-encode in DER before applying the signature check
               will 
               invalidate the signature on the certificate.
            </p><p>
               In practice, X.509 implementations check the signature on certificates
               exactly as encoded, which means that they're verifying exactly the same data
               as the signer signed, and the signature will remain valid regardless of
               whether the signer and verifier agree on what constitutes a DER encoding. As
               a result, the safest course is to treat the certificate opaquely where
               possible and avoid any re-encoding steps that might invalidate the
               signature.
               
            </p>
            <p>
               The <code>X509Certificate</code> element is generically defined to contain a
               base64-encoded certificate without regard to the underlying ASN.1 encoding
               used. However, experience has shown that interoperability issues are
               possible if encodings other than BER or DER are used, and use of other
               certificate encodings should be approached with caution. While some
               applications may not have flexibility in the certificates they must deal
               with, others might, and such applications may wish to consider further
               constraints on the encodings they allow.
               
            </p>
         </div>
         <div id="prefer-xpath-filter2" class="section">
            <h3><span class="secno">2.10 </span>For Applications: Prefer the XPath Filter 2
                 Transform to the XPath Filter Transform
                 
            </h3>
            <div class="practice">
               <p>
                 <span id="bp-prefer-xpath-filter2" class="practicelab">Best Practice 25: Prefer the XPath Filter 2 Transform to the
                         XPath Filter Transform if possible.
                         </span></p>
               <p class="practicedesc">
                      Applications should prefer the XPath Filter 2 
                      Transform to the 
                      XPath Filter 
                      Transform when generating XML Signatures.
                    
               </p>
            </div>
            <p>The XPath Filter 2 
               Transform was designed to improve the performance issues associated with 
               the XPath Filter Transform and allow signing operations to be expressed 
               more clearly and efficiently, as well as helping to mitigate the denial 
               of service attacks discussed in section 2.1.2. See 
               <a href="http://www.w3.org/TR/xmldsig-filter2/#sec-Intro">XML-Signature XPath Filter 2.0</a> for
               more information. 
               
            </p>
            <p>Even though XPath Filter 2.0 is not recommended in XML Signature
               1.0, implementations may still be able to support it. In this case
               signers and verifiers may be  able 
               to follow this best practice.
               
            </p>
         </div>
      </div>
      <div id="bp-summary" class="section"><!--OddPage--><h2><span class="secno">3. </span>Best Practices Summary</h2><ul><li><a href="#bp-authenticate-signature-first">Best Practice 1</a>: Mitigate
                                         denial of service attacks by 
                                         executing potentially dangerous operations only
                                         after successfully authenticating the signature. </li><li><a href="#bp-validate-signing-key">Best Practice 2</a>: Establish trust in the
                                         verification/validation key.</li><li><a href="#bp-avoid-xslt">Best Practice 3</a>: Consider avoiding XSLT
                    Transforms</li><li><a href="#bp-avoid-xslt-extensions">Best Practice 4</a>: When XSLT is required disallow the use of user-defined extensions</li><li><a href="#bp-avoid-xpath">Best Practice 5</a>: Try to avoid or limit XPath
                      transforms</li><li><a href="#bp-streaming-xpath-limits">Best Practice 6</a>: Avoid
                      using the "descendant", "descendant-or-self", 
                      "following-sibling", and "following" axes when using streaming XPaths.
                  </li><li><a href="#bp-avoid-retrievalmethod">Best Practice 7</a>: Try to avoid or limit <code>ds:RetrievalMethod</code>
                      support with <code>ds:KeyInfo</code></li><li><a href="#bp-control-external-references">Best Practice 8</a>: Control External References</li><li><a href="#bp-limit-number-of-transforms">Best Practice 9</a>: Limit number of <code>ds:Reference</code> transforms allowed.</li><li><a href="#bp-inspect-reference-uri-and-transforms">Best Practice 10</a>: Enable
                     verifier to automate "see
                     what is signed" functionality.</li><li><a href="#bp-verify-signed-vs-expected">Best Practice 11</a>: When
                        applying XML Signatures using XPath it is recommended to always actively
                        verify that the signature protects the intended elements and not more or
                        less.</li><li><a href="#bp-inspect-reference-uri">Best Practice 12</a>: When checking a reference URI, don't
                                                just check the name of the element</li><li><a href="#bp-see-sign-api">Best Practice 13</a>: Offer interfaces for application to learn what was
                        signed.
                        </li><li><a href="#bp-sign-everything">Best Practice 14</a>: Unless impractical, sign all parts of
                                                the document.</li><li><a href="#bp-nonce-plus-datetime">Best Practice 15</a>: Use a nonce in combination with signing
                                            time</li><li><a href="#bp-not-app">Best Practice 16</a>: Do not rely on application logic to prevent
                                            replay attacks since
                                            applications may change.</li><li><a href="#bp-sign-nonce-dateTime">Best Practice 17</a>: Nonce and signing time must be signature
                                            protected.</li><li><a href="#bp-timestamp-authorities-for-long-lived-sigs">Best Practice 18</a>: Use Timestamp tokens issued by Timestamp
                                            authorities for long lived signatures</li><li><a href="#bp-use-timestamp">Best Practice 19</a>: Long lived signatures should include a xsd:dateTime field to indicate the time of
                        signing just as a handwritten signature does.</li><li><a href="#bp-namespace-inheritance">Best Practice 20</a>: When creating an enveloping signature over XML
                     without namespace information, take steps to avoid having that content
                     inherit the XML Signature namespace.</li><li><a href="#unparsed-external-entity-refs">Best Practice 21</a>: Do not transmit unparsed external entity
               references.</li><li><a href="#consider-schema-processing">Best Practice 22</a>: Signers: Do not rely on a validating processor on the consumer's
                     			    end.</li><li><a href="#avoid-destructive-validation">Best Practice 23</a>: Verifiers: Avoid destructive validation before signature validation.</li><li><a href="#bp-certificate-encoding">Best Practice 24</a>: Do not re-encode certificates, use DER when
                                         possible with the X509Certificate element.
                                         </li><li><a href="#bp-prefer-xpath-filter2">Best Practice 25</a>: Prefer the XPath Filter 2 Transform to the
                         XPath Filter Transform if possible.
                         </li></ul></div>
      <div id="thanks" class="section">
         <!--OddPage--><h2><span class="secno">4. </span>Acknowledgments</h2>
         <p>
            	This document records best practices related to XML Signature from a variety of sources, including
            	the W3C Workshop on Next Steps for XML Signature and XML Encryption [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSEC-NEXTSTEPS-2007">XMLSEC-NEXTSTEPS-2007</a></cite>].
         </p>
      </div>
      		
      	
   
   

<div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">A. </span>References</h2><p>Dated references below are to the latest known or appropriate edition of the referenced work.  The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which  editions are supported.</p><div id="normative-references" class="section"><h3><span class="secno">A.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">A.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-MCINTOSH-WRAP">[MCINTOSH-WRAP]</dt><dd> Michael McIntosh; Paula Austel. <cite>XML signature element wrapping attacks and countermeasures.</cite> In Workshop on Secure Web Services, 2005
</dd><dt id="bib-RFC3161">[RFC3161]</dt><dd>C. Adams, P. Cain, D. Pinkas, R. Zuccherato. <a href="http://www.rfc-editor.org/rfc/rfc3161.txt"><cite>Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)</cite></a> August 2001. Internet RFC 3161. URL: <a href="http://www.rfc-editor.org/rfc/rfc3161.txt">http://www.rfc-editor.org/rfc/rfc3161.txt</a> 
</dd><dt id="bib-RFC3161-PKIX-UPDATE-9">[RFC3161-PKIX-UPDATE-9]</dt><dd>Stefan Santesson, Nick Pope. <a href="http://tools.ietf.org/id/draft-ietf-pkix-rfc3161-update-09.txt"><cite> ESSCertIDv2 update for RFC 3161</cite></a> 29 April 2010, IETF Internet Draft. URL: <a href="http://tools.ietf.org/id/draft-ietf-pkix-rfc3161-update-09.txt"> http://tools.ietf.org/id/draft-ietf-pkix-rfc3161-update-09.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/standards#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/standards#wssv1.1">http://www.oasis-open.org/standards#wssv1.1</a> 
</dd><dt id="bib-WebBug-Wikipedia">[WebBug-Wikipedia]</dt><dd><a href="http://en.wikipedia.org/wiki/Web_bug"><cite>Wikipedia Web Bug definition</cite></a> URL: <a href="http://en.wikipedia.org/wiki/Web_bug"> http://en.wikipedia.org/wiki/Web_bug</a> 
</dd><dt id="bib-XADES">[XADES]</dt><dd><a href="http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf"><cite>XML Advanced Electronic Signatures (XAdES)</cite></a>.  ETSI TS 101 903 V1.4.1 (2009-06) URL: <a href="http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf">http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf</a>
</dd><dt id="bib-XMLDSIG-COMPLEXITY">[XMLDSIG-COMPLEXITY]</dt><dd>Brad Hill. <a href="http://www.w3.org/2007/xmlsec/ws/papers/04-hill-isecpartners/"><cite>Complexity as the Enemy of Security: Position Paper for W3C Workshop on Next Steps for XML Signature and XML Encryption.</cite></a>. 25-26 September 2007. W3C Workshop. URL: <a href="http://www.w3.org/2007/xmlsec/ws/papers/04-hill-isecpartners/">http://www.w3.org/2007/xmlsec/ws/papers/04-hill-isecpartners/</a> 
</dd><dt id="bib-XMLDSIG-CORE1">[XMLDSIG-CORE1]</dt><dd>D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, K. Yiu. <a href="http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/"><cite>XML Signature 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-xmldsig-core1-20110303/">http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/</a> 
</dd><dt id="bib-XMLDSIG-SEMANTICS">[XMLDSIG-SEMANTICS]</dt><dd>Sebastian Gajek, Lijun Liao, and Jörg Schwenk. <a href="http://www.w3.org/2007/xmlsec/ws/papers/07-gajek-rub/"><cite> Towards a Semantic of XML Signature: Position Paper for W3C Workshop on Next Steps for XML Signature and XML Encryption </cite></a> 25-26 September 2007. W3C Workshop. URL: <a href="http://www.w3.org/2007/xmlsec/ws/papers/07-gajek-rub/">http://www.w3.org/2007/xmlsec/ws/papers/07-gajek-rub/</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-XMLSEC-NEXTSTEPS-2007">[XMLSEC-NEXTSTEPS-2007]</dt><dd>Frederick Hirsch; Thomas Roessler. <a href="http://www.w3.org/2007/xmlsec/ws/report.html"><cite>Workshop Report W3C Workshop on Next Steps for XML Signature and XML Encryption</cite></a> 25-26 September 2007. W3C Workshop Report. URL: <a href="http://www.w3.org/2007/xmlsec/ws/report.html">http://www.w3.org/2007/xmlsec/ws/report.html</a>
</dd></dl></div></div></body></html>