You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1539 lines
77 KiB
1539 lines
77 KiB
<!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> © 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> (PICS-1.1
|
|
<Service 1 section>
|
|
<Service 2 section>
|
|
<Service 3 section>)</PRE>
|
|
Where each service section contains options and labels:
|
|
<PRE> <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>
|
|
...</PRE>
|
|
The general form for a label list (formatted for presentation, and not
|
|
showing error status codes) is:
|
|
<PRE> (PICS-1.1
|
|
<I><service 1 url> </I>[service 1 <I>option...</I>]
|
|
labels [label 1 <I>option...</I>] ratings (<category> <value> ...)
|
|
[label 2 option...] ratings (<category> <value> ...)
|
|
...
|
|
<<I>service 2 url</I>> [<I>service 2 option...</I>]
|
|
labels [<I>label 3 option...</I>] ratings (<category> <value> ...)
|
|
[label 4 option...] ratings (<category> <value> ...)
|
|
...
|
|
...)</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> (PICS-1.1
|
|
<<I>service 2 url</I>>
|
|
labels [ <I>service 2 options + </I>label 4 option...]
|
|
ratings (<category> <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 <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> ("Hash Algorithm Identifier" "base64-string of hash" "hash date")</TT></PRE>
|
|
The <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> '"http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"' resinfo-data</I>+ ')'
|
|
<B>resinfo-data </B>::=<B> </B>'(' <I>HashAlgoID resource-hash hash-date? </I>')'
|
|
<B>HashAlgoID </B>::=<B> </B><I>quotedURL</I>
|
|
<B>quotedURL </B>::= '"' <I>URL</I> '"'
|
|
<B>resource-hash </B>::= '"<i>base64-string</i>"'
|
|
<B>hash-date</B> ::= quoted-ISO-date
|
|
<B>quoted-ISO-date</B> ::= '"' YYYY <i>sep</i> MM <i>sep</i> DD 'T' hh ':' mm[':' ss['.' f+]] Stz '"'
|
|
based on the PICS-defined ISO 8601:1988 date and time format, restricted
|
|
to the specific form described here:
|
|
<B>sep </B>::= '.' | '-'
|
|
<B>YYYY </B>::= four-digit year
|
|
<B>MM </B>::= two-digit month (01=January, etc.)
|
|
<B>DD </B> ::= two-digit day of month (01 through 31)
|
|
<B>hh </B> ::= two digits of hour (00 through 23) (am/pm NOT allowed)
|
|
<B>mm </B> ::= two digits of minute (00 through 59)
|
|
<B>ss </B> ::= two digits of second (00 through 59), optional
|
|
<B>f </B> ::= digit(s) of fractions of second, optional
|
|
<B>S </B> ::= sign of time zone offset from UTC ('+' or '-')
|
|
<B>tz </B> ::= 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 <I>quoted-ISO-date
|
|
</I> denoting November 5, 1994, 8:15 am, US Eastern Standard Time
|
|
<B>Notes:</B>
|
|
1. The ISO 8601:1988 date and time format standard allows considerably
|
|
greater flexibility than that described here. DSig requires <I>precisely
|
|
</I> the syntax described here -- neither the time nor the time zone may
|
|
be omitted, none of the alternate ISO formats are permitted, and
|
|
the punctuation must be as specified here, Except:
|
|
2. ISO date described here differs from the PICS 1.1 and ISO 8601:1988
|
|
date and time format. PICS 1.1 uses '.' as separators while the ISO
|
|
standard calls for '-'. DSig supports both syntaxes. PICS 1.1 also
|
|
does not support the optional seconds and fractions of seconds fields
|
|
and permits minutes to range from 0 to 60.
|
|
<B>base64-string</B> ::= as defined in RFC-1521.
|
|
<B>URL</B> ::= 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> extension
|
|
( optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
|
|
( "http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "base64 hash" )
|
|
( "http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "base64 hash"
|
|
"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> extension
|
|
( optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"
|
|
<attribution info> <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 <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> ( "AttribInfo"
|
|
( "CertificateFamilyIdentifierURL" "Certificate Data")
|
|
( "CertificateFamilyIdentifierURL" "Certificate Data")
|
|
...)</PRE>
|
|
Here is an example Attribution Information section:
|
|
<PRE> ( "AttribInfo"
|
|
( "http://www.w3.org/PICS/DSig/X509-1_0" "base64-x.509-cert")
|
|
( "http://www.w3.org/PICS/DSig/X509-1_0"
|
|
"http://ice-tel-ca/certs/DN/CN=Lipp,O=TU-Graz,OU=IAIK")
|
|
( "http://www.w3.org/PICS/DSig/pgpcert-1_0" "base64-pgp-signed-key")
|
|
( "http://www.w3.org/PICS/DSig/pgpcert-1_0"
|
|
"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> ( "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 <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> ( "ByKey" <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> ( "ByKey"
|
|
( "P" "base64-encoded-modulus" )
|
|
( "Q" "base64-encoded-divisor" )
|
|
( "G" "base64-encoded-number" )
|
|
( "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> ("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> ( "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> ( "ByCert" ( "CA-Name-as-string-value" <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> ("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> ( "exclude" field-list )
|
|
( "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 ::= '(' option-list? ratings-list? extension-list? ')'
|
|
option-list ::= '(' "options" <options>* ')'
|
|
ratings-list ::= '(' "ratings" <ratings>* ')'
|
|
extension-list ::= '(' "extensions" <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> extension (optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"
|
|
("AttribInfo"
|
|
("http://www.w3.org/PICS/DSig/X509-1_0" "base64-x.509-cert")
|
|
("http://www.w3.org/PICS/DSig/X509-1_0"
|
|
"http://SomeCa/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")
|
|
("http://www.w3.org/PICS/DSig/pgpcert-1_0" "base64-pgp-signed-key")
|
|
("http://www.w3.org/PICS/DSig/pgpcert-1_0"
|
|
"http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at"))
|
|
("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0"
|
|
("byKey" (("N" "aba21241241=")
|
|
("E" "abcdefghijklmnop=")))
|
|
("on" "1996-12-02T22:20-0000")
|
|
("exclude" (("extensions" "http://foo/badextension")))
|
|
("SigCrypto" "aba1241241=="))
|
|
("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/DSS-1_0"
|
|
("ByName" "plipp@iaik.tu-graz.ac.at")
|
|
("on" "1996-12-02T22:20-0000")
|
|
("SigCrypto" (("R" "aba124124156")
|
|
("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> ::= 'extension ( optional'
|
|
SigBlockURL AttributionInfo Signature* ')'
|
|
<B>SigBlockURL</B> ::= '"http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"'
|
|
<B>AttributionInfo</B> ::= '(' '"AttribInfo"' Certificate* ')'
|
|
<B>Certificate</B> ::= '(' CertificateFamilyID CertificateData ')'
|
|
<B>CertificateFamilyID</B> ::= quotedUrl
|
|
<B>CertificateData</B> ::= quotedBase64String | quotedUrl
|
|
<B>Signature</B> ::= '( "Signature"' SignatureSuiteID SigData+ ')'
|
|
<B>SigData</B> ::= '(' SigTokenString SigInfo ')'
|
|
<B>SigTokenString</B> ::= quotedName
|
|
<B>SigInfo</B> ::= SigData | quotedURL | quoted-ISO-date | quotedBase64String
|
|
| quotedName | number | '(' SigInfo+ ')'
|
|
<B>SignatureSuiteID</B> ::= quotedUrl
|
|
<B>quotedURL </B> ::= '"' URL '"'
|
|
<B>URL</B> ::= as<I> defined by RFC-1738.
|
|
</I><B>quotedBase64String </B> ::= '"' base64String '"'
|
|
<B>base64String</B> ::= <I>as defined in RFC-1521.
|
|
</I><B>alpha</B> ::= 'A' | .. | 'Z' | 'a' | .. | 'z'
|
|
<B>digit</B> ::= '0' | .. | '9'
|
|
<B>quotedName </B> ::= '"' ( urlChar | ' ')+ '"'
|
|
<B>urlChar </B> ::=<B> </B>alphaNumPM | '.' | '$' | ',' | ';' | ':'
|
|
| '&' | '=' | '?' | '!' | '*' | '~' | '@'
|
|
| '#' | '_' | '(' | ')' | '/' | '%' hex hex
|
|
<I> ; Note: Use the "%" escape technique to insert
|
|
; single or double quotation marks within a URL
|
|
</I><B>alphaNumPM </B> ::= alpha | digit | sign
|
|
<B>hex </B>::= digit | 'A' | .. | 'F' | 'a' | .. | 'f'
|
|
<B>sign</B> ::= '+' / '-'
|
|
<B>number</B> ::=<B> </B>[sign]unsignedInt['.' [unsignedInt]]
|
|
<B>unsignedInt</B> ::= digit+
|
|
<B>quoted-ISO-date</B> ::= '"' YYYY <i>sep</i> MM <i>sep</i> DD 'T' hh ':' mm[':' ss['.' f+]] Stz '"'
|
|
based on the PICS-defined ISO 8601:1988 date and time format, restricted
|
|
to the specific form described here:
|
|
<B>sep </B>::= '.' | '-'
|
|
<B>YYYY </B>::= four-digit year
|
|
<B>MM </B>::= two-digit month (01=January, etc.)
|
|
<B>DD </B> ::= two-digit day of month (01 through 31)
|
|
<B>hh </B> ::= two digits of hour (00 through 23) (am/pm NOT allowed)
|
|
<B>mm </B> ::= two digits of minute (00 through 59)
|
|
<B>ss </B> ::= two digits of second (00 through 59), optional
|
|
<B>f </B> ::= digit(s) of fractions of second, optional
|
|
<B>S </B> ::= sign of time zone offset from UTC ('+' or '-')
|
|
<B>tz </B> ::= 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 <I>quoted-ISO-date
|
|
</I> denoting November 5, 1994, 8:15 am, US Eastern Standard Time
|
|
<B>Notes:</B>
|
|
1. The ISO 8601:1988 date and time format standard allows considerably
|
|
greater flexibility than that described here. DSig requires <I>precisely
|
|
</I> the syntax described here -- neither the time nor the time zone may
|
|
be omitted, none of the alternate ISO formats are permitted, and
|
|
the punctuation must be as specified here, Except:
|
|
2. ISO date described here differs from the PICS 1.1 and ISO 8601:1988
|
|
date and time format. PICS 1.1 uses '.' as separators while the ISO
|
|
standard calls for '-'. DSig supports both syntaxes. PICS 1.1 also
|
|
does not support the optional seconds and fractions of seconds fields
|
|
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> (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> ...)
|
|
...
|
|
...
|
|
)</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 <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> (PICS-1.1
|
|
<service 2 url>
|
|
labels [service 2 option...] OVERRIDDEN BY [label 4 option...]
|
|
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) 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> (PICS-1.1 "http://www.gcf.org/v2.5"
|
|
by "John Doe"
|
|
labels
|
|
for "http://www.w3.org/PICS/DSig/Overview"
|
|
on "1994.11.05T08:15-0500"
|
|
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> (PICS-1.1 "http://www.gcf.org/v2.5"
|
|
by "John Doe"
|
|
labels
|
|
for "http://www.w3.org/PICS/DSig/Overview"
|
|
extension
|
|
(optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
|
|
("http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "aba21241241=")
|
|
("http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="
|
|
"1997-02-05T08:15-0500"))
|
|
on "1994.11.05T08:15-0500"
|
|
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"
|
|
extension ( optional
|
|
"http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0" (
|
|
"http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="
|
|
"1997-02-05T08:15-0500" ) ( "http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0"
|
|
"aba21241241=" ) ) for "http://www.w3.org/PICS/DSig/Overview"
|
|
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> (PICS-1.1 "http://www.gcf.org/v2.5"
|
|
by "John Doe"
|
|
labels
|
|
for "http://www.w3.org/PICS/DSig/Overview"
|
|
extension
|
|
(optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
|
|
("http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "aba21241241=")
|
|
("http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="
|
|
"1997-02-05T08:15-0500"))
|
|
extension
|
|
(optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"
|
|
("AttribInfo"
|
|
("http://www.w3.org/PICS/DSig/X509-1_0" "efe64685685=")
|
|
("http://www.w3.org/PICS/DSig/X509-1_0"
|
|
"http://SomeCA/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")
|
|
("http://www.w3.org/PICS/DSig/pgpcert-1_0" "ghg86807807=")
|
|
("http://www.w3.org/PICS/DSig/pgpcert-1_0"
|
|
"http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at"))
|
|
("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0"
|
|
("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))</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>
|