W3CWD-DSIG-label-970516

DSig 1.0 Signature Labels

Using PICS 1.1 Labels for Digital Signatures

W3C Working Draft 16-May-97

This version:
http://www.w3.org/pub/WWW/TR/WD-DSIG-label-970516.html
Latest Version:
http://www.w3.org/pub/WWW/TR/WD-DSIG-label.html
Previous Version:
none

Editor

Authors:

Status of This Document

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.

Contents

DSig 1.0 Overview

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.

PICS Architecture

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 1.1 labels and label lists

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:

PICS Options and DSig

Semantics of Embedded Signature Blocks

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"

Applying PICS to DSig

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.

  1. Information about the document that is labeled.
    at quoted-ISO-date
    The last modification date of the information resource to which this assertion applies, at the time the assertion was made . This can serve as a less expensive, but less reliable, alternative to the DSig 1.0 resinfo extension.
    MIC-md5 "Base64-string"
    -or- md5 "Base64-string"
    Not used in DSig 1.0. If this option is present in a DSig 1.0 label, is should be ignored. Further, it should be removed from the label for the purposes of signing. This has been replaced with the DSig 1.0 resinfo extension.
  2. Information about the label itself.
    by quotedname
    An identifier for the person or entity who was responsible for creating this particular label. This may be human readable, an email address, or it may be used to contain a (base-64 encoded) set of certificates and other information used to verify the signature on the label. For DSig 1.0, this field is considered to be for informational only. The by option name need not be the same as that of the signer(s). In the DSig 1.0 sigblock extension, the identity of the signer is part of the signature section and certificates (or references to them) identifying the signer(s) are contained in the attribution information section not the extension.
    for quotedURL
    The URL (or prefix string of a URL) of the information resource to which this assertion applies. This option must contain the full URL of the information resource if the DSig 1.0 resinfo extension is going to be used to provide a hash of the information resource referenced in the label. This option is required for generic labels and in certain other cases (see "Requesting Labels Separately," PICS Label Distribution Label Syntax and Communication Protocols Version 1.1); it is optional in other cases. Since a single document can have many URLs, the URL used to retrieve a document may differ from the URL in the for option of a label that accompanies the document, but the document retrieved must be the same document or the hash(s) contained in the resinfo extension will not be valid. The for option is valid as both a service and label option in a label list. The DSig 1.0 resinfo extension is valid in either of these cases.
    generic boolean
    -or- gen boolean
    If this option is set to true, the label can be applied to any URL starting with the prefix given in the for option. By default, this option is false. It is used to supply ratings for entire sites or any subparts of sites. All generic labels must also include the for option. A generic label should not be created unless it can be legitimately applied to all documents whose URL begins with the prefix specified in the for option (even if a more specific label exists). If the generic option is used with a true value, the DSig 1.0 resinfo extension can not be used because there will not be a specific information resource to hash.
    on quoted-ISO-date
    The date on which this label was created. This may be different than the date the label was signed (in the DSig 1.0 signature block extension).
    signature-RSA-MD5 "Base64-string"
    Not used in DSig 1.0. If this option is present in a DSig 1.0 label, is should be ignored. Further, it should be removed from the label for the purposes of signing. This has been replaced with the DSig 1.0 signature block extension.
    until quoted-ISO-date
    -or- exp quoted-ISO-date
    The date on which the assertions in this label expire.
  3. Other information.
    comment quotedname
    Information for humans who may see the label; no associated semantics.
    complete-label quotedURL
    -or- full quotedURL
    Dereferencing this URL returns a complete label that can be used in place of the current one. The complete label has values for as many attributes as possible. This is used when a short label is transmitted for performance purposes but additional information is also available. When the URL is dereferenced it returns an item of type application/pics-labels that contains a labellist with exactly one label. In DSig 1.0 this might be used if the initial label transmitted was an abbreviated version of the full label. The abbreviated version might contain minimal options and no signature. The client application could dereference this URL to get the full, signed version of the label.
    extension (optional quotedURL data*)
    -or- extension (mandatory quotedURL data*)
    Future extension mechanism. To avoid duplication of extension names, each extension is identified by a quotedURL. The URL can be dereferenced to get a human-readable description of the extension. If the extension is optional then software which does not understand the extension can simply ignore it; if the extension is mandatory then software which does not understand the extension should act as though no label had been supplied. Each item of data must be one of a fixed set of simple-to-parse data types as specified in the detailed syntax below. See http://w3.org/PICS/extensions/ to find out what extensions are currently in use. DSig 1.0 uses this option to add the refinfo and signature block extensions (See "DSig Extensions," below for details.)

Notes:

DSig Extensions

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.

Resource Reference Information Extension

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:

Detailed Syntax of the Resinfo Extension in a PICS 1.1 label

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.

Embedding the DSig Signature Block

The sigblock extension specification will be added here shortly. It is currently under revision.

Signing

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

Signing a label

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.

Creating equivalent standalone label

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
Cannonicalization the equivalent standalone label for signing
An Example

(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))
Signing Notes

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.

Appendix 1: Service Resource Information

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.

Appendix 2: Transporting DSig 1.0 Labels

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.

Glossary

Acknowledgements

Authors Addresses

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