Digital Signature Initiative

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:

  1. 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.
  2. 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:

  1. 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").
  2. A common body of code - a sample implementation - used industry-wide for implementing the core of this framework.
  3. An on-going process for maintaining and extending all of the above (e.g. an 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:

  1. They were planning work in the area, and were interested in having W3C undertake work in this area.
  2. There are two issues that must be clearly separated, but addressed concurrently:
  3. The work should make use of existing standards where possible, particularly PKCS7, 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," 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:

At the general session, Ron Rivest of MIT gave an overview of SDSI (Simple Distributed Security Architecture), 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:

  1. The signature must be able to be transported in three different ways
  2. 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 involve ASN.1 encoding technique. SDSI is also relevant as it provides a new signature block syntax).
  3. 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)

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:

  1. 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.
  2. 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)
  3. 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:

  1. All W3C members will be invited to participate in an email discussion forum and biweekly project progress meetings by teleconference.
  2. 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)
  3. 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.
  4. 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.
  5. 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.
  6. 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 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:

  1. 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")
  2. 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
  3. 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 to others by using 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).

Java Applet Capabilities


((PICS-version 1.0)
 (rating-system "http://www.javasoft.com/capsv01.html")
 (rating-service "http://www.gamelan.com/")
 (name "Gamelan's Assessment of Java Applet Capabilities")
 (description "JavaSoft has defined several levels of priviliges an applet might request a user for to do its job. Gamelan rates applets on this scale to let you know which capabilities we think are appropriate")

 (category
  (transmit-as "f")
  (name "Filesystem Access Levels")
  (label
   (name "None")
   (description "Does NOT require access to disk drives")
   (value 0))
  (label
   (name "Limited Read")
   (description "Needs to read specific directories -- PICS needs exts to describe which dirs")
   (value 1))
  (label
   (name "Limited Read-Write")
   (description "Needs to read AND WRITE specific directories -- PICS needs exts to describe which dirs")
   (value 2))
  (label
   (name "Full Access")
   (description "Needs to read and write files anywhere in your system")
   (value 3)))

 (category
  (transmit-as "n")
  (name "Network Access Levels")
  (label
   (name "None")
   (description "Does NOT require access to the Internet")
   (value 0))
  (label
   (name "Limited Hosts")
   (description "Needs to contact specific hosts -- PICS needs exts to describe which hosts, and which ports")
   (value 1))
  (label
   (name "Limited Protocols")
   (description "Needs to use specific network protocols -- PICS needs exts to describe which hosts, and which ports")
   (value 2))
  (label
   (name "Full Access")
   (description "Needs to contact hosts anywhere on the Internet using any protocols")
   (value 3)))

 (category
  (transmit-as "u")
  (name "User Interface Access Levels")
  (label
   (name "None")
   (description "Does NOT have any user interface")
   (value 0))
  (label
   (name "Text Only")
   (description "Only uses java.io")
   (value 1))
  (label
   (name "Embedded")
   (description "Only draws within an applet frame")
   (value 2))
  (label
   (name "Full Graphical Access")
   (description "Can make any AWT call, including creating windows -- PICS 
should specify which version of AWT?")
   (value 3)))

 (category
  (transmit-as "c")
  (name "Additional Capabilities -- multivalue")
  (label
   (name "Color")
   (description "Requires a color depth -- can PICS specify depth?")
   (value 0))
  (label
   (name "Audio")
   (description "Requires basic audio support, up to 16bit 44kHz")
   (value 1))
  (label
   (name "RealAudio")
   (description "Requires RealAudio (TM) support")
   (value 2))
  (label
   (name "VRML")
   (description "Works only in conjunction with VRML support")
   (value 3)))

 )

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))
 )


 )

VERISIGN ID level


((PICS-version 1.0)
 (rating-system "http://www.versign.com/certsv01.html")
 (rating-service "http://www.verisign.com/")
 (name "Verisign Identity Assurance Levels")
 (description "Verisign issues a variety of identity certificates for indivduals and organization. This system describes the leves so you can choose which Verisign DigitalIDs you trust.")

 (category
  (transmit-as "c")
  (name "Commercial Assurance Levels")
  (label
   (name "Basic")
   (description "Self-declared as a Commerical Entity")
   (value 1))
  (label
   (name "Registered")
   (description "Has a DUNS number, place of business, and gov't registration")
   (value 2))
  (label
   (name "Solvent")
   (description "Has a DUNS credit rating above CCC and high-grade key protection")
   (value 3))
  (label
   (name "Blue Chip")
   (description "Publically traded firm with military-grade key protection")
   (value 4)))

 (category
  (transmit-as "i")
  (name "Individual Assurance Levels")
  (label
   (name "Self")
   (description "Has a unique Internet Address")
   (value 1))
  (label
   (name "Basic")
   (description "Has a real name and address")
   (value 2))
  (label
   (name "Notarized")
   (description "Provided passport, birth certificate, and license to a Notary Public")
   (value 3))
  (label
   (name "Investigated")
   (description "Background checked by credit bureaus and Verisign investigation")
   (value 4))
 )
 )