XMLDSIG Working Group Richard D. Brown
GlobeSet, Inc.
Expires December 1999 June 1999
Digital Signatures for XML - Comments
------- ---------- --- --- - --------
Richard D. Brown
GlobeSet, Inc.
Document Status
This document, file name <draft-ietf-xmldsig-signature-comments-
00.txt> is intended to become a Proposed Standard RFC. Distribution
of this document is unlimited. Comments should be sent to the XMLDSIG
mailing list or to the author. Additional information can be found on
the web sites maintained by the working group.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This specification consists of a series of comments and suggestions
with regard to the Internet-Draft XMLDSIG main specification. It
constitutes the primary source of information for forthcoming
revisions of the main specification.
The main specification can be accessed at
http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-signature-
00.txt
Richard D. Brown [Page 1]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
Contacts
Chair(s):
Donald Eastlake 3rd <dee3@torque.pothole.com>
Joseph Reagle Jr. <reagle@w3.org>
Author:
Richard D. Brown <rdbrown@globeset.com>
Mailing List:
Discussion: w3c-ietf-xmldsig@w3.org
Archive: http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig
Subscription: w3c-ietf-xmldsig-request@w3.org
specify (un)subscribe in SUBJECT line with an empty body.
Web Sites:
IETF: http://www.ietf.org/html.charters/xmldsig-charter.html
W3C: http://www.w3.org/Signature
Revision History
18-June-99:
Create independent document,
Create an index per status,
Add entry #99061601,
Add entry #99061602,
Add entry #99061603.
04-April-99:
Initial draft in main specification.
Richard D. Brown [Page 2]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
Table of Contents
Document Status............................................1
Abstract...................................................1
Contacts...................................................2
Revision History...........................................2
Table of Contents..........................................3
1. Comments and Suggestions................................4
2. Index per Reference Number.............................22
3. Index per Status.......................................23
Richard D. Brown [Page 3]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
1. Comments and Suggestions
This chapter consists of a central repository for all the comments
and suggestions that have been received with regard to the XMLDSIG
main specification.
#98072901 - Syntax too verbose
Origin: General
Status: Superceded by 98091001, 98091002
Comments:
"The syntax is far too much verbose."
Author Notes:
There are multiple optimizations that could be envisioned:
- Promote syntax compactness instead of element reusability.
- Adopt syntax that enables shared algorithm definitions.
- Adopt default attribute and parameter values.
#98091001 - Enable shared algorithm definitions
Origin: Richard D. Brown
Status: Opened
Comments:
"Considering that in most circumstances the digest of
authenticate resources will be computed by means of a common
digest algorithm, it seems preferable to define a syntax that
allows shared algorithm definitions.
Several approaches might be considered. The first one consists
of adding a DigestAlgorithms element in every signature
Manifest and using some linking mechanism (i.e. IDREF) to bind
a digest value with a digest algorithm. Another approach is to
allow definitions throughout the document and requiring the
canonicalizer to inline the algorithm definition in the Digest
elements."
Richard D. Brown [Page 4]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
Author Notes:
The first approach does not prevent replication of algorithm
definitions in the header of the document and the different
signature Manifests. On the other hand, the second approach
requires particular behaviors in the canonicalizers and
therefore cannot suffice with a surface string digest
algorithm.
#98091002 - Promote compactness over reusability
Origin: Richard D. Brown
Status: Opened
Comments:
"The current specification makes use of reusable element types.
This approach obviously increases the "verbosity" of the
syntax. It might be preferable to promote compactness instead
of reusability."
For example, the following optimizations might be considered:
- Collapsing Locator into Resource.
- Collapsing ContentInfo into Package.
- Replacing basic data types (i.e. Integer, Date, etc...) by
a DCD attribute and a PCDATA contents on the parent
element.
Author Notes:
#98111301 - Add a Resource criticality attribute
Origin: Milton M. Anderson
Status: Opened
Comments:
"The definition of <resource> does not contain a feature to
allow the signer to declare that the resource is critical to
the validity of the signature."
Richard D. Brown [Page 5]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
Author Notes:
I do not have all the elements for judging how relevant is this
particular comment, but my first guess is that a signature
applies to a particular content and semantics verification
shall be left to the application layer.
#98111302 - Remove dsig:eval global attribute
Origin: Milton M. Anderson
Status: Closed
Comments:
"Having the dsig:eval attribute in the element that defines the
authenticated block is probably a bad idea, since different
signers can use different hash algorithm."
Author Notes:
Others have made a similar comment, but we have reached a
different conclusion: dsig:eval shall be an IDREFS instead of
an IDREF.
#98111303 - Add a logging attribute
Origin: Milton M. Anderson
Status: Closed
Comments:
"No ability to mark data for logging by a signing hardware is
included."
Author Notes:
Also, very much application specific. I am not quite sure this
shall be a concern for the XML DSIG Proposal.
Richard D. Brown [Page 6]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
#98111304 - Add a signature purpose attribute
Origin: Milton M. Anderson
Status: Closed
Comments:
"The signature doesn't have a "type of signature" element."
Author Notes:
This may be provided at the application level by means of a
complementary attribute.
#98111305 - Add a Nonce in the Manifest
Origin: Milton M. Anderson
Status: Closed
Comments:
"No nonce to be used in hashing the resource is defined."
Author Notes:
Milton refers to a scheme that could be used for preventing
birthday-attacks against the digest algorithm.
E-Check makes use of this artifice to make sure that a
fraudulent signer or a Trojan Horse on the signer's computer
does not have full control over the data being signed by the
signing device. If the attacker were able to find two messages
M1 and M2 such that H(M1) = H(M2), it could send M1 to the
device and then substitute M2 later. The hardware log will
record that M1 has been signed and not M2.
This problem may be addressed in the hardware log by itself.
The device may sign H(M1), pick a nonce at random, and log the
nonce value along with H(nonce||M1) for example.
Richard D. Brown [Page 7]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
#98112501 - Leverage DCD and other specifications
Origin: Hiroshi Maruyama
Status: Opened
Comments:
"For data types, I think we could refer to other activities
such as DCD."
Author Notes:
Agreed as long as these specifications are adopted in time.
Notice that DCD provides mostly for basic data types. This will
not resolve the problem for the constructed data types such as
IssuerAndSerialNumber, Package, etc...
#98121501 - IssuerAndSerialNumber is too restrictive
Origin: Richard D. Brown
Status: Opened
Comments:
"Identifying a certificate by means of the constructed data
types IssuerAndSerialNumber might be too restrictive. It is not
obvious that this construct is sufficient for certificates
other than X509v3. The specification shall adopt syntax a bit
more opened.
For example, a certificate might be uniquely identified by
means of a Identifier element, whose syntax depends upon the
type of the certificate."
Author Notes:
Richard D. Brown [Page 8]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
#98122601 - Allow multiple Resource in Manifest
Origin: Don Eastlake
Status: Adopted (990404)
Comments:
"I believe that multiple occurrences of Resource should be
permitted in the Manifest"
Author Notes:
The Manifest now requires a Resources element.
#98122602 - Add a base locator for HREFs
Origin: Don Eastlake - IOTP WG
Status: Opened
Comments:
"Some of the IOTP concerns about many huge locator HREFs could
be satisfied if a "base" attribute were permitted at the
Resources level or, even more general, a Base element, which
effected all following resource."
Author Notes:
#98122603 - Rename the attribute dsig:eval
Origin: Don Eastlake
Status: Opened
Comments:
"I do not like the choice of "eval" even if it is arbitrary. It
makes me think of Lisp or the like. I would expect it to
evaluate arithmetic expressions or the like. I think the
previous "hash" was better and perhaps "dsig:digest" would be
best..."
Author Notes:
Richard D. Brown [Page 9]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
#98122604 - Default encoding attribute to base64
Origin: Don Eastlake
Status: Opened
Comments:
"What's about defaulting to base64 instead of none for the
encoding."
Author Notes:
#99010201 - Add a ID attribute to Algorithm
Origin: Mark Linehan
Status: Superceded (98091001)
Comments:
"I suggest adding an "id" attribute to the Algorithm element,
and adding an algref attribute to any element that contains an
Algorithm. Purpose is to avoid repeating the same Algorithm
text in many places."
Author Notes:
One approach to address #98091001
#99010202 - Provide a default digest algorithm
Origin: Mark Linehan
Status: Closed
Comments:
"I suggest that it would be helpful to have a way to declare a
default or standard digest algorithm. Reason: in most cases,
the same algorithm will be used throughout a document."
Author Notes:
Adequate optimization should enable use of shared definitions.
In such circumstances, the overhead on a Resource element will
be limited to an IDREF. At first, removing all algorithm
references from the Resource element does not seem a good idea
Richard D. Brown [Page 10]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
#99010203 - Add a type to RecipientInfo and OriginatorInfo
Origin: Mark Linehan
Status: Closed
Comments:
"I suggest that OriginatorInfo and RecipientInfo have a "type"
attribute for the same reason as the Attribute element: to
identify the format of the ANY content."
Author Notes:
RecipientInfo and OriginatorInfo are expected to be a
collection of "attributes". Therefore, it does not make sense
to define a "type" attribute for these elements.
#99020301 - Adopt URL instead of URI
Origin: Joseph Reagle
Status: Opened
Comments:
"What's about adopting URLs instead of URNs. This will prevent
registration requirements. At the least, the specification
should allow URIs."
Author Notes:
#99021201 - Allow multiple signatures on a Manifest
Origin: IOTP WG
Status: Opened
Comments:
"Ability to have multiple signatures on a single Manifest and
ability to adhere a recipient to a Signature."
Richard D. Brown [Page 11]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
To address these concerns, IOTP DTD proposes the following
construct:
<!-- DTD Extract -->
<!ELEMENT Signature (Manifest, Value+)>
<!ELEMENT Manifest ((Manifest,
Resources, Attributes?, OriginatorInfo, RecipientInfo+
)>
<!ELEMENT RecipientInfo ANY>
<!ATTLIST RecipientInfo
SignatureValueRef IDREF #REQUIRED
SignatureCertRef IDREF #IMPLIED
>
<!-- Signature Example -->
<Signature>
<Manifest>
<Resources>
...
</Resources>
<OriginatorInfo>
...
</OriginatorInfo>
<RecipientInfo
SignatureValueRef='sigv1'
SignatureCertRef='cert1'>
...
</RecipientInfo>
<RecipientInfo
SignatureValueRef='sigv2'
SignatureCertRef='cert2'>
...
</RecipientInfo>
...
</Manifest>
<Value id='sigv1'>
aBcdsejhtksagnbf==
</Value>
<Value id='sigv2'>
ehlekjrekkjrk==
</Value>
</Signature>
Richard D. Brown [Page 12]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
<Certificates>
<Certificate id='cert1' ...>
...
</Certificate>
<Certificate id='cert2' ...>
...
</Certificate>
</Certificate>
Author Notes:
Assuming that the benefit expected from this construct is to
prevent replication of a large Manifest in multiple Signature
elements, I would remind that this specification allows for
shared Resources element
I can see at least three potential drawbacks with this
construct:
- Privacy: A signature value cannot be verified unless all
the RecipientInfo elements are preserved into the
Manifest. In some circumstances, it may not be desirable
to disclose the identity of the other recipients. Notice
however that this construct does not preclude the
creation of independent signature elements.
- Complexity: This construct is obviously more
complicated than the one currently proposed. Dual forward
references are not always easy to handle.
- Inconsistency: Applying multiple signatures to a single
document usually implies that the application has adopted
some secret-key authentication scheme. In such
circumstances, the originator may be known by the
recipients under different names or accounts. But, this
construct does not allow replication of the
OriginatorInfo element (per recipient basis), which is
supposed to carry such pieces of information.
#99021202 - Enable shared digest algorithm definitions
Origin: IOTP WG
Status: Superceded by 98091002
Comments:
"Ability to share digest algorithms for signatures, digest, and
canonicalization"
Richard D. Brown [Page 13]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
To address this concern, the IOTP DTD proposes to insert a
collection of algorithm definitions into the signature Manifest
and to use a linking mechanism for binding Resource definitions
and signature algorithms to these shared definitions.
<!-- DTD Extract -->
<!ELEMENT Manifest (
Algorithm+,
Resource+,
Attributes?,
OriginatorInfo,
RecipientInfo+
)>
<!ELEMENT Digest (#PCDATA)>
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
Author Notes:
Potential solution to optimizing the syntax. However, I would
suggest replacing the collection of Algorithm elements by a
DigestAlgorithms element. Also, I would limit this
functionality to the Digest elements.
#99031601 - Remove criticality attribute on Attribute
Origin: Dave Solo, Eric Riscola
Status: Opened
Comments:
... IETF Meeting - following a presentation of criticality
flag...
Dave: "it's a bad idea: experience in CMS was to remove it"
Eric: "I reinforce Dave: this bogs down every new attribute
with a debate over 'criticality' ... PKIX and S/MIME show signs
of precisely this kind of bloat."
Author Notes:
Tend to agree that criticality shall be a matter of the relying
party and, therefore, a criticality attribute provided by the
signer is not necessary in the syntax.
Richard D. Brown [Page 14]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
#99040101 - Remove Attributes element
Origin: Yoshiaki Kawatsura
Status: Closed
Comments:
"I do not understand why the Attributes element is needed."
Author Notes:
Collection elements such Attributes, Certificates, and
Signatures has been proposed to facilitate DOM manipulation.
For example, one may call some trust verification engine by
passing the Certificates sub-tree. This construct enables
containment of similar and related elements.
#99040102 - Allow attributes on Resource
Origin: Richard D. Brown
Status: Opened
Comments:
"It seems that allowing per Resource attributes may have
interesting applications. For example, a rating standard could
define a rating:Public attribute that could be associated
directly with the Resource element. In such circumstances, a
rating standard could almost suffice with the current DTD
definitions."
Author Notes:
#99040103 - Add an CanonicalizerAlgorithm element
Origin: Richard D. Brown
Status: Opened
Comments:
"All signature schemes require canonicalization and digest of
the Manifest. Thence, all the signature algorithms require at
least a digest-algorithm parameter and this has lead to some
inconsistencies such as requiring a digest algorithm for rsa
encryption or two hash functions for HMAC.
Richard D. Brown [Page 15]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
It may be preferable to add a CanonicalAlgorithm element in the
signature Manifest. This element will identify the
digest/canonical algorithm to be used for computation of the
fingerprint of the Signature Manifest."
<!ELEMENT Manifest(
DigestAlgorithms,
Resources,
Attributes?,
OriginatorInfo,
RecipientInfo,
KeyAgreementAlgorithm?,
CanonicalizerAlgorithm,
SignatureAlgorithm
)>
Author Notes:
#99040104 - Allow attributes on Package
Origin: Richard D. Brown
Status: Opened
Comments:
"Similarly to adding attributes to the Resource element. For
example, such added functionality could be used for attaching
an origin attribute to a package. This may be used for binding
indirectly a detached-signature with an internal Package
element."
Author Notes:
#99040105 - Change Attributes contents to ANY
Origin: Richard D. Brown
Status: Opened
Comments:
"Currently, the Attributes element consists of a collection of
Attribute elements, which specify a type and contain an inner
value element
Richard D. Brown [Page 16]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
An alternative a bit more opened would consist of defining
Attributes as an element of ANY contents and use constructed
attribute element."
<Resource href='http://www.w3c.org/doc.xml'>
<Attributes>
<rating:Audience value='all'/>
</Attributes>
...
</Resource>
Author Notes:
One could argue that origin, digest, and the forth are also
attributes of the resource and, therefore, could be sealed in
the Attributes element. In fact, we could remove the Attributes
element and define Resource as an element of ANY contents. But,
if we were to do so, it would be impossible to enforce the
presence of mandatory attribute elements such as resource
locator and digest by means of the DTD.
If this suggestion were to be adopted, we may consider
converting the ContentInfo element into a standard attribute.
#99040106 - Change ContentInfo contents to PCDATA
Origin: Richard D. Brown
Status: Opened
Comments:
"The specification proposes a ContentInfo element with a type
and subtype attribute. The type attribute is defined as an URN.
Unfortunately, URN specification does not allow the character
"/" in the NSS. Thence, it is not possible to map directly
existing MIME types into an URN without adopting adequate NSS
encoding. For example, "application/msword" shall be encoded
into something like "urn:MIME:application%2fmsword."
Richard D. Brown [Page 17]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
An alternative could be to define the ContentInfo element as
follows:
<!ELEMENT ContentInfo (#PCDATA)>
<!ATTLIST ContentInfo
type CDATA #IMPLIED 'urn:MIME'
>
<!-- Examples -->
<ContentInfo>
application/msword
</ContentInfo>
<ContentInfo type='urn:IOTP'>
OrderDescription
</ContentInfo>
Author Notes:
#99040701 - Allow Resource by value in Manifest
Origin: John Boyer, Richard D. Brown
Status: Opened
Comments:
"It may be worth considering the possibility to define a
Resource either by means of a locator and a digest or by
value."
We may consider the following definition:
<!ELEMENT Resource ((Locator, Digest) | Value)>
Author Notes:
Adopting this approach will disallow collapsing the Locator
element into the Resource element. If the value is provided it
does not make a lot of sense to specify a resource location.
But, Xlink specification seems to require the href attribute
(not clear in the specification).
Richard D. Brown [Page 18]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
#99040801 - Add a Certificate Appendix to specification
Origin: Richard D. Brown
Status: Opened
Comments:
"It may be worth considering adding a certificate appendix that
documents specifics for the different certificate types or
certificate locators. As a matter of fact, a LDAP URL might be
used but it is not sufficient for locating a particular
certificate"
Author Notes:
#99040802 - Add a Security Appendix to specification
Origin: Richard D. Brown
Status: Opened
Comments:
"It may be worth considering adding a security appendix such as
the one mandated by IETF."
Author Notes:
#99040803 - Add a Compliance Appendix to specification
Origin: Richard D. Brown
Status: Opened
Comments:
"It may be worth considering adding an appendix that defines
compliance requirements."
Author Notes:
Richard D. Brown [Page 19]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
#99040804 - Segregate basic data types
Origin: Richard D. Brown
Status: Opened
Comments:
"It may be worth considering segregation of the data types that
do not directly relate to XML-DSIG. For example, elements such
as Integer, Float, and value might be replaced by making use of
some DCD attribute, and others such as IssuerAndSerialNumber or
Package might be temporarily moved into some Data DTD. These
element definitions will be later superceded by definitions
adopted by specialized DTDs.
Author Notes:
#99061601 - Replace dsig:eval by a PI
Origin: Richard D. Brown
Status: Opened
Comments:
As mentioned earlier by Milton M. Anderson (98111302), having
the dsig:eval attribute directly in the element being
authenticated may be unpractical if different signers were to
use different hash algorithms.
A different approach consists of the definition of a Processing
Instruction that specifies the algorithm to be used. This
processing instruction could be inserted just before the
element to be hashed and is not part of the hash value. Change
in the value of the processing instruction does not invalidate
previous signatures. Moreover, because the digest algorithm
definitions are replicated into the Manifest, an attacker
cannot attack the authentication scheme by tampering with the
processing instruction.
Document>
<dsig:DigestAlgorithms>
<dsig:Algorithm id='sha1' type='urn:nist-gov:sha1'/>
<dsig:Algorithm id='md5' type='urn:rsasdi-com:md5'/>
</dsig:DigestAlgorithms>
Richard D. Brown [Page 20]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
<Element>
<?xmldsig eval='sha1 md5'?>
<HashedElement>
...
</HashedElement>
</Element>
</Document>
Author Notes:
#99061602 - Adopt RDF Data Model
Origin: XMLDISG'99 Participants
Status: Opened
Comments:
"XML-Signature should use the RDF data model but need not use
the RDF serialization syntax. " In other words, the XML
Signature syntax should consist of a static representation of a
RDF schema. In the short term this static representation will
translate into a DTD that will be replaced by the actual RDF
schema as RDF awareness will develop in the Industry.
Author Notes:
#99061603 - Add a index per Category
Origin: Don Eastlake
Status: Opened
Comments:
"Categorize the comments and suggestions and attach an Index
per category."
Author Notes:
Richard D. Brown [Page 21]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
2. Index per Reference Number
#98072901 - Syntax too verbose
#98091001 - Enable shared algorithm definitions
#98091002 - Promote compactness over reusability
#98111301 - Add a Resource criticality attribute
#98111302 - Remove dsig:eval global attribute
#98111303 - Add a logging attribute
#98111304 - Add a signature purpose attribute
#98111305 - Add a Nonce in the Manifest
#98112501 - Leverage DCD and other specifications
#98121501 - IssuerAndSerialNumber is too restrictive
#98122601 - Allow multiple Resource in Manifest
#98122602 - Add a base locator for HREFs
#98122603 - Rename the attribute dsig:eval
#98122604 - Default encoding attribute to base64
#99010201 - Add a ID attribute to Algorithm
#99010202 - Provide a default digest algorithm
#99010203 - Add a type to RecipientInfo and OriginatorInfo
#99020301 - Adopt URL instead of URI
#99021201 - Allow multiple signatures on a Manifest
#99021202 - Enable shared digest algorithm definitions
#99031601 - Remove criticality attribute on Attribute
#99040101 - Remove Attributes element
#99040102 - Allow attributes on Resource
#99040103 - Add an CanonicalizerAlgorithm element
#99040104 - Allow attributes on Package
#99040105 - Change Attributes contents to ANY
#99040106 - Change ContentInfo contents to PCDATA
#99040701 - Allow Resource by value in Manifest
#99040801 - Add a Certificate Appendix to specification
#99040802 - Add a Security Appendix to specification
#99040803 - Add a Compliance Appendix to specification
#99040804 - Segregate basic data types
#99061601 - Replace dsig:eval by a PI
#99061602 - Adopt RDF Data Model
Richard D. Brown [Page 22]
INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments
3. Index per Status
Opened
#98091001 - Enable shared algorithm definitions
#98091002 - Promote compactness over reusability
#98111301 - Add a Resource criticality attribute
#98112501 - Leverage DCD and other specifications
#98121501 - IssuerAndSerialNumber is too restrictive
#98122602 - Add a base locator for HREFs
#98122603 - Rename the attribute dsig:eval
#98122604 - Default encoding attribute to base64
#99020301 - Adopt URL instead of URI
#99021201 - Allow multiple signatures on a Manifest
#99031601 - Remove criticality attribute on Attribute
#99040102 - Allow attributes on Resource
#99040103 - Add an CanonicalizerAlgorithm element
#99040104 - Allow attributes on Package
#99040105 - Change Attributes contents to ANY
#99040106 - Change ContentInfo contents to PCDATA
#99040701 - Allow Resource by value in Manifest
#99040801 - Add a Certificate Appendix to specification
#99040802 - Add a Security Appendix to specification
#99040803 - Add a Compliance Appendix to specification
#99040804 - Segregate basic data types
#99061601 - Replace dsig:eval by a PI
#99061602 - Adopt RDF Data Model
#99061603 - Add a index per Category
Closed
#98111302 - Remove dsig:eval global attribute
#98111303 - Add a logging attribute
#98111304 - Add a signature purpose attribute
#98111305 - Add a Nonce in the Manifest
#99010202 - Provide a default digest algorithm
#99010203 - Add a type to RecipientInfo and OriginatorInfo
#99040101 - Remove Attributes element
Superceded
#98072901 - Syntax too verbose
#99010201 - Add a ID attribute to Algorithm
#99021202 - Enable shared digest algorithm definitions
Adopted
#98122601 - Allow multiple Resource in Manifest
File Name: draft-ietf-xmldsig-signature-comments-00.txt
Expires: December 1999
Richard D. Brown [Page 23]
