Editor's Note:This document represents the general DSigarchitecture as envisioned by the DSig Design team. Work in implementing this architecturealong with interaction with other groups working on metadata related efforts (PICS-NG,XML, DSig Collections, etc. ) has led to substantial changes in the way we now envisionthe DSig architecture. The document presented below is incongruous with the current DSig1.0 Digital Signature specification and the planned direction for DSig 2.0 and thus isobsolete. A major revision of the DSig Architecture will be available by 1 December, 1997athttp://www.w3.org/pub/WWW/TR/WD-DSIG-label-arch.html.
This is a W3C Working Draft for review by W3C members and other interested parties. Itis a draft document and may be updated, replaced or obsoleted by other documents at anytime. It is inappropriate to use W3C Working Drafts as reference material or to cite themas other than "work in progress". A list of current W3C working drafts can befound at:http://www.w3.org/pub/WWW/TR.
Note: since working drafts are subject to frequent change, you are advised toreference the above URL, rather than the URLs for working drafts themselves.
This document presents the architecture and design rationale behind DSig's DigitalSignature Label specifications. The overall goal is to use digitally signed labels to makeauthenticatable assertions about standalone documents or about manifests of aggregateobjects. The three basic elements, digital signatures, assertions, and manifests, are eachanalyzed in terms of its design, operation, data format, and distribution strategy. Theseelements can be assembled today within a PICS label to make a signed assertion about aninformation resource, or by signing a manifest, making assertions about several resources.
The Digital Signature Label team is chartered with the design of a signed assertionformat which states 'thekeyholder believesassertion(s) aboutinformationresource(s).' This statement format satisfies the twin goals of the DSig project: toidentifyandendorse information resources. This team, in turn, has decomposed its goal intothree subtasks:
Each of these subtasks will result in interlocking technical specifications:
(Please consult the DSig Team pages for detailed updates on the timeline and status ofthese specifications.)
Each of these components can be combined in several ways; this document providescontext on how they fit together:
For example, a typical DSig scenario combines the three components in a tree. Here ishow an author might first package up an applet in a manifest declaring his ownership, thenadditional certify that the package, taken as a whole, is a safe and useful applet whenused correctly.
The recipient can reverse the process, verifying the author's signature andconstructing a pathway of three hash values and two assertions between the label and theeventual applet data proving the author's ownidentity andendorsement ofthat applet. DSig's real power, though, is that a third party can come along and replacesteps 3 and 4 above:
In this scenario, the end-user's trust manager can go seek out a reviewer's endorsementand make a similar induction chain from the reviewer to the "cool" applet. WithDSig in place, the end-user's trust policy can automate the decision process.
As part of its deliberations, the SigLabel team crafted a mission statement to defineits design envelope.
A Digital Signature Label is astandalone,cryptographically-protected statement that 'keyholder believesassertion aboutinformation resource(s)'.
Expanding some of the key terms defines the scope of our effort:
In this document, we illustrate several of the concepts referred to above with thefollowing icons:
 Key Information |  Information Resource |
 Identity Certificate |  Resource Reference Information |
 Ciphersuite |  Assertion |
 Digital Signature |  Signature Label |
 Signature Block |  Manifest |
This section describes the design, operation, format, and transmission of the DSigsignature block. Our SigBlock is a general-purpose, simply encoded,cryptographically-neutral standalone signature -- and it does not rely on any particularcertification/identification scheme, either. It does not have any inherent semantics: theSigBlock only establishes that the some process had access to the data and a secret (wewill argue later that its semantics are strengthened when it is embedded in a particularapplication).
The SigBlock was identified as a separate design task very early on in the project.Signature systems such as PKCS-7', PGP, etc. traditionally build upon a core datastructure which represents the actual cryptography, and DSig is no exception. On the otherhand, every signature system goes on to add idiosyncratic information to this structure:crytographic protection (padding, protection of algorithm identifiers),certification-authority dependence (naming, key serial #s), content-dependent modification(how is whitespace hashed in?), and mini-assertions (time of signature, whether signed inhardware/software). The result is then encoded in a particular format (ASN.1, ASCII armor)and often used to wrap the whole signed data stream. The design goals for the DSigSigBlock differentiate it from such approaches:
To understand the SigBlock design, consider this picture of the signing process:
[Diagram of document being signed by a ciphersuite and a key to produce a bright, shinydigital signature.]
[Diagram of the SigBlock itself with its pile of keyholder information, certificatesand digital signature cryptography bits.]
There are three central pieces of data in the diagrams above:
With these concepts in mind, here's the story:
Auser controls her ownsigning key andcertificate. Her softwareand hardware tokens implements a fewciphersuites. With adocument andchoice ofciphersuite in hand, the signature process runs through to completion andproduce a bright, shiny chunk ofsignature-crypto. Along the way, thesigningkey,date, andhash function name may have all been inputs to thesigning process and show up inside thesignature-crypto. To make a complete,formatted SigBlock, though, a few more pieces of information have to be pieced together asdiscussed in Section 3.3.
There are a few more operations available to our user. She can proceed to attachadditional parallel signatures of the same document. She may do this herself using severaldifferent algorithms so her recipients in other jurisdictions or in the future can verifyher signatures against whichever ciphersuites they (still) trust. Other like-mindedcolleagues can also attach their signatures to the same statement to support policies thatrequire K-of-N signatories to agree. She can't cascade another signature to her own,though. The DSIG design team has decided to support SigBlocks with parallel signatures,but not cascaded statements about a signature. Successive endorsements are still possible,though, by giving a SigLabel a name a producing another SigLabel about the first (SeeSection 4.4).
The SigBlock Format is a concrete representation of the various data elements requiredfor a standalone signature. Broadly speaking, there are two levels at which we discuss theSigBlock format: the generic arrangement of attribution-information and signature data,and the specific level of encoding choices for particular ciphersuites.
[@@ diagram of SigBlock data structure with examples ofhttp://w3.org/dsig/rsa/md5andhttp://rsalabs.com/PKCS-7/ --a structured set of bits vs. an opaque ASN.1blob]
At the generic level, a SigBlock needs to flesh out thesignature-crypto withinformation about the signer. The first step is to pair the signature withattribution-info,a passive container for certificates and other credentials. This allows the trustmanagement system to evaluate whether a certain keyholder is trusted and whether the keyis valid. The second step is to make a link from the signature to the keyholder, by addingsomekeyholder-info to the signature itself.
There are several kinds ofkeyholder-info envisioned by DSig: the key itself,a digested fingerprint of the key, a Distinguished Name, a certifying authority and serialnumber, a role, etc. Each type serves to establish a path from the key to a credential(keyholder). Remember, the wholeattribution-info section is optional material;thekeyholder-info is the only normative link from a signature to a certificationsystem. It's a critical disintermediating step, because it allows the user to separatelychoose a CA infrastructure without changing the signature block format.
That's it for the generic level. By treating the cryptography as opaque, the onlyadditional information required is keyholder identification. Within the cryptographicdetails, though, are a great number of critical, specific formatting decisions.
Theciphersuite is what defines the information found below it. For anexisting format, say PKCS-7' (for RSA), all that's possible is to say "coming up, oneblob of PKCS-7' data". DSig's preferred modes, though, encourage more trasnparency.The DSig ciphersuite for RSA, for example, is inspired by SDSI, with separate entries forthe exponent, ciphertext, hash algorithm, signature time, etc burst out into anS-expression.
Note well the location of the signature-timestamp: per the first goal listed in Section3.1, the only cryptographically protected data is found within the customizablesignature-crypto.If an implementation of RSA needs to sign its hash algorithm id, it can do so on its own-- rather than predicating that all DSig-usable ciphersuites must. For example, the USGovernment's Digital Signature Algorithm need not, since it is only defined in conjunctionwith SHA.
Of course, all this flexibility empowers any organization to issue a new ciphersuite --how can users trust that they are cryptographically safe combinations? Indeed, how willthe DSig project validate its own recommendations? In the end, users and organizationswill have to choose what makes sense for themselves. DSig will produce a small set of themost popular ciphersuites and work closely with leading cryptographers and organizationsto vet its work. In particular, the Signature Label Implementation Team will include auser-driven review team that will cooperate with RSA Labs (holder of the PKCSspecifications), the IETF, and IEEE 1363 in establishing its core set of DSigciphersuites.
It is worth reiterating that the SigBlock is only a stepping-stone in our work. It isnot deployable on its own for two reasons: 1) technologically, because it does not haveany pointer or connection to the data being signed -- not even a document hash (since somesignature ciphersuites do not expose an intermediate hash value) and 2) philosophically,because it does not include any assertions about the data being signed. Deploying 'naked'SigBlocks without associated assertions drags us back to circular question "yes, butwhat does this signaturemean?". In short, the DSig project only supportssigned assertions, which translates into SigBlocks embedded in PICS labels or in amanifest. SigBlocks may later be embedded in other formats, which is why we have made theeffort to separate out its definition -- but even then, not without clear, automatablesemantics in the new embedding.
The first implementation target is an embedding of SigBlocks into PICS 1.x labels, asdiscussed in Section 4.4. In this case, signing PICS ratings imbues SigBlocks withstronger semantics particular to this context: 'keyholder believes ratings are correct'.
While many signature projects have succeeded at proving the identity or provenance ofan information resource, the DSig project breaks new ground because of its emphasis onendorsement,in the form of signed assertions which users can rely upon to make trust decisionsautomatable. The bedrock of this work is reducing generic "assertions" toconcrete rating labels so we can have clear, machine-readable semantics to sign. In thissection, we discuss the design of a assertion format, inspired largely by PICS-1.x.
Though there are several reasons motivating out adoption of PICS -- its distributionmechanisms, established user base, rating organizations -- but this section only discussesthe rating part of a label; ensuring the integrity of the binding to the eventualinformation resource is a critical function presented in Section 5.
DSig needs an assertion system designed to convey a clear meaning applied to almost anykind of content. This drives two sets of design criteria, one about the semantics of'assertable' statements and another about what can be labeled.
DSig needs to apply assertions with those qualities to several different kinds ofdocuments:
Finally, there is a new consideration about theheritability of signedassertions. While it is technically correct to insist that ratings only apply to theparticular information resource specified, typical Web client usage may trigger a wholeseries of actions when visiting a single 'location': loading inline images, embeddedapplets, etc. So at one level, assertions need to precisely delineate what they apply to.Secondly, there is a mathematical question of how far to extend a network of linkedobjects. A SigBlock protects a label directly; the label points indirectly to a manifest;the manifest points indirectly to the target information resource; and so on. Even if eachstep of the way is verified by a document hash, how large can the tree grow withconfidence that all of the links allow the top-level assertion to be inherited? DSigdesign guidelines are clear on this point as well. The conservative rule is thatassertions only apply one level removed by default.
There are a number of additional considerations about working with collections ofdifferent resources, which are discussed at length in Section 5.
[Diagram: An signature label which combines an assertion, information about thereferenced resource, and a digital signature block. If we zoomed in on the SigLabel, aPICS 1.x label, it would contain a pointer-to-schema (URL), pointer-to-document (URI),machine-readable rating, extended non-machine-readable rating comments, info-about-rating(on, by, generic flag), info-about-document (resinfo), and embedded SigBlock.]
A rating assertion is a passive data structure which can be used to answer a series ofquestions, whether in the context of a simple content-filtering UI or a full-blown trustmanagement system:
Of course, an assertion label alone cannot prove that a recipient shouldbelievethat assertion. A Trust Management systems has to investigate several aspects of a signedlabel before making that decision. For example, the TM would have to establish theintegrity of the connection of the label to the resource it's labeling. Particular piecesof resource information can be attacked, but taken together they can prove the integrityof the association between assertion and the resource. For example, providing the namealone is vulnerable to attacks on the Domain Name System; a cryptographic hash could bereverse-engineered or 'birthday-attacked'; and a file length can be tampered with, but aTM system can check each of these.
All of this additional information, orresinfo, has its roots in PICS-1.1 usage,but expands the range of possible additional data and provides for its own extensionmechanism. More details can be found in the specification for signing PICS 1.x labels byBrian LaMacchia. Paul Resnick, one of the original designers of PICS, commented that:
I admit that the PICS-1.1 label format does not syntactically separate the components that describe the information resource (e.g., the URL, hash, and ratings) from those components that describe the label (e.g., expiration date, signature, by). The PICS designers' understanding of this separation idea evolved as we wrote the specs: in our text description of the fields in the spec, we divide them into those that describe the document and those that describe the label, but we didn't get so far as to make a syntactic distinction, in the labels themselves. It remains to be seen whether we can remedy this in PICS-1.2 or 2.0, but it is certainly an important design goal.
We are proposing using the PICS rating label format with some expected modifications.Some are minor, like allowing full S-expressions as the value of an extension field(instead of only allowing strings). Others are more substantial, but already in discussionfor PICS-1.2, such as string-valued ratings. As DSig implementation continues, we expect adialogue with the PICS Working Group which will influence the evolution of both projects.
With respect to signing PICS rating labels, there is a concern about which PICSextension fields are included under the protection of the SigBlock. For now, we proposethat the entire PICS label and all extension data must be signed together withoutexceptions.
Finally, it makes sense to provide default rating systems for basic signatureapplications, along the lines of 'This is True' and 'This is Mine'. Just as the SigBlockis used to prove the identity and integrity of an assertion, these rating systems can beused to make signed testaments of the provenance and veracity of information resourcesthemselves.
One of the primary reasons DSig builds upon PICS for its label syntax is to reusePICS's three label distribution mechanisms. Since SigLabels are just PICS labels withembedded SigBlocks, they can be sent:
The first mode could be popular for many other trust management applications, such asembedding SigLabels into applets, fonts, and other protected resources. Especially for thelatter two modes, though, there must be a reliable link to the actual informationresource. As discussed in Section 4.2, labels must accommodate a range of additionalresource information to vouch for the connection. Document hashes are a particularlyeffective way of proving the link even when the label and content are separated, but onlyfor static documents. For dynamic data, such as a chat room or live video camera feed,other properties might be used.
Note that this assertion distribution strategy also fixes a SigBlock distributionstrategy: embedded in rating labels. SigBlocks are only found embedded in PICS labels inthis scenario. This makes the association of a SigBlock to its signed data extremelyclear.
Finally, there is another implicit resource that must be distributed reliably with theassertions: the rating schema. Since a rating systems can legitimately exist in severallanguages and compatible versions, it is not a simple task to protect the integrity of thereference to the rating system. DSig recommends that applications which are sensitive tothis need should use manifests and include the exact rating system(s). In this case, arating system is just one more information resource the overall package depends on, like afont or a configuration file.
Many applications which call for the added security and integrity of digital signaturesactually address sets of interrelated content rather than a single information resource.Several of the organizations participating in the DSig design phase arrived with proposalsincluding proprietary manifest formats. This section presents common design considerationsfor using standalone manifest files and proposes a new intermediate, the DSig CommonManifest Format (DCMF).
The critical difference between a set of singular signed assertions and as collectedinto a manifest and signed jointly is the interrelationships between the elements.Manifests establish relationships by the mere act of selection and grouping; by ratingcomponents on the same scales; and through additional resource information. Each entry inthe manifest also needs to provide enough information about the target resource tounambiguously identify it. Finally, there can be additional goals for particular manifestformats, such as optimized data layout, real-time manifest generation, and user interfacesupport.
The relationships between components can dramatically shade their meaning. A pictureand a caption, for example, are strongly connected, and a different choice amongalternative captions can shade the meaning of the picture dramatically. First, the act ofpreparing a manifest alone allows us to make statements about the aggregate as a whole.Different manifests can associate a picture with different captions. In a legal context,it can be essential to demonstrate that all parties are referring to the completeagreement (e.g. a Will and its codicils). Second, the assertions about each entry in themanifest establish another kind of relationship, specific to the rating system at hand. Auser could select components by label ('please show all the Impressionist pictures').Third, additional resource information can clarify relationships like'32-bit-color-version-of' or 'full-screen-sized'.
Beyond clarifying the semantics of a package, a manifest file must unambiguouslyidentify its components to legitimately stand in for signing each individual part.Operationally, manifests allow us to seal N resources at once, which is more efficientthan having to execute N potentially expensive and time-consuming signature operations. Tomathematically verify this aggregation, each referent must include verifiable informationabout the target resource, like its hash fingerprints. In fact, the entire resinfomechanism presented in Section 4.2 actually emerged from manifest discussions. ThePICS-1.1 resinfo extension was created to emphasize the isomorphism between an individuallabel and an individual manifest referent.
Finally, there can be more specific design goals for particular manifest formats. Someapplications may integrate the 'user interface' of a package with the manifest itself. AnHTML WebMap file can represent manifest referentsand a visual hierarchy,multimedia descriptions, and more. Another example is signing streaming or dynamic data.For a real-time video stream, it may be essential to provide a new kind of hash tree foreach video segment rather than a single hash value at the end. A dynamically generated webpage may have several components and use a manifest that sends its table-of-contentsfirst, then its hash values. Such data layout considerations are discussed in Section 5.3and in the DCMF specification.
[Diagram: a SigLabel pointing at an aggregate-object-manifest instead of a singledocument (and the target resources, in turn, which can also be manifests).]
As far as the signature label is concerned, a manifest is just another type ofinformation resource. In turn, the manifest is just the collection of resource references;the cryptographic protection is inherited from the SigLabel and doesn't appear directlywithin the manifest. The induction chain from the SigBlock to the target resource ismediated by two assertions, one from the SigLabel that applies to the entire manifest andan optional assertion from the referent in the manifest.
The manifest itself provides several pieces of data for each referent: name, hashinformation, additional resource information, and a rating assertion. This is the sameinformation provided for a reference in a singular PICS SigLabel, too. The hashinformation, in particular, is the crux of the chaining argument that allows the top-levelSigBlock to 'sign' the target data. In fact, the chain can extend further if the target isanother aggregate subcomponent represented by a manifest.
There is a new operational concern about signing several assertions jointly. To protectthe cryptographic hygiene of a signing key, it may be necessary to restrict which kinds ofassertions it can speak for. For example, it could be risky to use the same key to protecthigh-value assertions about indemification and low-value assertions about the colorscheme.
The data format for the manifest should be compact and allow efficient access to dataabout each referent. In DCMF, 'fixed' information like the selection of hash algorithmsused and the rating schemas are declared once, in a preamble. Then, for each referentseveral columns of data are available: the name (URI), ratings, several hash values (ifapplicable), and additional resinfo.
This abstract model of a manifest describes many formats: Java JARchives, IBM'sCryptolope, a PICS labellist, an HTML Web collection (Sitemap). Though a file in any ofthese formats could be signed with a SigLabel, and a Trust Management engine could parseall of them to establish links back to the target resources, DCMF's alleviatescompatiblity problems. DCMF's data layout is designed to be compact, streamable, easilydecoded, extensible, and scalable -- an evolutionary successor to many of thesecontenders.
Since manifests are useful indexes quite separately from SigLabels, severaldistribution strategies should be supported. Standalone manifest files can be madeavailable with the data, from third parties, or embedded directly into a package (e.g. aZIP or TAR archive). The complexity is compounded by the additional options fordistributing SigLabels. The SigLabel providing the integrity of a manifest might beembedded within it, sent with it over HTTP, or come from yet another third party.
As long as a manifest file is static (i.e. can be hashed itself) and can provideverifiable information about which resources it refers to, any of these distributionstrategies will work. The mathematics can support an induction chain from any SigLabelthrough any manifest to any target resource -- even through a cascaded chain of nestedmanifests.
Though we have separated the tasks into understanding how each of these three pieceswork on their own, they are intended to work together. This section explains how the DSigproject implementation will assemble these components to solve users' trust problems.
In general, the user starts with a single object or aggregate object to make anassertion about. The assertion is prepared as a PICS 1.x rating about the object oraggregate, then the label is signed with a SigBlock. Indeed, several signatures can beincluded in parallel, from multiple endorsers using multiple ciphersuites. In the case ofan aggregate object, the components are listed out in a manifest, optionally includingassertions describing the role of each.
There are many combinations of distributions strategies to reach the end user. A simpleon-line scenario is a signed press release with a SigLabel in its HTTP entity headers. Foran aggregate object distributed over the Web, a user could fetch the manifest over HTTPand receive the author's SigLabel with it before proceeding to fetch any of itscomponents. A CD-ROM might include a manifest with an embedded SigLabel. Before running anapplet found on the Internet, a user's trust engine could try to fetch a SigLabel from athird-party label bureau. Scenarios can be generated for every combination of informationresource, speaker, format, and distribution technique.
Digital signature labels are assembled from three interlocking components. Signatureblocks, assertions, and manifests have each been described in terms of their design,operation, format, and distribution. The initial deployment target is signed PICS ratinglabels applied to single information resources; manifests are a particular kind ofinformation resource which can be used to point in turn at several more resources whilemaintaining cryptographic integrity of the signature label.
This architecture document serves as the context for several subsidiary technicaldocuments specifying the exact syntax and semantics of the SigBlock, SigBlock embedding inPICS 1.x, and DSig Common Manifest Format (DCMF). Comments on this document should bedirected to the author or any of the specification editors. The SigLabel design team hasits own (closed) mailing list for discussing these issues atw3c-dsig-label@w3.org;W3C member organizations can send comments there directly. Members are also encouraged tojoin the DSig implementation phase to continue developing these specifications inproducts, or through our user-organization review teams.
This document reflects a hard-won consensus among all the various players of theSigLabel team. Many of the ideas here came from different participants; my role isprimarily to wrap it all together here in this architecture document. Kudos to all!
Copyright © 1997W3C(MIT,INRIA,Keio ), All Rights Reserved. W3Cliability,trademark,documentuseandsoftwarelicensingrules apply.