idnits 2.17.1 draft-ietf-xmldsig-signature-comments-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** Missing revision: the document name given in the document, 'draft-ietf-xmldsig-signature-comments-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-xmldsig-signature-comments-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-xmldsig-signature-comments-', but the file name used is 'draft-ietf-xmldsig-signature-comments-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 3) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 1999) is 9081 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 1 flaw (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XMLDSIG Working Group Richard D. Brown 2 GlobeSet, Inc. 3 Expires December 1999 June 1999 5 Digital Signatures for XML - Comments 6 ------- ---------- --- --- - -------- 8 Richard D. Brown 9 GlobeSet, Inc. 11 Document Status 13 This document, file name is intended to become a Proposed Standard RFC. Distribution 15 of this document is unlimited. Comments should be sent to the XMLDSIG 16 mailing list or to the author. Additional information can be found on 17 the web sites maintained by the working group. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 This specification consists of a series of comments and suggestions 40 with regard to the Internet-Draft XMLDSIG main specification. It 41 constitutes the primary source of information for forthcoming 42 revisions of the main specification. 44 The main specification can be accessed at 45 http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-signature- 46 00.txt 48 Contacts 50 Chair(s): 51 Donald Eastlake 3rd 52 Joseph Reagle Jr. 54 Author: 55 Richard D. Brown 57 Mailing List: 58 Discussion: w3c-ietf-xmldsig@w3.org 59 Archive: http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig 60 Subscription: w3c-ietf-xmldsig-request@w3.org 61 specify (un)subscribe in SUBJECT line with an empty body. 63 Web Sites: 64 IETF: http://www.ietf.org/html.charters/xmldsig-charter.html 65 W3C: http://www.w3.org/Signature 67 Revision History 69 18-June-99: 70 Create independent document, 71 Create an index per status, 72 Add entry #99061601, 73 Add entry #99061602, 74 Add entry #99061603. 76 04-April-99: 77 Initial draft in main specification. 79 Table of Contents 81 Document Status............................................1 82 Abstract...................................................1 83 Contacts...................................................2 84 Revision History...........................................2 86 Table of Contents..........................................3 88 1. Comments and Suggestions................................4 89 2. Index per Reference Number.............................22 90 3. Index per Status.......................................23 92 1. Comments and Suggestions 94 This chapter consists of a central repository for all the comments 95 and suggestions that have been received with regard to the XMLDSIG 96 main specification. 98 #98072901 - Syntax too verbose 100 Origin: General 101 Status: Superceded by 98091001, 98091002 103 Comments: 105 "The syntax is far too much verbose." 107 Author Notes: 109 There are multiple optimizations that could be envisioned: 111 - Promote syntax compactness instead of element reusability. 112 - Adopt syntax that enables shared algorithm definitions. 113 - Adopt default attribute and parameter values. 115 #98091001 - Enable shared algorithm definitions 117 Origin: Richard D. Brown 118 Status: Opened 120 Comments: 122 "Considering that in most circumstances the digest of 123 authenticate resources will be computed by means of a common 124 digest algorithm, it seems preferable to define a syntax that 125 allows shared algorithm definitions. 127 Several approaches might be considered. The first one consists 128 of adding a DigestAlgorithms element in every signature 129 Manifest and using some linking mechanism (i.e. IDREF) to bind 130 a digest value with a digest algorithm. Another approach is to 131 allow definitions throughout the document and requiring the 132 canonicalizer to inline the algorithm definition in the Digest 133 elements." 135 Author Notes: 137 The first approach does not prevent replication of algorithm 138 definitions in the header of the document and the different 139 signature Manifests. On the other hand, the second approach 140 requires particular behaviors in the canonicalizers and 141 therefore cannot suffice with a surface string digest 142 algorithm. 144 #98091002 - Promote compactness over reusability 146 Origin: Richard D. Brown 147 Status: Opened 149 Comments: 151 "The current specification makes use of reusable element types. 152 This approach obviously increases the "verbosity" of the 153 syntax. It might be preferable to promote compactness instead 154 of reusability." 156 For example, the following optimizations might be considered: 158 - Collapsing Locator into Resource. 159 - Collapsing ContentInfo into Package. 160 - Replacing basic data types (i.e. Integer, Date, etc...) by 161 a DCD attribute and a PCDATA contents on the parent 162 element. 164 Author Notes: 166 #98111301 - Add a Resource criticality attribute 168 Origin: Milton M. Anderson 169 Status: Opened 171 Comments: 173 "The definition of does not contain a feature to 174 allow the signer to declare that the resource is critical to 175 the validity of the signature." 177 Author Notes: 179 I do not have all the elements for judging how relevant is this 180 particular comment, but my first guess is that a signature 181 applies to a particular content and semantics verification 182 shall be left to the application layer. 184 #98111302 - Remove dsig:eval global attribute 186 Origin: Milton M. Anderson 187 Status: Closed 189 Comments: 191 "Having the dsig:eval attribute in the element that defines the 192 authenticated block is probably a bad idea, since different 193 signers can use different hash algorithm." 195 Author Notes: 197 Others have made a similar comment, but we have reached a 198 different conclusion: dsig:eval shall be an IDREFS instead of 199 an IDREF. 201 #98111303 - Add a logging attribute 203 Origin: Milton M. Anderson 204 Status: Closed 206 Comments: 208 "No ability to mark data for logging by a signing hardware is 209 included." 211 Author Notes: 213 Also, very much application specific. I am not quite sure this 214 shall be a concern for the XML DSIG Proposal. 216 #98111304 - Add a signature purpose attribute 218 Origin: Milton M. Anderson 219 Status: Closed 221 Comments: 223 "The signature doesn't have a "type of signature" element." 225 Author Notes: 227 This may be provided at the application level by means of a 228 complementary attribute. 230 #98111305 - Add a Nonce in the Manifest 232 Origin: Milton M. Anderson 233 Status: Closed 235 Comments: 237 "No nonce to be used in hashing the resource is defined." 239 Author Notes: 241 Milton refers to a scheme that could be used for preventing 242 birthday-attacks against the digest algorithm. 244 E-Check makes use of this artifice to make sure that a 245 fraudulent signer or a Trojan Horse on the signer's computer 246 does not have full control over the data being signed by the 247 signing device. If the attacker were able to find two messages 248 M1 and M2 such that H(M1) = H(M2), it could send M1 to the 249 device and then substitute M2 later. The hardware log will 250 record that M1 has been signed and not M2. 252 This problem may be addressed in the hardware log by itself. 253 The device may sign H(M1), pick a nonce at random, and log the 254 nonce value along with H(nonce||M1) for example. 256 #98112501 - Leverage DCD and other specifications 258 Origin: Hiroshi Maruyama 259 Status: Opened 261 Comments: 263 "For data types, I think we could refer to other activities 264 such as DCD." 266 Author Notes: 268 Agreed as long as these specifications are adopted in time. 269 Notice that DCD provides mostly for basic data types. This will 270 not resolve the problem for the constructed data types such as 271 IssuerAndSerialNumber, Package, etc... 273 #98121501 - IssuerAndSerialNumber is too restrictive 275 Origin: Richard D. Brown 276 Status: Opened 278 Comments: 280 "Identifying a certificate by means of the constructed data 281 types IssuerAndSerialNumber might be too restrictive. It is not 282 obvious that this construct is sufficient for certificates 283 other than X509v3. The specification shall adopt syntax a bit 284 more opened. 286 For example, a certificate might be uniquely identified by 287 means of a Identifier element, whose syntax depends upon the 288 type of the certificate." 290 Author Notes: 292 #98122601 - Allow multiple Resource in Manifest 294 Origin: Don Eastlake 295 Status: Adopted (990404) 297 Comments: 299 "I believe that multiple occurrences of Resource should be 300 permitted in the Manifest" 302 Author Notes: 304 The Manifest now requires a Resources element. 306 #98122602 - Add a base locator for HREFs 308 Origin: Don Eastlake - IOTP WG 309 Status: Opened 311 Comments: 313 "Some of the IOTP concerns about many huge locator HREFs could 314 be satisfied if a "base" attribute were permitted at the 315 Resources level or, even more general, a Base element, which 316 effected all following resource." 318 Author Notes: 320 #98122603 - Rename the attribute dsig:eval 322 Origin: Don Eastlake 323 Status: Opened 325 Comments: 327 "I do not like the choice of "eval" even if it is arbitrary. It 328 makes me think of Lisp or the like. I would expect it to 329 evaluate arithmetic expressions or the like. I think the 330 previous "hash" was better and perhaps "dsig:digest" would be 331 best..." 333 Author Notes: 335 #98122604 - Default encoding attribute to base64 337 Origin: Don Eastlake 338 Status: Opened 340 Comments: 342 "What's about defaulting to base64 instead of none for the 343 encoding." 345 Author Notes: 347 #99010201 - Add a ID attribute to Algorithm 349 Origin: Mark Linehan 350 Status: Superceded (98091001) 352 Comments: 354 "I suggest adding an "id" attribute to the Algorithm element, 355 and adding an algref attribute to any element that contains an 356 Algorithm. Purpose is to avoid repeating the same Algorithm 357 text in many places." 359 Author Notes: 361 One approach to address #98091001 363 #99010202 - Provide a default digest algorithm 365 Origin: Mark Linehan 366 Status: Closed 368 Comments: 370 "I suggest that it would be helpful to have a way to declare a 371 default or standard digest algorithm. Reason: in most cases, 372 the same algorithm will be used throughout a document." 374 Author Notes: 376 Adequate optimization should enable use of shared definitions. 377 In such circumstances, the overhead on a Resource element will 378 be limited to an IDREF. At first, removing all algorithm 379 references from the Resource element does not seem a good idea 381 #99010203 - Add a type to RecipientInfo and OriginatorInfo 383 Origin: Mark Linehan 384 Status: Closed 386 Comments: 388 "I suggest that OriginatorInfo and RecipientInfo have a "type" 389 attribute for the same reason as the Attribute element: to 390 identify the format of the ANY content." 392 Author Notes: 394 RecipientInfo and OriginatorInfo are expected to be a 395 collection of "attributes". Therefore, it does not make sense 396 to define a "type" attribute for these elements. 398 #99020301 - Adopt URL instead of URI 400 Origin: Joseph Reagle 401 Status: Opened 403 Comments: 405 "What's about adopting URLs instead of URNs. This will prevent 406 registration requirements. At the least, the specification 407 should allow URIs." 409 Author Notes: 411 #99021201 - Allow multiple signatures on a Manifest 413 Origin: IOTP WG 414 Status: Opened 416 Comments: 418 "Ability to have multiple signatures on a single Manifest and 419 ability to adhere a recipient to a Signature." 420 To address these concerns, IOTP DTD proposes the following 421 construct: 423 425 426 429 430 435 437 438 439 440 ... 441 442 443 ... 444 445 448 ... 449 450 453 ... 454 455 ... 456 457 458 aBcdsejhtksagnbf== 459 460 461 ehlekjrekkjrk== 462 463 464 465 466 ... 467 468 469 ... 470 471 473 Author Notes: 475 Assuming that the benefit expected from this construct is to 476 prevent replication of a large Manifest in multiple Signature 477 elements, I would remind that this specification allows for 478 shared Resources element 480 I can see at least three potential drawbacks with this 481 construct: 483 - Privacy: A signature value cannot be verified unless all 484 the RecipientInfo elements are preserved into the 485 Manifest. In some circumstances, it may not be desirable 486 to disclose the identity of the other recipients. Notice 487 however that this construct does not preclude the 488 creation of independent signature elements. 490 - Complexity: This construct is obviously more 491 complicated than the one currently proposed. Dual forward 492 references are not always easy to handle. 494 - Inconsistency: Applying multiple signatures to a single 495 document usually implies that the application has adopted 496 some secret-key authentication scheme. In such 497 circumstances, the originator may be known by the 498 recipients under different names or accounts. But, this 499 construct does not allow replication of the 500 OriginatorInfo element (per recipient basis), which is 501 supposed to carry such pieces of information. 503 #99021202 - Enable shared digest algorithm definitions 505 Origin: IOTP WG 506 Status: Superceded by 98091002 508 Comments: 510 "Ability to share digest algorithms for signatures, digest, and 511 canonicalization" 512 To address this concern, the IOTP DTD proposes to insert a 513 collection of algorithm definitions into the signature Manifest 514 and to use a linking mechanism for binding Resource definitions 515 and signature algorithms to these shared definitions. 517 519 527 528 532 Author Notes: 534 Potential solution to optimizing the syntax. However, I would 535 suggest replacing the collection of Algorithm elements by a 536 DigestAlgorithms element. Also, I would limit this 537 functionality to the Digest elements. 539 #99031601 - Remove criticality attribute on Attribute 541 Origin: Dave Solo, Eric Riscola 542 Status: Opened 544 Comments: 546 ... IETF Meeting - following a presentation of criticality 547 flag... 549 Dave: "it's a bad idea: experience in CMS was to remove it" 551 Eric: "I reinforce Dave: this bogs down every new attribute 552 with a debate over 'criticality' ... PKIX and S/MIME show signs 553 of precisely this kind of bloat." 555 Author Notes: 557 Tend to agree that criticality shall be a matter of the relying 558 party and, therefore, a criticality attribute provided by the 559 signer is not necessary in the syntax. 561 #99040101 - Remove Attributes element 563 Origin: Yoshiaki Kawatsura 564 Status: Closed 566 Comments: 568 "I do not understand why the Attributes element is needed." 570 Author Notes: 572 Collection elements such Attributes, Certificates, and 573 Signatures has been proposed to facilitate DOM manipulation. 574 For example, one may call some trust verification engine by 575 passing the Certificates sub-tree. This construct enables 576 containment of similar and related elements. 578 #99040102 - Allow attributes on Resource 580 Origin: Richard D. Brown 581 Status: Opened 583 Comments: 585 "It seems that allowing per Resource attributes may have 586 interesting applications. For example, a rating standard could 587 define a rating:Public attribute that could be associated 588 directly with the Resource element. In such circumstances, a 589 rating standard could almost suffice with the current DTD 590 definitions." 592 Author Notes: 594 #99040103 - Add an CanonicalizerAlgorithm element 596 Origin: Richard D. Brown 597 Status: Opened 599 Comments: 601 "All signature schemes require canonicalization and digest of 602 the Manifest. Thence, all the signature algorithms require at 603 least a digest-algorithm parameter and this has lead to some 604 inconsistencies such as requiring a digest algorithm for rsa 605 encryption or two hash functions for HMAC. 607 It may be preferable to add a CanonicalAlgorithm element in the 608 signature Manifest. This element will identify the 609 digest/canonical algorithm to be used for computation of the 610 fingerprint of the Signature Manifest." 612 623 Author Notes: 625 #99040104 - Allow attributes on Package 627 Origin: Richard D. Brown 628 Status: Opened 630 Comments: 632 "Similarly to adding attributes to the Resource element. For 633 example, such added functionality could be used for attaching 634 an origin attribute to a package. This may be used for binding 635 indirectly a detached-signature with an internal Package 636 element." 638 Author Notes: 640 #99040105 - Change Attributes contents to ANY 642 Origin: Richard D. Brown 643 Status: Opened 645 Comments: 647 "Currently, the Attributes element consists of a collection of 648 Attribute elements, which specify a type and contain an inner 649 value element 650 An alternative a bit more opened would consist of defining 651 Attributes as an element of ANY contents and use constructed 652 attribute element." 654 655 656 657 658 ... 659 661 Author Notes: 663 One could argue that origin, digest, and the forth are also 664 attributes of the resource and, therefore, could be sealed in 665 the Attributes element. In fact, we could remove the Attributes 666 element and define Resource as an element of ANY contents. But, 667 if we were to do so, it would be impossible to enforce the 668 presence of mandatory attribute elements such as resource 669 locator and digest by means of the DTD. 671 If this suggestion were to be adopted, we may consider 672 converting the ContentInfo element into a standard attribute. 674 #99040106 - Change ContentInfo contents to PCDATA 676 Origin: Richard D. Brown 677 Status: Opened 679 Comments: 681 "The specification proposes a ContentInfo element with a type 682 and subtype attribute. The type attribute is defined as an URN. 683 Unfortunately, URN specification does not allow the character 684 "/" in the NSS. Thence, it is not possible to map directly 685 existing MIME types into an URN without adopting adequate NSS 686 encoding. For example, "application/msword" shall be encoded 687 into something like "urn:MIME:application%2fmsword." 688 An alternative could be to define the ContentInfo element as 689 follows: 691 692 696 698 699 application/msword 700 702 703 OrderDescription 704 706 Author Notes: 708 #99040701 - Allow Resource by value in Manifest 710 Origin: John Boyer, Richard D. Brown 711 Status: Opened 713 Comments: 715 "It may be worth considering the possibility to define a 716 Resource either by means of a locator and a digest or by 717 value." 719 We may consider the following definition: 721 723 Author Notes: 725 Adopting this approach will disallow collapsing the Locator 726 element into the Resource element. If the value is provided it 727 does not make a lot of sense to specify a resource location. 728 But, Xlink specification seems to require the href attribute 729 (not clear in the specification). 731 #99040801 - Add a Certificate Appendix to specification 733 Origin: Richard D. Brown 734 Status: Opened 736 Comments: 738 "It may be worth considering adding a certificate appendix that 739 documents specifics for the different certificate types or 740 certificate locators. As a matter of fact, a LDAP URL might be 741 used but it is not sufficient for locating a particular 742 certificate" 744 Author Notes: 746 #99040802 - Add a Security Appendix to specification 748 Origin: Richard D. Brown 749 Status: Opened 751 Comments: 753 "It may be worth considering adding a security appendix such as 754 the one mandated by IETF." 756 Author Notes: 758 #99040803 - Add a Compliance Appendix to specification 760 Origin: Richard D. Brown 761 Status: Opened 763 Comments: 765 "It may be worth considering adding an appendix that defines 766 compliance requirements." 768 Author Notes: 770 #99040804 - Segregate basic data types 772 Origin: Richard D. Brown 773 Status: Opened 775 Comments: 777 "It may be worth considering segregation of the data types that 778 do not directly relate to XML-DSIG. For example, elements such 779 as Integer, Float, and value might be replaced by making use of 780 some DCD attribute, and others such as IssuerAndSerialNumber or 781 Package might be temporarily moved into some Data DTD. These 782 element definitions will be later superceded by definitions 783 adopted by specialized DTDs. 785 Author Notes: 787 #99061601 - Replace dsig:eval by a PI 789 Origin: Richard D. Brown 790 Status: Opened 792 Comments: 794 As mentioned earlier by Milton M. Anderson (98111302), having 795 the dsig:eval attribute directly in the element being 796 authenticated may be unpractical if different signers were to 797 use different hash algorithms. 799 A different approach consists of the definition of a Processing 800 Instruction that specifies the algorithm to be used. This 801 processing instruction could be inserted just before the 802 element to be hashed and is not part of the hash value. Change 803 in the value of the processing instruction does not invalidate 804 previous signatures. Moreover, because the digest algorithm 805 definitions are replicated into the Manifest, an attacker 806 cannot attack the authentication scheme by tampering with the 807 processing instruction. 809 Document> 811 812 813 814 815 817 818 819 ... 820 822 823 825 Author Notes: 827 #99061602 - Adopt RDF Data Model 829 Origin: XMLDISG'99 Participants 830 Status: Opened 832 Comments: 834 "XML-Signature should use the RDF data model but need not use 835 the RDF serialization syntax. " In other words, the XML 836 Signature syntax should consist of a static representation of a 837 RDF schema. In the short term this static representation will 838 translate into a DTD that will be replaced by the actual RDF 839 schema as RDF awareness will develop in the Industry. 841 Author Notes: 843 #99061603 - Add a index per Category 845 Origin: Don Eastlake 846 Status: Opened 848 Comments: 850 "Categorize the comments and suggestions and attach an Index 851 per category." 853 Author Notes: 855 2. Index per Reference Number 857 #98072901 - Syntax too verbose 858 #98091001 - Enable shared algorithm definitions 859 #98091002 - Promote compactness over reusability 860 #98111301 - Add a Resource criticality attribute 861 #98111302 - Remove dsig:eval global attribute 862 #98111303 - Add a logging attribute 863 #98111304 - Add a signature purpose attribute 865 #98111305 - Add a Nonce in the Manifest 866 #98112501 - Leverage DCD and other specifications 867 #98121501 - IssuerAndSerialNumber is too restrictive 868 #98122601 - Allow multiple Resource in Manifest 869 #98122602 - Add a base locator for HREFs 870 #98122603 - Rename the attribute dsig:eval 871 #98122604 - Default encoding attribute to base64 872 #99010201 - Add a ID attribute to Algorithm 873 #99010202 - Provide a default digest algorithm 874 #99010203 - Add a type to RecipientInfo and OriginatorInfo 875 #99020301 - Adopt URL instead of URI 876 #99021201 - Allow multiple signatures on a Manifest 877 #99021202 - Enable shared digest algorithm definitions 878 #99031601 - Remove criticality attribute on Attribute 879 #99040101 - Remove Attributes element 880 #99040102 - Allow attributes on Resource 881 #99040103 - Add an CanonicalizerAlgorithm element 882 #99040104 - Allow attributes on Package 883 #99040105 - Change Attributes contents to ANY 884 #99040106 - Change ContentInfo contents to PCDATA 885 #99040701 - Allow Resource by value in Manifest 886 #99040801 - Add a Certificate Appendix to specification 887 #99040802 - Add a Security Appendix to specification 888 #99040803 - Add a Compliance Appendix to specification 889 #99040804 - Segregate basic data types 890 #99061601 - Replace dsig:eval by a PI 891 #99061602 - Adopt RDF Data Model 893 3. Index per Status 895 Opened 897 #98091001 - Enable shared algorithm definitions 898 #98091002 - Promote compactness over reusability 899 #98111301 - Add a Resource criticality attribute 900 #98112501 - Leverage DCD and other specifications 901 #98121501 - IssuerAndSerialNumber is too restrictive 902 #98122602 - Add a base locator for HREFs 903 #98122603 - Rename the attribute dsig:eval 904 #98122604 - Default encoding attribute to base64 905 #99020301 - Adopt URL instead of URI 906 #99021201 - Allow multiple signatures on a Manifest 907 #99031601 - Remove criticality attribute on Attribute 908 #99040102 - Allow attributes on Resource 909 #99040103 - Add an CanonicalizerAlgorithm element 910 #99040104 - Allow attributes on Package 911 #99040105 - Change Attributes contents to ANY 912 #99040106 - Change ContentInfo contents to PCDATA 913 #99040701 - Allow Resource by value in Manifest 914 #99040801 - Add a Certificate Appendix to specification 915 #99040802 - Add a Security Appendix to specification 916 #99040803 - Add a Compliance Appendix to specification 917 #99040804 - Segregate basic data types 918 #99061601 - Replace dsig:eval by a PI 919 #99061602 - Adopt RDF Data Model 920 #99061603 - Add a index per Category 922 Closed 924 #98111302 - Remove dsig:eval global attribute 925 #98111303 - Add a logging attribute 926 #98111304 - Add a signature purpose attribute 927 #98111305 - Add a Nonce in the Manifest 928 #99010202 - Provide a default digest algorithm 929 #99010203 - Add a type to RecipientInfo and OriginatorInfo 930 #99040101 - Remove Attributes element 932 Superceded 934 #98072901 - Syntax too verbose 935 #99010201 - Add a ID attribute to Algorithm 936 #99021202 - Enable shared digest algorithm definitions 938 Adopted 940 #98122601 - Allow multiple Resource in Manifest 942 File Name: draft-ietf-xmldsig-signature-comments-00.txt 943 Expires: December 1999