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 Working Group ("DSig") proposes a standard format for making digitally-signed, machine-readable assertions about a particular information resource. More generally, 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.
The W3C Digital Signature Working Group ("DSig") proposes a standard format for making digitally-signed, machine-readable assertions about a particular information resource. More generally, 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.
DSig 1.0 signature labels inherit both a means of transporting signature block data and a simple framework for making the machine-readable assertions from the underlying PICS framework. PICS compliant applications can syntactically parse DSig 1.0 signature labels; only cryptographic functions need to be added to PICS-aware applications in order to make use of the semantic content of a DSig signature.
In its simplest form, a DSig 1.0 signature label is a signed statement about an information resource. This document described two DSig-specific extensions to standard PICS 1.1 labels: resinfo and sigblock. The resinfo extension is used to create cryptographic links between the signature label and the information resource described by the label. Typically this linkage is created through the use of one or more cryptographic hash functions. The sigblock extension contains one or more digital signatures of the other contents of the label.
In DSig 1.0, it is important to note that:
The basic structure of a PICS 1.1 label is described below.
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 signature labels are built on top of PICS 1.1 labels.
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 service are uniquely identified by the particular 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. This 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 1.0 utilizes the PICS infrastructure as described above with a few exceptions:
PICS labels are always transmitted as lists of one or more individual PICS labels ("label lists"); in common PICS practice PICS label lists usually contain exactly one label. Full details of PICS labels and label lists are available in "PICS Label Distribution Label Syntax and Communication Protocols Version 1.1" document:
In DSig 1.0, 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 which allows for some data aggregation.
A PICS labels contains one or more service sections:
(PICS-1.1 <Service 1 section> <Service 2 section> <Service 3 section>)
Where each service section contains options and labels:
<Service URL> <Service options for all labels in this section> labels <options for this label> ratings <rating for this label> <options for this label> ratings <rating for this label> ...
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> ...) ... ...)
Labels in a label list are grouped by service. Each service may have service options which are inherited by each label within the scope of the service; service options may be overridden by individual label options. When a new service is identified in the label list, the options from the previous service no longer apply. Thus, in the above example label 4 could be equivalently 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 or portions thereof; the details of signing labels are presented below.
PICS defines two distinct types of labels, specific and generic:
By convention, a DSig signature block itself has the weakest possible semantics, namely "the entity possessing the key that created this 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 somewhat stronger semantics that also includes the semantics of the ratings contained within the label. Thus, by definition a PICS label which includes a DSig 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 asserts 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 now 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.
2. Information about the label itself.
3. Other information.
A DSig label 'signs' an information resource. To do this in a secure fashion, the signed label must have a cryptographic connection to that resource. We create cryptographic links between a label and the labeled resource by including one or more hashes of the information resource within the signature label. Similar, albeit limited, functionality was accomplished in the PICS 1.1 specification via the MIC-md5 (or md5) option. DSig 1.0 replaces this option with the resinfo extension, which permits a single label to include multiple hashes using multiple hash algorithms.
PICS 1.1 also specified a signature option, signature-RSA-MD5, but its functionality was similarly limited. DSig replaces signature-RSA-MD5 with the sigblock extension. The sigblock extension may contain one or more signatures using any cryptographic algorithm; in addition, a sigblock may optionally include information in the form of certificates or links to certificates.
A DSig 1.0 Signature Label is a standard PICS 1.1 label. The DSig extensions resinfo and sigblock are both optional and can be used as needed. A PICS 1.1 label is only considered a DSig 1.0 Signature Label when it contains a sigblock extension,
The goal of the resource reference information (resinfo) extension is to provide a cryptographic link between the signature label and an information resource. DSig 1.0's resinfo extension builds upon the PICS 1.1 for, at and MIC-md5 options to provide this cryptographic link. Specifically, the resinfo extension provides a mechanism for including cryptographic checksums (hashes), in any named cryptographic algorithm, to 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 about which the assertion was made.
The resinfo extension is associated with a specific resource. This resource may be identified by the for option or may be implied by the context of the label (in the resource, delivered in the HTTP header with the resource, returned by a label bureau based on a request, etc.).
In the structure of a PICS label, the resinfo extension can be a service option and/or a label option. It functions identically to any other option with respect to inheritance within a service section from service option to label option. 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.
Structurally, resinfo contains one or more hashes of the information resource; each hash includes a hash algorithm identifier, the actual hash of the resource and (optionally) the date the hash was computed.
("hash algorithm identifier" "base64-string of hash" "hash date")
The hash algorithm identifier is a quoted URL, it identifies the specific hashing algorithm by which the following hash was computed. The DSig 1.0 compliance document identifies several hash algorithms currently in common use and defines standard URLs for each. To ensure that no two hash algorithms use the same identifier, the identifier 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 (although it is not required that any document be accessible at a given URL). A document so referenced 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.
or the entire label should be disregarded. Optional implies that even if the processing software does not understand the extension, it should still process the label. These are powerful options which allow the author of the label wide latitude in affecting the processing policy of the client.
The following syntax of the resinfo extension is written in modified BNF. By convention, '*' indicates 0 or more instances of the token that precedes the special character, '*1' indicates 0 or 1 instance of the token, and '+' indicates 1 or more instances of the token. The Quoted strings are case sensitive but other literal elements are case insensitive..
resinfo-extension ::= 'extension (' mand/opt '"http://www.w3.org/PICS/DSig/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.
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-hash" ) ( "http://www.w3.org/PICS/DSig/MD5.html" "base64-hash" "1997.02.05T08:15-0500" ) )
In this example, we begin with the extension ( optional tokens which identify this extension as an optional extension to the PICS label within which it is contained. This declaration is followed by a URL, http://www.w3.org/PICS/DSig/resinfo-1_0.html, which provides a unique name for the extension. De-referencing the URL should provide human readable information on the extension. Finally we have two repeating subsections of the extension, each of which contain hash information. Here again, de-referencing 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. The second clause uses the MD5 hash algorithm.
The DSig 1.0 Signature Block Extension (sigblock) provides cryptographic protection of the DSig 1.0 label by using digital signature techniques. It identifies
The sigblock extension can also contain certificates that can be used by a trust management system (TMS) to decide if the signature is trustworthy.
A Signature Block consists of
The Signature Block extension can be either an optional or a mandatory PICS 1.1 extension. We do not require that the extension be understood (mandatory) because the information contained within the label may be useful to applications that cannot understand the signature information. Whether information contained within an unsigned or unverified label should be used is a trust management question.
Here is a structural representation of the sigblock extension:
extension ( optional http://www.w3.org/PICS/DSig/sigblock-1_0.html <attribution info> <signature>* ) )
The Attribution Information section contains self-verifiable information related to the creation of the digital signature on the label. In particular, cryptographic certificates asserting identity, authorization or other capabilities may be included here. Certificates may be directly embedded within the Attribution Information section of the sigblock extension, or URLs pointing to certificates may be included. Attribution Information is not required (i.e. this section of the extension may be empty), in which case trust management systems must depend on other information sources when interpreting the label. Furthermore, the information provided herein may or may not be used by the trust management system in processing the label.
Attribution Information supports many certificate formats, and the types of certificates included will depend on the public key infrastructure used by the application. Certificate format is indicated by a unique URL identifier (like the hash identifier in the resinfo extension above); DSig 1.0 defines URLs identifying X.509v3 certificates and PGP style certificates, but also is open to new, emerging standards like SDSI or SPKI. These formats need not be registered, they must only be valid and unique URLs:
URLs identifying certificate families need not necessarily point to anything; the fact that they are unique is sufficient to distinguish between certificate formats. If a certificate family URL does de-reference to a document, the resulting document should provide a description of the format of certificates within the certificate family or pointers to other locations where such descriptions may be found. We strongly recommend that such format descriptions always be provided. In the future, we expect certificate family identifiers to point to downloadable active elements that are able to parse the certificate format.
None of the information contained within the Attribution Information section is signed by the labels signature because certificates themselves are expected to be self-verifying. (More precisely, none of the information within the entire sigblock extension, including the Attribution Information section, contributes to the hash of the label that is signed as part of the signature option.) Thus, applications may augment the contents of the Attribution Information section without invalidating the signature on the label (e.g. newly-discovered certificates may be included in the Attribution Information section as they are found, or an expired certificate may be replaced).
Here is an example Attribution Information section:
( "AttribInfo" ( "http://www.w3.org/PICS/DSig/X509.html" "base64-x.509-cert") ( "http://www.w3.org/PICS/DSig/X509.html" "http://ice-tel-ca/certs/DN/CN=Lipp,O=TU-Graz,OU=IAIK") ( "http://www.w3.org/PICS/DSig/pgpcert.html" "base64-pgp-signed-key") ( "http://www.w3.org/PICS/DSig/pgpcert.html" "http://email@example.com" ) )
The Signature section of the sigblock extension contains the actual digital signature data. Each Signature section contains exactly one signature; multiple Signature sections may be included in the sigblock extension when multiple, parallel signatures are desired. The syntax of the a Signature section is:
( "Signature" SignatureSuite SigData*1)
Being crypto-neutral, DSig 1.0 does not prescribe the use of particular algorithms for generating hashes or digital signatures. DSig 1.0 also does not define any particular format for representing cryptographic information in the sigblock. Instead, we introduce the concept of "signature suites," which bundle together certain hashing algorithms, signature algorithms and representation format. Each digital signature includes a signature suite identifier that tells applications how the signature was generated and how it should be parsed.
Like hash and certificate family identifiers, the Signature-suite element is an URL that uniquely identifies the signature-suite used for generating the associated signature. If de-referencing the URL yields a document, that document should provide all necessary details for parsing, interpreting and verifying the signature data. If the signature-suite is proprietary (e.g. tied to a hardware token), the URL need not point to a specification document and serves only as an identifier.
The "DSig 1.0 Compatibility Document," a sibling to this specification, defines URL identifiers for some common, popular signature suites and defines minimum required support for those suites in DSig 1.0 compliant implementations. Of course, DSig 1.0 implementations are not restricted to using only these signature suites.
Each signature suite:
Signature suites have complete control over the contents of the SigData immediately following the Signature-Suite URL. The format of this data must satisfy the SigData portion of the BNF (basically, the data must be a single s-expression); beyond that requirement the format of the data is also governed by the signature suite.
Although each signature suite is free to specify its own format for signature data (SigData) fields, there are some types of information that are likely to be used by most signature suites. For example, signature suites need to include the actual cryptographic data that constitutes a digital signature. Signature suites will probably also wish to include information about the cryptographic keys used to generate and verify the signature. We now define some common SigData fields and their identifying string tokens ("SigTokenString" in the BNF below). These string tokens are reserved words in the sense that any signature suite that uses SigData field identified by these tokens must do so in a manner consistent with this specification.
Mathematically, a digital signature only cryptographically guarantees that at a particular point in time some process had access to both the signing (secret) key and the text of the signed document. The "Keyholder"-type SigData fields of a signature provides information about the key that was used to create the corresponding signature. The key may be bound to some entity (such as a person, server, or organization) by various certificates. There are four common ways to uniquely specify a particular key; each has its own identifying token:
To be useful, the information identifying the signing key will lead the application to corresponding certificates in the Attribution Information section (if any) or provide the starting point for fetching certificates from remote sources.
The following subsections specify the content of the SigInfo fields associated with each of these tokens.
The token "ByKey" identifies the value that follows as the key that should be used to validate the signature (or sufficient information to generate that key locally).
( "ByKey" <Key-Value, Signature-Suite dependent> )
The format of the included key necessarily depends on the particular signature-suite used and must be specified in the signature-suite document. Here is an example use of "ByKey" within the Digital Signature Algorithm (DSA) signature suite:
( "ByKey" ( "P" "base64-encoded-modulus" ) ( "Q" "base64-encoded-divisor" ) ( "G" "base64-encoded-number" ) ( "Y" "base64-encoded-public-key" ) )
The token "ByHash" identifies the value that follows as the hash of the key that should be used to validate the signature.
("ByHash" "base-64-encoded-hash-of-key" )
Details on how the hash for a key is generated is a property of individual signature suites.
The token "ByName" identifies the value that follows as a name (or other reference) that may be used to identify the corresponding public key. The name that should be provided depends on the relevant public key infrastructure.
( "ByName" "Name-as-string-value" )
The token "ByCert" identifies the value that follows as containing the name of a certifying authority (CA) and the serial number a relevant certificate issued by that CA. The name given for the CA depends on the naming conventions of the relevant public key or certification infrastructure.
( "ByCert" ( "CA-Name-as-string-value" <CA-Serial-No.> ) )
The token "On" identifies the value that follows as the time the label's signature was generated. (This option is distinct from the PICS 1.1 label option "on" which indicates the time at which the label itself was created.) We recommend using this standard element in all signature suites.
The time that the signature was created is encoded as a quoted-ISO-Date. The format of a quoted-ISO-Date is defined in the PICS 1.1 specifications.
Notice that the "on" time is advisory only to applications verifying the digital signature; as this section is part of the entire sigblock extension it is not cryptographically protected by the signature itself. (The contents of the sigblock do not contribute to the hash of the label that is signed by the signature.) If a cryptographically-protected date is desired, the correct way to implement it is to include the date within another PICS label extension; that extension may then contribute to the hash of the canonicalized label.
If an application wishes to transmit both signed and unsigned information in a label the suggested method for doing so is to generate two labels (one signed, one unsigned) and send both labels as a PICS label list. However, some PICS 1.1 protocols, including the protocol for requesting labels from a PICS label bureau, require that exactly one PICS label be returned in response to a request, and thus it may be necessary for a signing application to sign only a subset of a PICS label. If the signature suite permits signatures over partial contents of labels, the "include" and "exclude" tokens provide that functionality:
( "exclude" field-list ) ( "include" field-list )
The "include" and "exclude" SigData fields modify the default behavior of the label canonicalizer. Before a label is signed, it is put into canonical form; the section "Creating an equivalent standalone label" below describes in detail the canonicalization process. PICS labels have many semantically-equivalent forms yet these forms yield distinct hashes, so it is important that signing and verifying applications canonicalize labels in the same way. After the equivalent standalone label has been generated following the default canonicalization rules, individual label options may be dropped if an "include" or "exclude" option is present. If an "include" option is present, any field not listed in the field-list is removed from the canonicalized label. If an "exclude" option is present, all fields listed in the field-list are removed from the canonicalized label. At most one "include" or "exclude"; field may appear; it is an error to have both an "include" and an "exclude" option.
The value associated with an "include" or "exclude" option (the "field-list") is a list of label fields to be included or excluded in the canonicalized form. There are three types of fields in PICS 1.1 labels: options, ratings transmit/value pairs, and extensions. The format of a field-list is as follows:
field-list ::= '(' 1option-list*1 ratings-list*1 extension-list*1 ')' option-list ::= '(' "options" <options>* ')' ratings-list ::= '(' "ratings" <ratings>* ')' extension-list ::= '(' "extensions" <quoted-URL>* ')'
A field-list is simply a collections of at most one of each an option-list, ratings-list and extension-list. An option-list is a list of PICS 1.1 label option names (e.g. "for" or "by"). A ratings-list is a list of PICS 1.1 ratings service transmit-names (e.g. "suds" in the example "Good Clean Fun" rating service). An extension-list is a list of quotes-URLs where each quoted-URL uniquely identifies a particular PICS 1.1 label extension.
Note: The "include" and "exclude" SigData types exist in this specification strictly to overcome limitations in PICS 1.1 protocols. These limitations should disappear in the next revision of the PICS specifications, and thus the requirement for these fields will disappear. It is the intention of the DSig working group that "include" and "exclude" not be present in the DSig 2.0 specification, which will build on new version of PICS.
The "SigCrypto" token identifies the SigData field that contains the cryptographic data that is the signature itself. The format and contents of this field are entirely specified by particular signature suites.
Correct hashing is the key to successful signing. DSig 1.0 therefore specifies how a PICS 1.1 label is converted into a unique, canonicalized form which does not include the sigblock extension (this process is explained in the Signing section below). This canonicalized label is the input to the signature suites signature algorithm. The signature algorithm may require or accept other inputs in addition to the contents of the equivalent standalone label. For example, the signature suite may pad the data in a particular way, or mix into the hash of the data information concerning the algorithms used to generate the hash and signature.
Multiple parallel signatures on the same PICS 1.1 label may be created simply by including several "Signature" fields within the sigblock extension. Cascaded signatures (signatures on signatures) are not supported within a single DSig signature label. To create a cascaded signature, a DSig signature label may be signed using another DSig signature label.
extension (optional "http://www.w3.org/PICS/DSig/sigblock-1_0.html" ("AttribInfo" ("http://www.w3.org/PICS/DSig/X509.html" "base64-x.509-cert") ("http://www.w3.org/PICS/DSig/X509.html" "http://SomeCa/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK") ("http://www.w3.org/PICS/DSig/pgpcert.html" "base64-pgp-signed-key") ("http://www.w3.org/PICS/DSig/pgpcert.html" "http://firstname.lastname@example.org")) ("Signature" "http://www.w3.org/PICS/DSig/RSA-MD5.html" ("byKey" (("N" "aba21241241=") ("E" "abcdefghijklmnop="))) ("on" "1996.12.02T22:20-0000") ("exclude" ("extensions" "http://foo/badextension.html")) ("SigCrypto" "aba1241241==")) ("Signature" "http://www.w3.org/PICS/DSig/DSS.html" ("ByName" "email@example.com") ("on" "1996.12.02T22:20-0000") ("SigCrypto" (("R" "aba124124156") ("S" "casdfkl3r489")))))
We now present a formal syntax for the sigblock extension. The is written in modified BNF. By convention, '*' indicates 0 or more instances of the token that precedes the special character, '*1' indicates 0 or 1 instance of the token, and '+' indicates 1 or more instances of the token. Quoted strings are case sensitive but other literal elements are case insensitive. Whitespace is ignored except in quoted strings. Multiple contiguous whitespace characters may be treated as though they were a single space character.
Note: This extension is not a valid PICS 1.1 extension because Base64 as defined in RFC-1521 contains a '/' which technically cannot be represented as a PICS 1.1 datum. Nonetheless, we believe that all parsers will support the grammar presented below, and expect the problem to be solved in the next version of PICS..
SignatureExtension ::= 'extension (' mand/opt SigBlockURL AttributionInfo Signature* ')' Mand/opt ::= 'optional' | 'mandatory' SigBlockURL ::= '"http://www.w3.org/PICS/DSig/sigblock-1_0.html"' AttributionInfo ::= '(' '"AttribInfo"' Certificate* ')' Certificate ::= '(' CertificateType CertificateData ')' CertificateType ::= quotedUrl CertificateData ::= quotedBase64String | quotedUrl Signature ::= '( "Signature"' SignatureSuite SigData* ')' SigData ::= '(' SigTokenString SigInfo*1 ')' SigTokenString ::= '"' quotedName '"' SigInfo ::= SigData | quotedURL | quotedBase64String | quotedName | number | '(' SigInfo* ')' SignatureSuite ::= quotedUrl quotedURL ::= '"' URL '"' URL ::= as defined by RFC-1738. quotedBase64String ::= '"' base64String '"' base64String ::= as defined in RFC-1521. alpha ::= 'A' | .. | 'Z' | 'a' | .. | 'z' digit ::= '0' | .. | '9' quotedName ::= '"' ( urlChar | ' ')+ '"' urlChar ::= alphaNumPM | '.' | '$' | ',' | ';' | ':' | '&' | '=' | '?' | '!' | '*' | '~' | '@' | '#' | '_' | '(' | ')' | '/' | '%' hex hex ; Note: Use the "%" escape technique to insert ; single or double quotation marks within a URL alphaNumPM ::= alpha | digit | sign hex ::= digit | 'A' | .. | 'F' | 'a' | .. | 'f' sign ::= '+' / '-' number ::= [sign]unsignedInt['.' [unsignedInt]] unsignedInt ::= digit+
Since even a single DSig 1.0 signature label must be represented as a PICS 1.1 label list, it is important to understand the structure of such a list. This is explained above in the section PICS 1.1 labels and label lists. Here again is a structural representation of a PICS 1.1 label 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 straightforward whether the label list containing the label is made up of a single label or a series of labels. First we create an equivalent standalone label for the label to be signed. Then the equivalent standalone label is canonicalized (similar to canonicalizing a PICS label for transmission). Finally, a digital signature is generated, inserted into a sigblock extension, and that extension is placed in the label as a label extension. An equivalent standalone 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 label list containing a single label. The single label must be 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 label list 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 ...]))
This is not yet an equivalent standalone label. We still need to take into account any modifications denoted by "include" or "exclude" specifiers in the sigblock extension. (Obviously, if the signature is being created the application knows which fields it wants to include in or exclude from the equivalent standalone label. The "include" and "exclude" options convey this information to applications trying to verify the signature.) The resulting label list is the equivalent standalone label.
The following example illustrates a step-by-step process to sign a PICS 1.1 label.
Step 1: creates a PICS 1.1 label
(PICS-1.1 "http://www.gcf.org/v2.5" by "John Doe" labels for "http://www.w3.org/PICS/DSig/Overview.html" on "1994.11.05T08:15-0500" ratings (suds 0.5 density 0 color 1))
Step 2: compute the hashes of the document, create the resinfo extension, and insert it in the label
(PICS-1.1 "http://www.gcf.org/v2.5" by "John Doe" labels for "http://www.w3.org/PICS/DSig/Overview.html" extension (optional "http://www.w3.org/PICS/DSig/resinfo-1_0.html" ("http://www.w3.org/PICS/DSig/SHA1.html" "aba21241241=") ("http://www.w3.org/PICS/DSig/MD5.html" "cdc43463463=" "1997.02.05T08:15-0500")) on "1994.11.05T08:15-0500" ratings (suds 0.5 density 0 color 1))
Step 3: canonicalize the label
( PICS-1.1 "http://www.gcf.org/v2.5" l by "John Doe" for "http://www.w3.org/PICS/DSig/Overview.html" extension ( optional "http://www.w3.org/PICS/DSig/resinfo-1_0.html" ( "http://www.w3.org/PICS/DSig/MD5.html" "cdc43463463=" "1997.02.05T08:15-0500" ) ( "http://www.w3.org/PICS/DSig/SHA1.html" "aba21241241=" ) ) on "1994.11.05T08:15-0500" r ( suds 0.5 density 0 color 1 ) )
Step 4: sign the canonicalized form of the label and insert it in the label
(PICS-1.1 "http://www.gcf.org/v2.5" by "John Doe" labels for "http://www.w3.org/PICS/DSig/Overview.html" extension (optional "http://www.w3.org/PICS/DSig/resinfo-1_0.html" ("http://www.w3.org/PICS/DSig/SHA1.html" "aba21241241=") ("http://www.w3.org/PICS/DSig/MD5.html" "cdc43463463=" "1997.02.05T08:15-0500")) extension (optional "http://www.w3.org/PICS/DSig/sigblock-1_0.html" ("AttribInfo" ("http://www.w3.org/PICS/DSig/X509.html" "efe64685685=") ("http://www.w3.org/PICS/DSig/X509.html" "http://SomeCA/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK") ("http://www.w3.org/PICS/DSig/pgpcert.html" "ghg86807807=") ("http://www.w3.org/PICS/DSig/pgpcert.html" "http://firstname.lastname@example.org")) ("Signature" "http://www.w3.org/PICS/DSig/RSA-MD5.html" ("byKey" (("N" "aba212412412=") ("E" "3jdg93fj"))) ("on" "1996.12.02T22:20-0000") ("SigCrypto" "3j9fsaJ30SD=")) on "1994.11.05T08:15-0500" ratings (suds 0.5 density 0 color 1))
And now we have a valid DSig-1.0 label.
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 de-reference 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, referenced via a URL. When the URL is de-referenced it returns an item of type application/pics-labels that contains a label list.
The specifications for embedding a PICS 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.
Project Manager, Technology and Society Domain, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
IAIK, University of Technology, Graz
Institute for Applied Information Processing and Communications
Klosterwiesgasse 32/I, A-8010 Graz, Austria
180 Park Ave., Room B220
P.O. Box 971
Florham Park, NJ 07932-0971, U.S.A.
Technical Staff, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.