REC-DSig-label-20091124 77 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <TITLE>PICS Signed Labels (DSig) 1.0 Specification</TITLE>
</HEAD>
<BODY BACKGROUND="http://www.w3.org/Icons/Backgrounds/recbg.jpg">

<DIV ALIGN=right>
<H3>
<A HREF="http://www.w3.org/"><IMG SRC="http://www.w3.org/Icons/WWW/w3c_home" ALT="W3C" BORDER=0  ALIGN=LEFT></A>REC-DSig-label-20091124</H3></DIV>

<br>
<CENTER>
<H1>
PICS Signed Labels<br>(DSig)<br>1.0 Specification</H1></CENTER>

<CENTER>
<H3>
W3C Recommendation 27-May-1998 (revised 24-Nov-2009)</H3></CENTER>

<DL>
<DT>
Latest Version:</DT>

<DD>
<A HREF="http://www.w3.org/TR/REC-DSig-label">http://www.w3.org/TR/REC-DSig-label</A></DD>

<DT>
This version:</DT>

<DD>
<A HREF="http://www.w3.org/TR/2009/REC-DSig-label-20091124">http://www.w3.org/TR/2009/REC-DSig-label-20091124</A></DD>

<DT>
Previous version:</DT>

<DD>
<A HREF="http://www.w3.org/TR/1998/REC-DSig-label-19980527">http://www.w3.org/TR/1998/REC-DSig-label-19980527/</A></DD>
</DL>

<p style="border: solid thick red; padding: 1em"><strong>Note:<em>This paragraph is informative.</em> This document is
currently not maintained. PICS has been superseded by the Protocol for Web Description Resources (<a href="/2007/powder/">POWDER</a>). W3C encourages authors and
implementors to refer to POWDER (or its successor) rather than PICS when developing systems to describe Web content or agents to
act on those descriptions. A brief document outlining the advantages offered by POWDER compared with PICS is <a href="/2009/08/pics_superseded.html">available
separately</a>.</strong></p>


<B>Editor</B>
<UL>
<LI>
Philip DesAutels</LI>
</UL>
<B>Authors:</B>
<UL>
<LI>
<A HREF="#Yang_hua_Chu">Yang-hua Chu</A></LI>

<LI>
<A HREF="#Philip_DesAutels">Philip DesAutels</A></LI>

<LI>
<A HREF="#Brian_LaMacchia">Brian LaMacchia</A></LI>

<LI>
<A HREF="#Peter_Lipp">Peter Lipp</A></LI>
</UL>


<P>
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">
Copyright</A> &nbsp;&copy;&nbsp; 1998 <A href="http://www.w3.org">W3C</A>
(<A href="http://www.lcs.mit.edu">MIT</A>,
<A href="http://www.inria.fr/">INRIA</A>,
<A href="http://www.keio.ac.jp/">Keio</A> ), All Rights Reserved. W3C
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer">liability,</A>
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks">trademark</A>,
<A href="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
use </A>and
<A href="http://www.w3.org/Consortium/Legal/copyright-software.html">software
licensing </A>rules apply.

<HR>
<H2>
Status of this document</H2>
<!-- hhmts start -->
Last updated: 1998-06-01T14:03:02Z
<!-- hhmts end -->

<p>
This document has been reviewed by W3C Members and other interested
parties and has been endorsed by the Director as a W3C
Recommendation. It is a stable document and may be used as reference
material or cited as a normative reference from another
document. W3C's role in making the Recommendation is to draw attention
to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web.

<p>
As a result of comments supplied during the balloting period, the
syntax of quoted ISO dates has been changed from strictly PICS 1.1 conformant
to permit either PICS 1.1 or ISO conformant forms.
At the same time we have added optional seconds and decimal
fractions of seconds fields to support those cryptographic algorithms
that require sub-minute precision in timestamps.</p>

<p>
A confusing reference to sigblocks in equivalent standalone labels
is fixed.  The title is changed to indicate that this is a signature
specification specifically for PICS labels.
</p>

<p>
At the time this Recommendation was published a possible
revision to PICS 1.1 was being discussed.  That revision to PICS 1.1 was
expected to be called PICS 1.2 and was expected to have no significant
impact on this specification.  All
references herein to "PICS 1.1" should be interpreted to mean "PICS 1.1
and PICS 1.2".</p>

<p>Comments on this Recommendation may
be sent to <A HREF="mailto:w3c-dsig-ask@w3.org">w3c-dsig-ask@w3.org</A>.

<P>This document is part of the <A HREF="http://www.w3.org/">W3C</A>
<A HREF="/DSig/">Digital Signature Project</A>.

<P>A list of current W3C Recommendations, Proposed Recommendations and
Working Drafts can be found at: <A HREF="/TR/">http://www.w3.org/TR</A>
<BR>
<HR>
<H2>
Abstract</H2>
The W3C Digital Signature Working Group ("DSig") proposes a standard format
for making digitally-signed, machine-readable assertions about a particular
information resource.
<a href="http://www.w3.org/TR/REC-PICS-labels">PICS 1.1 labels</a> are
an example of such machine-readable assertions.  This document describes
a method of adding extensions to PICS 1.1 labels for purposes of signing
them.   More generally, it is the goal of the DSig project
to provide a mechanism to make the statement: <I>signer</I> believes <I>statement</I>
about <I>information resource</I>.  In DSig 1.0 <i>statement</i> is any
statement that can be expressed with PICS 1.1.
<BR>
<HR>
<H2>
Contents</H2>

<UL>
<LI>
<A HREF="#DSig_1_0_Overview">DSig 1.0 Overview</A></LI>

<LI>
<A HREF="#PICS_Architecture">PICS Architecture</A></LI>

<LI>
<A HREF="#PICS_Options_and_DSig">PICS Options and DSig</A></LI>

<LI>
<A HREF="#DSig_Extensions">DSig Extensions</A>
<UL>
<LI>
<A HREF="#URLID">URLs as identifiers</A></LI>

<LI>
<A HREF="#Reference_Information">Resource Reference Information Extension</A></LI>

<LI>
<A HREF="#Signature_Block">Signature Block Extension</A></LI>
</UL>
</li>
<LI>
<A HREF="#Signing">Signing</A></LI>

<LI>
<A HREF="#Appendix_1">Appendices</A></LI>

<LI>
<A HREF="#Reference Materials">Reference Materials</A></LI>
</UL>

<HR>
<H2>
<A NAME="DSig_1_0_Overview"></A>DSig 1.0 Overview</H2>
The W3C Digital Signature Working Group ("DSig") proposes a standard format
for making digitally-signed, machine-readable assertions about a particular
information resource.
<a href="http://www.w3.org/TR/REC-PICS-labels">PICS 1.1 labels</a> are
an example of such machine-readable assertions.  This document describes
a method of adding extensions to PICS 1.1 labels for purposes of signing
them.   More generally, it is the goal of the DSig project
to provide a mechanism to make the statement: <p>
<CENTER><B><I>signer</I></B> believes <B><I>statement</I></B> about <B><I>information
resource</I></B></CENTER>
<p>In this specification <i>statement</i> is any
statement that can be expressed with PICS 1.1.
This document also provides detailed usage guidelines for creating
PICS 1.1 labels that are valid DSig 1.0 Signature labels.

<P>DSig 1.0 signature labels inherit both a means of transporting a 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.

<P>In its simplest form, a DSig 1.0 signature label is a signed statement
about an information resource. This document describes two DSig-specific
extensions to standard PICS 1.1 labels: <B><I>resinfo</I></B> and <B><I>sigblock</I></B>.
The <B><I>resinfo</I></B> 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 <B><I>sigblock</I></B> extension contains
one or more digital signatures of the other contents of the label.

<P>In DSig 1.0, it is important to note that:
<UL>
<LI>
At no time does a DSig 1.0 signature label 'wrap' the information resource
it is signing;</LI>

<LI>
The signature label can always be separated from the information resource;</LI>

<LI>
DSig 1.0 Signature Labels provide a means of making assertions about resources
with cryptographic integrity but they do not protect the confidentiality
of the information resource referenced.</LI>
</UL>
The basic structure of a PICS 1.1 label is described below.

<P>W3C recommendations and working drafts related to this document include:
<UL>
<LI>
PICS Label Distribution Label Syntax and Communication Protocols version
1.1: <A HREF="/TR/REC-PICS-labels">http://www.w3.org/TR/REC-PICS-labels</A></LI>

<LI>
Rating Services and Rating Systems (and Their Machine Readable Descriptions)
Version 1.1: <A HREF="/TR/REC-PICS-services">http://www.w3.org/TR/REC-PICS-services</A></LI>
</UL>
We assume familiarity with these documents.

<P>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.
<H2>
<A NAME="PICS_Architecture"></A>PICS Architecture</H2>
At the core of the PICS infrastructure is the rating service. The <B>rating
service</B> either chooses an existing, or develops a new <B>rating system</B>
to use in labeling content. The rating system, which is described in a
human readable form at the <B>rating system URL</B>, specifies 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 <B>service URL</B>. 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 <B>service description file</B>. This is a machine-readable
version of the rating system with pointers to the rating system URL and
the rating service URL. While not required, it is recommended that this
be available automatically at the service URL.
<CENTER><IMG SRC="http://www.w3.org/TR/1998/REC-DSig-label-19980527/pics" ALT="Elements of PICS infrastructure" HEIGHT=428 WIDTH=451></CENTER>


<P>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 potentially automatable)
task to retrieve the appropriate service description file to understand
what statements are being made in the label.

<P>DSig 1.0 utilizes the PICS infrastructure as described above with a
few differences:
<UL>
<LI>
In DSig 1.0, the notion of content labels and raters is somewhat different.
In DSig 1.0 the <I>rater</I> is considered to be a <I>labeler</I>.</LI>

<LI>
The labeler is making an <I>assertion</I> about an information resource
and creating an<I> assertion label</I>.</LI>

<LI>
By signing an assertion label, the signer explicitly confirms belief in
the truth of the statements contained within the label. A signature does
not indicate that the signer created the label, only that they believe
the statements made within it are valid."</LI>

<LI>
Additional signatures can be added in parallel with existing signatures
at any point in time.</LI>

<LI>
The labeler and signer may be, but do not have to be different entities
in a DSig label. DSig 1.0 signature labels provide fields for storing information
about both the label creator and the signer(s).</LI>

<LI>
The PICS rating system referenced in the signature label is an <I>assertion
system</I> in DSig. The statement in the label (made via the PICS ratings)
is an assertion that the labeler is making about the referenced content.</LI>

<LI>
Additional resource reference information may be included within the DSig
label to help disambiguate the subject of the label. The DSig <B><I>resinfo</I></B>
extension is one way of including such information; it allows the label
signer to provide cryptographic hashes of the labeled content. Other private
extension types may also be defined and included in accordance with the
PICS 1.1 specifications.</LI>
</UL>

<H3>
<A NAME="PICS_1_1_labels"></A>PICS 1.1 labels and label lists</H3>
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 "<A HREF="/TR/REC-PICS-labels">PICS
Label Distribution Label Syntax and Communication Protocols Version 1.1</A>"
document:
<UL>
<LI>
General Format of PICS Labels</LI>

<LI>
Semantics of PICS Labels and Label Lists</LI>

<LI>
Requesting Labels Separately</LI>
</UL>
In DSig 1.0, each assertion about an information resource is given in a
label. A label consists of a <I>service identifier</I>, <I>options</I>,
<I>extensions</I> and an <I>assertion</I> (in PICS 1.1 the assertion is
called a rating). The service identifier is the URL chosen by the rating
service (see <A HREF="/TR/REC-PICS-services">Rating
Services and Rating Systems</A>) 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.

<P>A PICS labels contains one or more service sections:
<PRE>&nbsp;&nbsp; (PICS-1.1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;Service 1 section>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;Service 2 section>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;Service 3 section>)</PRE>
Where each service section contains options and labels:
<PRE>&nbsp;&nbsp; &lt;Service URL> &lt;Service options for all labels in this section>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; labels &lt;options for this label> ratings &lt;rating for this label>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;options for this label> ratings &lt;rating for this label>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...</PRE>
The general form for a label list (formatted for presentation, and not
showing error status codes) is:
<PRE>&nbsp;&nbsp; (PICS-1.1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <I>&lt;service 1 url> </I>[service 1 <I>option...</I>]&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; labels [label 1 <I>option...</I>] ratings (&lt;category> &lt;value> ...)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [label 2 option...] ratings (&lt;category> &lt;value> ...)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<I>service 2 url</I>> [<I>service 2 option...</I>]&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; labels [<I>label 3 option...</I>] ratings (&lt;category> &lt;value> ...)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [label 4 option...] ratings (&lt;category> &lt;value> ...)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...)</PRE>
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:
<PRE>&nbsp;&nbsp; (PICS-1.1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<I>service 2 url</I>>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; labels [ <I>service 2 options + </I>label 4 option...]
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings (&lt;category> &lt;value> ...))</PRE>
In DSig 1.0, we sign individual labels or portions thereof; the details
of signing labels are presented below.

<P>PICS defines two distinct types of labels, <I>specific</I> and <I>generic</I>:
<UL>
<LI>
A <I>specific</I> label applies to a single resource. For example, if a
labeled document is in HTML format, the label applies only to the HTML
document itself and not to any other documents referenced via hyperlinks
or &lt;img> tags. This is the default label type.</LI>

<LI>
A <I>generic</I> label (identified by the use of the PICS <B>generic</B>
option within the label) applies to any document with a URL that has a
particular prefix (the prefix is specified via the PICS <B>for</B> option
in the label). A generic label for a site or directory should only be used
if it applies to all the documents in that site or directory. The DSig
1.0 <B><I>resinfo</I></B> extension is not meaningful within a generic
label.</LI>
</UL>

<H2>
<A NAME="PICS_Options_and_DSig"></A>PICS Options and DSig</H2>

<H3>
Semantics of Embedded Signature Blocks</H3>
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 <B><I>sigblock</I></B>
extension has the following semantics:
<BLOCKQUOTE>"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 <I>and asserts that the statements made within the label are valid</I>"</BLOCKQUOTE>

<H3>
Applying PICS to DSig</H3>
Following the format given in <A HREF="/TR/REC-PICS-labels">PICS
Label Distribution Label Syntax and Communication Protocols Version 1.1</A>
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.

<P>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.
<ol>
<LI>
<B>Information about the document that is labeled.</B>

<DL>
<DT>
at <I>quoted-PICS-ISO-date</I></DT>

<DD>
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 <B><I>resinfo
</I></B>extension.</DD>

<DT>
MIC-md5 "<I>Base64-string</I>"</DT>

<DT>
-or- md5 "<I>Base64-string</I>"</DT>

<DD>
<B><FONT COLOR="#FF0000">This option is not used in DSig 1.0.</FONT></B>
If this option is present in a DSig 1.0 label, it should be ignored. Further,
it should be removed from the label for the purposes of signing. This option
has been superceded by the DSig 1.0 <B><I>resinfo </I></B>extension.</DD>
</DL>
</li>
<li><B>Information about the label itself.</B>
<DL>
<DT>
by <I>quotedname</I></DT>

<DD>
An identifier for the person or entity who was responsible for creating
this particular label. The contents of the by field are not restricted
by the DSig 1.0 specification; it is common practice in PICS usage to include
a name or e-mail address in the string value of the <B>by</B> field. Within
DSig 1.0, the <B>by</B> field is considered informational only; the <B>by</B>
option name need not be the same as that of the signer(s). The <B><I>sigblock
</I></B>extension includes fields for the identity of the signer (in the
<I>signature</I> section) and certificates (or references to them) identifying
the signer(s) (within the <I>attribution information</I> section).</DD>

<DT>
for <I>quotedURL</I></DT>

<DD>
The URL (or prefix string of a URL) of the information resource to which
this assertion applies. 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. The <B>for</B> option is valid as both a service
and label option in a label list.</DD>

<DT>
generic <i>boolean</i></DT>

<DT>
-or- gen <I>boolean</I></DT>

<DD>
If this option is set to true, the label can be applied to any URL starting
with the prefix given in the <B>for</B> option. By default, this option
is false. Set to true, it is used to supply ratings for entire sites or
subparts of sites. All generic labels must also include the <B>for</B>
option. A generic label should not be created unless it can be legitimately
applied to <I>all</I> documents whose URL begins with the prefix specified
in the <B>for</B> option (even if a more specific label exists). If the
generic option is used with a true value, the DSig 1.0 <B><I>resinfo </I></B>extension
can not be used because there will not be a specific information resource
to hash.</DD>

<DT>
on <I>quoted-PICS-ISO-date</I></DT>

<DD>
The date on which this label was created. This may be different than the
date the label was signed (which may be included within the DSig 1.0 <B><I>sigblock</I></B>
extension).</DD>

<DT>
signature-RSA-MD5 "<I>Base64-string</I>"</DT>

<DD>
<B><FONT COLOR="#FF0000">This option is not used in DSig 1.0.</FONT></B>
If this option is present in a DSig 1.0 label it should be ignored and
removed from the label for the purposes of signing. This option has been
replaced with the DSig 1.0 <B><I>sigblock</I></B> extension.</DD>

<DT>
until <I>quoted-PICS-ISO-date</I></DT>

<DT>
-or- exp <I>quoted-PICS-ISO-date</I></DT>

<DD>
The date on which the label expires (how long the label is good for).</DD>
</DL>
</li>
<li>
<B>Other information.</B>
<DL>
<DT>
comment <I>quotedname</I></DT>

<DD>
Information for humans who may see the label; no associated semantics.</DD>

<DT>
complete-label <I>quotedURL</I></DT>

<DT>
-or- full <I>quotedURL</I></DT>

<DD>
De-referencing 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 option is used when a short label is transmitted for
performance purposes but additional information is also available. When
the URL is de-referenced it returns an item of type application/pics-labels
that contains a label list with exactly one label. In DSig 1.0 this option
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 then de-reference this URL
to get the full, signed version of the label.</DD>

<DT>
extension (optional <I>quotedURL data</I>*)</DT>

<DT>
-or- extension (mandatory <I>quotedURL data</I>*)</DT>

<DD>
Future extension mechanism. To avoid duplication of extension names, each
extension is identified by a <I>quotedURL</I>. The URL is de-referencable,
yielding a human-readable description of the extension. If the extension
is <B>optional</B> then software which does not understand the extension
can simply ignore it; if the extension is <B>mandatory</B> then software
which does not understand the extension should act as though no label had
been supplied. Each item of <I>data</I> must be one of a fixed set of simple-to-parse
data types as specified in the detailed syntax below. See <A HREF="http://www.w3.org/PICS/extensions/">http://www.w3.org/PICS/extensions/</A> for a partial
listing of extension URIs previously defined.
The DSig 1.0 <B><I>resinfo</I></B>
and <B><I>sigblock</I></B> extensions uses this mechanism (See "<A HREF="#DSig_Extensions">DSig
Extensions</A>," below for details.)</DD>
</DL>
</li>
</ol>

<H2>
<A NAME="DSig_Extensions"></A>DSig Extensions</H2>
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 <B>MIC-md5</B> (or <B>md5</B>) option.
DSig 1.0 replaces this option with the <B><I>resinfo </I></B>extension,
which permits a single label to include multiple hashes using multiple
hash algorithms.

<P>PICS 1.1 also specified a signature option, <B>signature-RSA-MD5</B>,
but its functionality was similarly limited. DSig replaces <B>signature-RSA-MD5</B>
with the <B><I>sigblock</I></B> extension. The <B><I>sigblock</I></B> extension
may contain one or more signatures using any cryptographic algorithm; in
addition, a <B><I>sigblock</I></B> may optionally include information in
the form of certificates or links to certificates.

<P>A DSig 1.0 Signature Label is a standard PICS 1.1 label. The DSig extensions
<B><I>resinfo</I></B> and <B><I>sigblock</I></B> 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 <B><I>sigblock</I></B> extension.

<P>The syntax of the extensions presented below is written in modified
BNF. By convention,
<BLOCKQUOTE>
<DL>
<DT>
a?</DT>

<DD>
a or nothing; optional a.</DD>

<DT>
a+</DT>

<DD>
one or more occurrences of a.</DD>

<DT>
a*</DT>

<DD>
zero or more occurrences of a.</DD>
</DL>
</BLOCKQUOTE>
Quoted strings are case sensitive but other literal elements are case insensitive.
Multiple contiguous space characters are be treated as though they were
a single space character except in quoted strings.
<H3>
<A NAME="URLID"></A>URLs as identifiers</H3>
Within the DSig 1.0 <B><I>sigblock</I></B> and <B><I>resinfo</I></B> extensions,
URLs are used as identifiers to indicate a particular hashing algorithm,
certificate type or signature type. Specifically, they are used as:
<UL>
<LI>
<A HREF="#hahsalgoid">hash algorithm identifiers</A></LI>

<LI>
<A HREF="#certfamilyid">certificate family identifiers</A>, and</LI>

<LI>
<A HREF="#sigsuiteid">signature suite identifiers</A></LI>
</UL>
To ensure the uniqueness of identifiers, 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.

<P>Since the identifier is a URL, it must, when resolved, yield a a document.
We recommend the returned document:
<UL>
<LI>
be available at least in HTML format;</LI>

<LI>
identify the entity which created and maintains the identifier;</LI>

<LI>
describe the specifics of the algorithms and encodings, or provide a link
to another document which does so; and</LI>

<LI>
be available in multiple languages, either through an existing negotiation
mechanism or through links to alternate language versions</LI>
</UL>
We require that such identifier description documents always be provided.

<P>Any incompatible change in an identifier should be accomplished by creating
an entirely new identifier URL.

<P><A HREF="http://www.w3.org/PICS/DSig/">URL identifiers
for some common, popular signature suites are available</A>. Of course,
DSig 1.0 implementations are not restricted to using these or only these.
To provide a base level of interoperability, all DSig 1.0 implementations
are required to implement the signature suites listed in Appendix 3.

<H3>
<A NAME="Reference_Information"></A>Resource Reference Information Extension</H3>
The goal of the resource reference information (<B><I>resinfo</I></B>)
extension is to provide a cryptographic link between the signature label
and an information resource. DSig 1.0's <B><I>resinfo</I></B> extension
builds upon the PICS 1.1 <B>for</B>, <B>at</B> and <B>MIC-md5 </B>options
to provide this cryptographic link. Specifically, the <B><I>resinfo</I></B>
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.

<P>The <B><I>resinfo</I></B> extension is associated with a specific resource.
This resource may be identified by the <B>for</B> 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.).

<P>In the structure of a PICS label, the <B><I>resinfo</I></B> extension
can be a <I>service</I> option and/or a <I>label</I> 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 <B>for</B> option of a label that accompanies the document, but
the document retrieved must be the same document or the hash(s) contained
in the <B><I>resinfo</I></B> extension will not be valid.

<P>Structurally, <B><I>resinfo</I></B> 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.
<PRE><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("Hash Algorithm Identifier" "base64-string of hash" "hash date")</TT></PRE>
The&nbsp;<A NAME="hahsalgoid"></A>hash algorithm identifier is a quoted
URL identifier <A HREF="#URLID">as defined above</A>. It identifies the
specific hashing algorithm by which the following hash was computed. The
actual hash is given as a quoted base64 encoded string.

<P>Usage notes:
<UL>
<LI>
The <B><I>resinfo</I></B> extension can either be a service option or a
label option. If both are present, the extension given as a label option
takes precedence over the service option. Thus, an <A HREF="#equivalent_label">equivalent
standalone label</A> will have at most one <B><I>resinfo</I></B> extension
and that extension will be the extension given as the label option for
that label unless none is present, in which case the extension given as
a service option will be used. If neither is present, the equivalent standalone
label will have no <B><I>resinfo</I></B> extension.</LI>

<LI>
A <B><I>resinfo</I></B> extension can contain multiple hashes of the information
resource. Each must necessarily use a different hash algorithm; it is not
valid to label multiple versions of a single document by including multiple,
distinct hashes in one label.</LI>

<LI>
The <B><I>resinfo</I></B> extension is an "optional" extension. <I>Optional</I>
implies that even if the processing software does not understand the extension,
it should still process the label.</LI>

<LI>
The <B><I>resinfo</I></B> extension is not valid in a <I>generic</I> PICS
1.1 label. It is only valid within a <I>specific</I> (non-generic) PICS
1.1 label.</LI>

<LI>
<B><I>Resinfo</I></B> is not extensible: In DSig 1.0, if other disambiguating
or differentiating information is needed, a separate extension will need
to be created. We assume that the next version of DSig will allow for much
richer and extensible resource reference information.</LI>
</UL>

<H4>
Detailed Syntax of the <B><I>resinfo</I></B> Extension in a PICS 1.1 Label</H4>

<PRE><B>resinfo-extension</B> ::=<B> </B>'extension ( optional '
<I>&nbsp;&nbsp;&nbsp;&nbsp; '"http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"' resinfo-data</I>+ ')'
<B>resinfo-data&nbsp;&nbsp;&nbsp; </B>::=<B> </B>'(' <I>HashAlgoID resource-hash hash-date? </I>')'
<B>HashAlgoID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </B>::=<B> </B><I>quotedURL</I>
<B>quotedURL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </B>::= '"' <I>URL</I> '"'
<B>resource-hash&nbsp;&nbsp; </B>::= '"<i>base64-string</i>"'
<B>hash-date</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= quoted-ISO-date
<B>quoted-ISO-date</B> ::= '"' YYYY <i>sep</i> MM <i>sep</i> DD 'T' hh ':' mm[':' ss['.' f+]] Stz '"'
&nbsp;&nbsp;&nbsp;&nbsp; based on the PICS-defined ISO 8601:1988 date and time format, restricted
&nbsp;&nbsp;&nbsp;&nbsp; to the specific form described here:
&nbsp;&nbsp;&nbsp;&nbsp; <B>sep&nbsp;&nbsp; </B>::= '.' | '-'
&nbsp;&nbsp;&nbsp;&nbsp; <B>YYYY&nbsp; </B>::= four-digit year
&nbsp;&nbsp;&nbsp;&nbsp; <B>MM&nbsp;&nbsp;&nbsp; </B>::= two-digit month (01=January, etc.)
&nbsp;&nbsp;&nbsp;&nbsp; <B>DD&nbsp;&nbsp;&nbsp;</B> ::= two-digit day of month (01 through 31)
&nbsp;&nbsp;&nbsp;&nbsp; <B>hh&nbsp;&nbsp;&nbsp;</B> ::= two digits of hour (00 through 23) (am/pm NOT allowed)
&nbsp;&nbsp;&nbsp;&nbsp; <B>mm&nbsp;&nbsp;&nbsp;</B> ::= two digits of minute (00 through 59)
&nbsp;&nbsp;&nbsp;&nbsp; <B>ss&nbsp;&nbsp;&nbsp;</B> ::= two digits of second (00 through 59), optional
&nbsp;&nbsp;&nbsp;&nbsp; <B>f&nbsp;&nbsp;&nbsp;&nbsp;</B> ::= digit(s) of fractions of second, optional
&nbsp;&nbsp;&nbsp;&nbsp; <B>S&nbsp;&nbsp;&nbsp;&nbsp;</B> ::= sign of time zone offset from UTC ('+' or '-')
&nbsp;&nbsp;&nbsp;&nbsp; <B>tz&nbsp;&nbsp; </B> ::= four digit amount of offset from UTC
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (e.g., 1512 means 15 hours and 12 minutes)
&nbsp;&nbsp;&nbsp;&nbsp; For example, "1994-11-05T08:15-0500" is a valid <I>quoted-ISO-date
</I>&nbsp;&nbsp;&nbsp;&nbsp; denoting November 5, 1994, 8:15 am, US Eastern Standard Time
&nbsp;&nbsp;&nbsp;&nbsp; <B>Notes:</B>&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; 1. The ISO 8601:1988 date and time format standard allows considerably&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; greater flexibility than that described here.&nbsp; DSig requires <I>precisely
</I>&nbsp;&nbsp;&nbsp;&nbsp; the syntax described here -- neither the time nor the time zone may
&nbsp;&nbsp;&nbsp;&nbsp; be omitted, none of the alternate ISO formats are permitted, and
&nbsp;&nbsp;&nbsp;&nbsp; the punctuation must be as specified here, Except:
&nbsp;&nbsp;&nbsp;&nbsp; 2. ISO date described here differs from the PICS 1.1 and ISO 8601:1988&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; date and time format. PICS 1.1 uses '.' as separators while the ISO
&nbsp;&nbsp;&nbsp;&nbsp; standard calls for '-'.  DSig supports both syntaxes.  PICS 1.1 also
&nbsp;&nbsp;&nbsp;&nbsp; does not support the optional seconds and fractions of seconds fields
&nbsp;&nbsp;&nbsp;&nbsp; and permits minutes to range from 0 to 60.
<B>base64-string</B> ::= as defined in RFC-1521.
<B>URL</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= as defined in RFC-1738.</PRE>
The following example shows a valid DSig 1.0 <B><I>resinfo</I></B> extension
with two hashes of the referenced information resource.
<PRE><TT>&nbsp;&nbsp; extension
&nbsp;&nbsp;&nbsp;&nbsp; ( optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "base64 hash" )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "base64 hash"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "1997-02-05T08:15-0500" ) )</TT></PRE>
In this example, we begin with the <B><I>extension ( optional</I></B> tokens
which identify this extension as an optional extension to the PICS label
within which it is contained. This declaration is followed by a <B><I>URL</I></B>,
http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0, which provides a unique name
for the extension. De-referencing the URL provides 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 returns 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.
<H3>
<A NAME="Signature_Block"></A>The Signature Block Extension</H3>
The DSig 1.0 Signature Block Extension (<B><I>sigblock</I></B>) provides
cryptographic protection of the DSig 1.0 label by using digital signature
techniques. It identifies
<UL>
<LI>
who has signed the information resource,</LI>

<LI>
which parts of the label were signed (if not the entire label), and</LI>

<LI>
which algorithms were used to generate the signature, and</LI>

<LI>
the signature data itself.</LI>
</UL>
The <B><I>sigblock</I></B> extension can also contain certificates that
can be used by a trust management system (TMS) to decide if the signature
is trustworthy.
<H4>
<A NAME="SigFormatSpec"></A>Format Specification</H4>
A Signature Block consists of
<UL>
<LI>
Attribution Information, and</LI>

<LI>
one or more Signatures.</LI>
</UL>
Usage notes:
<UL>
<LI>
The <B><I>sigblock</I></B> extension is an "optional" extension. <I>Optional</I>
implies that even if the processing software does not understand the extension,
it should still process the label. 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.</LI>

<LI>
The <B><I>sigblock</I></B> extension is valid in both <I>generic</I> and
<I>specific</I> (non-generic) PICS 1.1 labels.</LI>

<LI>
The <B><I>sigblock</I></B> extension is extensible via <A HREF="#sigsuite">signature
suites</A>.</LI>

<LI>
A <B><I>sigblock</I></B> extension is only valid as a label option.</LI>
</UL>
Here is a structural representation of the <B><I>sigblock</I></B> extension:
<PRE>&nbsp;&nbsp; extension
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;attribution info> &lt;signature>* ) )</PRE>

<H4>
<A NAME="AttribInfo"></A>Attribution Information</H4>
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 <B><I>sigblock</I></B> 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.

<P>Attribution Information supports any certificate format; the types of
certificates included will depend on the public key infrastructure used
by the application. Certificate format is indicated by the&nbsp;<A NAME="certfamilyid"></A>certificate
family identifier, a quoted URL identifier <A HREF="#URLID">as defined
above</A>. This certificate family identifier, when dereferenced, provides
information on the format of the data to follow.

<P>None of the information contained within the Attribution Information
section is signed by the label's signature because certificates themselves
are expected to be self-verifying. (More precisely, none of the information
within the entire <B><I>sigblock</I></B> 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).

<P>Here is a structural representation of the Attribution Information section:
<PRE>&nbsp;&nbsp; ( "AttribInfo"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "CertificateFamilyIdentifierURL" "Certificate Data")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "CertificateFamilyIdentifierURL" "Certificate Data")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...)</PRE>
Here is an example Attribution Information section:
<PRE>&nbsp;&nbsp; ( "AttribInfo"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "http://www.w3.org/PICS/DSig/X509-1_0" "base64-x.509-cert")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "http://www.w3.org/PICS/DSig/X509-1_0"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "http://ice-tel-ca/certs/DN/CN=Lipp,O=TU-Graz,OU=IAIK")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "http://www.w3.org/PICS/DSig/pgpcert-1_0" "base64-pgp-signed-key")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "http://www.w3.org/PICS/DSig/pgpcert-1_0"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at" ) )</PRE>

<H4>
<A NAME="Signature"></A>Signatures</H4>
The Signature section of the <I><B>sigblock</B> </I>extension contains
the actual digital signature data. Each Signature section contains exactly
one signature; multiple Signature sections may be included in the <B><I>sigblock</I></B>
extension when multiple, parallel signatures are desired. The syntax of
the Signature section is:
<PRE>&nbsp;&nbsp; ( "Signature" SignatureSuite SigData+)</PRE>
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 <B><I>sigblock</I></B>. Instead, we introduce the concept of "<A NAME="sigsuite"></A>signature
suites," which bundle together certain hashing algorithms, signature algorithms
and representation format. Each digital signature includes a&nbsp;<A NAME="sigsuiteid"></A>signature
suite identifier (a quoted URL identifier <A HREF="#URLID">as defined above</A>)
that tells applications how the signature was generated and how it should
be parsed.

<P>Each signature suite:
<UL>
<LI>
specifies the algorithms that have been used for creating the signature,
and</LI>

<LI>
defines the content of any subsequent SigData.</LI>
</UL>
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; beyond that requirement, the
format of the data is governed by the definition given in the signature
suite.
DSig 1.0 does define two hash algorithms and two signature suites for
interoperability; see Appendix 3.
Implementations must implement these four algorithms in addition to any others
they may wish to define.

<H4>
Common SigData fields</H4>
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 <I>reserved words </I>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.
<H5>
<A NAME="Keyholder"></A>Keyholder tokens: information about keys related
to the signature</H5>
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:
<OL>
<LI>
Provide the public key directly ("ByKey");</LI>

<LI>
Provide a hash (or fingerprint) of the public key ("ByHash");</LI>

<LI>
Provide some <I>name</I> that is associated with the public key, such as
an X.509 "distinguished name" or the UserID string of a PGP key ("ByName");
or</LI>

<LI>
Provide the name of a certifying authority (CA) and information, which
identifies the desired key to the CA ("ByCert").</LI>
</OL>
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.

<P>The following subsections specify the content of the SigInfo fields
associated with each of these tokens.
<H5>
"ByKey"</H5>
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).
<PRE>&nbsp;&nbsp; ( "ByKey" &lt;Key-Value, SignatureSuite dependent> )</PRE>
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:
<PRE>&nbsp;&nbsp; ( "ByKey"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "P" "base64-encoded-modulus" )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "Q" "base64-encoded-divisor" )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "G" "base64-encoded-number" )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "Y" "base64-encoded-public-key" ) )</PRE>

<H5>
"ByHash"</H5>
The token "ByHash"<I> </I>identifies the value that follows as the hash
of the key that should be used to validate the signature.
<PRE>&nbsp;&nbsp; ("ByHash" "base-64-encoded-hash-of-key" )</PRE>
Details on how the hash for a key is generated is a property of individual
signature suites.
<H5>
"ByName"</H5>
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.
<PRE>&nbsp;&nbsp; ( "ByName" "Name-as-string-value" )</PRE>

<H5>
"ByCert"</H5>
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.
<PRE>&nbsp;&nbsp; ( "ByCert" ( "CA-Name-as-string-value" &lt;CA-Serial-No.> ) )</PRE>

<H5>
<A NAME="SigInfo"></A>The "On" token: Time of Signature generation</H5>
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.

<P>The time that the signature was created is encoded as a <I>quoted-ISO-Date</i>.
The format of a quoted-ISO-Date is defined below.
<PRE>&nbsp;&nbsp; ("on" quoted-ISO-Date)</PRE>
Notice that the "on" time is advisory only to applications verifying the
digital signature; as this section is part of the entire <B><I>sigblock</I></B>
extension it is not cryptographically protected by the signature itself.
(The contents of the <B><I>sigblock</I></B> 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.
<H5>
<A NAME="SigCrypto"></A>The "include" and "exclude" tokens: modifying the
canonicalized form of the label</H5>
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:
<PRE>&nbsp;&nbsp; ( "exclude" field-list )&nbsp;
&nbsp;&nbsp; ( "include" field-list )</PRE>
The "include" and "exclude" SigData fields modify the default behavior
of the label canonicalizer. "include" indicates that only the fields listed
are included in the signature, "exclude" indicates that all fields are
included in the signature except those listed. Before a label is signed,
it is put into canonical form; the section "<A HREF="#equivalent_label">Creating
an equivalent standalone label</A>" 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.

<P>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:
<PRE>field-list&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= '(' option-list? ratings-list? extension-list? ')'
option-list&nbsp;&nbsp;&nbsp;&nbsp; ::= '(' "options" &lt;options>* ')'
ratings-list&nbsp;&nbsp;&nbsp; ::= '(' "ratings" &lt;ratings>* ')'
extension-list&nbsp; ::= '(' "extensions" &lt;quoted-URL>* ')'</PRE>
A field-list is simply at most, one each of: option-list, ratings-list
and extension-list, with their associated data. 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 quoted-URLs
where each quoted-URL uniquely identifies a particular PICS 1.1 label extension.

<P>Note: The "include" and "exclude" SigData types exist in this specification
strictly to overcome limitations in PICS 1.1 protocols. W3C's new metadata
infrastructure, <A HREF="http://www.w3.org/RDF/">Resource Description
Framework (RDF)</A> should not have these limitations and it is the intent
of the DSig working group that "include" and "exclude" not be present in
the DSig 2.0 specification, which will build on RDF.
<H5>
The "SigCrypto" token: signature cryptographic data</H5>
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.
<H4>
<A NAME="Hashing"></A>Hashing</H4>
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 <B><I>sigblock</I></B> extension (this process is
explained in the <A HREF="#Signing">Signing </A>section below). This canonicalized
label is the input to the signature suite's 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.
<H3>
Parallel and cascaded signatures</H3>
Multiple parallel signatures on the same PICS 1.1 label may be created
simply by including several "Signature" fields within the <B><I>sigblock</I></B>
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.
<H4>
<A NAME="Example"></A>An example <B><I>sigblock</I></B> extension:</H4>

<PRE>&nbsp;&nbsp; extension (optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("AttribInfo"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/PICS/DSig/X509-1_0" "base64-x.509-cert")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/PICS/DSig/X509-1_0"&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "http://SomeCa/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/PICS/DSig/pgpcert-1_0" "base64-pgp-signed-key")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/PICS/DSig/pgpcert-1_0"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at"))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("byKey" (("N" "aba21241241=")&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("E" "abcdefghijklmnop=")))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("on" "1996-12-02T22:20-0000")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("exclude" (("extensions" "http://foo/badextension")))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("SigCrypto" "aba1241241=="))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/DSS-1_0"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("ByName" "plipp@iaik.tu-graz.ac.at")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("on" "1996-12-02T22:20-0000")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("SigCrypto" (("R" "aba124124156")&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("S" "casdfkl3r489")))))</PRE>

<H4>
Detailed Syntax of the <B><I>sigblock</I></B> Extension in a PICS 1.1 Label</H4>
Note: This extension is not a valid PICS 1.1 extension because Base64 encoding
uses a '/' which cannot be represented as a PICS 1.1 datum. Nonetheless,
since quotedURL (which <B>does</B> allow the use of '/') and quotedname
(which does not) are indistinguishable at a lexical level (and both are
legitimate for use as a PICS 1.1. datum), we believe that all existing
PICS parsers will support the grammar presented below.
<PRE><B>SignatureExtension</B>&nbsp; ::= 'extension ( optional'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SigBlockURL AttributionInfo Signature* ')'
<B>SigBlockURL</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= '"http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"'
<B>AttributionInfo</B>&nbsp;&nbsp;&nbsp;&nbsp; ::= '(' '"AttribInfo"' Certificate* ')'
<B>Certificate</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= '(' CertificateFamilyID CertificateData ')'
<B>CertificateFamilyID</B> ::= quotedUrl
<B>CertificateData</B>&nbsp;&nbsp;&nbsp;&nbsp; ::= quotedBase64String | quotedUrl
<B>Signature</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= '( "Signature"' SignatureSuiteID SigData+ ')'
<B>SigData</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= '(' SigTokenString SigInfo ')'
<B>SigTokenString</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= quotedName
<B>SigInfo</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= SigData | quotedURL | quoted-ISO-date | quotedBase64String
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | quotedName | number | '(' SigInfo+ ')'
<B>SignatureSuiteID</B>&nbsp;&nbsp;&nbsp; ::= quotedUrl
<B>quotedURL&nbsp;&nbsp;</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= '"' URL '"'
<B>URL</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= as<I> defined by RFC-1738.
</I><B>quotedBase64String&nbsp;</B> ::= '"' base64String '"'
<B>base64String</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= <I>as defined in RFC-1521.
</I><B>alpha</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= 'A' | .. | 'Z' | 'a' | .. | 'z'
<B>digit</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= '0' | .. | '9'
<B>quotedName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</B> ::= '"' ( urlChar | ' ')+ '"'
<B>urlChar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</B> ::=<B> </B>alphaNumPM | '.' | '$' | ',' | ';' | ':'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | '&amp;' | '=' | '?' | '!' | '*' | '~' | '@'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | '#' | '_' | '(' | ')' | '/' | '%' hex hex
<I>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ; Note: Use the "%" escape technique to insert
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ; single or double quotation marks within a URL
</I><B>alphaNumPM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</B> ::= alpha | digit | sign
<B>hex&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </B>::= digit | 'A' | .. | 'F' | 'a' | .. | 'f'
<B>sign</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= '+' / '-'
<B>number</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=<B> </B>[sign]unsignedInt['.' [unsignedInt]]
<B>unsignedInt</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= digit+
<B>quoted-ISO-date</B> ::= '"' YYYY <i>sep</i> MM <i>sep</i> DD 'T' hh ':' mm[':' ss['.' f+]] Stz '"'
&nbsp;&nbsp;&nbsp;&nbsp; based on the PICS-defined ISO 8601:1988 date and time format, restricted
&nbsp;&nbsp;&nbsp;&nbsp; to the specific form described here:
&nbsp;&nbsp;&nbsp;&nbsp; <B>sep&nbsp;&nbsp; </B>::= '.' | '-'
&nbsp;&nbsp;&nbsp;&nbsp; <B>YYYY&nbsp; </B>::= four-digit year
&nbsp;&nbsp;&nbsp;&nbsp; <B>MM&nbsp;&nbsp;&nbsp; </B>::= two-digit month (01=January, etc.)
&nbsp;&nbsp;&nbsp;&nbsp; <B>DD&nbsp;&nbsp;&nbsp;</B> ::= two-digit day of month (01 through 31)
&nbsp;&nbsp;&nbsp;&nbsp; <B>hh&nbsp;&nbsp;&nbsp;</B> ::= two digits of hour (00 through 23) (am/pm NOT allowed)
&nbsp;&nbsp;&nbsp;&nbsp; <B>mm&nbsp;&nbsp;&nbsp;</B> ::= two digits of minute (00 through 59)
&nbsp;&nbsp;&nbsp;&nbsp; <B>ss&nbsp;&nbsp;&nbsp;</B> ::= two digits of second (00 through 59), optional
&nbsp;&nbsp;&nbsp;&nbsp; <B>f&nbsp;&nbsp;&nbsp;&nbsp;</B> ::= digit(s) of fractions of second, optional
&nbsp;&nbsp;&nbsp;&nbsp; <B>S&nbsp;&nbsp;&nbsp;&nbsp;</B> ::= sign of time zone offset from UTC ('+' or '-')
&nbsp;&nbsp;&nbsp;&nbsp; <B>tz&nbsp;&nbsp; </B> ::= four digit amount of offset from UTC
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (e.g., 1512 means 15 hours and 12 minutes)
&nbsp;&nbsp;&nbsp;&nbsp; For example, "1994-11-05T08:15-0500" is a valid <I>quoted-ISO-date
</I>&nbsp;&nbsp;&nbsp;&nbsp; denoting November 5, 1994, 8:15 am, US Eastern Standard Time
&nbsp;&nbsp;&nbsp;&nbsp; <B>Notes:</B>&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; 1. The ISO 8601:1988 date and time format standard allows considerably&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; greater flexibility than that described here.&nbsp; DSig requires <I>precisely
</I>&nbsp;&nbsp;&nbsp;&nbsp; the syntax described here -- neither the time nor the time zone may
&nbsp;&nbsp;&nbsp;&nbsp; be omitted, none of the alternate ISO formats are permitted, and
&nbsp;&nbsp;&nbsp;&nbsp; the punctuation must be as specified here, Except:
&nbsp;&nbsp;&nbsp;&nbsp; 2. ISO date described here differs from the PICS 1.1 and ISO 8601:1988&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; date and time format. PICS 1.1 uses '.' as separators while the ISO
&nbsp;&nbsp;&nbsp;&nbsp; standard calls for '-'.  DSig supports both syntaxes.  PICS 1.1 also
&nbsp;&nbsp;&nbsp;&nbsp; does not support the optional seconds and fractions of seconds fields
&nbsp;&nbsp;&nbsp;&nbsp; and permits minutes to range from 0 to 60.
</PRE>

<H2>
<A NAME="Signing"></A>Signing</H2>
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 <A HREF="#PICS_1_1_labels">PICS
1.1 labels and label lists</A>. Here again is a structural representation
of a PICS 1.1 label list:
<PRE>&nbsp;&nbsp; (PICS-1.1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;service 1 url> [service 1 option...]
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; labels [label 1 options...] [label 1 signature]&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings (&lt;category> &lt;value> ...)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [label 2 options...] [label 2 signature]&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings (&lt;category> &lt;value> ...)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;service 2 url> [service 2 option...]&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; labels [label 3 options...] [label 3 signature]&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings (&lt;category> &lt;value> ...)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [label 4 options...] [label 4 signature]&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings (&lt;category> &lt;value> ...)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
&nbsp;&nbsp; )</PRE>

<H3>
Signing a label</H3>
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 <I>equivalent standalone label for the label to be signed</I>.
Then the equivalent standalone label is canonicalized (similar to canonicalizing
a PICS label for transmission). Finally, a digital signature is generated,
inserted into a <B><I>sigblock</I></B> extension, and that extension is
placed in the label as a label extension. An equivalent standalone label
can have at most one <B><I>resinfo</I></B> extension (which it may inherit
from the service options).
<H4>
Creating an&nbsp;<A NAME="equivalent_label"></A>equivalent standalone label</H4>
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 <B><I>sigblock</I></B>
extension (if present) has been removed.<FONT COLOR="#FFFF00"> </FONT>From
the example label list above, label 4 could be reduced to the single label:
<PRE>&nbsp;&nbsp; (PICS-1.1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;service 2 url>&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; labels [service 2 option...] OVERRIDDEN BY [label 4 option...]&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings ([label 4 ratings ...]))</PRE>
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 <B><I>sigblock</I></B> extension. (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.
<H4>
<A NAME="Canonicalization"></A>Canonicalization of the equivalent standalone
label for signing</H4>

<UL>
<LI>
For a given PICS 1.1 label, insert a single space character between any
two tokens. PICS 1.1 tokens include left and right parenthesis, symbols,
quoted-strings, and numbers. Symbols are case insensitive and converted
to lowercases. Tokens in multi-value syntax are considered symbols. Do
not insert spaces for either the leading left parenthesis or the the trailing
right parenthesis of a PICS 1.1 label list. No carriage-returns or linefeeds
are present in a cannonicalized label.</LI>

<LI>
A normalized DSig-1.0 label consists of three parts in order: the PICS
1.1 header, the options, and the ratings. The header part is the 'pics-1.1'
symbol followed by the <I>serviceURL</I>.</LI>

<LI>
The option part is headed by the label keyword "l", followed by a set of
PICS-1.1 options, including the extensions. The set of options, including
the extensions, are determined by the <I>option-list</I> and the <I>extension-list</I>
fields of the <I>"exclude</I>" or the <I>"include</I>" option in the signature
suite. The options are sorted alphabetically (i.e. lexicographically ordered
by the unquoted US ASCII characters)&nbsp;&nbsp; by their shortest names
(i.e. use <I>full</I> instead of <I>complete-label</I>, <I>exp</I> instead
of <I>until</I>). Extension options are sorted first by <I>"extension"</I>
and then by the <I>"extension" URL</I>.</LI>

<LI>
The rating part is headed by the rating keyword "r", followed by a set
of transmit name and value pairs. The set of transmit-name and value pairs
are determined by the <I>"rating-list</I>" field of the <I>"include</I>"
or <I>"exclude</I>" option in the signature. Transmit names are sorted
alphabetically.</LI>

<LI>
When the client computes the equivalent standalone label format described
above, it will use all options available to it: both service and label
options. This implies a constraint on the server when it decides what options
to include in the transmitted set. The transmitted set must include all
options necessary as either service or label options to create the same
equivalent standalone label as was signed.</LI>
</UL>

<H3>
An Example</H3>
The following example illustrates a step-by-step process to sign a PICS
1.1 label.

<P>Step 1: creates a PICS 1.1 label
<PRE>&nbsp; (PICS-1.1 "http://www.gcf.org/v2.5"
&nbsp;&nbsp;&nbsp;&nbsp; by "John Doe"
&nbsp;&nbsp;&nbsp;&nbsp; labels&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for "http://www.w3.org/PICS/DSig/Overview"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on "1994.11.05T08:15-0500"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings (suds 0.5 density 0 color 1))</PRE>
Step 2: compute the hashes of the document, create the <B><I>resinfo</I></B>
extension, and insert it in the label
<PRE>&nbsp; (PICS-1.1 "http://www.gcf.org/v2.5"
&nbsp;&nbsp;&nbsp;&nbsp; by "John Doe"
&nbsp;&nbsp;&nbsp;&nbsp; labels&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for "http://www.w3.org/PICS/DSig/Overview"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "aba21241241=")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "1997-02-05T08:15-0500"))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on "1994.11.05T08:15-0500"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings (suds 0.5 density 0 color 1))</PRE>
Step 3: canonicalize the label
<BR><I><FONT SIZE=-1>(NOTE: Carriage-returns in the above example are for
display purposes only. Properly canonicalized, this label would have no
carriage-returns.)</FONT></I>
<PRE>( PICS-1.1 "http://www.gcf.org/v2.5" l by "John Doe"
&nbsp; extension ( optional&nbsp;
&nbsp; "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0" (&nbsp;
&nbsp; "http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="&nbsp;&nbsp;
&nbsp; "1997-02-05T08:15-0500" ) ( "http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0"
&nbsp; "aba21241241=" ) ) for "http://www.w3.org/PICS/DSig/Overview"&nbsp;
&nbsp; on "1994.11.05T08:15-0500" r ( color 1 density 0 suds 0.5 ) )</PRE>
Step 4: sign the canonicalized form of the label and insert it in the label
<PRE>&nbsp; (PICS-1.1 "http://www.gcf.org/v2.5"
&nbsp;&nbsp;&nbsp;&nbsp; by "John Doe"
&nbsp;&nbsp;&nbsp;&nbsp; labels&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for "http://www.w3.org/PICS/DSig/Overview"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "aba21241241=")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "1997-02-05T08:15-0500"))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("AttribInfo"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/PICS/DSig/X509-1_0" "efe64685685=")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/PICS/DSig/X509-1_0"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "http://SomeCA/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/PICS/DSig/pgpcert-1_0" "ghg86807807=")
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("http://www.w3.org/PICS/DSig/pgpcert-1_0"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at"))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0"&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("byKey" (("N" "aba212412412=")&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("E" "3jdg93fj")))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("on" "1996-12-02T22:20-0000")&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("SigCrypto" "3j9fsaJ30SD=")))
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on "1994.11.05T08:15-0500"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ratings (suds 0.5 density 0 color 1))</PRE>
And now we have a valid DSig-1.0 label.
<H3>
Signing Notes</H3>
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 <B>complete</B>
option pointing to a full, signed label. Client software in need of a signed
label can de-reference the <B>complete</B> option's URL to retrieve a complete,
signed label.
<H2>
<A NAME="Appendix_1"></A>Appendix 1: Service Resource Information</H2>
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 <I>after</I>
the label has been created without invalidating the label.

<P>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.
<H2>
<A NAME="Appendix_2"></A>Appendix 2: Transporting DSig 1.0 Labels</H2>
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.

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

<P>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.
<H2>
<A NAME="Appendix_3"></A>Appendix 3: Conforming Implementations</H2>
In order to conform with this Recommendation, an implementation must
      support:
<ul>
  <li>resinfo 1.0 hash algorithms:
  <ul>
    <li>
      <a HREF="/TR/1998/REC-DSig-label/MD5-1_0">MD5 hashing
        (http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0)</A>,
    <li>
      <A HREF="/TR/1998/REC-DSig-label/SHA1-1_0">SHA1 hashing
        (http://www.w3.org//TR/1998/REC-DSig-label/SHA1-1_0)</A>
  </ul>

  <li>sigblock 1.0 signature suites:
  <ul>
    <li>
      <A HREF="/TR/1998/REC-DSig-label/RSA-MD5-1_0">MD5 hashing with
        RSA crypto (http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0)</A>,
    <li>
      <A HREF="/TR/1998/REC-DSig-label/DSS-1_0">SHA1 hashing
        with DSA crypto
        (http://www.w3.org//TR/1998/REC-DSig-label/DSS-1_0)</A>
        (known as DSS).
  </ul>
</ul>
<H2>
<A NAME="Acknowledgements"></A>Acknowledgments</H2>

<UL>
<LI>
John Carbajal carbajal@ibeam.intel.com</LI>

<LI>
Rosario Gennaro rosario@watson.ibm.com</LI>

<LI>
Amy Katriel amygk@watson.ibm.com</LI>

<LI>
Rohit Khare khare@w3.org</LI>

<LI>
Paul Lambert palamber@us.oracle.com</LI>

<LI>
Jim Miller jmiller@w3.org</LI>

<LI>
Hemma Prafullchandra hemma@eng.sun.com</LI>

<LI>
Rob Price robp@microsoft.com</LI>

<LI>
Paul Resnick presnick@research.att.com</LI>

<LI>
Pankaj Rohatgi rohatgi@watson.ibm.com</LI>

<LI>
Andreas Sterbenz sterbenz@iaik.tu-graz.ac.at</LI>
</UL>

<HR>
<H2>
<A NAME="Reference Materials"></A>Reference Materials</H2>

<UL>
<LI>
N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mai Extensions) Part
One: Mechanisms for Specifying and Describing the Format of Internet Message
Bodies", RFC 1521, 09/23/1993. <A HREF="ftp://ds.internic.net/rfc/rfc1521.txt">ftp://ds.internic.net/rfc/rfc1521.txt</A></LI>

<LI>
T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators (URLs)",
RFC 1738, 12/20/94. <A HREF="ftp://ds.internic.net/rfc/rfc1738.txt">ftp://ds.internic.net/rfc/rfc1738.txt</A></LI>

<LI>
Digital Signature Label Architecture, <I>W3C Working Draft</I>, <A HREF="/TR/WD-DSIG-label-arch">http://www.w3.org/TR/WD-DSIG-label-arch</A></LI>

<LI>
Rating Services and Rating Systems and Their Machine Readable Descriptions
Version 1.1, <I>W3C Recommendation,</I> <A HREF="/TR/REC-PICS-services">http://www.w3.org/TR/REC-PICS-services</A></LI>

<LI>
PICS Label Distribution Label Syntax and Communication Protocols Version
1.1, <I>W3C Recommendation,</I> <A HREF="/TR/REC-PICS-labels">http://www.w3.org/TR/REC-PICS-labels</A></LI>
</UL>

<HR>
<H2>
<A NAME="Authors_Addresses"></A>Authors Addresses</H2>
<A NAME="Yang_hua_Chu"></A>Yang-hua Chu
<BR>Carnegie Mellon University
<BR>Department of Computer Science
<BR>Wean Hall 5123
<BR>5000 Forbes Avenue
<BR>Pittsburgh, PA 15213
<BR>Email: <A HREF="mailto:yhchu@cs.cmu.edu">yhchu@cs.cmu.edu</A>

<P><A NAME="Philip_DesAutels"></A>Philip DesAutels
<BR>Formerly: Project Manager, Technology and Society Domain, W3 Consortium
<BR>Current Address:
<BR>Senior Principal Architect
<BR>MatchLogic, Inc.
<BR>400 S. McCaslin Blvd.
<BR>Louisville, Colorado 80027
<BR>Email: <A HREF="mailto:philipd@matchlogic.com">philipd@matchlogic.com</A>

<P><A NAME="Brian_LaMacchia"></A>Brian LaMacchia
<BR>Microsoft Corporation
<BR>One Microsoft Way
<BR>Redmond, WA 98052-6399
<BR>Email: <A HREF="mailto:bal@microsoft.com">bal@microsoft.com</A>

<P><A NAME="Peter_Lipp"></A>Peter Lipp
<BR>IAIK, University of Technology, Graz
<BR>Institute for Applied Information Processing and Communications
<BR>Klosterwiesgasse 32/I, A-8010 Graz, Austria
<BR>Email: <A HREF="mailto:plipp@iaik.tu-graz.ac.at">plipp@iaik.tu-graz.ac.at</A>
<hr>
<h2>Change History</h2>
1998-06-01 Make the document fully
<a href="http://validator.w3.org/">valid HTML 4.0</a><br>
1998-05-27 First version published on
<a href="http://www.w3.org/TR">http://www.w3.org/TR</a><br>
</BODY>
</HTML>