WD-DSIG-arch-961026 WD-DSIG-arch-961026This document is obsolete. For the the latest information on DSIG, please consult http://www.w3.org/pub/WWW/Security/DSig/Group/.
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR.
Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
W3C's current Digital Signature Initiative (DSig) began with the assertion that it is important that end users have a reliable mechanism that allows them to decide what Web content they can trust. Such trust can be established by attaching digital signatures to on-line documents. These signatures serve to identify the origin of a document -- the identity of the signer. For many uses, however, there is additional information required to make these trust decisions. This typically takes the form of requiring endorsements by parties trusted by the users. For example, software execution authority may be based on statements from PC Week or may be permitted only by endorsement of an MIS office.
There are four major objectives for DSig:
We propose to extend PICS labels to become the standard signature block A digitally signed PICS label can serve as a signature on the document itself bound together with machine-readable semantics. A well designed signature extension block for PICS can address crytpographic and certification flexibility, and PICS labels themselves already provide the transmission modes. The new PICS Signature Block presented here is such a solution.
Stepping back, though, let's consider the overall architecture of separate signatures (as opposed to the security community's traditional wrapping and enveloping approaches).
As a result, a signed PICS label neatly bundles up these elements to address the DSig objectives. The resulting trustable assertion is:
Labeler of rating-service says resource-named-by-URI with document-hash at last-modified-date had rating within rating-system at last-rated-date.
Labeler's digital signature allows us to believe the whole assertion, including the association to the document at hand. Of course, the label itself is a document allowing others to rate the ratings and sign the signers.
We aim to create a new signature block including an assertion
layer, but the current PICS-1.1 language is limited. By extending
the semantics of PICS, it can be used as a 'universal' document
signature block. The following diagram of an abstract signature
block recaps how an extension can easily provide the necessary
link between a document, its signer and the assertion that the
signer is making.
| Where | Element | Rationale |
| Label | Self-description URL | provides a link to the rating system, the policy file, etc. |
| Label | Rating | the endorsement ; what labeler is attesting to |
| Label | Rating System | the system defines the axes and meaning of the rating. |
| Sig | Labeler's Key (+ Algorithm) | who is making the assertion. Can we assume keys are algorithm-specific, hence implying the labeler's cryptographic technique? |
| Sig | Labeler's Identity | Hints about the labeler's well-known identity, for querying directory services |
| Sig | Labeler's Certificate | identity certificates that vouch for the labeler's identity. Can be transmitted immediately or indirectly through a certificate URI |
| Label | Document-URI | name of the information resource at hand |
| Label or Sig? | Document Hash (+ Algorithm) | used to unambiguously and unforgeably associate a document with its label |
| Label | Document Last-Modified | delimits the version of the document which was examined |
| Sig | Label-Hash (+Algorithm) | used to unambiguously and unforgeably
associate a label with its signature need to specify which extensions are included in the hash and which are not |
| Label | Label Date (+ Expiration) | delimits the freshness of the rating |
| Sig | Signature | for each cryptographic technique, the signature data itself. For example, the RSA public exponent and signature itself. |
| Sig | Signature Date (+ Expiration) | delimits the freshness of the signature (may be superceded by revocation of an identity certificate, though) |
The current PICS label syntax has an extension field which can accommodate all of the above. See Appendix A for a detailed proposal.
There are two ways to use signatures as embedded in this block format:
We need to explore using this signature strategy in relation to:
Of course, signature labels inherit all of the transmission vectors of PICS labels:
Additionally, we can have new document formats built around signatures and associated metainformation. The HTML ERB is already involved with proposals for including signatures and other metainfo within HTML files. As a result, a bookmarks or table-of-contents-file can include PICS ratings, DSIG endorsements, certificates, and more (this kind of facility was once referred to as 'sitemap').
application/pics-labellist is already one such format - and a specific query is the only way we can 'name' labels today. Is that sufficient? It should be possible to replace any reference to a PICS label with a pointer - a URI - to a singleton labellist. We could also use a hypothtical data:<base64> immediate format too (for ease of embedding).
The Digital Signature Initiative is not about cryptography for cryptography's sake, though. The fundamental aim is:
To help users decide what to trust on the Web
Cryptography is one way to establish identity and ownership, but the goal above highlights the need to understand users' problems in a trust management context - what does this signature mean? What should be done about this information resource?
Indeed, a wide variety of trust decisions can be made more automatable with PICS ratings and signature labels - intellectual property rights management, executable content evaluation, working with public documents, and more. From W3C's perspective, we have a series of interlocking goals for DSIG, arranged in a bull's-eye:
Though DSIG has its roots in the 'hot-button' issue of mobile code-signing, we expect the tools and formats developed by DSIG will be the foundation for addressing many new Web challenges in the next 12-18 months.
[This section was authored in part by Paul Resnick and reflects the position of the REFEREE authors]
Digital signatures alone are not sufficient for code signing and other applications: signatures can solve the problem of authentication, but not security or trust. For code signing, users need a way to describe their security policies (under what conditions do they trust the code, and what do they trust the code to do) and an environment for evaluating their policies. We believe that code signing and other digital signature applications will benefit from a simple language that can describe most common user policies and can be extended to handled more complex policies.
We will propose a profiles language that describes policies in terms of what PICS labels are needed in order to authorize operations. Mechanically, policies are programs that can fetch and process PICS labels in order to determine whether a requested operation is permitted. In the course of execution, they can call other programs/policies, for example to check signatures to determine the authenticity of labels. This group need only come to agreement about signature formats and algorithms, then make a new signature checking program available; the rest of the trust management infrastructure, including the profiles language, need not be updated.
For example, here is a sample policy written in the profile
language. The call to invoke-with-tagged-append
calls a subroutine that retrieves PICS labels for THE-URL
from some set of known sources (label bureaus, or perhaps a local
label repository on CD-ROM). The second line (match)
searches among all the retrieved labels for labels that (a) use
the "http://www.rsac.org/" rating system, and (b) rate
THE-URL in category "s" with a value less than 2.
(invoke "load-label" INITIAL-STATEMENT-LIST THE-URL)
(match
(("load-label" ...)
(... (PICS-1.1 ... "service" "http://www.rsac.org/" ... (ratings (< s 2))))))
INITIAL-STATEMENT-LIST)
We will also propose an underlying kernel on which to build an interpreter for the profiles language. The kernel, called REFEREE (Rule-controlled Environment For Evaluating Rules and Everything Else), offers several advantages for implementers of the profiles language:
The trust management kernel maintains a database of programs that are trusted to run. All compliant programs accept the same required arguments, and may accept additional optional arguments. All compliant programs have the same return type. A trusted program can invoke other programs (delegate trust) or install and uninstall other new programs in the database. A few built-in programs (policies) are supplied initially for bootstrapping.
W3C and AT&T Labs have been actively working on the design of the profiles language and the trust management kernel. The kernel is based loosely on principles gleaned from the PolicyMaker system developed at AT&T Labs by Blaze, Feigenbaum, and Lacy.
The initial application of DSIG, though, remains executable-content approval. We've spent the most time thinking about that scenario, and how it fits into today's client models.
Today, in Authenticode™ and similar systems, only one kind of check is being made, namely identity verification. The main trust problem is managing the trusted roots of an identity certification tree. In addition, clients might also check for endorsements written into an identity certificate, such as Authenticode's 'commercial software provider' switch.
With signature labels, though, behind the scenes clients may be manipulating induction chains of identity and endorsement: 'run this code because Joe says it's three out of five stars and I trust it's Joe because it's his key and it's his key because I have an identity document rated A1 by Bonded Investigators, Inc and I trust it's BII because they have a VeriCert…'. Of course, building effective user interfaces to this is a challenge for software developers, but some discussion of a common model could jumpstart thinking. This section is reseved for this sort of discussion.
Hopefully, this section will reflect growing consensus about the value of pluggable policy configurations - simple user statements of 'run anything Joe approves or above 4 stars from Starz.com'-which can be reused across their tools. One of the archetypal examples to keep in mind is the scenario of sending a child's policy along to a web search service with his or her query so that the search service can prefilter the result list. Remember, too, the controversy which follows hardwired policies, such as Microsoft's initial Authenticode deployment.
This note describes a possible application of the PICS label extension mechanism that will permit digital signatures to be stored within a PICS label. We assume the reader is familiar with the PICS-1.1 label standard.
A PICS label looks like this:
(PICS-1.1
<service url> [option...]
labels [option...] ratings (<category> <value> ...)
[option...] ratings (<category> <value> ...)
...
<service url> [option...]
labels [option...] ratings (<category> <value> ...)
[option...] ratings (<category> <value> ...)
...
...)
Any place where there is a valid [option] we may have an extension block. So (I think) we can have an extension either on the service block or on individual ratings blocks. We have to be careful with what the semantics are if the scope of a signature encompasses multiple ratings (it may not make sense).
Basically, an extension looks like this:
extension (<optional-or-mandatory> <extension-url> <args>)
The digital signature extension is usually "optional", has a particular URL, and <args> is a quoted s-expression assoc-list of tagged arguments.
Here's a more detailed picture of a DSig extension block (I use Scheme notation below; lines beginning with ";" are comment lines):
extension
(optional
;;; the URL describing the extension
"http://www.w3.org/PICS/DSig"
"(
;; first, we ned the hash (MIC) of the document. We may want to
;; provide multiple hashes with multiple different hash functions:
(document-hash
(<hash-algorithm-id-1> <the-hash-1>)
...
(<hash-algorithm-id-n> <the-hash-n>))
;; we may also need to split the-hash into a vector for streaming data
;; and we need the signature of the label, again possibly with
;; multiple algorithms.
;;
;; Jim says we have to include the signer's public key in the label
;; so that the signature can be verified (not necessarily trusted, just
;; verified) with only the contents of the label. This is stronger than
;; the SDSI model which does not require that the key be specified in
;; a signed object.
(label-signature
(
(<sig-algorithm-id-1> <the-hash-1>) ; must be present
(<sig-key-1>) ; may be present
(<list-of-excluded-extensions-1>) ; may be present
)
...
((<sig-algorithm-id-n> <the-hash-n>)
(<sig-key-n>)
(<list-of-excluded-extensions-n>)))
<optional-parts>
)"
)
This block currently has two mandatory parts:
and other optional parts.
The document-hash section contains one or more hashes of the document referenced by the label. Each hash is a two-element list containing the name of the hash and the value of the hash. We will need to specify some standard encoding scheme for hash values as well as standard hash names (or use URLS here too). Sample:
(document-hash (md5-hash =deadbeef=) (sha-1-hash =13570246=))
I assume for purposes of this document that cryptographic hashes and other binary data are base64 encoded, delimited by equal signs (=).
The label-signature section contains digital signatures of the label. That is, the contents of the label are hashed and encrypted with some private key. When computing the hash of the label:
I'm not sure what else we're going to need yet.
RK: I believe the labeler-info goes here: labeler name, certs, cert-pointers. If the per-algorithm sig block includes the key bits directly, the labeler-info is indeed strictly optional.
Here's a PICS label example (taken from the PICS spec). It describes ratings for two separate documents Overview.html and Underview.html) using the same ratings system (Good, Clean Fun v2.5). The rating for Overview.html is by "John Doe" and the rating for Underview.html is by "Jane Doe".
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels
on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
ratings (suds 0.5 density 0 color/hue 1)
for "http://w3.org/PICS/Underview.html"
by "Jane Doe"
ratings (subject 2 density 1 color/hue 1))
Let's now create a signed version of this label using the DSig extension. First, here's how John Doe signs his rating of Overview.html using his SDSI key:
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels
on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
extension
(optional "http://www.w3.org/PICS/DSig"
"((document-hash (md5 =mQENAzJIVvwAAAEH/3fI2oaZ=))
(label-signature
((rsa-md5=qZOtfMNCg9/WdWEBvZTvIWPj=)
(SDSI-Principal:
(Public-Key: (Algorithm: rsa-md5)
(N: =b22O+CXLSJEv56AamFl=)
(E: 17)))))
)")
ratings (suds 0.5 density 0 color/hue 1)
for "http://w3.org/PICS/Underview.html"
by "Jane Doe"
ratings (subject 2 density 1 color/hue 1)
)
NOTE: There's a scoping issue here too. When John Doe signs the label for Overview.html is he also signing the service-wide options (the 'by "John Doe"' line in the above example)? I believe he is, even though such service options may be over-ridden by label-specific options. I don't believe the mere fact that the option is no longer in effect is sufficient to excuse its presence from the label, and thus it must be included in the hash of the label. However, if it is legal to rewrite PICS labels by pushing service options down into individual labels, then I'm probably wrong and arbitrary rewriting can occur before signing.
One DSig goal is to define the semantics of a digital signature attached to a document. To a first-order approximation I would argue that the semantics of a digital signature encapsulated within a PICS label are specified by the ratings service listed in that label. That is, if key K signs a label for document D and the label includes ratings list R in service R_serv, then the semantics of "K says R about D" are defined by the rating service R_serv. For example, suppose I wish to witness the signing of a digital contract. I might establish a rating service (or use an existing rating service) designed specifically for such a purpose. Let's suppose there's a rating service: http://www.witness.org/third-party-witness with the following application/pics-service description file:
((PICS-version 1.1)
(rating-system "http://www.witness.org/third-party-witness.html")
(rating-service "http://www.witness.org/third-party-witness/v1.0/")
(name "Third-party witness service for digital contracts")
(description "An example of a rating service that describes semantics
for digital signatures")
(category
(transmit-as "witnessed")
(name "Assertion that document was witnessed")
(label-only))
(category
(transmit-as "number-id")
(name "Number of photo IDs of each signatory to the contract
examined by the witness")
(integer)
)
Further, let's assume that http://www.witness.org/third-party-witness.html says something like this:
<html>
This is the PICS service description file for www.witness.org's "Third-party witness service for digital contracts." This service is intended to be use by third parties who witness the signing of a digital contracts.
A signed rating of "witnessed" is an attestation that the signer of the label containing such a rating did indeed witness the signing of the contract by all parties to the contract.
A signed integer rating transmitted as a value of "number-id" is an attestation that the signer of the label containing such a rating inspected the stated number of photo IDs for each signatory to the contract.
A rating in this system is only semantically meaningful when digitally signed by one or more parties (the witnesses).
</html>
(Granted, it may seem odd to have a witness signing service for digital documents, but it serves our need for this thought experiment.) Now, if I witness the signing of a contract in digital form, I can attest to witnessing that event as follows:
(PICS-1.1 "http://www.witness.org/third-party-witness/v1.0/"
labels
on "1996.10.16"
for "http://www.uaw.org/ord/1996Contract.html"
extension
(optional "http://www.w3.org/PICS/DSig"
"((document-hash (md5 =mQENAzJIVvwAAAEH/3fI2oaZ=))
(label-signature
((rsa-md5 =qZOtfMNCg9/WdWEBvZTvIWPj=)
(SDSI-Principal:
(Public-Key: (Algorithm: rsa-md5)
(N: =b22O+CXLSJEv56AamFl=)
(E: 17)))))
)")
ratings (witnessed)
)
The meaning of my signature is well-defined by the rating service; I witnessed the signing of the contract and by assigning a rating of "witnessed" to the actual document I attest to that fact.
OK, all well and good so far, but consider our earlier example:
(PICS-1.1 "http://www.gcf.org/v2.5"
labels
on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
extension
(optional "http://www.w3.org/PICS/DSig"
"((document-hash (md5 =mQENAzJIVvwAAAEH/3fI2oaZ=))
(label-signature
((rsa-md5 =qZOtfMNCg9/WdWEBvZTvIWPj=)
(SDSI-Principal:
(Public-Key: (Algorithm: rsa-md5)
(N: =b22O+CXLSJEv56AamFl=)
(E: 17)))))
)")
ratings (suds 0.5 density 0 color/hue 1)
)
What is the meaning of the digital signature contained within this label? Under our model the semantics of the signature are defined by the rating service, http://www.gcf.org/v2.5. But while GCF, Inc. provides a semantics for "suds 0.5," "density 0," and "color/hue 1", they do not necessarily tell what it means to digitally sign such a rating. After all, the rating is valid with or without a digital signature, and in fact the presence of the signature in this case does not change the semantics of the underlying document.
Here's the problem: we are overloading PICS labels so that they may describe not only the semantics of named documents but also the semantics of signatures attached to documents. But when the signature is concerned not with the contents of a document but with the contents of labels about documents, how do we distinguish between the semantics of the label itself and the semantics of the signature on the label? I might have an RSACi label that is digitally signed by three people. What's the meaning of each of those digital signatures? Must they be equivalent? If the semantics of the digital signature is defined by RSACi, and RSACi says nothing, then what's the default meaning? Is there a default meaning? [I think we could certainly define a default meaning, something like: "the holder of the key used to sign this label states that the labeled document and the given ratings list together satisfy the semantics of the given rating system." Something very weak like that.]
I suspect that we will eventually reach one of two conclusions:
The Backgrounder document states that these extended PICS labels need to support both parallel and cascaded digital signatures. Parallel digital signatures are easy and straightforward; simply include multiple signatures in the label-signature block:
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels
on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
extension
(optional "http://www.w3.org/PICS/DSig"
"((document-hash (md5 =mQENAzJIVvwAAAEH/3fI2oaZ=))
(label-signature
((rsa-md5 =qZOtfMNCg9/WdWEBvZTvIWPj=)
(SDSI-Principal:
(Public-Key: (Algorithm: rsa-md5)
(N: =b22O+CXLSJEv56AamFl=)
(E: 17))))
((rsa-sha1 =dchjshgvhuerbhdkbvfhkjf=)
(X-509v3-DN: "c=US@o=USPS-Aegis Star Pilot@cn=USPS, AEGIS"))
)
)")
ratings (suds 0.5 density 0 color/hue 1)
)
The semantics of parallel signatures are clear: absent a signature-specific semantic modification both signatures conform to the semantics dictated by the given rating service. Amendments or modifications to those given semantics would have to be stated within each particular signature block, as they may change on a per-signature basis.
Cascaded (serial) signatures are a different story, and cannot be expressed within a single label in this scheme. Since the semantics of a signature are dictated by a rating service, we would need to construct arbitrary-depth labels in order to support arbitrary-depth signatures. A cleaner solution (although requiring multiple label fetches, perhaps), is to create cascaded signatures by labeling labels. That is, assume that A signs a label for document D with ratings R. The semantics of that signature are defined by R in conjunction with the overall semantics of the rating system. If B wants to sign A's statement, then:
Naming a label as another document makes labels first-class objects, so serial signatures can each be embedded in labels defining their semantics.
One of the questions asked in the Backgrounder document
concerns handling multiple ratings. How are collections of
ratings signed? I think the answer to this questions depends on
the separate and joint semantics of the ratings systems in
question. That is, if two (or more) ratings systems have
compatible semantics (or, rather, non-conflicting semantics),
then perhaps one should be able to sign a joint declaration of
ratings. Such a signature is not possible within a single
extension
block as outlined in this document, as the scope of the extension
block is limited to a particular label.
To sign a collection of ratings one would have to:
This is equivalent to the work required to perform a cascaded signature. Notice that we assume implicitly when creating a compound signature that the rating services are compatible, that the semantics assigned to a signature by the rating services are compatible, and that any additional semantics assigned to the signature (within the signature block) are compatible.
We do not specify what happens when the semantics of the ratings services in a compound label are in conflict. Within traditional PICS itself it's not possible to mix ratings from multiple rating services. Any linkage between two rating services is thus provided by the signature, assuming that the semantics of one or more of the signed services actually provides for such linkage.
This note does not address the larger issues of transport of credentials beyond a basic assumption that any signature- or credential-related information may be encapsulated as necessary within the digital signature extension. Since it is not clear what sort of credentials will be required by various users, the digital signature extension needs to provide sufficient flexibility to encompass a number of formats and webs of trust.
It would be a mistake to characterize all the possible certificates that can show up in a digital signature extension as "identity certificates," as there is no requirement (and indeed it is not desirable) that the public key signing a label be bound to a known entity. Whether or not a particular user or system chooses to trust a presented security credential is an issue for the evaluating system's trust management policy.
To emphasize this point, Carl Ellison adds:
The meaning of a signature is frequently left out when people talk about digital signatures. I've been on a crusade lately to keep people focussed on the meaning -- or, what we in SPKI call "authorization". I believe I have found a way to unify X.509 certs, SDSI certs, SPKI certs, PICS labels and PolicyMaker programs, in terms of a single general operator which deals with these authorizations. I don't have time to write this up before the meeting. [I'm still not sure I'll be done with the present emergency and be able to attend.] But, if I do make it, I'll bring transparency pens and will be prepared to describe what I'm talking about -- assuming there's time for that. - Carl