One document matched: draft-ietf-trade-xml-sig-00.txt-62616.txt
TRADE Working Group Richard D. Brown
GlobeSet, Inc.
Expires May 1999 November 1998
Digital Signatures for XML
------- ---------- --- ---
Richard D. Brown
GlobeSet, Inc.
Status of This Document
This draft, file name draft-ietf-trade-xml-sig-00.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the TRADE working group mailing
list at <ietf-trade@eListX.com>.
This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
A syntax and procedures for the computation and verification of XML
digital signatures is specified.
Richard D. Brown [Page 1]
INTERNET-DRAFT November 1998 Digital Signatures for XML
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................4
2. Objective and Requirements..............................4
3. Signature Basics........................................5
3.1 Resource Element.......................................5
3.2 Originator and Recipient Information Elements..........6
3.3 Other Attributes.......................................7
3.4 Signature Algorithms Element...........................7
4. Signature Principles....................................8
4.1 Enabling Signature in XML Applications.................8
4.2 Encapsulating Arbitrary Contents.......................9
4.3 Implementing Endorsement..............................10
4.4 Supporting Composite Documents........................10
4.5 Facilitating One-pass Processing......................11
5. Detailed Signature Syntax..............................12
5.1 Namespace Attributes..................................13
5.2 dsig:hash Global Attribute............................13
5.3 Document..............................................14
5.4 DigestAlgorithms......................................15
5.5 Package...............................................16
5.6 ContentType...........................................16
5.7 Value.................................................17
5.8 Signatures............................................17
5.9 Signature.............................................18
5.10 Manifest.............................................18
5.11 Resource.............................................19
5.12 Locator..............................................20
5.13 Digest...............................................20
5.14 OriginatorInfo.......................................21
5.15 RecipientInfo........................................21
5.16 OriginatorInfo.......................................21
5.17 RecipientInfo........................................22
5.18 Identifier...........................................22
5.19 IssuerAndSerialNumber................................23
5.20 Attributes...........................................23
5.21 Attribute............................................24
5.22 Date.................................................24
5.23 SignatureAlgorithms..................................25
5.24 Certificates.........................................26
5.25 Certificate..........................................26
5.26 Resources............................................27
6. Supported Algorithms...................................28
6.1 Algorithm Definition..................................28
6.2 Canonicalizers........................................28
Richard D. Brown [Page 2]
INTERNET-DRAFT November 1998 Digital Signatures for XML
6.3 Digest Algorithms.....................................28
6.4 Key-agreement Algorithms..............................28
6.5 Signature Algorithms..................................28
6.6 Base64 Comments.......................................28
7. Supported Content Type.................................28
8. Certificate Supplement.................................29
9. Conformance Requirements...............................29
10. Examples..............................................29
10.1 Signature DTD - Embedded Content.....................29
10.2 Signature DTD - Detached Signature...................31
10.3 Extended DTD - Domain-specific Attribute.............32
11. Signature DTD.........................................34
12. Security Considerations...............................34
References................................................35
Author's Address..........................................35
Expiration and File Name..................................35
Richard D. Brown [Page 3]
INTERNET-DRAFT November 1998 Digital Signatures for XML
1. Introduction
XML, the Extensible Markup Language, is a syntactical standard
elaborated by the W3C XML Activity, which produced the first
recommendation on February 10, 1998. XML is a subset of an existing
and widely used international text processing standard known as SGML
(Standard Generalized Markup Language). XML is intended primarily for
structuring data exchanged and served over the World Wide Web.
As it is anticipated that XML will be widely used in the exchange of
business and commercial data, and it has been already established
that digital signatures will play an important role in enabling
electronic commerce, the necessity to promote a digital signature
standard for general XML documents becomes evident.
Drafted with IOTP (Internet Open Trading Protocol) requirements in
mind, this document has been further enhanced as comments were
received and alternative proposals disclosed. It is now expected that
it provides a more general solution to signing XML documents.
2. Objective and Requirements
The objective of this document is to propose syntax and procedures
for the computation and verification of digital signatures applicable
to general XML documents.
This proposal has been established in light of the requirements that
have been gathered while reviewing diverse projects and alternative
approaches such as IOTP [draft-ietf-trade-iotp-v1.0-protocol-*.txt],
eCheck [x], BIPS [x], SDML [x], and XMLDSIG [x]. The following
requirements have been identified:
1. The solution shall provide a means for building authentication
into XML applications, but shall also propose an XML alternative
to binary signature syntax for signing arbitrary contents.
2. The solution shall provide indifferently for digital signature and
message authentication codes, considering symmetric and asymmetric
authentication schemes as well as dynamic negotiation of keying
material.
3. The solution shall provide a mechanism that eases the production
of composite documents that consist of the combination by addition
or deletion of authenticated blocks of information, while
preserving verifiability of the origin and authenticity of these
blocks of information.
4. The solution shall enable authentication of part or totality of an
Richard D. Brown [Page 4]
INTERNET-DRAFT November 1998 Digital Signatures for XML
XML document.
5. The solution shall enable authentication of internal and external
resources.
6. The solution shall provide for extended signature functionality
such as co-signature, endorsement, plurality of recipients, etc.
3. Signature Basics
This specification consists primarily of the definition of an XML
element known as the Signature element. This element is comprised of
two sub-elements. The first one is a set of authenticated attributes,
known as the signature Manifest, which comprises such things as a
unique reference to the resource being authenticated and an
indication of the keying material and algorithms being used. The
second sub-element consists of the digital signature value.
<Signature>
<Manifest>
(resource information block)
(originator information block)
(recipient information block)
(other attributes)
(signature algorithms information block)
</Manifest>
<Value encoding= "encoding scheme">
(encoded signature value)
<Value>
</Signature>
The digital signature is not computed directly from the pieces of
information to be authenticated. Instead, the digital signature is
computed from a set of authenticated attributes (the Manifest), which
include a reference to, and a digest of, these pieces of information.
The authentication is therefore "indirect".
3.1 Resource Element
The Resource element consists of a unique and unambiguous reference
to the resource being authenticated. It is constructed of a locator,
a fingerprint, and optionally a content-type qualifier.
Richard D. Brown [Page 5]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<Resource>
<Locator href= "resource locator"/>
<ContentType type= "type qualifier"/>
<Digest>
<DigestAlgorithms>
<Canonicalizer>
(algorithm information block)
</Canonicalizer>
<DigestAlgorithm>
(algorithm information block)
</DigestAlgorithm>
</DigestAlgorithms>
<Value encoding= "encoding scheme">
(encoded digest value)
</Value>
</Digest>
</Resource>
The resource locator is implemented as a simple XML Link[x]. This not
only provides a unique addressing scheme for internal and external
resources, but also facilitates authentication of composite documents
(see section 4.4). Besides the digest algorithm, the Digest element
provides for a canonicalizer. This algorithm ensures consistency of
the information being digested by extracting its core semantic.
Changes in the external representation of a piece of information
shall not affect its canonical representation.
3.2 Originator and Recipient Information Elements
The purpose of the Originator and Recipient information elements
consists of providing identification and keying material for these
respective parties.
<OriginatorInfo>
(identification information block)
(keying material information block)
</OriginatorInfo>
<RecipientInfo>
(identification information block)
(keying material information block)
</RecipientInfo>
The actual content of these two elements depends on the
authentication scheme being used and the existence or non-existence
of a prior relationship between the parties. In some circumstances,
it may be quite difficult to distinguish between identification and
keying material information. A unique reference to a digital
Richard D. Brown [Page 6]
INTERNET-DRAFT November 1998 Digital Signatures for XML
certificate provides for both. This may also stand true for an
account number when a prior relationship exists between the parties.
The Originator information element is mandatory. Depending on the
existence or non-existence of a prior relationship with the
recipient, this block either refers to a public credential such as a
digital certificate or displays a unique identifier known by the
recipient.
The Recipient information element may be used when a document
contains multiple signature information blocks, each being intended
for a particular recipient. A unique reference in the Recipient
information block helps the recipients identify their respective
Signature information block.
The Recipient information element may also be used when determination
of the authentication key consists of a combination of keying
material provided by both parties. This would be the case, for
example, when establishing a key by means of Diffie Hellman[x] Key
Exchange algorithm.
3.3 Other Attributes
The Attributes element consists of a collection of Attribute elements
that could be used for inserting specific pieces of information
directly into the Signature element. An Attribute element is
constructed of a type, a criticality, and a value.
<Attributes>
<Attribute type= "signing-time" critical= "true">
<Date value="1998-10-28T08:15-0500">
</Attribute>
<Attribute type= "private-type" critical= "false">
(ANY attribute value)
</Attribute>
</Attributes>
The attribute value consists of ANY content that is defined in the
application DTD. Nevertheless, to facilitate the adoption of
"standard" attributes, the Signature DTD provides for common types
such as "signing-time".
3.4 Signature Algorithms Element
The Signature Algorithms element indicates the algorithms to be used
for computation of the signature value. This element indicates not
Richard D. Brown [Page 7]
INTERNET-DRAFT November 1998 Digital Signatures for XML
only the signature algorithm but also a canonicalizer and an optional
key-agreement algorithm.
<SignatureAlgorithms>
<Canonicalizer>
(algorithm information block)
</Canonicalizer>
<KeyAgreementAlgorithm>
(algorithm information block)
</KeyAgreementAlgorithm>
<SignatureAlgorithm>
(algorithm information block)
</SignatureAlgorithm>
</SignatureAlgorithms>
In consideration of the requirements stated previously, this document
uses the terminology of "signature" for qualifying indifferently
signature and authentication schemes. Therefore, the signature
algorithm mentioned above might refer to a signature algorithm such
as DSS or to a message authentication code (MAC) such as HMAC.
The key-agreement algorithm may be used for deriving a one-time
session key from an established master key. Usage of one-time session
key prevents some kinds of attack that require a large volume of
cipher-text to be produced by a given key.
4. Signature Principles
4.1 Enabling Signature in XML Applications
As mentioned previously, this proposal shall provide a means for
building authentication into general XML applications. The mechanism
adopted herein considers the "XML Namespaces" specifications[x],
which define the requirements for combining multiple DTDs or parts of
individual DTD into a single document.
According to these specifications, an XML application can build
digital signature support by referring explicitly to the elements
defined in the Signature DTD. This is accomplished by associating a
namespace prefix to the Signature DTD and qualifying Signature
element names by means of this prefix. Association of a namespace
prefix to a DTD shall be done by means of a xmlns attribute, which
could appear in any element that either refers to or contains sub-
elements that refer to elements of the DTD considered. A qualified
name consists of a namespace prefix, a colon, and a name.
Richard D. Brown [Page 8]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<Document xmlns:dsig=" Signature-DTD-URI">
<Element id=" Element" ...>
<SubElement ...>
...
</SubElement>
...
</Element>
<dsig:Signature>
<Manifest>
<Resource>
<Locator href=" #Element"/>
...
</Resource>
...
</Manifest>
<Value>
...
</Value>
</dsig:Signature>
</Document>
[The XML Namespaces specifications are still work in progress at W3C.
A final draft should be available soon, as the specifications entered
"last call" September 16, 1998.
There are still a few unknowns regarding combination of DTD and use
of qualified names in an application DTD that inherits definitions
from another DTD. The current paragraph will be developed, as
clarifications will be obtained.]
4.2 Encapsulating Arbitrary Contents
To facilitate encapsulation of arbitrary contents into an XML
document, the Signature DTD defines a Package element. Quite similar
to a MIME wrapper, this element provides for such things as content
type and content encoding.
<Package>
<ContentType type= "type qualifier"/>
<Value encoding= "encoding scheme">
(safe content)
</Value>
</Package>
Though it addresses a similar purpose, the Package element specified
by this draft proposal is radically different from the one given in
the " XML Pack- age" proposal[x]. Such decision has been driven by
Richard D. Brown [Page 9]
INTERNET-DRAFT November 1998 Digital Signatures for XML
the possibility to leverage other element definitions of this DTD.
However, the current definition might be amended in time if the
Package proposal were to be adopted.
4.3 Implementing Endorsement
Endorsement consists of signing another signature. To facilitate
endorsement, the definition of the Signature element provides for an
element identifier attribute, which can be used to target a Signature
element from a Resource element.
<Signature id=" Signature">
<Manifest>
<Resource>
<Locator href=" resource locator"/>
...
</Resource>
...
</Manifest>
...
</Signature>
<Signature id=" CounterSignature">
<Manifest>
<Resource
<Locator href="# Signature"/>
...
</Resource>
...
</Manifest>
...
</Signature>
4.4 Supporting Composite Documents
Some protocols consist of the exchange of documents that result from
the combination by addition or deletion of common information blocks.
This proposal preserves verifiability of the origin and authenticity
of these blocks of information as they are exchanged between parties.
To facilitate creation and verifiability of composite documents, the
current draft proposal has adopted an element, known as the Resources
element, which consist of a collection of Resource elements. The
authentication of the Resources element is sufficient for ensuring
proper authentication of the blocks of information that it
references, and verifiability is preserved when individual blocks of
Richard D. Brown [Page 10]
INTERNET-DRAFT November 1998 Digital Signatures for XML
information are missing.
<Block id=" Block01">
...
</Block>
<Block id=" Block02">
...
</Block>
<Resources id=" Resources">
<Resource>
<Locator href="# Block01"/>
...
</Resource>
<Resource>
<Locator href="# Block02">
...
</Resource>
</Resources>
<Signature>
<Manifest>
<Resource>
<Locator href="# Resources">
...
</Resource>
...
</Manifest
...
</Signature>
The adoption of simple XML links as resource locators makes possible
the authentication of composite documents. If IDREFs were used
instead, it would have been impossible to ensure validity of partial
documents - some IDREFs could have been left referencing non-embedded
IDs.
4.5 Facilitating One-pass Processing
Without further definitions, it would be impossible to determine
which blocks of information require authentication and which
algorithms need to be employed before interpretation of the Resource
elements. These elements being generally located at the end of the
document, this restriction would prevent computation of the digests
during acquisition of the blocks of information.
To facilitate one-pass processing, this specification uses another
Richard D. Brown [Page 11]
INTERNET-DRAFT November 1998 Digital Signatures for XML
functionality offered by the namespaces proposal. This functionality
provides for the definition of global attributes that may be used and
recognized across multiple elements. This document specifies the
dsig:hash global attribute, which could be used for identifying the
blocks of information to be authenticated. This attribute shall
reference a Digest Algorithms element, which should be declared
before making use of the attribute.
<Document xmlns:dsig=" Signature-DTD-URI">
<dsig:DigestAlgorithms id=" Algorithms">
...
</dsig:DigestAlgorithms>
<AuthenticatedBlock id=" AuthBlock"
dsig:hash="Algorithms">
...
</AuthenticatedBlock>
<dsig:Signature>
<Manifest>
<Resource>
<Locator href="# AuthBlock">
...
</Resource>
...
</Manifest>
...
</dsig:Signature>
</Document>
When encountering the dsig:hash global attribute on the Authenticated
Block element, the XML parser is immediately aware of the requirement
of computing the digest of this element. All the pieces of
information necessary for such computation are provided by the Digest
Algorithms element referenced by the attribute.
5. Detailed Signature Syntax
Though it is expected that Signature support will be primarily built
into general XML applications by incorporating definitions of the
Signature DTD into other XML applications, the Signature DTD defines
the elements necessary to providing an XML alternative to binary
signature syntaxes.
Richard D. Brown [Page 12]
INTERNET-DRAFT November 1998 Digital Signatures for XML
5.1 Namespace Attributes
All the elements defined by the Signature DTD are explicitly bound to
the XMLDSIG namespace by means of a dsig prefix. In order to make
sure that every element could be individually imported by other XML
applications, the element definitions given hereinafter
systematically declare a fixed xmlns:dsig attribute.
<!ELEMENT dsig:element definition...>
<!ATTLIST dsig:element
xmlns:dsig CDATA #FIXED %xmldsig.dtd;
...
>
Recall that many XML applications, presumably including namespaces-
sensitive ones, fail to require validating processors. For correct
operation with such applications, namespaces declarations must be
also provided either directly or via default attributes declared in
the internal subset of the DTD.
5.2 dsig:hash Global Attribute
As mentioned previously, this draft proposal specifies a dsig:hash
global attribute that could be used for identifying a block of
information to be authenticated. This attribute shall refer to a
Digest Algorithms element, which should be declared before making use
of the attribute.
The XML Namespaces specifications do not explicitly provide for
declaration of global attributes. Distinguishing between global
attributes and element attributes exists only in the prose
description of such attributes. An essential property of global
attributes consists nonetheless of the uniqueness of their name that
is independent of the elements where they are defined.
The definition of elements that could be subject to authentication
may define the dsig:hash attribute as follows:
<!ELEMENT element definition...>
<!ATTLIST element
dsig:hash IDREF #IMPLIED
>
Recall that the namespace prefix that is bound to the XMLDSIG
namespace shall be defined before being employed. However, such
definition may occur in the element that defines the dsig:hash
Richard D. Brown [Page 13]
INTERNET-DRAFT November 1998 Digital Signatures for XML
attribute.
The reader shall notice that the terminology "dsig:hash" is
inappropriate and used solely for illustrative purposes. This simply
means that the name of this attribute is hash and it belongs to the
XMLDSIG namespace (whatever prefix is used).
5.3 Document
The Document element constitutes the outermost envelope of an XML
document that conforms to the Signature DTD. The definition of this
element has been intentionally kept simple and is only intended to
provide an XML alternative to the ASN1 data types Authenticated Data
and Signed Data defined by CMS[x] and PKCS7[x] binary syntax
standards.
It is expected that this simple, though complete, definition will
help the adoption of this proposal and facilitate the production of
conformant implementations by a plurality of providers. This
definition does not preclude however the definition of more
sophisticated constructions to be adopted by particular XML
applications. Such applications may either redefine the Document
element or promote their own DTD, which shall be partially
constructed of elements defined by the Signature DTD.
<!ELEMENT dsig:Document (
( dsig:DigestAlgorithms, dsig:Package )?,
dsig:Signatures, dsig:Certificates?
)>
<!ATTLIST dsig:Document
xmlns:dsig CDATA #FIXED %xmldsig.dtd;
>
The definition given above has been deemed sufficient for
implementing the following functionality provided by CMS or PKCS7:
-- Authentication of arbitrary contents: This may be done by adequate
en-capsulation and encoding of the arbitrary contents into the
Package ele-ment, which shall be further authenticated by means of
a Signature ele-ment.
-- Detached signature: This may be done by means of a Signature
element that refers to a resource external to the document.
-- Authentication versus signature: The distinction between
authentication and signature only depends upon the algorithms
being employed for computation of the "signature" value.
-- Plurality of recipients: This consists of the insertion of a
plurality of Sig-nature elements, each making use of recipient-
dependent keying mate-rial.
Richard D. Brown [Page 14]
INTERNET-DRAFT November 1998 Digital Signatures for XML
-- Plurality of signers: This consists of the insertion of a
plurality of Signature elements, each making use of originator-
dependent keying material.
Content Description
DigestAlgorithms: This element has been made mandatory whenever
the document embeds the contents to be authenticated. This
element specifies the algorithms to be used for computation
of the digest of the Package element, thus enabling one-pass
processing.
Package: This element is used for enveloping and encoding of the
contents to be authenticated. Whenever employed, this
element shall make use of the dsig:hash global attribute to
refer to the Digest Algorithms element described above.
Signatures: This element consists of a collection of Signature
elements.
Certificates: This element consists of a collection of
Certificate elements, which may be required by a given key
management infrastructure.
The definition of collection elements (i.e. Certificates and
Signatures) for the sole purpose of grouping similar sub-elements has
been adopted for facilitat- ing DOM manipulations.
5.4 DigestAlgorithms
The purpose of the DigestAlgorithms element consists of specifying
the algorithms to be employed in the computation of a message digest.
This element is used either as a standalone element for enabling
one-pass processing or as a sub-element of the Digest element.
<!ELEMENT dsig:DigestAlgorithms (
dsig:Canonicalizer?, dsig:DigestAlgorithm
)>
<!ATTLIST dsig:DigestAlgorithms
xmlns CDATA #FIXED %xmldsig.dtd;
id ID #IMPLIED
>
Content Description
Canonicalizer: Algorithm to be used for normalizing the contents
to be authenticated (cf. Supported Algorithms). By default,
Richard D. Brown [Page 15]
INTERNET-DRAFT November 1998 Digital Signatures for XML
the digest value is computed on the surface string of the
content value.
DigestAlgorithm: Algorithm to be used for computation of the
Digest value (cf. Supported Algorithms)
Attributes Description
id: Element identifier that is used on standalone element for
enabling reference by the dsig:hash global attribute.
5.5 Package
The Package element enables encapsulation of an arbitrary content
into an XML document. Behaving like a MIME wrapper, the Package
element provides for such things as content type identification and
content encoding.
<!ELEMENT dsig:Package (
dsig:ContentType?, dsig:Value
)>
<!ATTLIST dsig:Package
xmlns:dsig CDATA #FIXED %xmldsig.dtd;
dsig:hash IDREF #IMPLIED
id ID #IMPLIED
>
Content Description
ContentType: Type qualifier for the content.
Value: Content value.
Attributes Description
id: Element identifier that could be used for referencing this
element from a Resource element.
5.6 ContentType
The purpose of the ContentType element is to describe a given content
such that a receiving user agent can deal with the data in an
appropriate manner.
Richard D. Brown [Page 16]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<!ELEMENT dsig:ContentType EMPTY>
<!ATTLIST dsig:ContentType
xmlns:dsig PCDATA #FIXED %xmldsig.dtd;
type PCDATA #REQUIRED
>
Attributes Description
type: Type of the content. In order to prevent potential conflict
in the definition of content types, this draft proposal makes
use of Universal Resource Names[x] (cf. Supported Content
Types).
5.7 Value
<!ELEMENT dsig:Value ( #PCDATA )>
<!ATTLIST dsig:Value
xmlns:disg CDATA #FIXED %xmldsig.dtd;
encoding ( base64 | none ) #REQUIRED 'none'
>
Content Description
PCDATA: Content value after adequate encoding.
Attributes Description
encoding: This attribute specifies the decoding scheme to be
employed for recovering the original byte stream from the
content of the element. The current draft proposal recognizes
the following two schemes:
none: the content has not been subject to any particular
encoding. This does not preclude however the use of native
XML encoding such as CDATA section or XML escaping.
base64: The content has been encoded by means of the base64
encoding scheme (cf. Supported Algorithms)
5.8 Signatures
The Signatures element consists of a collection of Signature
elements. As mentioned in a previous paragraph, this element has been
defined for the sole purpose of facilitating DOM manipulations.
Richard D. Brown [Page 17]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<!ELEMENT dsig:Signatures ( dsig:Signature+ )>
<!ATTLIST dsig:Signatures
xmlns:dsig CDATA #FIXED %xmldsig.dtd;
>
Content Description
Signature: A collection of Signature elements.
5.9 Signature
The Signature element constitutes the core of this draft proposal. It
is comprised of two sub-elements. The first one is a set of
attributes, known as the Manifest, which actually constitutes the
authenticated part of the document. The second sub-element consists
of the signature value.
<!ELEMENT dsig:Signature ( dsig:Manifest, dsig:Value )>
<!ATTLIST dsig:Signature
xmlns:dsig CDATA #FIXED %xmldsig.dtd;
dsig:hash IDREF #IMPLIED
id ID #IMPLIED
>
Content Description
Manifest: A set of attributes that actually constitutes the
authenticated part of the document.
Value: Encoding of the signature value.
Attributes Description
id: Element identifier that could be used for referencing the
Signature element from a Resource element when implementing
endorsement.
5.10 Manifest
The Manifest element consists of a collection of attributes that
specify such things as a unique reference to the resource being
authenticated and an indication of the keying material and algorithms
to be used. The Manifest actually constitutes the authenticated part
of the document.
Richard D. Brown [Page 18]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<!ELEMENT dsig:Manifest (
dsig:Resource, dsig:OriginatorInfo,
dsig:RecipientInfo?, dsig:Attributes?,
dsig:SignatureAlgorithms
)>
<!ATTLIST dsig:Manifest
xmlns:dsig PCDATA #FIXED %xmldsig.dtd;
>
Content Description
Resource: Unique and unambiguous reference to the resource being
authenticated.
OriginatorInfo: Identification and keying material information
related to the originator.
RecipientInfo: Identification and keying material
information related to the recipient.
Attributes: An optional collection of complementary attributes to
be authenticated.
SignatureAlgorithms: Element that indicates the algorithms to be
used for computation of the signature value.
5.11 Resource
The Resource element consists of a unique and unambiguous reference
to a resource being authenticated. It is comprised of a resource
locator, a fingerprint, and optionally a content-type qualifier.
<!ELEMENT dsig:Resource (
dsig:ContentType?, dsig:Locator, dsig:Digest
)>
<!ATTLIST dsig:Resource
xmlns:dsig CDATA #FIXED %xmldsig.dtd;
>
Content Description
ContentType: Content type qualifier.
Locator: Locator value that contains either a URI, a fragment
identifier, or both. Notice that making use of a fragment
identifier for a document content other than XML is out of
Richard D. Brown [Page 19]
INTERNET-DRAFT November 1998 Digital Signatures for XML
the scope of this draft proposal and may lead to inconsistent
results.
Digest: Fingerprint of the resource being authenticated.
5.12
The Locator element consists of simple XML link[x]. This element
allows unambiguous reference to a resource or fragment of a resource.
<!ELEMENT dsig:Locator EMPTY>
<!ATTLIST dsig:Locator
xmlns:disg CDATA #FIXED %xmldsig.dtd;
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED
>
Attributes Description
xml:link Required XML link attribute that specifies the nature of
the link (simple in this case).
href: Locator value that may contains either a URI, a fragment
identifier, or both. (see restrictions when used with a
Resource element).
5.13 Digest
The Digest element consists of the fingerprint of a given resource.
This element is constructed of two sub-elements. This first one
indicates the algorithms to be used for computation of the
fingerprint. The second element consists of the fingerprint value.
<!ELEMENT dsig:Digest ( dsig:DigestAlgorithms, dsig:Value )>
<!ATTLIST dsig:Digest
xmlns:disg CDATA #FIXED %xmldsig.dtd;
>
Content Description
DigestAlgorithms: Algorithms to be used for computation of the
fingerprint.
Value: Encoding of the fingerprint value.
Richard D. Brown [Page 20]
INTERNET-DRAFT November 1998 Digital Signatures for XML
5.14 OriginatorInfo
The OriginatorInfo element is used for providing identification and
keying material information for the originator.
<!ELEMENT dsig:OriginatorInfo (
dsig:Identifier | dsig:IssuerAndSerialNumber
)>
<!ATTLIST dsig:OriginatorInfo
xmlns:disg PCDATA #FIXED %xmldsig.dtd;
>
Content Description
Identifier: Free form identification that could be used when a
prior relationship exists between the parties. The actual
content of this element is left to the parties and may
consist of such things as an account number, a key
identifier, or a combination of both.
IssuerAndSerialNumber: Unique reference to a certificate, and
thereby to an entity and a public key, by means of an issuer
distinguished name and issuer-specific serial number.
5.15 RecipientInfo
The RecipientInfo element is used for providing identification and
keying material information for the recipient. This element is used
either for enabling recognition of a Signature element by a given
recipient or when determination of the authentication key consists of
the combination of keying material provided by both the recipient and
the originator.
Content Description
DigestAlgorithms: lgorithms to be used for computation of the
fingerprint.
Value: Encoding of the fingerprint value.
5.16 OriginatorInfo
The OriginatorInfo element is used for providing identification and
keying material information for the originator.
Richard D. Brown [Page 21]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<!ELEMENT dsig:OriginatorInfo (
dsig:Identifier | dsig:IssuerAndSerialNumber
)>
<!ATTLIST dsig:OriginatorInfo
xmlns:disg PCDATA #FIXED %xmldsig.dtd;
>
Content Description
Identifier: Free form identification that could be used when a
prior relationship exists between the parties. The actual
content of this element is left to the parties and may
consist of such things as an account number, a key
identifier, or a combination of both.
IssuerAndSerialNumber: Unique reference to a certificate, and
thereby to an entity and a public key, by means of an issuer
distinguished name and issuer-specific serial number.
5.17 RecipientInfo
The RecipientInfo element is used for providing identification and
keying material information for the recipient. This element is used
either for enabling recognition of a Signature element by a given
recipient or when determination of the authentication key consists of
the combination of keying material provided by both the recipient and
the originator.
Content Description
The content of this element is similar to the one defined for the
originator (cf. OriginatorInfo element description).
5.18 Identifier
The Identifier element enables identification between parties that
benefit from a prior relationship. The actual meaning and content of
this element is left to the parties.
<!ELEMENT dsig:Identifier EMPTY>
<!ATTLIST dsig:Identifier
xmlns:disg CDATA #FIXED %xmldsig.dtd;
value CDATA #REQUIRED
>
Richard D. Brown [Page 22]
INTERNET-DRAFT November 1998 Digital Signatures for XML
Attributes Description
value: Identification data value.
5.19 IssuerAndSerialNumber
The IssuerAndSerialNumber element identifies a certificate, and
thereby an entity and a public key, by the distinguished name of the
certificate issuer and an issuer-specific certificate serial number.
<!ELEMENT dsig:IssuerAndSerialNumber EMPTY >
<!ATTLIST dsig:IssuerAndSerialNumber
xmlns:disg CDATA #FIXED %xmldsig.dtd;
issuer CDATA #REQUIRED
number CDATA #REQUIRED
>
Attributes Description
issuer: Distinguished name of the issuing certification
authority.
number: Issuer-specific certificate serial number. The type of
this serial number (cf. element description) does not need to
be specified. However, if present, the adequate value shall
be used.
5.20 Attributes
The Attributes element consists of a collection of complementary
attributes, which shall be included in the authenticated part of the
document.
<!ELEMENT dsig:Attributes ( dsig:Attribute+ )>
<!ATTLIST dsig:Attributes
xmlns:disg PCDATA #FIXED %xmldsig.dtd;
>
Content Description
Attribute: Collection of Attribute elements.
Richard D. Brown [Page 23]
INTERNET-DRAFT November 1998 Digital Signatures for XML
5.21 Attribute
The Attribute element consists of a complementary piece of
information, which shall be included in the authenticated part of the
document. Though the current draft proposal defines well-known
attributes, this element has been defined primarily for enabling some
level of customization in the signature element. An Attribute element
consists of a value, a type, and a criticality.
<!ELEMENT dsig:Attribute ANY>
<!ATTLIST dsig:Attribute
xmlns:disg CDATA #FIXED %xmldsig.dtd;
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED 'false'
>
Content Description
ANY: The actual value of an attribute depends solely upon its
type.
Attributes Description
type: Type of the attribute. In order to prevent potential
conflict in the definition of the attribute types, this draft
proposal makes use of Universal Resource Names[x].
critical: Boolean value that indicates if the attribute is
critical (true) or not (false). A recipient shall reject a
signature that contains a critical attribute that he does not
recognize. However, an unrecognized non-critical attribute
may be ignored.
Signing-time Attribute
Standard attribute that could be used for specifying the time at
which the originator purportedly performed the signature process.
This attribute content shall be given as a Date element (cf.
element description). The type identifier of this attribute is
given in the URN appendix.
5.22 Date
The Date element consists of a constrained ISO 8601:1998 date and
time value.
Richard D. Brown [Page 24]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<!ELEMENT dsig:Date EMPTY>
<!ATTLIST dsig:Date
xmlns:disg CDATA #FIXED %xmldsig.dtd;
value CDATA #REQUIRED
>
Attributes Description
value: Identification data value.
Date Format
The current draft proposal requires date values to be expressed
according to the following pattern: YYYY '-' MM '-' DD 'T' hh
':' mm [':' ss ['.' f+]]('+' | '-') hhmm
YYYY: four-digit year
MM: two-digit month (01=January, etc.)
DD: two-digit day of the month (01-31)
hh: two digits of hour (00-23)
mm: two digits of minute (00-59)
ss: two digits of second (00-59) optional
f: digit(s) of fractions of second - optional
zzzz: four digits of amount of offset from UTC expressed in hour
(00-11) and minute (00-59)
For example "1994-11-05T16:15:02.031-0500" denotes November 5,
1994, 4:15:02 pm and 31 milliseconds, US Eastern Standard
Time.
5.23 SignatureAlgorithms
The SignatureAlgorithms element is used for specifying the algorithms
to be used for computation of the signature value.
<!ELEMENT dsig:SignatureAlgorithms (
dsig:Canonicalizer,
dsig:KeyAgreementAlgorithm?,
dsig:SignatureAlgorithm
)>
<!ATTLIST dsig:SignatureAlgorithms
xmlns:dsig PCDATA #FIXED %xmldsig.dtd;
>
Content Description
Richard D. Brown [Page 25]
INTERNET-DRAFT November 1998 Digital Signatures for XML
Canonicalizer: Algorithm to be used for normalizing the content
to be authenticated (cf. Supported Algorithms).
KeyAgreementAlgorithm: Optional algorithm that could be used for
deriving a one-time session key from an established master
key (cf. Supported Algorithms).
SignatureAlgorithm: Algorithm to be used for computation of the
signature value (cf. Supported Algorithms).
5.24 Certificates
The Certificates element consists of a collection of Certificate
elements. The Certificate elements contained in this element are
intended to be sufficient to make chains from the originator
credential(s) to a recognized "certification authority" for all the
recipients. However, this element may contain more Certificate
elements than necessary or, alternatively, less than necessary if it
is known that recipients have an alternate means of obtaining
necessary certificates.
<!ELEMENT dsig:Certificates ( dsig:Certificate+ )>
<!ATTLIST dsig:Certificates
xmlns:dsig CDATA #FIXED %xmldsig.dtd;
>
Content Description
Certificate: A collection of Certificate elements.
5.25 Certificate
The Certificate element may be used for either providing the value of
a digital certificate or specifying a location from where it may be
retrieved.
<!ELEMENT dsig:Certificate (
dsig:IssuerAndSerialNumber,
( dsig:Value | dsig:Locator )
)>
<!ATTLIST dsig:Certificate
xmlns:disg CDATA #FIXED %xmldsig.dtd;
type NMTOKEN #REQUIRED
>
Richard D. Brown [Page 26]
INTERNET-DRAFT November 1998 Digital Signatures for XML
Content Description
IssuerAndSerialNumber: Unique identifier of this certificate. This element
has been made mandatory is order to prevent
unnecessary decoding during validation of a
certificate chain. This feature also helps
certificates caching, especially when the value
is not directly provided.
Value: Encoding of the certificate value. The actual
value to be encoded depends upon the type of
the certificate (cf. Certificate Supplement).
Locator: XML link element that could be used for
retrieving a copy of the digital certificate. The
actual value being returned by means of this
locator depends upon the protocol being used
(i.e. http versus ldap) (cf. Certificate
Supplement).
Attributes Description
type: Type of the digital certificate. This attribute is
specified as a Universal Resource Name (cf.
Certificate Supplement).
5.26 Resources
The Resources element consists of a collection of Resource elements.
Though inaccessible from the Document element of the Signature DTD, this
element is available to more sophisticated constructs that make use of com-posite
documents.
<!ELEMENT dsig:Resources ( dsig:Resource+ )>
<!ATTLIST Resources
xmlns:disg CDATA #FIXED %xmldsig.dtd;
dsig:hash IDREF #IMPLIED
id ID #IMPLIED
>
Content Description
Resource: A collection of Resource elements. Attributes
Description
id: Element identifier that could be used for referencing this
element from a Resource element.
Richard D. Brown [Page 27]
INTERNET-DRAFT November 1998 Digital Signatures for XML
6. Supported Algorithms
6.1 Algorithm Definition
6.2 Canonicalizers
IBM DOMHASH
GLOBESET XHASH
6.3 Digest Algorithms
SHA1
6.4 Key-agreement Algorithms
RSA-PKCS12-PBE
6.5 Signature Algorithms
HMAC
DSA
RSA-PKCS1
ECCDSA
6.6 Base64 Comments
Segmentation at 76 characters made mandatory.
7. Supported Content Type
Leveraging MIME Types
Richard D. Brown [Page 28]
INTERNET-DRAFT November 1998 Digital Signatures for XML
Non-MIME Types
8. Certificate Supplement
Locator Protocols (HTTP, LDAP)
Certificate Type URNs
Expected Formats
9. Conformance Requirements
TBD
10. Examples
The URN given in the following examples are purely illustrative and,
therefore, shall not be used as reference material.
10.1 Signature DTD - Embedded Content
<?xml version="1.0"?>
<!DOCTYPE dsig:Document PUBLIC "urn:org-w3c:xmldsig.dtd"
SYSTEM "http://www.w3c.org/dtd/xmldsig.dtd"
>
<dsig:Document>
<dsig:DigestAlgorithms id="digest-algorithms">
<dsig:Canonicalizer>
<dsig:Algorithm type="urn:com-globeset:xhash"/>
</dsig:Canonicalizer>
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</DigestAlgorithms>
<dsig:Package id="data" dsig:hash="#digest-algorithms">
<dsig:ContentType type="urn:mime:application-msword"/>
<dsig:Value encoding="base64">
abncjflf311257gghn6mj2k134h64AANHdd12==
</dsig:Value>
</dsig:Package>
<dsig:Signatures>
Richard D. Brown [Page 29]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<dsig:Signature>
<dsig:Manifest>
<dsig:Resource>
<dsig:Locator href="#data"/>
<dsig:Digest>
<dsig:DigestAlgorithms>
<dsig:Canonicalizer>
<dsig:Algorithm type="urn:com-globeset:xhash"/>
</dsig:Canonicalizer>
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</DigestAlgorithms>
<dsig:Value encoding="base64">
bndWGryrt245u6t1dgURTIrr4ir5=
</dsig:Value>
</dsig:Digest>
</dsig:Resource>
<dsig:OriginatorInfo>
<dsig:IssuerAndSerialNumber
issuer="o=GlobeSet Inc., c=US"
number="123456789102356"
/>
</dsig:OriginatorInfo>
<dsig:Attributes>
<dsig:Attribute
type="urn:org-w3c:xmldsig.signing-time"
>
<dsig:Date value="1998-10-29T13:26-0500"/>
</dsig:Attribute>
</dsig:Attributes>
<dsig:SignatureAlgorithms>
<dsig:Canonicalizer>
<dsig:Algorithm type="urn:com-globeset:xhash"/>
</dsig:Canonicalizer>
<dsig:SignatureAlgorithm>
<dsig:Algorithm type="urn:com-rsa:rsa-pkcs1">
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</dsig:Algorithm>
</dsig:SignatureAlgorithm>
</dsig:SignatureAlgorithms>
</dsig:Manifest>
<dsig:Value encoding="base64">
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
</dsig:Value>
</dsig:Signature>
</dsig:Signatures>
<dsig:Certificates>
Richard D. Brown [Page 30]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<dsig:Certificate type="urn:X500:X509v3">
<dsig:IssuerAndSerialNumber
issuer="o=GlobeSet Inc., c=US"
number="123456789102356"
/>
<dsig:Locator href="http://certs.globeset.com/smith.der"/>
</dsig:Certificate>
</dsig:Certificates>
</dsig:Document>
10.2 Signature DTD - Detached Signature
<?xml version="1.0"?>
<!DOCTYPE dsig:Document PUBLIC "urn:org-w3c:xmldsig.dtd"
SYSTEM "http://www.w3c.org/dtd/xmldsig.dtd"
>
<dsig:Document>
<dsig:Signatures>
<dsig:Signature>
<dsig:Manifest>
<dsig:Resource>
<dsig:ContentType type="urn:mime:application-msword"/>
<dsig:Locator href="http://www.globeset.com/xml.doc"/>
<dsig:Digest>
<dsig:DigestAlgorithms>
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</DigestAlgorithms>
<dsig:Value encoding="base64">
bndWGryrt245u6t1dgURTIrr4ir5=
</dsig:Value>
</dsig:Digest>
</dsig:Resource>
<dsig:OriginatorInfo>
<dsig:IssuerAndSerialNumber
issuer="o=GlobeSet Inc., c=US"
number="123456789102356"
/>
</dsig:OriginatorInfo>
<dsig:Attributes>
<dsig:Attribute
type="urn:org-w3c:xmldsig.signing-time"
>
<dsig:Date value="1998-10-29T13:26-0500"/>
</dsig:Attribute>
</dsig:Attributes>
<dsig:SignatureAlgorithms>
Richard D. Brown [Page 31]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<dsig:Canonicalizer>
<dsig:Algorithm type="urn:com-globeset:xhash"/>
</dsig:Canonicalizer>
<dsig:SignatureAlgorithm>
<dsig:Algorithm type="urn:com-rsa:rsa-pkcs1">
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</dsig:Algorithm>
</dsig:SignatureAlgorithm>
</dsig:SignatureAlgorithms>
</dsig:Manifest>
<dsig:Value encoding="base64">
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
</dsig:Value>
</dsig:Signature>
</dsig:Signatures>
<dsig:Certificates>
<dsig:Certificate type="urn:X500:X509v3">
<dsig:IssuerAndSerialNumber
issuer="o=GlobeSet Inc., c=US"
number="123456789102356"
/>
<dsig:Locator href="http://certs.globeset.com/smith.der"/>
</dsig:Certificate>
</dsig:Certificates>
</dsig:Document>
10.3 Extended DTD - Domain-specific Attribute
<?xml version="1.0"?>
<!DOCTYPE Document PUBLIC "urn:org-w3c:xmldsig.dtd"
SYSTEM "http://www.w3c.org/dtd/xmldsig.dtd" [
<!ELEMENT MyDocument (
dsig:Resources, dsig:Signature
)>
<!ELEMENT AssetCategory EMPTY>
<!ATTLIST AssetCategory
type PCDATA #REQUIRED
>
]>
<MyDocument>
<dsig:Resources id="data">
<dsig:Resource>
<dsig:ContentType type="urn:com-globeset:demo-invoice"/>
<dsig:Locator href="http://www.globeset.com/invoice.xml"/>
<dsig:Digest>
<dsig:DigestAlgorithms>
Richard D. Brown [Page 32]
INTERNET-DRAFT November 1998 Digital Signatures for XML
<dsig:Canonicalizer>
<dsig:Algorithm type="urn:com-globeset:xhash"/>
</dsig:Canonicalizer>
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</DigestAlgorithms>
<dsig:Value encoding="base64">
bndWGryrt245u6t1dgURTIrr4ir5=
</dsig:Value>
</dsig:Digest>
</dsig:Resource>
<dsig:Resource>
<dsig:ContentType type="urn:com-globeset:demo-receipt"/>
<dsig:Locator href="http://www.globeset.com/receipt.xml"/>
<dsig:Digest>
<dsig:Canonicalizer>
<dsig:Algorithm type="urn:com-globeset:xhash"/>
</dsig:Canonicalizer>
<dsig:DigestAlgorithms>
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</DigestAlgorithms>
<dsig:Value encoding="base64">
bndWGryrt245u6t1dgURTIrr4ir5=
</dsig:Value>
</dsig:Digest>
</dsig:Resource>
</dsig:Resources>
<dsig:Signature>
<dsig:Manifest>
<dsig:Resource>
<dsig:Locator href="#data"/>
<dsig:Digest>
<dsig:DigestAlgorithms>
<dsig:Canonicalizer>
<dsig:Algorithm type="urn:com-globeset:xhash"/>
</dsig:Canonicalizer>
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</DigestAlgorithms>
<dsig:Value encoding="base64">
bndWGryrt245u6t1dgURTIrr4ir5=
</dsig:Value>
</dsig:Digest>
</dsig:Resource>
<dsig:OriginatorInfo>
<dsig:Identifier value="smith"/>
Richard D. Brown [Page 33]
INTERNET-DRAFT November 1998 Digital Signatures for XML
</dsig:OriginatorInfo>
<dsig:Attributes>
<dsig:Attribute
type="urn:com-globeset:asset-category"
critical="true"
>
<AssetCategory type="HDW325DPT7896"/>
</dsig:Attribute>
</dsig:Attributes>
<dsig:SignatureAlgorithms>
<dsig:Canonicalizer>
<dsig:Algorithm type="urn:com-globeset:xhash"/>
</dsig:Canonicalizer>
<dsig:SignatureAlgorithm>
<dsig:Algorithm type="urn:com-rsa:rsa-pkcs1">
<dsig:DigestAlgorithm>
<dsig:Algorithm type="urn:fips:sha1"/>
</dsig:DigestAlgorithm>
</dsig:Algorithm>
</dsig:SignatureAlgorithm>
</dsig:SignatureAlgorithms>
</dsig:Manifest>
<dsig:Value encoding="base64">
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
</dsig:Value>
</dsig:Signature>
</MyDocument>
11. Signature DTD
(Insert here)
12. Security Considerations
The entirety of this document is concerned with a signature standard
for XML.
Richard D. Brown [Page 34]
INTERNET-DRAFT November 1998 Digital Signatures for XML
References
draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett
[more to be added]
Author's Address
Richard D. Brown
GlobeSet, Inc.
1250 Capital of TX Hwy. So.
Building One, Suite 300
Austin, TX 78746 USA
EMail: richard_dbrown@globeset.com
Expiration and File Name
This draft expires May 1999.
Its file name is draft-ietf-trade-xml-sig-00.txt.
Richard D. Brown [Page 35]
| PAFTECH AB 2003-2026 | 2026-04-24 06:09:28 |