Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a widget package to be digitally signed. Widget authors and distributors can digitally sign widgets as a trust and quality assurance mechanism. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the widget package and perform source authentication. This document specifies conformance requirements on both widget packages and user agents.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is produced by the Web Applications WG, part of the Rich Web Clients Activity in the W3C Interaction Domain. It is expected that this document will progress along the W3C's Recommendation track. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
You can find the latest Editor's Draft of this document in the W3C's CVS repository, which is updated on a very regular basis. The public is encouraged to send comments to the WebApps Working Group's public mailing list public-webapps@w3.org (archive). See W3C mailing list and archive usage guidelines. A detailed list of changes from the previous version is also available from the W3C's CVS server.
Implementers should be aware that this document is not stable. Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this document before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.
This document defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a widget package to be digitally signed. Widget authors and distributors can digitally sign widgets as a trust and quality assurance mechanism. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the widget package and perform source authentication. This document specifies conformance requirements on both widget packages and user agents.
A widget package can be signed by the author of the widget producing an [XMLDSIG11] signature that cryptographically includes all of the file entries other than signature files. A widget package can also be signed by one or more distributors, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source.
This specification makes use of [XML-Namespaces], and uses Uniform Resource Identifiers [URI] to identify resources, algorithms, and semantics.
Implementations of this specification MUST use the following URI as the XML namespace for [XML] elements used by this specification:
http://www.w3.org/ns/widgets-digsig
Implementations MUST support the [XML] specification and the [XML-Namespaces] specification.
While use of the above namespace URI is REQUIRED for XML elements used by this specification, the namespace prefix and entity declaration given below are merely editorial conventions used in this document. Their use by authors of digital signature documents is OPTIONAL.
<!ENTITY wsig
"http://www.w3.org/ns/widgets-digsig">
wsig:
For resources not under the control of this specification, we use the designated Uniform Resource Identifiers [URI] defined by the relevant specifications. For example:
ds:
namespacehttp://www.w3.org/2000/09/xmldsig
ds11:
namespacehttp://www.w3.org/2009/xmldsig11
Role
are defined in the dsp:
namespacehttp://www.w3.org/2009/xmldsig-properties
Note: No provision is made for an explicit version number in this specification. If a future version of this specification requires explicit versioning of the document format, a different namespace will be used.
A widget package is a [Zip] archive that conforms to the [Widgets Packaging] specification.
A file entry is the compressed (or Stored) representation of a physical file or folder contained within a widget package, as defined in the [Widgets Packaging] specification.
The root of the widget package is the top-most path level of the widget package, which MAY logically contain one or more file entries, as defined in the [Widgets Packaging] specification.
A file name is the name of a file contained in a widget package (derived from the file name field of a local file header of a file entry), as defined in the [Widgets Packaging] specification. All file names MUST be treated as case-sensitive. In other words, case matters in file name comparisons.
A digitally signed widget package is a widget package that contains one or more signature files.
An unsigned widget package is a widget package that does not contain any signature files.
A signature file is a file entry containing a detached [XMLDSIG11] signature (as profiled in this specification) whose file name follows the naming conventions of a signature file name.
A signature file name is a file name for a file entry that represents a signature file. This specification defines the naming conventions for both author signatures and distributor signatures.
An author signature is a signature file with a signature file name that adheres to the naming convention for an
author signature and has an [XMLDSIG-Properties] Role
element whose URI
attribute is equivalent
to the author role
attribute value. An author signature is intended to be generated by
the author of a widget (i.e., the person who authored the widget).
A distributor signature is a signature file with a signature file name that adheres to the naming convention for a
distributor signature and has an [XMLDSIG-Properties] Role
element whose URI
is equivalent to the distributor role
attribute value. A distributor signature is intended to be generated
by the distributor of a widget (i.e., a third party that is distributing
the widget on behalf of the author).
A wall clock timestamp is defined in the [XMLDSIG-Properties] specification.
A zip relative path MUST conform to the [ABNF] for
zip-rel-path
as specified in [Widgets Packaging].
This section is non-normative.
Defined terms appear as this sample defined term. Such terms are referenced as sample defined term, providing a link back to the term definition.
Words that denote a conformance clause or testable assertion use keywords from [RFC2119]: MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL.
Variables are formatted specially, e.g. variable. Code is
also specially formatted, such as code
.
Examples are highlighted to indicate the whole:
if (a <> 1234122){ //...do something }
Notes are highlighted specially and are used to note editorial issues, or items to be aware of.
This specification uses [ABNF] syntax to define file
names. Rules are concatenated by being written next to each other. A rule
prefixed by *
means zero or more. See [ABNF]
for details on this syntax.
This section is non-normative.
Example of a distributor signature
document, named signature1.xml
:
<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
Id="DistributorASignature">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="config.xml">
<DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="index.html">
<DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="icon.png">
<DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>...</DigestValue>
</Reference>
<Reference URI="#prop">
<DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>...</DigestValue>
</Reference>
</SignedInfo>
<Object Id="prop">
<SignatureProperties
xmlns:dsp="http://www.w3.org/2009/xmldsig-properties">
<SignatureProperty Id="profile" Target="#DistributorASignature">
<dsp:Profile URI="http://www.w3.org/ns/widgets-digsig#profile" />
</SignatureProperty>
<SignatureProperty Id="role" Target="#DistributorASignature">
<dsp:Role
URI="http://www.w3.org/ns/widgets-digsig#role-distributor" />
</SignatureProperty>
<SignatureProperty Id="identifier" Target="#DistributorASignature">
<dsp:Identifier>07425f59c544b9cebff04ab367e8854a</dsp:Identifier>
</SignatureProperty>
<SignatureProperty Id="created" Target="#DistributorASignature">
<dsp:Created>2009-03-12T10:00:00-05:00</dsp:Created>
</SignatureProperty>
</SignatureProperties>
</Object>
<SignatureValue>...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
The design goals and requirements for this specification are addressed in the Widgets 1.0 Requirements [Widgets Requirements] document. This document addresses the following requirements:
reference
element, and
ds:SignedInfo
element.In particular, this specification explicitly supports both author signatures and distributor signatures.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
As well as sections marked as non-normative, examples and notes in this specification are non-normative. Everything else in this specification is normative. The security considerations section is non-normative.
There are two classes of product that can claim conformance to this specification:
Products that generate a signature file MUST generate [XML] documents that conform to [XMLDSIG11] and conform to this specification.
A user agent is an implementation that attempts to support this specification. A user agent MUST behave as described by this specification in order to claim conformance.
Implementers are encouraged to provide mechanisms to enable end-users to install certificates for enabling verification of digital signatures within the widget package. Trust in a certificate is established through a security critical mechanism implemented by the user agent, which is out of scope for this specification.
This section defines how to locate digital signatures in a widget package for processing. An implementation MUST achieve the same result as the following algorithm used to locate digital signatures in a widget package:
Let signatures
be an empty list.
For each file entry in the root of the widget package, if
the file name matches the naming convention for
a distributor signature then append this file
entry to the signatures
list. An Implementation MUST perform a case-sensitive comparison.
If the signatures
list is not empty, sort the list of
signatures
by the file name field in ascending numerical
order (e.g. signature1.xml
followed by
signature2.xml
followed by signature3.xml
etc).
Search the root of the widget
package for any file name that matches the
naming convention
for an author signature and then append this file entry to the signatures
list.
An Implementation MUST perform a case-sensitive
comparison.
If the signatures
list is empty (meaning no signature files were found), terminate this
algorithm and treat this widget package as an unsigned widget package.
Validate the signature files in the signature list in numerical descending order, with distributor signatures first (if any).
The decision of which (if any) distributor signatures are to be validated and whether the author signature is validated is out of scope of this specification. This MAY be determined by the security policy used by the user agent.
Numerical order is the order based on the numeric portion of the signature file name. Thus the highest numbered distributor signature would be validated first.
Ordering of widget signature files by the numeric portion of the file name can be used to allow consistent processing and possible optimization.
Every signature that is validated MUST be validated according to Signature Validation defined in this specification.
A widget package MAY be digitally signed using XML Signature [XMLDSIG11].
Note: A user agent's security policy can affect how signature validation impacts operation, and may have additional constraints on establishing trust, including additional requirements on certificate chain validation and certificate revocation processing using CRLs [RFC5280] or OCSP [RFC2560].
Security policy may also require additional information to
be conveyed in ds:KeyInfo
. Security policy is out of scope of
this specification but has important implications for signature file
processing.
When a widget package is signed according to this specification, the following requirements on a signature file apply to any signature file included in widget package:
Each signature file MUST appear at the root of the widget package.
Each signature file MUST be a detached XML Signature that complies with XML Signature 1.1 syntax [XMLDSIG11].
Each signature file MUST be generated and validated in a manner compliant with XML Signature 1.1 processing rules [XMLDSIG11].
Each signature file MUST contain a dsp:Profile
signature
properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this
specification. This dsp:Profile
property MUST have the URI
attribute value of
http://www.w3.org/ns/widgets-digsig#profile
.
Each signature file MUST contain a dsp:Role
signature
properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this
specification.
Each signature file MUST contain a dsp:Identifier
signature
properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this
specification.
Each signature file MUST contain a dsp:Created
signature
properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this
specification.
Every ds:Reference
used within a signature file MUST have
a URI
attribute.
Every ds:Reference
used within a signature file MUST be
one of the following two kinds of reference:
ds:Signature
elementEvery ds:Reference
to an item within the signature file MUST use
an IDREF
value for the ds:Reference
URI
attribute, referring to a unique ID (as
defined in [XML-Schema-Datatypes])
within the signature file.
The URI attribute of every ds:Reference
to a file entry MUST be a
URL-encoded [URI] zip
relative path that identifies a file inside the widget package.
The author signature can be used todetermine:
A widget package MAY contain zero or one author signatures.
In addition to the requirements on a signature
file, the following MUST be true of an author signature‘s [XMLDSIG-Properties]
’s Role
elementURI
attribute
value:
Role
Attribute value (URI
):http://www.w3.org/ns/widgets-digsig#role-author
In addition, the ds:Signature
MUST have
ds:Reference
s for every file entry
of the widget package other than any signature file.
The author-sig-filename
[ABNF] rule defines the naming convention for an
author signature, as it applies to the signature file name of the author signature:
author-sig-filename = %x61.75.74.68.6f.72.2d.73.69.67.6e.61.74.75.72.65.2e.78.6d.6c
The author-sig-filename
rule defines the lower-case (case-sensitive) string
"author-signature.xml
".
The distributor signature can be used to determine:
A widget package MAY contain zero, one, or more distributor signatures.
In addition to the requirements on a signature
file, the following MUST be true of an distributor signature‘s [XMLDSIG-Properties]
’s Role
elementURI
attribute value:
Role
Attribute value (URI
):http://www.w3.org/ns/widgets-digsig#role-distributor
In addition, the ds:Signature
MUST
include ds:Reference
s for every file
entry of the widget package, including
any author signature, but excluding any distributor signatures. In other words,
distributor
signatures MUST countersign author signatures, but MUST
NOT countersign other distributor
signatures.
Each distributor signature MUST have a file name consisting
of the lower-case string "signature
" followed by a
digit in the range 1-9 inclusive, followed by zero or more digits in the
range 0-9 inclusive and then the lower-case string ".xml
".
The dist-sig-filename
[ABNF] rule formally defines the naming convention for a
distributor signature, as it applies to the signature file name of a distributor signature:
dist-sig-filename = signature-string non-zero-digit
*DIGIT xml-suffix-string
signature-string = %x73.69.67.6e.61.74.75.72.65
non-zero-digit = %x31-39
xml-suffix-string = %x2e.78.6d.6c
The signature-string
rule defines the lower-case
(case-sensitive) string "signature
".
The non-zero-digit
rule defines a digit in the range
1-9
.
DIGIT
is defined in [ABNF] as a digit
in the range 0-9
.
The xml-suffix-string
rule defines the lower-case
(case-sensitive) string ".xml
".
An example is "signature20.xml".
Leading zeros are disallowed in the numbers.
A file entry whose file name does not match the above ABNF MUST be ignored, meaning that an implementation MUST NOT treat the file entry as a signature file.
For example, a file with the file
name "signature01.xml
" will be ignored.
It is OPTIONAL that the signature file names of distributor signatures form a contiguous set of numeric values.
Within a widget package these signature files MUST be ordered based on the numeric portion of the signature file name.
Thus, for example, signature2.xml
precedes
signature11.xml
.
Every signature file MAY have additional information
contained in the signature ds:X509Data
element as specified
by the [XMLDSIG11] specification. This MAY include X.509 certificates, and/or CRL and/or OCSP
response information that, if included, MUST be
conveyed according to the [XMLDSIG11]
specification.
The X.509 certificate format MUST be supported when
certificates are used in the ds:X509Data
. This is the mandatory certificate format. The
RECOMMENDED version of the certificate format is X.509
version 3 as specified in [RFC5280].
Implementations MUST be prepared to accept X.509 v3
certificates [RFC5280].
Note: v3 certificates are necessary to use the v3 extension to express the basic constraints on a certificate. This allows CA certificates to be distinguished from end entity certificates, enabling more robust trust verification.
Identifier
Signature Property The dsp:Identifier
signature property is intended to be
used to uniquely identify the signature to enable signature management. It
MUST be unique for a given signer.
Created
Signature Property The dsp:Created
signature property provides the wall clock timestamp for when a signature file was created and is intended to
be used to provide additional information associated with signatures.
As an example of use, assume a distributor's signing process is found to have been compromised. Thus, it is not practical to exchange the signature key. Being able to invalidate all signatures made before a particular date would be important in such a scenario.
Definitions of the algorithm URI identifiers specified in [XMLDSIG11] take precedence if there is any difference in this document. Rules specified in [XMLDSIG11] regarding use of these algorithms MUST be followed.
Note: The Web Applications Working Group is seeking
feedback on required algorithms for signature files, in particular which
algorithms should be required in addition to RSAwithSHA256.
The Working Group has not yet agreed on a final set of required
algorithms.
This specification relies on XML Signature 1.1 [XMLDSIG11] that introduces new and stronger
algorithms to XML Signature. The XML Security Working Group has not yet
achieved consensus on required algorithms in XML Signature 1.1, in
particular whether to mandate ECDSAwithSHA256.
The XML Security Working Group is
also requesting feedback on the First Public Working Draft of XML
Signature 1.1, to be sent to to public-xmlsec-comments@w3.org
(with public
archive).
The following signature algorithms MUST be supported:
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
http://www.w3.org/2000/09/xmldsig#dsa-sha1
A user agent MAY support additional signature algorithms.
The RECOMMENDED key length (recommended key length) of the key used to generate the signature is 2048 bits. The key length of the key used to generate the signature MUST NOT be less than 1024 bits. Signatures generated using key lengths of less than 2048 bits SHOULD NOT be used unless the life time of the signature is less than one year.
The following digest algorithms MUST be supported:
REQUIRED: SHA-256
http://www.w3.org/2001/04/xmlenc#sha256
A user agent MAY support additional digest methods.
The following canonicalization algorithms MUST be supported:
REQUIRED: Canonical XML 1.1 (omits comments)
http://www.w3.org/2006/12/xml-c14n11
A user agent MAY support additional XML canonicalization methods.
The following constraints apply to both Signature Generation and Signature Validation. These constraints MUST be observed when generating a signature file and MUST be verified as met when validating a signature file.
A signature file MUST have a ds:Reference
for every file entry that is not a signature file.
A distributor signature MUST have a ds:Reference
for any author signature, if one is present within
the widget package.
For each ds:Reference
element:
The URI
attribute MUST be a zip relative
path from the root of the
widget package to the file entry being
referenced.
The Algorithm
attribute of the
ds:digestMethod
MUST be one of the digest algorithms.
The ds:Reference
MUST NOT have any
ds:Transform
elements.
Every Signature Property required by this specification MUST be incorporated into the signature as follows:
A signature file MUST include a ds:Object
element within
the ds:Signature
element. This ds:Object
element MUST have an Id
attribute
that is referenced by a ds:Reference
element within the
signature ds:SignedInfo
element.
This ds:Object
element MUST contain
a single ds:SignatureProperties
element that MUST contain a different
ds:SignatureProperty
element for each property required
by this specification.
Each ds:Signature
property required by this
specification MUST meet the syntax requirements of
[XMLDSIG-Properties].
The ds:Signature
MUST meet the
following requirements:
The Algorithm
attribute of the
ds:CanonicalizationMethod
element MUST be one of the canonicalization algorithms.
The ds:SignatureMethod
algorithm used in the
ds:SignatureValue
element MUST be one
of the signature algorithms. The
ds:Signature
MUST be produced using a
key of the recommended key
length or stronger (meaning larger than 2048 bits).
The ds:KeyInfo
element MAY be
included and MAY include certificate, CRL and/or
OCSP information. If so, it MUST be compliant with
the [XMLDSIG11] specification. If
certificates are used, they MUST conform to the mandatory certificate format.
The ds:SignedInfo
element MUST
include all the ds:Reference
elements listed in items 1,
2 and 4 of this section.
The signature file MUST be serialized as a [UTF-8] encoded [XML] document and be named using the appropriate naming convention: either the naming convention for a distributor signature or the naming convention for an author signature.
A signature file MUST be generated according to the Core Generation rules specified in [XMLDSIG11], including rules on Reference Generation and Signature Generation.
The Common Constraints for Signature Generation and Validation MUST be met on signature generation.
A wall clock timestamp SHOULD be placed in the dsp:Created
signature
property upon signature generation. It is OPTIONAL for
the granularity of the wall clock
timestamp to be finer than to the minute. The time SHOULD reflect the time when signature generation
completed.
A unique identifier string for the signature MUST
be placed in the dsp:Identifier
signature property by the
signer. This MUST be a unique signing string for all
signature files created by the signer.
A signature file MUST be validated according to Core Validation, as defined in XML Signature [XMLDSIG11], including Reference Validation and Signature Validation.
The Common Constraints for Signature Generation and Validation MUST be met on signature validation.
The Created Signature Property value SHOULD represent a wall clock timestamp earlier than the current time, to the nearest minute. There MUST NOT be more than one such value in the signature.
If a ds:KeyInfo
element is present, then it MUST conform to the [XMLDSIG11]
specification. If present, the user agent MUST perform
Basic Path Validation [RFC5280] on the signing key
and SHOULD perform revocation checking as appropriate.
If signature file validation fails for any reason, any external entities (e.g., a user agent that implements [Widgets Packaging]) relying on the validation of the signature file MUST be notified of the failure. This specification does not define the means or format of a failure notification, which is left up to implementers. The reason for validation failure MAY be returned by the implementation to an external entity, including reasons related to Reference validation, Signature validation, Signature Property validation and/or certificate and CRL/OCSP verification.
This section is non-normative.
The signature scheme described in this document deals with the content present inside a compressed widget package. This implies that, in order to verify a signature file, implementations need to decompress a data stream that can come from an arbitrary source. A signature according to this specification does not limit the attack surface of decompression and unpacking code used during signature extraction and verification.
Care should be taken to avoid resource exhaustion attacks through maliciously crafted widget packages during signature verification.
Implementations should be careful about trusting path components found in the widget package. Such path components might be interpreted by operating systems as pointing at security critical files outside the widget environment proper, and naive unpacking of widget packages into the file system might lead to undesirable and security relevant effects, such as overwriting of startup or system files.
There is no single signature file that includes all files of a widget package, including all of the signature files. This leaves a widget package subject to an attack where distributor signatures can be removed or added. An author signature could also be attacked by removing it and any distributor signatures if they are present. A signature file may also be renamed, which can affect processing.
Mechanisms to install new root certificates in a user agent should be subject to security critical mechanisms. End-users should be made aware of what they are doing and why when installing a new root certificate.
Issue: This specification relies on XML Signature Properties [XMLDSIG-Properties]. The following material has been added to the editors draft of that specification after the First Public Working Draft was published and is used by this specification, so is copied here. It is subject to possible change. This section will be removed once an updated Public Working Draft of XML Signature Properties is published.
The Identifier Property is intended to enable use cases where a unique identifier needs to be associated with the signature, such as to enable signature management.
Schema Definition
<element name="Identifier" type="dsp:IdentifierType"/>
<xsd:complexType name="IdentifierType" >
<xsd:extension base="xsd:String">
</xsd:extension>
</xsd:complexType>
Identifier string values MUST be unique for each signature from a given signer and SHOULD be unique across all signers.
Upon signature generation, if this property is used, the value is set to a unique value to be associated with the signature for a particular signer.
Applications are expected to use this property to identify the signature.
Profiles MUST specify details of the identifier property value creation and interpretation.
If multiple instances of this property are found on a single signature, then applications MUST NOT deem any of these properties valid.
The Created Property is intended to enable use cases where the time of signature creation needs to be recorded.
Schema Definition
<element name="Created" type="dsp:CreatedType"/>
<xsd:complexType name="CreatedType" >
<xsd:extension base="xsd:dateTime">
</xsd:extension>
</xsd:complexType>
Creation times MUST be given as timezoned values as define in section 3.2.7 of [XML-Schema-Datatypes]. This property MUST NOT occur more than once for a given signature.
Upon signature generation, if this property is used, the time value is set to a reference time, as defined by the application. It is OPTIONAL for the value of the time to be from a trusted timestamp authority. The time value needs only be accurate enough for comparison, as required by the application usage. The time SHOULD reflect the time when signature generation completed.
Applications are expected to use this property to identify the creation date of a signature. Evaluation of this property is with respect to an application defined reference time (possibly wall clock time, possibly a time that is determined otherwise).
Profiles MUST specify what reference time needs to be used when interpreting this property.
A Created property with an untimezoned time value MUST NOT be considered valid. If multiple instances of this property are found on a single signature, then applications MUST NOT deem any of these properties valid.
This section will be completed as the document matures.