Editor
Authors:
This is a prerelease of the DSig 1.0 Signature Labels working draft. Please reserve your comments for the official public draft which will be available on 23 May, 1997. It is incomplete at this time.
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.
The W3C Digital Signature ("DSig") Working Group proposes a standard format for making digitally-signed machine-readable assertions about a particular information resource. More generically, it is the goal of the DSig project to provide a mechanism to make the statement:
signer believes statement about information resource
This document describes a method of utilizing PICS 1.1 labels with extensions to meet this goal. It also provides detailed usage guidelines for creating PICS 1.1 labels which are valid DSig 1.0 Signature labels.
In its role as a DSig 1.0 signature of , the PICS label provides the syntax of the signature label. It gives us both a means of transporting signature block data and a simple framework for making the machine-readable assertions. While DSig 1.0 does not meet all of the design goals of the DSig project, it provides a substantial basis from which to build.
In its simplest form, the DSig 1.0 Signature Label is a signed statement about a specific information resource. If this information resource is fully named in the for option of the label (or implied by placing the label within the information resource itself), then a cryptographic link can be added in the form of the refinfo extension. The resulting DSig 1.0 Signature Labels label can be signed one or more times with the sigblock extension. In DSig 1.0, it is important to note:
The basic structure of a PICS 1.1 labels described below is:
<<PICTURE OMITTED>>
W3C recommendations and working drafts related to this document include:
We assume familiarity with these documents.
At the core of DSig 1.0 is the PICS 1.1 label, so we begin by reviewing the PICS 1.1 architecture and illustrating how DSig 1.0 fits into it.
At the core of the PICS infrastructure is the rating service. The rating service either chooses an existing, or develops a new, rating system to use in labeling content. The rating system, described in a human readable form at the rating system URL is the range of statements that can be made. The rating service establishes criteria for determining who can label content using their name and how the labels must be applied. This combination of criteria and rating system makes up a coterie which is uniquely identified by a service URL. This service URL becomes the brand, if you will, of the rating service. At a minimum, the service URL will return a human readable form of the rating criteria and a link to the description of the rating system. The rating service is also responsible for delivering a service description file. The is a machine readable version of the rating system with pointers to the rating system URL and the rating service. While not required, it is recommended that this be available automatically at the service URL. A labeler, given authority by the rating service, uses the criteria established by them along with the rating system to label content. These content labels contain a statement about the content of the resource being labeled and contain a link back to the service URL. Content labels can come in the content itself, with the content or from a trusted third party such as a label bureau. Policies determine what actions are taken based on the specific statements in the content label. If a content label is based on an unknown service URL, it is a simple (and automatable) task to retrieve the appropriate service description file to understand what statements are being made in the label.
DSig utilizes the PICS infrastructure as described above with a few exceptions:
PICS labels are always transmitted as labellists. The most common variant is a list containing one label. Full details of PICS Labels and Label Lists are available in PICS Label Distribution Label Syntax and Communication Protocols Version 1.1, sections:
In DSig, each assertion about an information resource is given in a label. A label consists of a service identifier, options, extensions and an assertion (in PICS 1.1 the assertion is called a rating). The service identifier is the URL chosen by the rating service (see Rating Services and Rating Systems) as its unique identifier. Options and extensions give additional properties of the label, the document being labeled and properties of the assertion itself. The assertion itself is a set of attribute-value pairs that describe a document along one or more dimensions. One or more labels may be distributed together as a list. Among other things, this allows for some data aggregation for efficiency. The general form for a label list (formatted for presentation, and not showing error status codes) is:
(PICS-1.1 <service 1 url> [service 1 option...] labels [label 1 option...] ratings (<category> <value> ...) [label 2 option...] ratings (<category> <value> ...) ... <service 2 url> [service 2 option...] labels [label 3 option...] ratings (<category> <value> ...) [label 4 option...] ratings (<category> <value> ...) ... ...)
As you can see, labels in a labellist are grouped by service. Each service may have service options which are inherited by each label under that service. These service options can be overridden by individual label options but they are inherited by every label in that service section. When a new service is identified in the labellist, the options from the previous service no longer apply. The full set of options which applies to a label are the label's service options, overridden by any specific label options. In the above example label 4 could be represented as
(PICS-1.1 <service 2 url> labels [ service 2 options + label 4 option...] ratings (<category> <value> ...))
In DSig 1.0, we sign individual labels. Signatures on individual labels can exclude specific options and assertion (rating) categories.The details of signing labels is below.
In PICS, there are two types of labels:
Now we examine how to apply the PICS 1.1 options to DSig 1.0 Signature Labels, but before we defined the syntax of embedding signature information within a PICS 1.1 label, we have to specify the semantics of the construction. By convention, a DSig signature block itself has the weakest possible semantics, namely "the entity possessing the key that signed the signature had access to the secret key used to generate the signature and the signed data at the same time." For DSig 1.0 Signature Labels, we want something stronger that also includes the ratings within the label. Thus, by convention, a PICS label which includes (optionally) a DSig resource information (resinfo) extension and a DSig signature block (sigblock ) extension has the following semantics:
"The entity possessing the secret key that digitally signed this PICS 1.1 label had access to the secret key and the label at the same time and states that the statements made within the label are valid"
Following the format given in PICS Label Distribution Label Syntax and Communication Protocols Version 1.1 we will review each of the PICS 1.1 options; giving appropriate usage rules for applying them within the context of DSig 1.0 Signature Labels.
PICS label options can be divided into three groups. Options from the first group supply information about the document to which the label applies. Options from the second group supply information about the label itself. Options in the last group provides miscellaneous information.
Notes:
As you can see from the list of options above, there are several options (MIC-md5 and signature-RSA-MD5) which have been obsoleted in DSig 1.0. The extensions which replace these, resinfo and sigblock options are outlined below.
A DSig label 'signs' an information resource. To do this, it must have a cryptographic connection to that resource. This is accomplished by having one or more hashes of the information resource included in the signature label. This was accomplished partially in PICS 1.1 label with the MIC-md5 (or md5) option. Unfortunately, this option only allows for one hash and was tied to one cryptographic algorithm. This was too limiting for the broader needs of DSig. DSig 1.0 replaces this option with the resinfo extension.
A PICS 1.1 label also contains a signature option, signature-RSA-MD5, but, like the MIC-md5 hash it contains only a single signature and is restricted to a single cryptographic algorithm. Again, the DSig team has a replacement for this option, the sigblock extension. This extension contains one or more signatures using any cryptographic algorithm and information in the form of certificates or links to certificates which should help in determining the identity of the signer and their authorizations.
Neither extension is required by DSig. While either can be omitted, omitting both extensions results in a PICS 1.1 label.
The goal of the resource reference information (resinfo) extension is to provide a cryptographic tie to an information resource. DSig 1.0's resinfo extension builds upon the PICS 1.1 for and at options, providing this cryptographic link. Specifically, the resinfo extension provides a mechanism for adding one or more hashes, in any named cryptographic algorithm, of the information resource identified by the URL in the for option of the label. These hashes provide a means for the receiver of the label to determine if the information resource they have is the same as the one which the assertion was made about.
The resinfo extension is associated with a specific for option. The for option can either be a service or label option. The resinfo extension must appear at the same level as the for option it is associated with in the label list.
Structurally, Resinfo contains one or more hashes of the information resource consisting of: a hash algorithm identifier, the actual hash of the resource and optionally, the date hash was computed.
("hash algorithm identifier" "base64-string of hash" "hash date")*
The hash algorithm identifier is a URL. It is included to identify the specific hashing algorithm that the hash which follows it was computed with. The DSig 1.0 compliance document identifies several such hash algorithm URLs. To ensure that no other hash algorithm uses the same identifier, the identifier it must be a valid URL. This in effect creates a distributed registry of unique names which can be created and shared by any community of interest.
Since the hash algorithm identifier is a URL, it can be resolved to retrieve a document. That document may be in any format, but we recommend that it:
Any incompatible change in a hash algorithm should be accomplished by creating an entirely new hash algorithm identifier URL.
Usage notes:
http://www.w3.org/PICS/DSig-suites/resinfo-1_0.html
or the entire label should be disregarded.The following grammar, in modified BNF, describes the syntax of the resinfo extension to a PICS 1.1 label. This extension is a valid extension per the PICS 1.1 specifications.
resinfo-extension :: 'extension (' mand/opt '"http://www.w3.org/PICS/DSig-suites/resinfo-1_0.html"' resinfo-data+ ')' mand/opt :: 'optional' | 'mandatory' resinfo-data :: '(' HashAlgoURL resource-hash hash-date*1 ')' HashAlgoURL :: quotedURL quotedURL :: '"' URL '"' resource-hash :: '"base64-string"' hash-date :: quoted-ISO-date quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"' based on the ISO 8601:1988 date and time standard, restricted to the specific form described here: YYYY :: four-digit year MM :: two-digit month (01=January, etc.) DD :: two-digit day of month (01 through 31) hh :: two digits of hour (00 through 23) (am/pm NOT allowed) mm :: two digits of minute (00 through 60) S :: sign of time zone offset from UTC ('+' or '-') tz :: four digit amount of offset from UTC (e.g., 1512 means 15 hours and 12 minutes) For example, "1994.11.05T08:15-0500" is a valid quoted-ISO-date denoting November 5, 1994, 8:15 am, US Eastern Standard Time Note: The ISO standard allows considerably greater flexibility than that described here. PICS requires precisely the syntax described here -- neither the time nor the time zone may be omitted, none of the alternate formats are permitted, and the punctuation must be as specified here. base64-string :: as defined in RFC-1521.
Notes:
The following example shows a valid DSig 1.0 resinfo extension with two hashes of the referenced information resource.
extension (optional
"http://www.w3.org/PICS/DSig/resinfo-1_0.html"
(
"http://www.w3.org/PICS/DSig/SHA1.html"
"base64-string of hash") (
"http://www.w3.org/PICS/DSig/MD5.html"
"base64-string of hash" "1997.02.05T08:15-0500"))
In this example, we begin with the PICS 1.1 options extension (optional which identifies this as an optional extension to the PICS label it is contained within. This is followed by a URL http://www.w3.org/PICS/DSig-suites/resinfo-1_0.html which provides a unique name for the extension. Dereferencing the URL should provide human readable information on the extension. Finally we have two repeating subsections of the extension. These contain the hash information. The general form of these is hash algorithm identifier, hash data, and optionally a hash date. Here again, dereferencing the hash algorithm identifier URL would return a human readable description, this time of the hash algorithm. In our specific example above, the first hash is of type SHA1. This is followed by the actual hash data and followed by the date the hash was computed. This is repeated using the MD5 has algorithm.
The sigblock extension specification will be added here shortly. It is currently under revision.
DSig 1.0 signature labels are PICS 1.1 labels with extensions. The resinfo extension provides a cryptographic tie between the label and the information resource. The sigblock extension is the 'signature'. It identifies who has signed the information resource, when this signature has been generated, which algorithms were used to generate the signature, and of course, the signature data itself. Signatures can only be applied to individual labels not to a label list. (Label signatures are given as label options for the label they apply to.)
Since even a single DSig 1.0 signature label must be represented as a PICS 1.1 label list, let's begin by looking at the structure of such a list.
(PICS-1.1 <service 1 url> [service 1 option...] labels [label 1 options...] [label 1 signature] ratings (<category> <value> ...) [label 2 options...] [label 2 signature] ratings (<category> <value> ...) ... <service 2 url> [service 2 option...] labels [label 3 options...] [label 3 signature] ratings (<category> <value> ...) [label 4 options...] [label 4 signature] ratings (<category> <value> ...) ... ...)
The process for signing a label is fairly straight forward whether the labellist the label is contained in is made up of a single label or a series of labels. First, we create an equivalent standalone label. Then we canonicalize the equivalent standalone label. Finally, we sign the result and place the sigblock extension that is created back into the label as a label option. A label can have at most one resinfo extension (which it may inherit from the service options) and one sigblock extension.
An equivalent standalone label is a PICS 1.1 labellist containing a single label, where the label has been normalized to a form where all options are label options (this includes extension options) and the sigblock extension (if present) has been removed. From the example labellist above, label 4 could be reduced to the single label:
(PICS-1.1 <service 2 url> labels [service 2 option...] + [label 4 option...] ratings (label 4 ratings <category> <value> ...))
This is not yet an equivalent standalone label though. We still need to take into account any options or ratings named by the Exclude standard signature suite option of the sigblock extension. As explained in the Embedding the DSig Signature Block section, the Exclude option allows the signer to specify options and rating categories which they want to exclude from their signature.
The resulting labellist (below) is the equivalent standalone label.
(PICS-1.1 <service 2 url> labels (Total Label 4 Options) ratings (Total Label 4 Ratings))
Where:
Total Label 4 Options = [service 2 option...] + [label 4 option...] - excluded options Total Label 4 Ratings = label 4 ratings (<category> <value> ...) - excluded category/value pairs
(The following example is incorrect and will be updated!!)
(PICS-1.1 "http://www.gcf.org/v2.5" by "John Doe" labels for "http://w3.org/PICS/Overview.html" extension (optional "http://www.w3.org/pub/DSIG/v1.0/resinfo" (resinfo (ResHashes (MD5 =aba212412412=)))) extension (optional "http://www.w3.org/pub/DSIG/v1.0/cryptinfo" (sigblock (signature (SigInfo (on 1996.11.05T08:15-0500") (CryptoSuite RSA/MD5)))))) on "1994.11.05T08:15-0500" ratings (suds 0.5 density 0 color 1)) The normalized form remove excessive white-space and linefeed, ( PICS-1.1 "http://www.gcf.org/v2.5" by "John Doe" labels for "http://w3.org/PICS/Overview.html" extension ( optional "http://www.w3.org/pub/DSIG/v1.0/resinfo" ( resinfo ( ResHashes ( MD5 =aba212412412= ) ) ) ) extension ( optional "http://www.w3.org/pub/DSIG/v1.0/cr yptinfo" ( sigblock ( signature ( SigInfo ( on 1994.11.05T08:15-0500" ) ( CryptoSuite RSA/MD5 ) ) ) ) ) ) on "1996.11.05T08:15-0500" r ( suds 0.5 density 0 color 1 ) ) After the signature is computed, the SigData is inserted as well as other 'unprotected' information to sigblock. Now this PICS label ready for FedEx delivery. (PICS-1.1 "http://www.gcf.org/v2.5" by "John Doe" labels for "http://w3.org/PICS/Overview.html" extension (optional "http://www.w3.org/pub/DSIG/v1.0/resinfo" (resinfo (ResHashes (MD5 =aba212412412=)))) extension (optional "http://www.w3.org/pub/DSIG/v1.0/cryptinfo" (sigblock (Attrib-Info ("http://iso.org/X/509/v3" =cdc323323223=) ("http://pgp.com/pgcert" =ded565566556=)) (signature (KeyHolder (RSA =gfg787788787= =1100)) (SigInfo (on 1996.11.05T08:15-0500") (CryptoSuite RSA/MD5)) (SigData =jkj89998394=)))) on "1994.11.05T08:15-0500" ratings (suds 0.5 density 0 color 1))
While PICS allows labels to be truncated to reduce their size, if this is done in DSig 1.0 after signing, the signature will no longer be valid. An alternative is to distribute an unsigned label with the complete option pointing to a full, signed label. Client software in need of a signed label can dereference the complete option's URL to retrieve a complete, signed label.
There is a security hole in the above proposal. The semantics of the assertions (ratings) in a PICS 1.1 label are defined by the rating service, and the only information about the rating service contained within the label itself is the service's URL. Since the human-readable description pointed to by that URL is what defines the rating semantics, it is possible under the current scheme for the semantics of the rating service to change after the label has been created without invalidating the label.
If this is a concern, a simple policy in the trust engine that evaluates signatures could be established to require a separate signature label on the service description file.
DSig 1.0 labels are PICS 1.1 compliant and thus may be transported in the same way as PICS 1.1 labels. PICS Label Distribution Label Syntax and Communication Protocols Version 1.1 identifies three ways that a PICS label can be transported: In an HTML document, With a document transported via a protocol that uses RFC-822 headers, or Separately from the document.
Labels may also exist on their own, referencable as a URL. When the URL is dereferenced it returns an item of type application/pics-labels that contains a labellist.
The specifications for embedding a PICS 1.1 label in an HTML document are well defined. It is possible to use DSig labels in document other than HTML. To do this, a specification for how the label is embedded in that document type and how the document is normalized for hashing into the label must be created.
Philip DesAutels
Project Manager, Technology and Society Domain, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Tel: +1.617.258.5714
Fax: +1.617.258.5999
Email: philipd@w3.org
Peter Lipp
Technical University, Gratz
Email: plipp@iaik.tu-graz.ac.at
Brian LaMacchia
AT&T Research Labs
Email: bal@research.att.com
Yang-hua Chu
Technical Staff, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Tel: +1.617.253.5884
Fax: +1.617.258.5999
Email: yhchu@w3.org