Digital Signature Initiative Proposal

August 1, 1996 - {danield, jmiller, khare}@w3.org

Executive Summary

To help the Web reach its full potential, it is important that end users have a
reliable mechanism that allows them to decide what Web content they can trust. In
particular, the industry has found two classes of documents where public trust has become
an issue of sufficient magnitude to immediately impact profitability:

Active content (e.g. ActiveX controls, Java applets, Plug ins, application macros,
etc.). Users must have sufficient reliable information about the content to decide what
privileges it should be granted.

Documents implying commitments (e.g. price lists, press releases, political statements).
Users need to be encouraged to verify the authenticity of these documents, and the
purported issuers need to be able to demonstrate both authorship and non-authorship.

Both of these needs are addressed by the ability to attach digital signatures to
on-line documents. These signatures serve to identify the origin of a document. 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 purchases may be affected by statements from
PC Week or may be permitted only by endorsement of an MIS office.

Market forces have caused different sotfware vendors to field an initial solution to
part of the first problem. These solutions (one example is Microsoft's Authenticode)
do not adequately address the larger set of problems raised here, but they are
nevertheless running the risk of setting a de facto standard in the industry.

As a result of a pair of industry meetings, W3C believes that a high-intensity, short
duration project can result in the following deliverables:

A specification of the framework, protocols, and formats that would address both of
these issues and be endorsed by the full W3C membership (a "W3C
Recommendation").

A common body of code - a sample implementation - used industry-wide for implementing
the core of this framework.

An on-going process for maintaining and extending all of the above (e.g. a W3C Editorial
Review Board, or a submission to IETF or ANSI)

The end state of this project should be a marketplace where competition focuses on
benefits to users rather than vendors' cryptographic features and formats.

The core framework will not specify user interface, policy management,
administration, APIs, or tools. This project will allow member companies to significantly
reduce their costs in developing the basic technology while enabling innovation and
competition in areas of clear user benefit.

Background

In April 1996, W3C convened a group of member companies to discuss the industry
interest in cooperatively addressing the problems surrounding the distribution of signed
objects over the Web. After two days of discussion, the participants (representing Apple,
Digital, GTE, IBM, Microsoft, Netscape, Oracle, Sun, VeriSign, and others) concluded:

They were planning work in the area, and were interested in having W3C undertake work in
this area.

There are two issues that must be clearly separated, but addressed concurrently:

Specifying identity of the signer.

Specifying endorsements (what the signature means).

The work should make use of existing standards where possible, particularly PKCS#7,
X.509v3, and PICS.

As a result of this meeting, W3C agreed to hire a new staff member to allow the work to
proceed "at Internet speed," and created some private mailing lists to discuss
the work. Unfortunately, W3C did not find a suitable candidate prior to convening a second
meeting in July of 1996, though we remain committed to hiring one.

Current Status

Much of the July meeting was spent describing current work by the member companies.
During the Digital Signature session, the following were presented:

Microsoft demonstrated their Authenticode system as it exists in Internet Explorer
3.0 Beta 2, and described a number of their detailed design decisions.

JavaSoft presented their JAR (Java Archive) technology and discussed how it could
support digital signatures.

Netscape described both their plans for signing Java classes using external signatures
and the evolution of the Java security architecture.

Oracle, Bell Labs, Apple, and Peter Lipp (University of Technology, Graz, Austria) made
short presentations on their current work.

At the general session, Ron Rivest of MIT gave an overview of SDSI (Simple Distributed
Security Infrastructure), which receives strong support from several members as an
alternative to X.509v3 and PKCS#7.

We then laid out the four major components that seemed to be part of any digital
signature scheme, in order to see if it was reasonable to form a group to work on a common
structure to guarantee both interoperability between the different parties involved
(browsers, signing tools, etc), and greater flexibility than the current Microsoft
Authenticode system:

The signature must be able to be transported in three different ways

Embedded in the document for those document types that can be extended to support
this (e.g. HTML, Java)

Attached with the document, in transfer headers or a parallel or containing file
(using HTTP extension headers and PEP for instance)

by querying a trusted third party

There must be a common format for a signature block that supports either enclosing the
signed data or referencing remote data which is signed, and also allows for categorization
of what is being signed and incremental processing where applicable (PKCS#7 should be
considered for this purpose, but it is more than just a signature block and involves ASN.1
encoding technique. SDSI is also relevant as it provides a new signature block syntax, and
so is Cryptolopes from IBM).

A systematic means for specifying the semantics of the signature, i.e. a way of
specifying a general statement X believes Y about Z where the entity X is given
some level of trust, the predicate Y might be authorship, publication, or some level of
testing of a given piece of code, and the object Z is a document or program found on the
Web (PICS appears to provide the flexibility needed for that purpose, and a quick demo was
presented to the W3C SIG on Jul 29 1996 to that effect - see Appendix)

The solution cannot mandate a specific cryptographic algorithm and must not require a
single certification hierarchy.

Proposed Project

W3C proposes to start a Digital Signature Initiative project to address all four of the
above concerns. The goals of the project are:

To create both a specification and an interoperable code base (in at least 2 languages,
e.g. C and Java, and on 3 platforms: NT, Mac and Linux) that addresses all four of the
above issues.

To create an interoperability test suite that can be used to ascertain that the signing
technique works as expected by web browsers and by standalone signing/verification tools
(which could be as simple as manually creating a set of signed documents on one platform
and try to "check" them on another)

To reach public commitment by the project participants to adopt the specification as
part of their baseline product by participating in a public demonstration of the system
(by means of running a subset of the I14Y suite for instance).

In order to reach these goals, W3C proposes a short-term project (no more than 6 months
duration) to be followed by the creation of an Editorial Review Board for on-going work:

All W3C members will be invited to join in an email discussion forum and biweekly
project progress meetings by teleconference.

The W3C will issue a call for participation. Participation will require an initial 3 day
kick-off face-to-face meeting, a 2 day face-to-face meeting monthly thereafter, and
significant work on coding and specification between meetings. W3C estimates that this
will require the full-time commitment of an engineer for three months and half-time
participation for an additional three months (more definitive resource information will be
provided after the first kick-off meeting)

In responding to the call, the member companies must state what software, if any, they
have already created which can be contributed to a common code base as well as what code
they would be willing to contribute if developed under the project. The encumberance level
of the code brought in will have to be clearly stated at that time, and although
willingness to share and openly redistribute code is not required, it may affect the
Director's choice of participants.

The Director of the W3C will select no more than seven companies to participate in the
project from those responding to the call. The Director of the W3C may select, from time
to time, additional guests to participate in specific meetings.

The initial kick-off meeting will be held as soon as practical, and will include only
engineers from the member companies, engineers from the W3C staff, and a project manager
to be chosen by the Director of the W3C. W3C will circulate a list of relevant technical
background documents prior to this meeting, and require that all participants be prepared
to take technical decisions on behalf of their companies during the meeting.

There will be no publicity about this work without the explicit consent of the Director
of the W3C, who will confer with the participating companies. All press releases must be
cleared through the W3C. We anticipate one major press announcement at the successful
conclusion of the kick-off meeting, and another when the initial project completes.

Next Step

This document will be presented to the W3C Advisory Committee. After feedback is
received, we anticipate that a formal project (starting with the kick-off meeting) could
be launched by mid-September, 1996.

Comments on this document should be addressed (via email) to the authors listed above,
or to Tim Berners-Lee, timbl@w3.org, Director of the W3C.

Appendix: PICS examples

Following are the three sample PICS rating service descriptions and a corresponding GUI
that we showed on Monday July 29 at the general W3C Security meeting in Redmond. These,
generated by Rohit Khare, were intended to convey the idea of how a PICS-like system could
be used to:

allow a certificate authority to describe its certificate classifications so that users
can configure their systems to state which kinds of certs they will accept for what
purposes (i.e. "run without checking if Verisign Commercial Level 3 or higher, or
Verisign Individual Level 4")

allow an applet rating organization (hypothetical Gamelan...) to specify the kind of
sandbox required for an applet, and allow the user to specify what forms of sandbox are
permitted with what forms of certification of the code

allow an independent party (not the publisher or author) to state things about code or
companies producing code (in this case, the Software Publishers' Association stating facts
about commercial publication practices).

These are not intended to be real, just realistic. They are thought pieces. They are
not actual proposals for such services or systems, and they do not represent any formal
position by the W3C or the organizations mentioned in the descriptions themselves. They
can be demonstrated using a PICS compliant browser, like the Microsoft Internet Explorer
3.0 Beta 2 or later (just load them into the Labels system -- either a separate tab, or
part of the security section of Properties).

SPA status

((PICS-version 1.0)
(rating-system "http://www.spa.org/publishersv01.html")
(rating-service "http://www.spa.org/")
(name "Software Publishers Association Members")
(description "The SPA is a group of US Software Publishers. Its members adhere to the highest professional standards in producing consumer
software")
(category
(transmit-as "m")
(name "Status as a Software Publisher")
(label
(name "NOT Member")
(description "Firm is NOT a member of SPA")
(value 0))
(label
(name "Individual")
(description "Though the SPA does not have individual members, it has a signed pledge from this individual on file.")
(value 1))
(label
(name "Corporate Member")
(description "SPA Member in good standing as of label_time")
(value 2))
(label
(name "Applet Publisher")
(description "SPA Member which has been certified as an Applet publisher and signed a pledge of writing secure software")
(value 3))
)
)