- From: <david.solo@citicorp.com>
- Date: Fri, 27 Aug 1999 14:08:03 -0400
- TO: w3c-ietf-xmldsig@w3.org
- CC: dsolo@alum.mit.edu
- Message-Id: <H0000cc4041dbba6@MHS>
Attached is an in process draft of the new document. While I'm in the middle
of finishing this, I wanted to get something out before the weekend and next
Monday's FTF. I'll be posting an updated draft some time Sunday that will
include the DTD, some reformatting, and more content (although any comments are
welcome in the mean time).
This document
- reflects syntax changes from my last note and recent list discussions
- new names for some elements and attributes (As I've mentioned before, I'm
more than willing to change any of these)
- sections describing each element
- preliminary thoughts on keyinfo
Dave
-----
XML Digital Signature Syntax and Processing
David Solo
Citigroup
dsolo@alum.mit.edu
27 August 1999
1.0 Introduction
This document describes the proposed syntax and processing rules for the
XML Digital Signature Standard. This standard 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 may either 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 manifest for referencing multiple
resources and key management and algorithm definitions.
2.0 General model
The general structure of an XML signature document is:
<signature>
<signedinfo/>
<signedobject/>
<keyinfo/>
<signaturevalue/>
</signature>
2.1 signedinfo
signedinfo is the actual data over which the signature is calculated.
It contains control information (algorithm identifiers, pre-processing
transformations), a digest over the object being signed, and optional
signed attributes (information associated with the signature).
2.2 signedobject
signedobject is an optional element which is used to include the object
being signed within the signature document. When present this element
may contain any item and specifies the encoding.
2.3 keyinfo
keyinfo is an optional element which enables the recipient(s) to obtain
the key(s) needed to validate the signature. keyinfo may contain the
key, may name the key, may include certificates and other public key
management information, may include inband key distribution or agreement
data, or use any other method.
2.4 signaturevalue
signaturevalue 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”).
3.0 signedinfo
The structure of signedinfo is:
<signedinfo>
<c14nalg/>
<signaturealg/>
<signedobjectdata/>
<signedattributes/>
</signedinfo>
The signedinfo element may contain an optional ID field that will allow
it to be referenced by other signatures.
3.1 c14nalg
c14nalg is an optional element which specifies the c14n algorithm
applied to the signedinfo element prior to performing signature
calculations. If the default c14n algorithm for signedinfo is used,
this element may be omitted. This element uses the general structure
here for algorithms in which an href is included as an attribute naming
the algorithm and 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), and more extensive
transformations such as the W3C c14n proposal.
3.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 an href 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.
3.3 signedobjectdata
The structure of signedobjectdata is:
<signedobjectdata>
<objectlocation/>
<transformations/>
<digestalg/>
<digestvalue/>
</signedobjectdata>
3.3.1 objectlocation
objectlocation identifies where to find the signedobject and optionally
information about the type of object being signed (e.g. manifest,
package, document, signedinfo, PDF file). This element may be omitted
if the location is implicit in the application. The element contains
two attributes, a type href and a location href.
3.3.2 transformations
transformations is an optional element that contains one or more
operations to be performed on the signedobject prior to signature
calculation. Examples of transformations include c14n, exclusion
(omitting certain portions of the object from the signature), encoding,
etc. Each element within transformations uses the general structure
here for algorithms in which an href 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.
If the transformations element is omitted, the only operation performed
is the default object c14n algorithm (null or identity).
3.3.3 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 an href 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.
3.3.4 digestvalue
digestvalue is a required element which contains the base64 encoded
value of the digest.
3.4 signedattributes
signedattributes is an optional element which contains one or more
attributedata elements. Each attributedata element contains a type
attribute naming the attribute type with an href and has a value defined
by the type. signedattributes contain information associated with the
signature itself. Information about the content should be included
within the signedobject.
4.0 signedobject
signedobject is an optional element which contains the signed object
identified in signed info. This element is used for embedded signatures
where the object being signed is to be included in the signature
document. The signedobject element may include optional type, ID, and
encoding attributes and may contain any data.
5.0 keyinfo
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 elements providing
information for the recipient(s). Some types are defined here, although
applications may define any mechanism they choose.
5.1 keyname
keyname contains an identifier for the key which may be useful to the
recipient. This may be a name, index, etc. It
5.2 keyvalue
keyvalue contains the actual key(s) used to validate the signature. If
the key is sent in protected form, the keymgmtdata element should be
used. Specific types must be defined for each algorithm type (see
algorithms).
5.3 subjectname
subjectname contains one or more names for the sender.
5.4 keyretrievalmethod
keyretrievalmethod is a uri which may be used to obtain key and/or
certificate information.
5.5 x509data
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.
5.6 pgpdata
5.7 keymgmtdata
keymgmtdata contains in-band key distribution or agreement data.
Examples may include DH key exchange, RSA key encryption etc.
6.0 signaturevalue
signaturevalue is a required element which contains the base64 encoded
value of the signature as defined by the signaturealg value in
signedinfo.
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 Digest algorithms
7.2 Signature algorithms
7.3 c14n algorithms
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
a) apply transformations determined by application to object to be
signed.
b) calculate digest over object
c) create signedobjectdata element including location of object, digest,
and transformation and digest algorithm elements, if required.
d) create signedinfo element with signaturealg, c14nalg (for
signedinfo), signedobjectdata, and signedattributes (if any).
e) canonicalize and calculate signature over signedinfo based on
algorithms in step d.
f) construct signature document with signedinfo, signedobject (if
desired, encoding may be different than that used for signing), keyinfo
(if required), and signaturevalue.
8.2 Validation
a) locate and apply transformations (e.g. c14n) to the signed object
based on signedobjectdata in the signedinfo element.
b) calculate digest over transformed signed object based on the
algorithm in signedobjectdata. If the object is contained within the
signedobject element, only the object itself is hashed (i.e. the
<signedobject> and </signedobject> tags are excluded).
c) compare value against digest value in signedinfo (if mismatch,
validation fails).
d) canonicalize the signedinfo element based on the c14n algorithm ID
in signedinfo (or based on the default if absent).
e) obtain the validation keying info from keyinfo or externally.
f) validate the signaturevalue based on the signaturealg in the
signedinfo
element, the key obtained in step c, and the results of step d.
- Digest calculation is performed over the signedInfo element including
start and end tags.
- The signedattributes element is treated as opaque with respect to
processing (i.e. signedattributes do not effect processing and are just
included in the signaturevalue calculation).
9.0 DTD
10.0 Example syntax:
<dsig:signature>
<dsig:signedinfo ID="...">
<dsig:c14nalg type="null"/>
<!-- applies to signedInfo, should have a default value -->
<dsig:signaturealg type="rsaWithSHA-1"/>
<dsig:signedobjectdata>
<dsig:objectlocation type="http://..." href="..."/>
<dsig:transformations>
<!--applies to object-->
<dsig:c14nalg type="http://..."/>
<dsig:encoding type="http://..."/>
</dsig:transformations>
<dsig:digestalg type="sha-1"/>
<dsig:digestvalue value="a23bcd43" />
</dsig:signedobjectdata>
<dsig:signedattributes>
<dsig:attributedata type="http://..."> 19990824132700Z
</dsig:attributedata>
</dsig:signedattributes>
</dsig:signedinfo>
<dsig:signedobject ID="..." type="http://..." encoding="http://...">
<!-- present if embedded object -->
jhasodutoinwoiahsh
</dsig:signedobject>
<dsig:keyinfo
<dsig:keyname> 3 </dsig:keyname>
</dsig:keyinfo>
<dsig:signaturevalue> dd2323dd </dsig:signaturevalue>
</dsig:signature>
11.0 Open Issues
1) At this time, the only method supported is to calculate a digest over
the signed object and include that digest in signedinfo. The signed
object may be anything (a manifest, a document, another signedinfo
element, etc.). Only a single such digest may appear (signing multiple
items is handled in the signedobject (e.g. in a manifest). Alternatives
would allow the actual object to be included within signed info or to
allow multiple digests. The decision to always use the digest method is
based on separating the pre-processing transformations (e.g. encoding,
c14n) for signedinfo and for the object itself and also to allow for
switching between detached and embedded signatures.
2) Default c14n algorithms for signedinfo and for objects. Other
defaults. Mandatory to implement cryptographic algorithms and keyinfo
types.
3) Identifying signed object. How do we handle the pointer from
signedinfo to the signed object, and what rules need to be defined for
the ID attributes in signedinfo and signedobject?
12.0 Security Considerations
13.0 References
14.0 Acknowledgements
Received on Friday, 27 August 1999 14:08:51 UTC