[1]IETF Logo [2]W3C Logo
[1] http://www.ietf.org/
[2] http://www.w3.org/
[3]XML-Signature Core Syntax
[3] http://www.w3.org/Signature
W3C Working Draft 1999-October-01
This Working Draft version:
[4]http://www.w3.org/Signature/Drafts/xmldsig-core-99100
1.html
[4] http://www.w3.org/Signature/Drafts/xmldsig-core-991001.html
Previous Working Group version:
[5]http://www.w3.org/Signature/Drafts/xmldsig-core-99092
2.html
[5] http://www.w3.org/Signature/Drafts/xmldsig-core-990922.html
Editor(s):
...
Author(s)
...
[6]dsolo@alum.mit.edu
[7]reagle@w3.org (990922)
[8]mbartel@JetForm.com (991006)
[6] mailto:dsolo@alum.mit.edu
[7] mailto:reagle@w3.org
[8] mailto:mbartel@JetForm.com
[9]Copyright © 1999 [10]The Internet Society & [11]W3C
([12]MIT, [13]INRIA, [14]Keio), All Rights Reserved. W3C
[15]liability, [16]trademark, [17]document use and [18]software
licensing rules apply.
[9] http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright
[10] http://www.ietf.org/
[11] http://www.w3.org/
[12] http://www.lcs.mit.edu/
[13] http://www.inria.fr/
[14] http://www.keio.ac.jp/
[15] http://www.w3.org/Consortium/Legal/ipr-notice.html#LegalDisclaimer
[16] http://www.w3.org/Consortium/Legal/ipr-notice.html#W3CTrademarks
[17] http://www.w3.org/Consortium/Legal/copyright-documents.html
[18] http://www.w3.org/Consortium/Legal/copyright-software.html
W3C Status of this Document
This document includes updates from the [19]990922 draft based
on the results of [20]990930 teleconference (and any resulting
email discussion). The goal is to get some version of this
document out as an ietf-draft and W3C technical report as soon
as possible. This draft covers most of the topics the final
specification will cover, however the text and syntax within
this specification is unstable.
[19] http://www.w3.org/Signature/Draft/xmldsig-core-990922.html
[20] http://www.w3.org/Signature/Minutes/990930-tele.html
Abstract
This document lists the core signature syntax.
Table of Contents
...
1.0 Introduction
This document describes the proposed syntax and processing
rules for the XML Digital Signature specification. This
specification provides a mechanism for applying digital
signatures to XML documents and other Internet resources.
The structure allows for both embedded and detached signatures.
An embedded signature can include the signature within the
signed object or embed the signed object within the signature.
A detached signature allows the signature to be independent of
the object. The processing structure allows for switching
between embedded and detached signatures without invalidating
the signature.
In addition to the basic signature document type, this document
also defines other useful types including a methods of
referencing multiple resources and key management and algorithm
definitions.
Editorial Comment: Presently most of this work is unspecified.
The working group needs to define things like manifest and
algorithm definitions more explicitly.
1.1 Editorial Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [RFC2119].
The XML namespace [[21]XML-namespace] URI that MUST be used by
experimental implementations of this dated specification is:
xmlns="http://www.w3.org/Signature/core-19990922"
While applications MUST support XML-namespaces, the use of our
"dsig" XML [22]namespace prefix and defaulting/scoping
conventions are OPTIONAL -- we use these facilities so as to
provide compact and readable examples.
[22] http://www.w3.org/TR/1999/REC-xml-names-19990114#dt-prefix
The URI in the namespace declaration above is also used as a
prefix for URIs which identify resources, algorithms, or
semantics under control of this specification. We use MIME
types to identify algorithithms, resources, or their
characteristics under the control of IANA. Otherwise we define
a URN Namespace Identifier of "dsig:" urn:dsig:signedattributes
[[23]RFC2141].
Editorial Comment: This mixed use of identification requires
further thought as it is confusing as presently specified and
used. The WG has not taken any steps to register the "urn:dsig"
namespace.
This document includes the following abbreviations for long
words. (The acronyms are generated by wrapping the
word_length-2 in the first and last letter):
* c14n: canonicalization
* i18n: internationalization
Finally, this document also includes editorial comments
(highlighted in a light tan wit a blue border) that point out
open issues the WG has not yet closed. Readers unfamiliar with
DTD syntax may wish to refer to Ron Bourret's "[24]Declaring
Elements and Attributes in an XML DTD."
[24] http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/xmldtd.html
1.2 Design Philosophy
The design philosophy and requirements of this specification
are addressed in the XML-Signature Requirements document
[[25]XML-Signature-RD]. However, a few of the key philosphy
axioms are repeated. This specification endeavors to rely upon
the syntax -- and the underlying data model -- to represent the
functionality and structure of a signature where ever possible.
One way this is manifested is by the use URIs to define the
relationships between a signature and its context (its
constituent parts, the objects it signs, the algorithms it
employs, etc.). This philosophy is best captured by the idea
that of "if you make statements about statements, signature is
merely one type of statement " This allows us to clearly (and
perhaps formally) define the meaning of a signature and how
that meaning interacts with the semantics of the content it
signs. One way this is manifested is in the choice of the WG to
avoid things like:
<attribute type="CDATA" and value="CDATA"/>
Instead, if applications need to associate external semantics
for key exchange or trust processing they must introduce a set
of qualified namespace [[26]XML-namespace] application elements
with clearly defined semantics, or they must make a statement
about an existing resource within some data model.
Editorial Comment: The syntax defined in this document is not
yet associated with a directed labeled graph data model --
which is a requirement the WG has not yet met. The WG has
decided not to use the RDF serialization syntax. Some WG
members have advocated using a "striped" XML syntax whereby the
structure and nesting of the XML can be read as {resource,
predicate, value} triples. Unfortunately, this can result in
superfluous syntax. The WG is investigating syntactical
alternative and the use of a schema definition to bind a
formally specified data model to an XML syntax that is
intuitive and compact.
2.0 Signature Structure
The general structure of an XML signature includes the
following elements:
* SignedInfo is the actual data over which the signature is
calculated. It contains control information (algorithm
identifiers, pre-processing transformations) and digest(s)
over the object(s) being signed.
* SignatureValue is an [27]empty-element tag [[28]XML] that
contains the actual value of the digital signature.
* KeyInfo is an optional element which enables the
recipient(s) to obtain the key(s) needed to validate the
signature.
* Object is an optional element wherein applications may
place (embed) content through use of the XML-namespace
facility. [[29]XML-namespace]
<!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?,
Object*)>
<!ATTLIST SignedInfo
Id ID #IMPLIED>
A simple example follows:
<Signature xmlns="http://www.w3.org/Signature/core-19990922">
<SignedInfo>
<c14nAlg Algorithm="null"/>
<SignatureAlg algorithm="dsig:rsaWithSHA-1"/>
<ObjectReference> ;one might use the manifest or package
container here
<Location HREF="http://www.iet.org"/>
<Type>text/html; charset="us-ascii"</Type>
<DigestAlg Algorithm="sha-1"/>
<DigestValue Value="a23bcd43" />
</ObjectReference>
</SignedInfo>
<SignatureValue
encoding="urn:dsig:base64">dd2323dd</SignatureValue>
<KeyInfo>
<keyname>Solo</keyname>
</keyinfo>
</Signature>
3.0 SignatureValue
SignatureValue is an [30]empty-element tag [[31]XML] that
contains the actual value of the digital signature. The ability
to define a SignatureAlg and SignatureValue pair which includes
multiple distinct signatures is explicitly permitted (e.g.
"rsawithsha-1 and ecdsawithsha-1").
<!ELEMENT SignatureValue CDATA)>
<!-- base64 encoded signature value -->
<!ATTLIST SignatureValuee
encoding CDATA "urn:dsig:base64">
4.0 SignedInfo
The structure of SignedInfo includes a canonicalizatin (c14n)
algorithm, a signature algorithm, and one or more references to
objects. The SignedInfo element may contain an optional ID
attribute that will allow it to be referenced by other
signatures and objects.
<!ELEMENT SignedInfo(c14nAlg?, SignatureAlg, ObjectReference+
)>
<!ATTLIST SignedInfo
Id ID #IMPLIED>
SignedInfo does not include explicit signature attributes (in
the traditional cryptographic sense). If an application needs
to associate semantics (such as signing time, signing device,
etc.) with the signature, it may add an additional Object that
includes those semantics and reference that Object via an
ObjectReference.
4.1 c14nAlg (Canonicalization)
c14nAlg is an optional element which specifies the
canonicalization (c14n) algorithm applied to the SignedInfo
element prior to performing signature calculations. This
element uses the general structure here for algorithms in which
an URI is included as an attribute naming the algorithm and
optional contents of the element contain any parameter, value,
or other information defined by the algorithm name. Possible
options may include a null algorithm (no changes), a simple
identity algorithm (CRLF and charset normalization), or more
extensive operations such as [[32]XML-C14N].
<!ELEMENT c14nAlg ANY>
<!ATTLIST c14nAlg
Algorithm CDATA "null">
<!-- Where CDATA conforms to the
productions specified by [URI] -->
4.2 SignatureAlg
SignatureAlg is a required element which specifies the
algorithm used for signature generation and validation. This
algorithm ID identifies all cryptographic functions involved in
the signature operation (e.g. hashing, public key algorithms,
MACs, etc.). This element uses the general structure here for
algorithms in which a URI is included as an attribute naming
the algorithm and optional contents of the element contain any
parameter, value, or other information defined by the algorithm
name. While there is a single identifier, that identifier may
specify a format containing multiple distinct signature values.
<!ELEMENT SignatureAlg ANY>
<!ATTLIST SignatureAlg
Algorithm CDATA #REQUIRED >
<!-- Where CDATA conforms to the
productions specified by [URI] -->
4.3 ObjectReference
ObjectReference is an element that may occur one or more
times. It includes a URI, the type of the object, specified
transformations, a digest algorith and digest value. Note, it
is the content yielded after the URI is dereferenced, decoded,
and transformed that the digest algorithm is applied to.
<!ELEMENT ObjectReference (Location?, Type?, Transformations?,
DigestAlg, DigestValue) >
4.3.1 Location
Location identifies where to find the Object . This element may
be omitted if the location is implicit in the application.
<!ELEMENT Location EMPTY >
<!ATTLIST Location
HREF CDATA #IMPLIED >
<!-- Where CDATA conforms to the
productions specified by [URI] -->
Editorial Comment: WG's members feel that an optional Location
is necessary for closed model signature applications that
implicitly know what the referant is based on its processing
context. However, these applications abuse the notion of the
open Web model and their signature will be of no utility
outside their own closed domain.
4.3.2 Type
;do week keep the type in the reference and object? Or only
place it in one place. -JR
; still under specified. Also, mixing the MIME type and URI's
seems awkard. Maybe we need <Type owner="IANA"> or <Type
owner="W3C"> etc.
Type is an optional element which contains information about
the type of object being signed (e.g. manifest, package,
document, SignedInfo, PDF file). This may be represented as a
name (e.g. MIME type), or URI.
<!ELEMENT Type (ANY | #PCDATA) >
<!-- where PCDATA conforms to the productions specified for
the
content of a Content-Type MIME header [RFC 2045] or is
a namespace qualified element name -->
Type is an optional element which contains information about
the type of object being signed (e.g. manifest, package,
document, SignedInfo, PDF file). This may be represented as a
name (e.g. MIME type), or URI. For example:
<Type>text/plain; charset="us-ascii"</Type>
<Type>http://www.w3.org/Signature/1999/07/cert</Type>
<Type>urn:dsig:signedattributes</Type>
4.3.3 Transformations
Transformations is an optional element that contains one or
more operations to be performed on the Object prior to
signature calculation. Examples of Transformations include
encoding, c14n, XPointer, XSL, filtering, encoding, etc. (These
operations are different from those specified in the signature;
those are are applied over signedinfo.)
Each element within Transformations uses the general structure
here for algorithms in which a URI is included as a value
specifying the algorithm and optional contents of the element
contain any parameter, value, or other information defined by
the algorithm name. If the Transformations element is omitted,
the only operation performed is the default object c14n
algorithm (null or identity).
<!ELEMENT Transformations ((Generic | c14nAlg? | Encoding? |
XSLT?
Stylesheet? | XPointer?)*) >
<!ELEMENT Generic EMPTY >
<!ATTLIST Generic
Algorithm CDATA #REQUIRED >
<!-- While not necessary because of the Generic, we
define a few specific transformation types.
<!ELEMENT Encoding EMPTY >
<!ATTLIST Encoding
Algorithm CDATA #REQUIRED >
<!ELEMENT c14nAlg EMPTY >
<!ATTLIST c14nAlg
Algorithm CDATA #REQUIRED >
<!ELEMENT XSLT EMPTY >
<!ATTLIST XSLT
Algorithm CDATA #REQUIRED >
<!ELEMENT Stylesheet EMPTY >
<!ATTLIST Stylesheet
Algorithm CDATA #REQUIRED >
<!ELEMENT XPointer EMPTY >
<!ATTLIST XPointer
Algorithm CDATA #REQUIRED >
<!-- Where CDATA conforms to the
productions specified by [URI] -->
Implementation Comment: When transformations are applied the
signer is not signing the native (original) document but the
resulting (transformed) document that is not captured
explicitly in the signature syntax. Where transformation
processes are well known and widely implemented an application
might include native content and specify transformations by
reference. Otherwise, an application may perform
transformations on the content itself and use the resulting
content within the signature.
Security Comment: Applications are recommended to ensure
signers understand the actual resulting content that is being
signed after transformations are applied. Users should not be
tricked into signing a native content that is transformed into
something that the user would not have signed otherwise. This
recommendation applied to transformations specified in the
signature block, as well as transformations found within the
document itself.
4.3.4 DigestAlg
DigestAlg is a required element which identifies the digest
algorithm to be applied to the signed object. This element uses
the general structure here for algorithms in which a URI is
included as an attribute naming the algorithm and optional
contents of the element contain any parameter, value, or other
information defined by the algorithm name.
<!ELEMENT DigestAlg ANY>
<!ATTLIST DigestAlg
Algorithm CDATA #REQUIRED >
<!-- Where CDATA conforms to the
productions specified by [URI] -->
4.3.5 digestvalue
digestvalue is a required [33]empty-element tag which contains
the base64 encoded value of the digest.
<!ELEMENT DigestValue EMPTY>
<!-- base64 encoded digest value -->
<!ATTLIST DigestValue
value CDATA #REQUIRED >
5.0 Object
. When present this element may contain any item and specifies
the encoding. It is important to note that the content of the
Object itself is not part of the hash algorithm over the
signature.
<!ELEMENT Object ANY>
<!ATTLIST Object
Id CDATA #IMPLIED
Type CDATA #IMPLIED
Encoding CDATA #IMPLIED >
<!-- Where type and encoding CDATA conforms to the
productions specified by [URI] -->
; Define what is meant by type, define the types. Also, do we
allow duplication in reference and object? Does the reference
type refer to the type of the Object tag, which will always be
XML. Don should tweak. -JR
Object is an optional element which may occur one or more
times. The purpose of Object element is to wrap elements
defined by any XML application as introduced through the
namespace [[34]XML-namespace] facility. For instance, the
following Object references a timestamp document that is
defined by some other specification.
<Object id="timestamp1" Type="signatureattributes" > ;who
defined this type?
<timestamp xmlsn="http://www.ietf.org/rfc/1234">
<date>19990908</date>
<time>14:34:34:34</time>
</timestamp>
</Object>
The Object's ID is referenced from the ObjectReference in
SignedInfo. This element is used for embedded signatures where
the object being signed is to be included in the signature
document. The Object element may include optional type, ID, and
encoding attributes. Note there is nothing that prevents these
other XML applications from referencing and making statements
about signatures.
<!ELEMENT Object ANY>
<!ATTLIST Object
id CDATA #IMPLIED
type CDATA #IMPLIED
encoding CDATA #IMPLIED >
6.0 KeyInfo
KeyInfo may contain keys, names, certificates and other public
key management information (such as inband key distribution or
agreement data or use any other method.) This specification
defines a few simple types but applications may place (embed)
their own key identification and exchange semantics within this
element through the XML-namespace facility. [[35]XML-namespace]
<!ELEMENT KeyInfo (ANY | (KeyName | KeyValue |
SubjectName | RetrievalMethod | x509Data |
PGPData | MgmtData)* )>
KeyInfo is an optional element which enables the recipient(s)
to obtain the key(s) needed to validate the signature. If
omitted, the recipient is expected to be able to identify the
key based on application context information. This element
contains one or more KeyInfo data elements providing
information for the recipient(s). Applications may define and
use any mechanism they choose through inclusion of elements
from a different namespace.
* KeyName contains an identifier for the key which may be
useful to the recipient. This may be a name, index, etc.
* KeyValue contains the actual key(s) used to validate the
signature. If the key is sent in protected form, the
MgmtData element should be used. Specific types must be
defined for each algorithm type (see algorithms).
* SubjectName contains one or more names for the sender.
Forms to be supported include a simple name string, encoded
DN, email address, etc.
* RetrievalMethod is a URI which may be used to obtain key
and/or certificate information. The URI should contain the
complete string for retrieving the key needed for this
message (rather than a generic URI).
* X509Data contains an identifier of the key/cert used for
validation (either an issuerserial value, a subject name,
or a subjectkeyID) and an optional collection of
certificates and revocation/status information which may be
used by the recipient. issuerserial contains the encoded
issuer name (RFCxxxx) along with the serial number.
* PGPData data associated with a PGP key.
* MgmtData contains in-band key distribution or agreement
data. Examples may include DH key exchange, RSA key
encryption etc.
<!ELEMENT KeyName (#PCDATA)>
<!ELEMENT KeyValue (#PCDATA)>
<!ELEMENT SubjectName (#PCDATA)>
<!ELEMENT RetrievalMethod (#PCDATA)>
<!ELEMENT X509Data (#PCDATA)>
<!ELEMENT MgmtData (#PCDATA)>
7.0 Algorithms
This sections identifies algorithms used with the XML digital
signature standard. Entries contain the identifier to be used
in signature documents, a reference to the formal
specification, and definitions, where applicable, for the
representation of keys and the results of cryptographic
operations.
7.1 Algorithm Identifiers and Requirements
The specification defines the following URNs that are
associated with algorithms we employ. Requirements are
specified over implementation, not requirements for signature
use.
Algorithm Type Algorithm Requirements Algorithm URI URN
Derivation
Digest
SHA1 REQUIRED urn:nist-gov:sha1 IOTP
MD5 RECOMMENDED urn:rsasdi-com:md5 extrapolated from IOTP
AESH (forthcoming) urn:nist-gov:aesh IOTP
MAC
HMAC-SHA1 REQUIRED urn:ietf-org:hmac-sha1 extrapolated from
IOTP
HMAC-MD5 OPTIONAL urn:ietf-org:hmac-md5 extrapolated from
IOTP
Signature
DSAwithSHA1 (DSS) REQUIRED urn:nist-gov:dsa IOTP
RSAwithSHA1 RECOMMENDED urn:rsasdi-com:rsa-sha1 extrapolated
from IOTP
RSAwithMD5 OPTIONAL urn:rsasdi-com:rsa-md5 extrapolated from
IOTP
ECDSA (forthcoming) urn:nist-gov:ecdsa extrapolated from IOTP
Canonicalization
:null REQUIRED http://www.w3.org/Signature/core-19990922/null
suggested W3C
:minimal REQUIRED
http://www.w3.org/Signature/core-19990922/minimal suggested W3C
XML-c14n RECOMMENDED
[36]http://www.w3.org/1999/07/WD-xml-c14n-19990729 W3C
DOM-c14n RECOMMENDED urn:ietf-org:dom-xml-canonicalization
suggested
Transformation
XPointer REQUIRED
[37]http://www.w3.org/1999/07/WD-xptr-19990709 W3C
[36] http://www.w3.org/1999/07/WD-xml-c14n-19990729.html
[37] http://www.w3.org/1999/07/WD-xptr-19990709
; I have attempted to match the URN scheme of IOTP. Some URNs
were pulled directly from IOTP. The urn:rsasdi-com:*,
urn:ietf-org:hmac-*, and urn:nist-gov:ecdsa URNs were
extrapolated from urn:rsasdi-com:rsa-encryption,
urn:ietf-org:hmac, and urn:nist-gov:dsa, respectively, in IOTP.
For the other URNs, I alternated ietf-org and w3-org
(presumably we would pick one). -MB
; URN namespace definition is discussed in [38]RFC 2611. As far
as I can tell, there are no registered namespaces. Therefore,
rather than attempting the scheme above which has many urn
namespaces, I would suggest we either prompt the ieft or w3c to
define a namespace and then hang everything off of that, or
just define a namespace for this standard. The first case would
result in URNs like urn:ietf-org:sha1, the second would result
in urn:w3c-xml-dsig:sha1. I think the first is preferable. -MB
[38] ftp://ftp.isi.edu/in-notes/rfc2611.txt
; Question, mostly to the chairs: are there URN namespace
applications in process for the ietf or for the w3c? If so,
where do we find the processes (and criteria) to add our own
URNs to those namespaces? If not, how do we make it happen if
we want to go that route? I presume we shouldn't unilaterally
apply for urn:ietf-org or urn:w3c-org. -MB
; Mark: The W3C would not likely use any URNs for anything in
their space, we prefer namespace URI's that look more like
dated URLs, so I've made the approriate tweaks that also fit
with section 1.1 .
To be done: add examples of the algorithm identification
elements (ie <DigestAlg/>) to the algorithms below; most are
obvious. -MB
7.2 Message Digests
7.2.1 SHA-1
The [39]SHA-1 algorithm identifier is urn:nist-gov:sha1. The
SHA-1 algorithm takes no parameters.
[39] http://csrc.nist.gov/fips/fip180-1.pdf
An SHA-1 digest is a 160-bit string. The content of the
DigestValue element shall be the base64 encoding of this bit
string viewed as an 20-octet octet stream. Example: the
DigestValue element for the message digest
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
from Appendix A of the SHA-1 standard would be
<DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
7.2.2 MD5
The [40]MD5 algorithm identifier is urn:rsasdi-com:md5.
The MD5 algorithm takes no parameters.
[40] ftp://ftp.isi.edu/in-notes/rfc1321.txt
The MD5 digest algorithm produces a sequence of bytes.
The content of the DigestValue element shall be the
base64 encoding of this sequence. Example: the
DigestValue element for the message digest
F96B697D 7CB7938D 525A2F31 AAF161D0
from the test suite of the sample implemention of in RFC 1321
would be
<DigestValue>+WtpfXy3k41SWi8xqvFh0A==</DigestValue>
7.3 Message Authentication Codes
7.3.1 HMAC
The [41]HMAC algorithm identifiers are
urn:dsig:hmac-sha1 and urn:dsig:hmac-md5. The HMAC
algorithm takes the truncation length in bits as a
parameter.
[41] ftp://ftp.isi.edu/in-notes/rfc2104.txt
; This is different than what the Brown draft had, which
appears to have come from IOTP. I can see some added
flexibility to the IOTP approach but I'd rather stick to
the RFC 2104 specification. HOWEVER: I am speaking from
ignorance; I don't now why IOTP did it that way. -MB
The output of the HMAC algorithm is ultimately the
output (possibly truncated) of the chosen digest
algorithm. This value shall be base64 encoded in the
same straightforward fashion as the output of the digest
algorithms. Example: the SignatureValue element for the
HMAC-MD5 digest
9294727A 3638BB1C 13F48EF8 158BFC9D
from the test vectors in RFC 2104 would be
<SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue>
7.4 Signature Algorithms
7.4.1 DSA
The [42]DSA algorithm identifier is urn:nist-gov:dsa.
The DSA algorithm takes no parameters.
[42] http://csrc.nist.gov/fips/fips1861.pdf
; This description was lifted almost word-for-word
directly from IOTP. Does it matter? Should it be
reworded? -MB
The output of the DSA algorithm consists of a pair of
integers usually referred by the pair (r, s). The
signature value shall consist of the base64 encoding of
the concatenation of two octet-streams that respectively
result from the octet-encoding of the values r and s.
Integer to octet-stream conversion shall be done
according to the I2OSP operation defined in the [43]PKCS
#1 specification with a k parameter equal to 20.
Example: the SignatureValue element for a DSA signature
(r, s) with values specified in hexadecimal
[43] ftp://ftp.isi.edu/in-notes/rfc2437.txt
r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0
s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8
from the example in Appendix 5 of the DSS standard would be
<SignatureValue>i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLo
tttzYyA==</SignatureValue>
7.4.2 RSA
The expression "RSA algorithm" as used in this document
refers to the RSASSA-PKCS1-v1_5 algorithm described in
[44]RFC 2437.
[44] ftp://ftp.isi.edu/in-notes/rfc2437.txt
The [45]RSA algorithm identifiers are
urn:rsasdi-com:rsa-sha1 and urn:rsasdi-com:rsa-md5. The
RSA algorithm takes no parameters.
[45] ftp://ftp.isi.edu/in-notes/rfc2437.txt
The output of the RSA algorithm is an octet string. The
SignatureValue content for an RSA signature shall be the
base64 encoding of this octet string. Example: <insert
example here>
7.5 Canonicalization Algorithms
7.5.1 Null Canonicalization
The null canonicalization produces a message
byte-for-byte identical with the original resource. No
character set, line ending, or white space normalization
is done.
The null canonicalization is appropriate for
applications where the resource to be signed is not XML,
or where the XML document will be exactly preserved. For
many applications, one of the other canonicalization
algorithms will be more appropriate.
7.5.2 Minimal Canonicalization
The minimal canonicalization algorithm:
+ converts the character encoding to UTF-8, removing the
encoding pseudo-attribute
+ normalizes line endings
+ normalizes white space
This algorithm is only applicable to XML resources.
7.5.3 XML Canonicalization
See the XML Canonicalization specification.
7.5.4 DOM Canonicalization
To be determined.
7.6 Transformation Algorithms
To be determined.
7.7. Algorithm References
Base64
[46]RFC 2045. Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet
Message Bodies. N. Freed & N. Borenstein. DRAFT
STANDARD.
[47]http://www.ietf.org/rfc/rfc2045.txt
[46] ftp://ftp.isi.edu/in-notes/rfc2045.txt
[47] http://www.ietf.org/rfc/rfc2045.txt
DSS
[48]FIPS PUB 186-1. Digital Signature Standard
(DSS). U.S. Department of Commerce/National
Institute of Standards and Technology.
[49]http://www.ietf.org/rfc/rfc2104.txt
[48] http://csrc.nist.gov/fips/fips1861.pdf
[49] http://www.ietf.org/rfc/rfc2104.txt
HMAC
[50]RFC 2104. HMAC: Keyed-Hashing for Message
Authentication. H. Krawczyk, M. Bellare, R.
Canetti. INFORMATIONAL.
[50] ftp://ftp.isi.edu/in-notes/rfc2104.txt
MD5
[51]RFC 1321. The MD5 Message-Digest Algorithm. R.
Rivest. INFORMATIONAL.
[52]http://www.ietf.org/rfc/rfc1321.
[51] ftp://ftp.isi.edu/in-notes/rfc1321.txt
[52] http://www.ietf.org/rfc/rfc1321
RSA
[53]RFC 2437. PKCS #1: RSA Cryptography
Specifications Version 2.0. B. Kaliski, J.
Staddon. INFORMATIONAL.
[54]http://www.ietf.org/rfc/rfc2432.txt
[53] ftp://ftp.isi.edu/in-notes/rfc2437.txt
[54] http://www.ietf.org/rfc/rfc2432.txt
SHA-1
[55]FIPS PUB 180-1. Secure Hash Standard. U.S.
Department of Commerce/National Institute of
Standards and Technology.
[56]http://csrc.nist.gov/fips/fip180-1.pdf
[55] http://csrc.nist.gov/fips/fip180-1.pdf
[56] http://csrc.nist.gov/fips/fip180-1.pdf
URNs
[57]RFC 2141. URN Syntax. R. Moats. PROPOSED
STANDARD.
[58]ftp://ftp.isi.edu/in-notes/rfc2141.txt
[59]RFC 2611. URN Namespace Definition Mechanisms.
L. Daigle, D. van Gulik, R. Iannella, P. Falstrom.
BEST CURRENT PRACTICE.
[60]ftp://ftp.isi.edu/in-notes/rfc2611.txt
[57] ftp://ftp.isi.edu/in-notes/rfc2141.txt
[58] ftp://ftp.isi.edu/in-notes/rfc2141.txt
[59] ftp://ftp.isi.edu/in-notes/rfc2611.txt
[60] ftp://ftp.isi.edu/in-notes/rfc2611.txt
XML-C14N
[61]XML Canonicalization Requirements. W3C Working
Draft
[62]http://www.w3.org/1999/07/WD-xml-c14n-19990729
[61] http://www.w3.org/1999/07/WD-xml-c14n-19990729.html
[62] http://www.w3.org/1999/07/WD-xml-c14n-19990729.html
XPointer
[63]XML Pointer Language (XPointer) W3C Working
Draft.
[64]http://www.w3.org/1999/07/WD-xptr-19990709
[63] http://www.w3.org/1999/07/WD-xptr-19990709
[64] http://www.w3.org/1999/07/WD-xptr-19990709
8.0 Processing rules
These sections describe the operations to be performed as part
of signature generation and validation. The description is of a
logical behavior and does not specify an order of execution,
nor specify discrete steps.
8.1 Generation
1. apply Transformations determined by application to object
being signed.
2. calculate digest over object
3. create Object reference element(s) including location of
object, digest, and transformation and digest algorithm
elements, if required.
4. create SignedInfoelement with signaturealg, c14nAlg (for
SignedInfo), and Object reference(s).
5. canonicalize and calculate signature over SignedInfobased
on algorithms in step d. f) construct signature document
with SignedInfo, Object (s) (if desired, encoding may be
different than that used for signing), KeyInfo (if
required), and SignatureValue.
8.2 Signature Validation
1. locate and apply Transformations (e.g. c14n) to the signed
object(s) based on all Object reference(s) in the
SignedInfoelement.
2. calculate digest over all transformed signed object(s)
based on the algorithm in Object reference(s). If the
object is contained within the Object element, only the
object itself is hashed (i.e. the <Object > and </Object >
tags are excluded).
3. compare value against digest value in SignedInfo(if
mismatch, validation fails).
4. canonicalize the SignedInfoelement based on the c14n
algorithm ID in SignedInfo(or based on the default if
absent).
5. obtain the validation keying info from KeyInfo or
externally.
6. validate the SignatureValue based on the SignatureAlg in
the SignedInfoelement, the key obtained in step c, and the
results of step d. - Digest calculation is performed over
the SignedInfoelement including start and end tags.
Note that while a signature may validate (a key was properly
applied to content to yield the stated SignatureValue) this
does not mean applications will necessarily trust or accept the
signature. For instance, perhaps the assertions within the
content that was signed could not be confirmed or validated
themselves.
9 DTD
Editorial Comment: Declarations are now in the body of the
text.
10.0 Example syntax
<Signature xmlns="http://www.w3.org/Signature/core-19990922">
<SignedInfo Id="5">
<c14nAlg Algorithm="null"/>
<SignatureAlg algorithm="dsig:rsaWithSHA-1"/> ; not a namespace but
an http urn scheme.
<ObjectReference> ;one might use the manifest or package container h
ere
<Location HREF="..."/>
<!-- pointer to external signedobject -->
<Type>text/plain; charset="us-ascii"</Type> ;don't really understa
nd
<Transformations>
<C14NAlg Algorithm="http://..."/>
<Encoding Algorithm="http://..."/>
</Transformations>
<DigestAlg Algorithm="sha-1"/>
<DigestValue Value="a23bcd43" />
</ObjectReference>
<ObjectReference>
<Location HREF="#timestamp"/>
<!-- points to Object below -->
<Type type="signatureattributes" /> ;who defines this type? awkwar
d
<Transformations>
<c14nAlg Algorithm="http://..."/>
</Transformations>
<DigestAlg Algorithm="sha-1"/>
<DigestValue Value="a53uud43" />
</ObjectReference>
</SignedInfo>
<SignatureValue encoding="urn:dsig:base64">dd2323dd</SignatureValue>
<Object id="timestamp1" type="signatureattributes" > ;who defined this
type?
<timestamp about="#5" xmlsn="http://www.ietf.org/rfc/1234">
<date>19990908</date>
<time>14:34:34:34</time>
</timestamp>
</Object>
<KeyInfo>
<keyname>Solo</keyname> ;changed to be elements
</keyinfo>
</Signature>
11.0 Open Issues
1. Default c14n algorithms for SignedInfoand for objects.
Other defaults. Mandatory to implement cryptographic
algorithms and KeyInfo types.
2. Identifying signed object. How do we handle the pointer
from SignedInfoto the signed object, and what rules need to
be defined for the ID attributes in SignedInfoand Object ?
12.0 Security Considerations
...
13.0 References
[DEL: DOMHASH :DEL]
[DEL: [65]Internet Draft. Digest Values for DOM
(DOMHASH)
[66]http://search.ietf.org/internet-drafts/draft-hiroshi
-dom-hash-01.txt . :DEL]
[65] http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-01.txt
[66] http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-01.txt
RDF
[67]RDF Schema
[68]http://www.w3.org/TR/1999/PR-rdf-schema-19990303
[69]RDF Model and Syntax
[70]http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
[67] http://www.w3.org/TR/1999/PR-rdf-schema-19990303
[68] http://www.w3.org/TR/1999/PR-rdf-schema-19990303
[69] http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
[70] http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
[RFC2119]
[71]RFC2119[72] -- Key words for use in RFCs to Indicate
Requirement Levels.
[73]http://www.ietf.org/rfc/rfc2119.txt
[71] http://info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt
[72] https://www.w3.org/info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt
[73] http://www.ietf.org/rfc/rfc2119.txt
[RFC2141]
[74]RFC 2141 -- URN Syntax
[75]http://www.ietf.org/rfc/rfc2141.txt
[74] ftp://ftp.isi.edu/in-notes/rfc2141.txt
[75] http://www.ietf.org/rfc/rfc2141.txt
URI
[76]Uniform Resource Identifiers (URI): Generic Syntax
[77]http://www.ietf.org/rfc/rfc2396.txt
[76] http://www.ietf.org/rfc/rfc2396.txt
[77] http://www.ietf.org/rfc/rfc2396.txt
XLink
[78]XML Linking Language
[79]http://www.w3.org/1999/07/WD-xlink-19990726
[78] http://www.w3.org/1999/07/WD-xlink-19990726
[79] http://www.w3.org/1999/07/WD-xlink-19990726
XML
[80]Extensible Markup Language (XML) Recommendation.
[81]http://www.w3.org/TR/1998/REC-xml-19980210
[80] http://www.w3.org/TR/1998/REC-xml-19980210
[81] http://www.w3.org/TR/1998/REC-xml-19980210
XML-C14N
[82]XML Canonicalization Requirements.
[83]http://www.w3.org/TR/1999/NOTE-xml-canonical-req-199
90605
[82] http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605
[83] http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605
XML-Fragment
[84]XML-Fragment Interchange
[85]http://www.w3.org/1999/06/WD-xml-fragment-19990630.h
tml
[84] http://www.w3.org/1999/06/WD-xml-fragment-19990630.html
[85] http://www.w3.org/1999/06/WD-xml-fragment-19990630.html
XML-namespace
[86]Namespaces in XML
[87]http://www.w3.org/TR/1999/REC-xml-names-19990114
[86] http://www.w3.org/TR/1999/REC-xml-names-19990114
[87] http://www.w3.org/TR/1999/REC-xml-names-19990114
XML-schema
[88]XML Schema Part 1: Structures
[89]http://www.w3.org/1999/05/06-xmlschema-1/
[90]XML Schema Part 2: Datatypes
[91]http://www.w3.org/1999/05/06-xmlschema-2/
[88] http://www.w3.org/1999/05/06-xmlschema-1/
[89] http://www.w3.org/1999/05/06-xmlschema-1/
[90] http://www.w3.org/1999/05/06-xmlschema-2/
[91] http://www.w3.org/1999/05/06-xmlschema-2/
XPointer
[92]XML Pointer Language (XPointer)
[93]http://www.w3.org/1999/07/WD-xptr-19990709
[92] http://www.w3.org/1999/07/WD-xptr-19990709
[93] http://www.w3.org/1999/07/WD-xptr-19990709
XML-Signature-RD
[94]XML-Signature Requirements
[95]http://www.w3.org/1999/08/WD-xmldsig-requirements-99
0820
[94] http://www.w3.org/1999/08/WD-xmldsig-requirements-990820.html
[95] http://www.w3.org/1999/08/WD-xmldsig-requirements-990820.html
WebData
[96]Web Architecture: Describing and Exchanging Data.
[97]http://www.w3.org/1999/04/WebData
[96] http://www.w3.org/1999/04/WebData
[97] http://www.w3.org/1999/04/WebData
14.0 Acknowledgements
[98]Members of the WG
[98] https://www.w3.org/tmp/Participants.html
15.0 Other Useful Types
We define the following types for use in identifying XML
resources that include Signture semantics.
http://www.w3.org/Signature/core-19990922/signatureattributes
designates that the referenced resource is a statement
about the referring signature.
http://www.w3.org/Signature/core-19990922/manifest
designates that the referenced resource is a collection
of other resources.
http://www.w3.org/Signature/core-19990922/package
designates that the referenced resources is a collection
of other resources and the creator of that collection
asserts that the specified resources, when transformed
as specified, yield the same exact content.