%last updated in April 2002 by Antje Endemann

%\documentclass[runningheads]{llncs}
%In order to omit page numbers and running heads
%please use the following line instead of the first command line:
\documentclass{llncs}
\usepackage{xspace}
\usepackage{graphicx}
\usepackage{subfigure}

%Furthermore change the line \pagestyle{headings} to
\pagestyle{empty}

%\input{psfig.sty}

% Define some custom commands for convenience
\newcommand{\etc}{etc.\@\xspace}
\newcommand{\ie}{i.e.\@\xspace}
\newcommand{\etal}{et al.\@\xspace}
\newcommand{\xmlsig}{XMLdsig\@\xspace}
\newcommand{\elem}[1]{\texttt{<#1>}}
\newcommand{\todo}[1]{\emph{\textbf{(TODO - #1)}}}

\newenvironment{bulletlist}{%
\renewcommand{\labelitemi}{$\bullet$}%
\begin{itemize}}{\end{itemize}}


\begin{document}

%\pagestyle{headings}
%In order to omit page numbers and running heads
%please change this line to
%\pagestyle{empty}
%and change the first command line too, see above.

\mainmatter

\title{Grouping Verifiable Content for\\Selective Disclosure}

\titlerunning{Lecture Notes in Computer Science}

\author{Laurence Bull\inst{1}
\and David McG. Squire\inst{1}
\and Jan Newmarch\inst{2}
\and Yuliang Zheng\inst{3}
}

\authorrunning{Laurence Bull et al.}

\institute{
School of Computer Science and Software Engineering, \\Monash University,
Caulfield East 3145, Australia\\
\email{\{Laurence.Bull, David.Squire\}@infotech.monash.edu.au}\\
\and
School of Network Computing, \\Monash University,
Frankston 3199, Australia\\
\email{Jan.Newmarch@infotech.monash.edu.au}\\
\and
Department of Software and Information Systems,\\
University of North Carolina at Charlotte, Charlotte, NC 28223, USA\\
\email{yzheng@uncc.edu}}

\maketitle

\begin{abstract}

This paper addresses the issue of selective disclosure of verifiable content.
It extends previous work relating to Content Extraction Signatures~\cite{SBZ02}
to implement a more complex structure that encodes a richer, more flexible
fragment extraction policy, which includes fragment grouping. The new
extraction policy enables the signer to specify both optional and mandatory
fragment associations (or groupings) for verifying extracted content.

\end{abstract}

\paragraph{Keywords:} Selective content disclosure, content extraction
signatures, privacy-enhancing signatures, fragment grouping.

\section{Introduction} \label{sec-intro}
As the pervasiveness of the Internet grows, so does electronic society.
Traditional communication and commerce based on paper documents is being
superseded by electronic processes and content. %The replacement, enhancement,
%and handling of formerly paper-based documents for an electronic society is the
%focus of this research.

\emph{Documents are merely containers.} Traditionally, documents have been
viewed and handled as coherent collections of semantically grouped information.
More specifically, there are types of documents that represent merely a
container of facts, such as a contract, an academic transcript, a non-fiction
book, or an encyclopedia. It is with such documents that our main focus lies.

Consider the retrieval and exchange of individual pieces of information
contained within a given document, rather than the handling of the whole
document.  Underlying this activity is the notion that the document itself
is not the most important thing to the holder in such cases. The value,
rather, lies with the document content, \ie its constituent pieces of
information. Furthermore, this concept is not constrained to small
containers of information such as letters, contracts, bank statements or
receipts. It is also scalable to very large collections such as books or
encyclopedias.

There are everyday situations where, for reasons of relevance or privacy,
one wants to disclose only certain parts of a document. Under the current
digital signature regime, however, the entire document is signed, thereby
forcing the document holder to disclose all of its contents to a third
party for the signature to be verifiable.

Stewart Baker, chief counsel for America's National Security Agency (NSA),
has warned of the threats to our privacy in an electronic society \cite{Bak94}:
\begin{quotation}
    The biggest threats to our privacy in a digital world come not
    from what we keep secret but from what we reveal willingly. We
    lose privacy in a digital world because it becomes cheap and
    easy to collate and transmit data\ldots Restricting these
    invasions of privacy is a challenge, but it isn't a job for
    encryption. Encryption can't protect you from the misuse of
    data you surrendered willingly.
\end{quotation}

Blakley claims that digital signatures are quite different from their
ink-based predecessors, and suggests that we should ``look more closely at
every way in which digital signatures differ'' so that we may fully realise
their worth \cite{Bla99}.

We agree with these views. In this paper we propose a means of reducing the
erosion of a document holder's privacy in real-world electronic interactions.
This is achieved through the use of Content Extraction Signatures
(CES)~\cite{SBZ02}, and the further development of a fragment extraction policy
that enables the document holder to selectively disclose verifiable content.

    \subsection{Background}

In the physical world commerce is conducted through interactions and
transactions. %While most of these interactions are viewed as being
%point-to-point, they may also be seen as parts of an asynchronous
%multiparty interaction.
The standard digital signature is well-suited to point-to-point interactions,
since party A simply signs the content they wish to send to party B. Not all
instances of commerce, however, should be characterised as merely a series of
point-to-point interactions. More properly, many instances are multipoint, or
multiparty, interactions where information flows from the information signer to
the document holder and then to the information consumer(s) as illustrated in
Fig.~\ref{fig-interact}.
%Consider a motorist proving to a police officer that s/he is
%authorised to drive a motor vehicle. Hopefully, prior to this event, the driver
%engaged in an interaction with the motor vehicle authority resulting in the
%issue of a driver's licence. The driver simply presents the licence
%for inspection as proof of authorisation to drive the
%vehicle. Here the document links the two interactions, thus establishing
%them as parts of an asynchronous multiparty interaction.
%The area of interest for this paper is a general multiparty scenario as
%illustrated in Fig.~\ref{fig-interact}:
Party A (Alice) produces and signs a document, party B (Bob) receives the
document and forwards selected parts thereof to party C (Carol), or party D
(Don), who verifies the information.

\begin{figure}
\begin{center}
\includegraphics[width=5cm]{fig_MultipartyIntereaction.eps}
\end{center}
\vspace{-0.5cm} \caption{A Multiparty interaction. \label{fig-interact}}
\end{figure}

    \subsection{Contents of this Paper}
After establishing the type of interaction of interest in
Section~\ref{sec-intro}, Section~\ref{sec-problem} introduces two problems
relating to electronic multiparty interactions. Section~\ref{sec-related}
covers related work from a policy and technical perspective. In
Section~\ref{sec-solutions}, an approach using the current digital signature is
discussed to illustrate its limitations and the erosion of the document
holder's privacy with its use in these types of interactions. A solution using
privacy-enhancing Content Extraction Signatures is then discussed to illustrate
their use in multiparty interactions.




\section{The Problems} \label{sec-problem}


The elegant concept of public-key cryptosystems \cite{DH76} and their
implementation \cite{RSA78} enabled a content-dependent digital signature to be
created for electronic documents. Beth, Frisch and Simmons \cite{BFS92} suggest
this changed the information security field and its primary focus from secrecy
alone to include broader notions of authentication, identification and
integrity verification. With the steady rollout of Public Key Infrastructure
(PKI), public, corporate and governmental acceptance of, and confidence in,
digital signatures has steadily grown.
%Apart from their use
%with electronic documents, they have also been adopted for widespread use with
%software distribution \cite{Bai00}, \cite{Ms99}.

Whilst digital signatures are becoming widely accepted, there is privacy
erosion attendant on their use in some common multiparty interactions. In other
multiparty interactions, the coarse granularity of information signing results
in higher and unnecessary usage of bandwidth.


    \subsection{Granularity versus Privacy}
%The standard digital signature is well-suited to point-to-point interactions, since party A simply signs the content they wish to send to party B. Not all
%instances of commerce, however, should be characterised as merely a series of point-to-point interactions. More properly, many instances are multipoint, or
%multiparty, interactions where information flows from the information signer to
%the document holder and then to the information consumer(s) as illustrated in
%Fig.~\ref{fig-interact}.

This can be illustrated with a commonplace online transaction where Bob wants
to purchase online an academic version of software from the Computer
Corporation. Computer Corp.\ requires proof that Bob is a current student. Bob
thus sends his electronic student identification document that has been issued
and signed by Ace University. Although he need supply only his name and expiry
date to establish that he is a current student, he is forced to reveal all of
the other information contained in his student identification document which
might include date of birth, address, course enrolment, his photograph, \etc

Ace University signs the information that it sends to Bob, thereby requiring
Bob to disclose \emph{all} of this information to Computer Corp.: otherwise it
will fail verification. This occurs even if only part of the information is
required for the interaction and Bob does not want to reveal all of the
information.

Ideally, the information holder should be free to disclose only the minimum
information required for the interaction. Bob should be able to disclose only
his name, student number and expiry date in support of this transaction.
However, this must also be in accordance with the signer's expectations of
reasonable use of the document's content. Bob's privacy in this transaction is
eroded as the document content is signed with a granularity that is too large
for this particular transaction. This demonstrates the tension between
verifiable information granularity and the information holder's privacy, as
illustrated below in Fig.~\ref{fig_Granularity tensions}(a).

%\begin{figure}
%\begin{center}
%\includegraphics[width=5cm]{fig_GranularityVprivacy.eps}
%\end{center}
%\vspace{-0.5cm} \caption{\label{fig-tension}Verifiable content
%granularity versus information holder's privacy.}
%\end{figure}

Our goal is to enhance the document holders' privacy in multiparty
interactions, moving from coarser content granularity towards finer
granularity.

    \subsection{Granularity versus Bandwidth}

The granularity of signed information in multiparty interactions does not
only affect privacy; it also causes unnecessary bandwidth usage. Consider
Bob, a document holder, who wants to pass a single item of
verifiable information to Carol. Instead of being able to pass this single
item of information, Bob is forced to furnish the entire document,
which could be significantly greater in size than the single item. %If he
%does not, Carol will not be able to verify the signature.

\begin{figure}
\begin{center}
\includegraphics[width=12cm]{fig_ElectronicNewspaperArticle.eps}
\end{center}
\vspace{-0.5cm} \caption{Example of electronic publishing which includes
verifiable content. \label{fig-Example of electronic publishing}}
\end{figure}

To illustrate such a scenario, which is not a privacy issue but one of
information relevance, consider an electronically published article, in
which some aspect of an interview with the Prime Minister (PM) is reported.
As depicted in Fig.~\ref{fig-Example of electronic publishing}, the PM's
office issues a transcript of the interview involving the PM, which has been
signed using the standard digital signature.

The publisher would like to quote only the PM's response to a particular
question as there are tight constraints on article size and it is neither
appropriate, nor possible, to include the entire transcript of the interview.
%Since the publisher has tight constraints on article size and is focussing
%on a particular topic, it is neither appropriate, nor possible, to
%include the entire transcript of the interview. Therefore, the publisher
%would like to quote only the PM's response to a particular question.
It is desirable for the reader to be able to verify the quoted content in the
article from the signed transcript as it would avoid problems of
misinterpretation and misquoting.

\begin{figure}
\centering \mbox{
\subfigure [With information privacy]
{\includegraphics[width=5cm]{fig_GranularityVprivacy.eps}}\qquad
\subfigure [With bandwidth usage]
{\includegraphics[width=5cm]{fig_GranularityVbandwidth.eps}}\qquad }
\vspace{-5mm} \caption{Tensions with verifiable content granularity
\label{fig_Granularity tensions}}
\end{figure}

%\vspace{-10mm}


If the interview transcript is signed using the standard digital signature,
this scenario is not possible. The problem is that the standard digital
signature requires all of the signed information to be present: otherwise it
will fail verification.

This example illustrates the tension that exists between verifiable content
granularity and bandwidth, as illustrated in Fig.~\ref{fig_Granularity
tensions}(b). This tension is likely to arise in many other scenarios as the
Internet burgeons. A further goal of this work is to reduce the signed content
granularity and move towards reduced bandwidth.
%\begin{figure}[ht]
%\begin{center}
%\includegraphics[width=5cm]{fig_GranularityVbandwidth.eps}
%\end{center}
%\vspace{-0.5cm} \caption{ Verifiable content granularity versus bandwidth
%usage.
%\label{fig-tension granularity versus bandwidth}}
%\end{figure}



    \subsection{Selective Content Disclosure Abuse}
The potential for abuse accompanies the ability to disclose verifiable
information contained in a document more selectively. For example, using the
above scenario, to avoid the PM's responses being quoted out of context, it is
desirable that the question and the response be linked so that the response is
always preceded by the corresponding question. Hence there is a requirement
that the information signer be able to exert some control over what verifiable
content can be selectively disclosed by the document holder. Conceivably, the
document signer would want to be able to specify which fragments: may be
extracted in isolation, be extracted only when accompanied by other specified
fragments, and never be extracted (\ie can only ever be provided with the
entire document).
%\begin{itemize}
%%\setlength{\itemsep}{-5pt}
%    \item be extracted in isolation,
%    \item be extracted only when accompanied by
%    other specified fragments, and
%    \item never be extracted (\ie can only ever be
%    provided with the entire document).
%\end{itemize}



\section{Related Work} \label{sec-related}
    \subsection{Policy Initiatives}

\begin{sloppypar}

The ever-increasing adoption of the Internet by government, business and the
community has added to existing concerns over privacy arising from the
widespread use of information technology. Governments in countries such as
Australia have responded by establishing privacy commissioners to develop and
administer privacy laws, privacy policies and standards with which
organisations must comply~\cite{FPC-a}. Privacy rights are often expressed in
the form of Privacy Principles. In Australia there are ten, which are based on
the Organisation for Economic Cooperation and Development (OECD) guidelines and
called the National Privacy Principles (NPP)~\cite{FPC-b}. Australia also has a
Privacy Commissioner~\cite{Cro00} who is charged with many functions and
responsibilities with respect to the Privacy Act.

\end{sloppypar}

Whilst the policies and legal framework initiatives are welcome, they are
not a panacea. They simply provide a framework within which organisations
under their jurisdiction must operate or face sanctions. What about
organisations that operate beyond their jurisdictions? Consider
Internet-based gambling.  Although it is now illegal in many countries, it
has simply moved offshore and out of the respective country's jurisdiction.

These initiatives will not prevent breaches of privacy, as illustrated
recently in an incident when customer credit card details were disclosed
outside of a company and were subsequently fraudulently used. After an
investigation, the Federal Privacy Commissioner stated that ``It is
important to note that addressing the privacy risks identified would not
necessarily prevent a breach such as the one that occurred
\dots''~\cite{FPC-c}

Once private information is released, you cannot recall it. In the above
example, all the credit cards had to be cancelled and new ones issued.
Perhaps not a particularly great inconvenience---what, however, if the
privacy breach involved much more sensitive information such as a digital
identity, or private key?

\emph{Policies alone cannot ensure privacy.} There needs to be technical
support for privacy and it needs to be put back into the hands of the people to
allow them a role in their own privacy.

%    \subsection{The Privacy Preferences Project}
%
%The World Wide Web Consortium (W3C) has a more hands-on approach called the
%Platform for Privacy Preferences (P3P) Project~\cite{Cra02} which has issued a
%specification for use with web sites and web browsers~\cite{CLM+02}. It
%enables users to specify their privacy preferences and for a web site to
%provide labelling information specifying its privacy policies, so that
%the user can decide if they want to use the site and to control how much
%information is given to the site.

    \subsection{The XML Signature}

The XML-Signature (XMLsig) specification~\cite{W3C-XMLsig}, also from the W3C,
defines a scheme for creating digital signatures that can be applied to digital
content, or data objects, which may be within the same XML document as the
signature, or located externally in other documents on various sites across the
web. The XMLsig enables the signer to sign anything that can be referenced by a
URI, along with any transforms of the information, so that other users can
verify the signature. In essence, the thrust of XMLsig is to enable a signer to
efficiently sign multiple objects  that may be located on physically different
servers and to enable a verifier to verify the available objects even though
the entire set of signed objects may not be available.

%The XMLsig specification
%includes a manifest item which is used to specify whether it is ``ok'' for
%a fragment to be missing. This corresponds to the rudimentary extraction
%policy structure utilised in our previous work ~\cite{SBZ02}.

Whilst the basic XMLsig's functionality is similar to our first CES scheme,
\emph{CommitVector}~\cite[\S 4.1]{SBZ02}, it is not designed to provide the CES
\emph{privacy} security for blinded content nor does it allow the signer to
specify an extraction policy. Nonetheless, it has been shown that the
functionality of the XMLsig can be extended to include CES
functionality~\cite{BSS03}, including a richer extraction policy to handle
fragment grouping, which is described in this paper. Due to space constraints
this could not be included with the work reported in this short version of the
paper, however, the interested reader is referred to the full version where it
is included~\cite{BSN+03tr}.

    \subsection{Other Work}
A general concept, proposed by Rivest~\cite{Riv00}, which has since been
referred to as ``\ldots signature schemes that admit forgery of signatures
derived by some specific operation on previous signatures but resist other
forgeries.''~\cite{BN02}. Micali and Rivest introduced transitive signature
schemes in this area~\cite{MR02}, while Bellare and Niven presented schemes
that provided performance improvements~\cite{BN02}.  Johnson, Molnar, Song and
Wagner have investigated a general approach to homomorphic signature schemes
for some binary operations such as: addition, subtraction, union,
intersection~\cite{JMS+02}.
%Whilst their additive
%scheme was proved to be insecure, their redactive scheme construction was
%shown to be secure.

%``Digital Credentials'' that are issued by trusted ``Credential Authorities''
%have been proposed by Brands and have the capability for selective disclosure
%of the data fields in the credential~\cite{Bra00,Bra02}. Brands suggests that
%Digital Credentials can also be used for such things as birth certificates, as
%well as gift certificates, tokens, train tickets \etc, in which case they have
%appeal as an alternative to identity certificates. Whilst it is envisaged that
%Content Extraction Signatures could be used for these types of application,
%they do not require the signing of the content to be performed by a
%Certification Authority.

Brands has performed extensive work on enhancing the privacy of document owners
and has proposed ``Digital Credentials'', which are issued by trusted
``Credential Authorities'', along with associated protocols that have the
capability for selective disclosure of the data fields in the
credential~\cite{Bra00,Bra02}.

%Johnson, Molnar, Song and Wagner \cite{JMS+02} have investigated a general
%approach to homomorphic signature schemes for some binary operations such as:
%addition, subtraction, union, intersection etc. Whilst their additive scheme
%was proved to be insecure, their redactive scheme construction was shown to be
%secure. Their solution to the risk of semantic attacks involves using visible
%markers for explicit indications of blinded content. This contrasts with the
%use of an extraction policy structure, the CEAS, with Content Extraction
%Signatures~\cite{SBZ02}. We felt that explicitly indicating blinded content may
%cause an unwarranted stigma by the verifier towards the document holder.

%A different approach was taken by Orman \cite{Orm02} who proposes an
%authorisation and validation model, using the XMLsig standard, for mildly active content in web pages. This model enables
%the content owner's intentions with respect to document modification to be
%embodied in the document so that any party can validate the document with
%respect to these intentions. The nature of this work differs from ours in
%that it enables document composition by more than one author. It permits the
%document owner to delegate modification rights verifiably by signing the URL: a
%form of ``late binding''.


A different approach was taken by Orman \cite{Orm02} who proposes using the
XMLsig for an authorisation and validation model for mildly active content in
web pages. This enables the content owner's intentions with respect to
document modification to be embodied in the document so that any party can
validate the document with respect to these intentions.  It permits the
document owner to delegate modification rights verifiably by signing the URL: a
form of ``late binding''.


Other work has focussed on certain types of path and selection queries over
XML documents that can be run on untrusted servers. Devanbu, Gertz, Kwong
\etal~\cite{DGK+01} have proposed a new approach to signing XML documents
so that answers to arbitrary queries can be certified.


\section{Solutions} \label{sec-solutions}


    \subsection{Using Standard Digital Signatures}
A simplistic approach to the content granularity problem is for Alice, the
signer, to sign the individual document fragments using the standard
digital signature and to forward all these signed fragments to Bob, the
information holder, for use. If there are $n$ content fragments, then the
computational overhead would be $n$ signatures.

Bob does not need to perform any further computation as all that is
required is simply to forward the required fragment(s) along with their
associated signature(s) to Carol, the information consumer, for
verification.  For peace of mind, however, it is likely that Bob would
first verify each fragment received from the signer, thus requiring $n$
signature verifications.

Carol, upon receipt of the fragment(s) would have to perform
$m$ signature verifications where $m < n$ and $m$ is the number of fragments
forwarded by Bob.

\subsubsection{How could Alice protect against the potential of disclosure abuse?}
If Alice follows the scheme described above, she \emph{cannot}  protect
against disclosure abuse. Her alternative is to decide upon allowed subsets
of fragments, corresponding to various permissable fragment associations,
or groupings. Each of these subsets could be signed and issued as a
separate document.  There is an upper bound of $2^{n}$ possible subsets,
which implies a considerable document management challenge for both Alice
and Bob.

Using the standard digital signature in this manner departs from the
conventional single document/container approach and involves many signed
items.  This would require more storage space and complicate the handling
required by Bob. Notwithstanding the storage problem, the prospect of
searching through the many items to find the desired combination of
fragments to disclose would be daunting.


    \subsection{Using Content Extraction Signatures}
Content Extraction Signatures can be verified for a subdocument which has
been generated by blinding or removing portions of the original signed
document, in accordance with the signer's policy for blinding the
document content~\cite{SBZ02}. The communications and/or computational cost
of CES is lower than that of the simple multiple signature solution using
the standard digital signature described above.

The same general structure initially proposed for CES will be used.
However, in this work we substantially extend the Content Extraction Access
Structure (CEAS) encoding to enable the signer to specify a \emph{richer
extraction policy} for the document fragments.


        \subsubsection{Fragment Extraction Policy}
In \cite{SBZ02} we did not specify an encoding scheme for the CEAS. In this
paper, we focus on the ability to select and extract particular fragments and
their associations, or grouping, with any other fragments. Thus, we have a
multidimensional view of the fragment. This presents a challenge: how to
achieve this flexibility in the fragment extraction policy whilst
constraining the size of the extraction signature. For a document containing
$n$ fragments there are $2^{n}$ subdocuments possible (although the number of
useful subdocuments would be smaller) and $2^{2^{n}}$ permutations of the CEAS
for the relationships of the $n$ fragments with each other.

The CEAS provides a mechanism for the document signer to avoid the abuse of
extracted content by specifying which fragments and groupings (via fragment
associations) can be extracted. It is an encoding of the subsets of fragment
groupings for which the document holder is `allowed' to extract valid
signatures. All associations are relative to a `primary target' fragment,
asymmetric and non-transitive. Association transitivity has not been included
in this work and has been left for further work.

A fragment that is allowed to be extracted in its own right is considered
to be a \emph{primary} target. Only primary targets may be directly
selected for extraction. If a fragment is not a primary target, then it is
called a \emph{secondary} target and may only be extracted through an
association with a primary target. If a fragment has a mandatory
association with a primary target, this means that the associated fragment
\emph{must} accompany the primary target fragment if it is extracted. A
fragment which has an optional association with a primary target fragment
\emph{may} accompany the primary target fragment if it is extracted. A
fragment cannot have a mandatory and optional association with the same
fragment.

We will now describe fragment policy options and their use by the document
owner. A fragment type and its extraction permissions can be identified as:


\begin{bulletlist}
%\setlength{\itemsep}{-5pt}
    \item   a secondary target with no associations---it can never be extracted;
    \item   a secondary target with mandatory associations---can only be
    extracted when accompanying a primary target fragment via a
    mandatory association;
    \item   a secondary target with optional associations---it can only be
    extracted when accompanying a primary target fragment through an
    optional association;
    \item   a primary target with no associations---it can be
    extracted by itself;
    \item   a primary target with mandatory associations---if extracted it
    must be accompanied by its associated mandatory fragments;
    \item   a primary target with optional associations---if extracted it
    may be accompanied by its associated optional fragments; or
    \item   a primary target with mandatory associations from \emph{all}
    other primary targets---a mandatory fragment which must accompany any
    primary fragment that is extracted.
\end{bulletlist}


\subsubsection {CEAS Using Byte Lists}
\label{sec-byte-lists}

A simple approach to storing the signer's fragment extraction policy is to
use lists for the fragment associations. We implement for each fragment a
list for its mandatory associations and a list for its optional
associations. A target's type is determined by which list its own number is
located in: primary target if in the mandatory list, otherwise secondary
target if in the optional list.

With a 32 bit fragment identifier, the size of the CEAS for a document
containing 100 fragments with an average of, say, 20 associations per
fragment would be 64kbits.



\subsubsection {CEAS Using Bit Vectors}

Bit vectors could be used as an alternative to using lists, where for a
document with $n$ fragments, we allocate a vector of $n$ bits for each
fragment. This can be seen as a $n \times n$ bit matrix, irrespective of the
number of associations. As there are $n$ bits available per fragment, we
use:
\begin{bulletlist}
%\setlength{\itemsep}{-5pt}
    \item \emph{the self-referent bit}---to specify if the fragment is a
    primary target or a secondary target; and
    \item \emph{the non self-referent bits (or other bits)}---to specify
    the mandatory and optional fragment associations.
\end{bulletlist}

The type of association specified by the other bits depends on whether the
fragment is a primary or secondary target. For primary targets the other bits
define the mandatory associations, while for secondary targets they define the
optional associations. Also, there are no optional associations between two
primary fragments. This would be redundant, as you can simply extract the two
primary fragments, or not, as required.

A simple CEAS for a document with six fragments is illustrated in
Table~\ref{tab-ceasEx}. This simple example illustrates the encoding of the
various fragment types as identified above. However, it is expected that an
actual extraction policy would likely involve a good deal more associations.
Following is an explanation of the fragment extraction policy for the document.

% Start of table for example CEAS for 6 fragments
\begin{table}
  \centering
  \caption{Sample CEAS for a document with 6 fragments}\label{tab-ceasEx}
  \begin{tabular}{|c|c|}
  \hline
  % Table Header Row
  \hspace{1mm} Fragment no. \hspace{1mm} & CEAS \\ % \hspace for nicer spacing
  \hline
  % Table Content
  1 & \hspace{1mm} 0 0 0 0 0 0 \hspace{1mm}  \\   % \hspace for nicer spacing
  2 & 0 0 0 0 0 0   \\
  3 & 0 0 0 0 1 0   \\
  4 & 0 1 0 1 0 1   \\
  5 & 0 0 0 0 1 1   \\
  6 & 0 0 0 0 0 1   \\
  \hline
  \end{tabular}
%  \vspace{5mm}
\end{table}


%\vspace{-8mm}
%\textbf{Extraction Policy explained}
\renewcommand{\descriptionlabel}[1]%
            {\hspace{\labelsep}\textrm{#1}} % redfines label so that it is not bold
\begin{description}
    \item[Frag1] is a secondary target and can never be
    extracted as no other fragments are associated with it, ie.
     $CEAS_{1}[1] \vee \ldots \vee CEAS_{n}[1] = F$

    \item[Frag2] is a secondary target and can only be extracted
    through its mandatory association with frag4. If frag4 is
    extracted, then frag2 must accompany it.

    \item[Frag3] is a secondary target and can only be extracted
    via its optional association with frag5. If frag5 is
    extracted, frag3 may optionally accompany it.

    \item[Frag4] is a primary target with some mandatory
    fragment associations that must accompany it should it be
    extracted. If frag4 is extracted, then frag2 and frag6 must
    accompany it.

    \item[Frag5] is a primary target with mandatory and optional
    fragment associations. Should frag5 be extracted, then frag6
    must accompany it, while frag3 may optionally accompany it.

    \item[Frag6] is a primary target with no associations that must
    accompany it should it be extracted. Frag6 can be extracted by
    itself.

    Frag6 is also a mandatory fragment, which must always be extracted, as every primary target has
    a mandatory association with it, ie.
    \\ $b_{1} \wedge b_{2} \wedge \ldots b_{n} = T$
    \\ where
    $b_{i} = \neg CEAS_{i}[i] \vee CEAS_{i}[6]$
    and $i$ indexes the fragments.

\end{description}

As the bit matrix hints, the CEAS is in fact a labelled directed graph, the
matrix in Table~\ref{tab-ceasEx} corresponding to the connectivity matrix. The
node labels indicate fragment identity, and edges represent associations.
Primary targets are represented by nodes that are connected to themselves.
Nodes corresponding to primary targets have edges directed to the nodes with
which they have mandatory associations. Nodes corresponding to secondary
targets have edges directed to nodes with which they have optional
associations.

List-based representations are most efficient when the average number of
associations (\ie edges) per fragment (\ie node) is low. The bit matrix
will be the better encoding when the association density is high. Let
$\mathit{f}$ be the size of the fragment identifier in bits and $\bar{a}$
be the average number of associations per fragment. The size of the list
encoding is $n\bar{a}\mathit{f}$ bits and the matrix encoding is $n^2$
bits. The matrix encoding will thus be the more efficient when $\bar{a} >
n/\mathit{f}$. For the example in Section~\ref{sec-byte-lists}, the matrix
representation would cost 10kbits.


        \subsubsection {Signing the Document}
        \label{sec-Signing the Document}
Signing the document using Content Extraction Signatures involves
a two step process: (i) define the fragments, and (ii) specify the
fragment extraction policy. The process of defining a fragment
includes specifying the content itself as well as whether it is a
primary or secondary target. Once the fragments have all been
defined, the signer specifies the mandatory and optional fragment
associations for each fragment. This information is included as
part of the extraction signature. On completion of signing, the
document and its extraction signature is forwarded to the document
holder.

%\section {Implementing with XML Signatures}
%\label{sec-Implementing with XML Signatures}
%
%Content Extraction Signatures enable selective disclosure of verifiable
%content, provide privacy for blinded content through the use of a salt, and
%enable the signer to specify the content the document owner is allowed to
%extract or blind. Combined, these properties give what we call \emph{CES
%functionality}.
%
%We now show how to implement XML Signatures to achieve \emph{CES
%functionality} with a richer multi-dimensional extraction policy. This is
%achieved through the use of an enhanced custom transform and modified
%\xmlsig structure first introduced in~\cite{BSS03}.
%
%    \subsection {XML Signatures in Brief}
%    \label{sec-XML Signatures in Brief}
%
%\begin{sloppypar}
%Basically, an \xmlsig is comprised of four main components or elements:
%\elem{SignedInfo}, \elem{SignatureValue}, \elem{KeyInfo} and \elem{Object}. The
%\elem{SignedInfo} element includes all of the content or resources to be signed
%with each item having a corresponding \elem{Reference} element, which
%identifies the content and a digest over it. The \elem{Reference} elements are
%digested and cryptographically signed in a manner similar to signing when using
%a standard digital signature. The resulting signature value is stored in the
%\elem{SignatureValue} element. The \elem{KeyInfo} and \elem{Object} elements
%are optional.
%\end{sloppypar}
%
%An \xmlsig has the \elem{Signature} element as the root element for its XML
%tree. It contains the four main components and has the following generic
%structure as defined in the specification~\cite{W3C-XMLsig}: \\
%\hspace*{.3cm}\elem{Signature} \\
%\hspace*{.7cm}\elem{SignedInfo} \\
%\hspace*{1.1cm}\elem{CanonicalizationMethod /} \\
%\hspace*{1.1cm}\elem{SignatureMethod /} \\
%\hspace*{1.1cm}\texttt{(}\elem{Reference} \\
%\hspace*{1.5cm}\texttt{(}\elem{Transforms}\texttt{)?} \\
%\hspace*{1.5cm}\elem{DigestMethod} \\
%\hspace*{1.5cm}\elem{DigestValue} \\
%\hspace*{1.1cm}\elem{/Reference}\texttt{)+} \\
%\hspace*{.7cm}\elem{/SignedInfo} \\
%\hspace*{.7cm}\elem{SignatureValue} \\
%\hspace*{.7cm}\texttt{(}\elem{KeyInfo}\texttt{)?} \\
%\hspace*{.7cm}\texttt{(}\elem{Object}\texttt{)*} \\
%\hspace*{.3cm}\elem{/Signature}
%%\vspace{-5mm}
%\begin{tabbing}
%%\hspace*{7cm}
%where: \= \texttt{?} denotes zero or one occurrences, \\
%         \> \texttt{*} denotes zero or more occurrences, and \\
%         \> \texttt{+} denotes one or more occurrences.
%\end{tabbing}
%
%
%        \subsubsection{The Reference Processing Model}
%        \label{sec-The Reference Processing Model}
%
%\begin{sloppypar}
%The signed content, which may be contained in the same document as the \xmlsig
%and/or external to the document containing the \xmlsig, is referenced with a
%\elem{Reference} element.  The URI (Uniform Resource Identifier)~\cite{BFM98}
%attribute of the \elem{Reference} element identifies the signed item. Each
%\elem{Reference} element may have zero or more transforms, which are applied to
%the dereferenced content prior to its being digested using the algorithm
%specified in the \elem{DigestMethod} element. The resulting digest is always
%base64 encoded~\cite{RFC2045} and stored in the \elem{DigestValue} element.
%\end{sloppypar}
%
%The \elem{Transforms} element may contain an ordered list of transforms to be
%applied to the dereferenced content. Each
%transform is specified using a \elem{Transform} element as follows: \\
%\hspace*{.3cm}\elem{Transforms} \\
%\hspace*{.7cm}\elem{Transform Algorithm="t1" /} \\
%\hspace*{.7cm}\elem{Transform Algorithm="t2" /} \\
%\hspace*{.7cm}\ldots \\
%\hspace*{.7cm}\elem{Transform Algorithm="tn" /} \\
%\hspace*{.3cm}\elem{/Transforms} \\
%
%
%The \xmlsig's Reference Processing Model~\cite[Sect.4.3.3.2]{W3C-XMLsig}
%specifies that the dereferenced content is supplied to the first transform. As
%illustrated in Fig.~\ref{fig-TransformChain}, the list of transforms forms a
%transform chain where the output from the first transform is supplied as the
%input to the second transform, its output to the next, and so forth, until the
%last transform, the output of which is supplied to the digest algorithm. The
%types of transforms defined include: Canonicalization (with comments and
%without comments); Base64; XPath Filtering; XSLT; and Enveloped Signature
%transform. The \xmlsig Reference Processing Model is also used for \xmlsig
%Reference Validation~\cite[Sect.3.2.1]{W3C-XMLsig}, which is a required part of
%\xmlsig Core Validation.
%
%
%%\vspace{-1.5cm}
%\begin{figure}
%\begin{center}
%\hspace{-4mm}
%\includegraphics[width=10cm]{fig_TransformChain.eps}
%\end{center}
%\vspace{-1.5cm} \caption{
%    \label{fig-TransformChain}
%    Transform chain for processing content prior to input to
%    digest algorithm.
%}\center{Adapted from \protect\cite[p.720]{LLL+02}}
%\end{figure}
%
%
%
%    \subsection {XML Signature Design}
%    \label{sec-XML Signature Design}
%
%\begin{sloppypar}
%As part of achieving CES functionality, compliance with the signer's extraction
%policy needs to be included into the \xmlsig Core
%Validation~\cite[Sect.3.2]{W3C-XMLsig} processing requirements.  This has been
%demonstrated in~\cite{BSS03}, however this was only with a simple,
%single-dimensional extraction policy. The policy checking mechanism uses the
%Reference Processing model and is inserted into the \elem{Reference} element
%being processed. Using this approach has the limitation that as the transform
%chain is executed it proceeds within a scope that is relative (and hence
%limited) to the current \elem{Reference} element being processed. The problem
%with this is that to handle fragment grouping, the \emph{VerifyPolicy}
%transform needs to access other \elem{Reference} element contents, which are
%effectively out of scope.
%
%To solve this problem, the \xmlsig needs to be restructured to enable the
%\emph{VerifyPolicy} transform to access all of the fragment nodes. This can be
%achieved by making all of the \elem{Fragment} elements children to the
%\elem{Object} element and using a single \elem{Reference} element to refer to
%the \elem{Object} elements as follows:\footnote{Prefixes such as
%http://pm.gov.au/tranforms/ have been omitted throughout for presentation and
%security reasons as they are not
%germane to the examples.} \\
%%\hspace*{.3cm}  \elem{Signature} \\
%%\hspace*{.6cm}  \elem{SignedInfo} \\
%%\hspace*{.9cm}  \ldots \\
%\hspace*{.3cm}  \elem{Reference URI="\#obj1" Type="\ldots\#Object"} \\
%\hspace*{.6cm} \elem{Transforms} \\
%\hspace*{.9cm} \elem{Transform Algorithm="\ldots
%ces\#VerifyPolicy"
%/} \\
%\hspace*{.6cm} \elem{/Transforms} \\
%\hspace*{.3cm}  \elem{/Reference} \\
%%\hspace*{.6cm}  \elem{/SignedInfo} \\
%%\hspace*{.6cm}  \elem{SignatueValue} \ldots \elem{/SignatueValue} \\
%
%The \elem{Object} element contains a \elem{Fragment} element for each
%item that is to be signed as follows: \\
%\hspace*{.3cm}  \elem{Object Id="obj1"} \\
%\hspace*{.6cm}  \elem{Fragment Id="frag1" URI="\ldots"} \\
%\hspace*{.9cm}  \elem{CEAS} \ldots \elem{CEAS} \\
%\hspace*{.9cm}  [\elem{Salt} $|$ \elem{Digest}] \\
%\hspace*{.6cm}  \elem{/Fragment} \\
%\hspace*{.6cm}  \elem{Fragment Id="frag2" URI="\ldots"} \\
%\hspace*{.9cm}  \elem{CEAS} \ldots \elem{CEAS} \\
%\hspace*{.9cm}  [\elem{Salt} $|$ \elem{Digest}] \\
%\hspace*{.6cm}  \elem{/Fragment} \\
%\hspace*{.6cm}  \ldots \\
%\hspace*{.3cm}  \elem{/Object} \\
%\vspace{-7mm}
%\begin{tabbing}
%%\hspace*{7cm}
%where: \= \texttt{|} denotes an exclusive OR. \\
%\end{tabbing}
%
%
%%\hspace*{.3cm}\elem{Reference URI="\#obj1" Type="\ldots\#Object"} \\
%%\hspace*{.6cm}\elem{Transforms} \\
%%\hspace*{.9cm}\elem{Transform Algorithm="\ldots ces\#VerifyPolicy"\footnote{The
%%prefix such as http://pm.gov.au/tranforms/ has been omitted for presentation as
%%it is not germane to the discussion.}
%%/} \\
%%\hspace*{.6cm}\ldots \\
%%\end{sloppypar}
%%
%%
%%
%%Each \elem{Object} element contains a \elem{Fragment} element that contains
%%either a \elem{Salt} or a \elem{Digest} element as follows: \\
%%\hspace*{.3cm}\elem{Object ID} \\
%%\hspace*{.6cm}\elem{Fragment URI CEAS} \\
%%\hspace*{.9cm}[\elem{Salt} $|$ \elem{Digest}] \\
%%\hspace*{.6cm}\elem{/Fragment} \\
%%\hspace*{.3cm}\elem{/Object} \\
%%\vspace{-5mm}
%%\begin{tabbing}
%%%\hspace*{7cm}
%%where: \= \texttt{|} denotes an exclusive OR. \\
%%\end{tabbing}
%
%\end{sloppypar}
%
%The URI attribute of the fragment references the fragment content while the
%CEAS element contains the encoding of the signer's extraction policy for
%that fragment. The \elem{Salt} element contains a salt value used in CES to
%ensure privacy of blinded content~\cite{SBZ02}. It is appended to the fragment
%content prior to digesting. The \elem{Salt} element is always present in the
%original signature from the document signer.
%
%When Bob, the document user, produces a subdocument, an extracted signature
%corresponding to the subdocument must be generated so that it can be validated
%by Carol, the subdocument recipient (or verifier), as being signed by Alice.
%This extracted signature has the \elem{Salt} element replaced with a
%\elem{Digest} element for the corresponding fragments which are not included
%(blinded) in the subdocument. The digest value is generated from the fragment
%content with the salt appended. Therefore, the extracted signature, which is
%generated for the subdocument, has a \elem{Salt} or \elem{Digest} element for
%fragments that are present or blinded respectively.
%
%
%    \subsection {Custom Extraction Policy Transform}
%    \label{sec-Custom Extraction Policy Transform}
%
%The custom transform to verify the extraction policy used in~\cite{BSS03} needs
%to be enhanced to handle fragment grouping.  The URIs of custom transforms can
%be signed, as can the transform code itself, thus establishing trust. The
%requirement for the custom transform is to process the \elem{Reference}
%element's dereferenced content by dereferencing the content of the
%\elem{Fragment} elements and checking compliance with the extraction policy,
%and finally emitting a Result byte stream for input to the digest algorithm.
%\begin{figure} [th]
%\begin{center}
%\includegraphics[width=8cm]{fig_VerifyPolicywithGrouping.eps}
%\end{center}
%\vspace{-0.3cm} \caption{
%    \label{fig-CEASverifyTransform}
%    \emph{VerifyPolicy} transform algorithm for fragment grouping.
%}
%\end{figure}
%
%\begin{sloppypar}
%As illustrated in Fig.~\ref{fig-CEASverifyTransform}, the transform
%processes the dereferenced content from the \elem{Reference} element, which
%will be XML content containing at least one \elem{Fragment} element. For
%each \elem{Fragment} element the transform first checks for the presence of
%a \elem{Digest} element, which indicates that the fragment has been
%blinded. If the fragment has been blinded, then the CEAS is checked for
%compliance with the fragment extraction policy.  Compliance sees the CEAS
%appended to the digest value, which is then appended to the Result. This
%Result will be emitted upon completion of processing of the last
%\elem{Fragment} element. Should verification of the extraction policy fail,
%then two bytes of zeroes will be appended to the Result in place of the
%digest value. This will ultimately cause reference validation failure and
%in turn core validation failure  as the appended bytes will not match those
%originally used to create the digest value stored in the reference's
%\elem{DigestValue} element.
%\end{sloppypar}
%
%On the other hand, if the fragment has not been blinded, the \elem{Digest}
%element will not be found. Rather, a \elem{Salt} element will be present.
%The fragment URI is dereferenced to retrieve the fragment content and the
%salt value from the \elem{Salt} element is appended to the fragment content
%prior to digesting. The resulting digest has the CEAS appended to it and is
%then appended to the Result which will be emitted.
%
%In addition to the explicit requirements of the transform, it also
%accommodates the mutation of the \elem{Fragment} elements, \ie
%present fragments to blinded fragments. Normally the content
%referenced by a \elem{Reference} element is invariant and a digest over it
%is included in the content signed by the cryptographic signature.

\section{Conclusion}\label{sec-comments}

In an electronic society where the use of paper is more the exception than
the norm, we have shown that the use of the current digital signature can
erode privacy and increase bandwidth usage in multiparty interactions. We
have introduced a new, more powerful, approach for encoding the signer's
fragment extraction policy. This approach is tailored more for
selective fragment grouping rather than selective fragment blinding, as was
the emphasis in our earlier paper.  This different perspective for the use
of CES presents the concept of handling verifiable information selectively
for paperless commerce in an online and a mobile environment.  Content
Extraction Signatures can be used for almost any multiparty interaction
involving the selective disclosure of information.


In a digital world, which promises far richer functionality than the
paper-based world, we seek more flexible applications of digital
signatures. With this work we are striving for additional functionality,
beyond that which a simple analogue of the humble and longstanding
hand-written signature provides.



% Comment out the following 2 lines prior to submission
%\bibliographystyle{abbrvurl}
%\bibliography{references}

% Uncomment following section and embed bibitems from .bbl file prior to submission
\begin{thebibliography}{10}

\bibitem{Bak94}
S.~Baker.
\newblock Don't worry be happy.
\newblock Available online, June 1994.
\newblock [Last accessed: July 27, 2002].
\newline\footnotesize \textbf{}
  \texttt{URL: http://www.wired.com/wired/archive/2.06/nsa.clipper\_pr.html}

\bibitem{W3C-XMLsig}
M.~Bartel, J.~Boyer, B.~Fox, B.~LaMacchia, and E.~Simon.
\newblock {XML}-signature syntax and processing.
\newblock In D.~Eastlake, J.~Reagle, and D.~Solo, editors, {\em {W3C}
  {R}ecommendation}. Feb.~12 2002.
\newblock [Last accessed: September 18, 2002].
\newline\footnotesize \textbf{}
  \texttt{URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/}

\bibitem{BN02}
M.~Bellare and G.~Neven.
\newblock Transitive signatures based on factoring and {RSA}.
\newblock In Y.~Zheng, editor, {\em Proceedings of The 8th International
  Conference on the Theory and Application of Cryptology and Information
  Security (ASIACRYPT 2002)}, volume 2501 of {\em Lecture Notes in Computer
  Science}, pages 397--414. Springer, December 2003.

\bibitem{BFS92}
T.~Beth, M.~Frisch, and G.~Simmons, editors.
\newblock {\em Public-Key Cryptography: State of the Art and Future
  Directions}, volume 578 of {\em Lecture Notes in Computer Science}. Springer,
  July 1992.
\newblock E.I.S.S. Workshop Oberwolfach Final Report.

\bibitem{Bla99}
G.~Blakley.
\newblock Twenty years of cryptography in the open literature.
\newblock In {\em Proceedings of 1999 IEEE Symposium on Security and Privacy},
  pages 106--7. IEEE Computer Society, May 1999.

\bibitem{Bra00}
S.~Brands.
\newblock {\em Rethinking Public Key Infrastructures and Digital Certificates:
  Building in Privacy}.
\newblock MIT Press, Cambridge, MA, 2000.

\bibitem{Bra02}
S.~Brands.
\newblock A technical overview of digital credentials.
\newblock Available online, Feb.~20 2002.
\newblock [Last accessed: February 18, 2003].
\newline\footnotesize \textbf{}
  \texttt{URL: http://www.credentica.com/technology/overview.pdf}

\bibitem{BSN+03tr}
L.~Bull, D.~M. Squire, J.~Newmarch, and Y.~Zheng.
\newblock Grouping verifiable content for selective disclosure using {XML}
  signatures.
\newblock Technical Report, School of Computer Science and Software
  Engineering, Monash University, 900 Dandenong Road, Caulfield East, Victoria
  3145 Australia, April 2003.

\bibitem{BSS03}
L.~Bull, P.~Stanski, and D.~M. Squire.
\newblock Content extraction signatures using {XML} digital signatures and
  custom transforms on-demand.
\newblock In {\em Proceedings of The 12th International World Wide Web
  Conference (WWW2003)}, Budapest, Hungary, 20--24~May 2003.
\newblock (to appear).

\bibitem{Cro00}
M.~Crompton.
\newblock The privacy act and the {A}ustralian federal privacy commissioner's
  functions.
\newblock In {\em Proceedings of the tenth conference on computers, freedom and
  privacy}, pages 145--8. ACM Press, 2000.

\bibitem{DGK+01}
P.~T. Devanbu, M.~Gertz, A.~Kwong, C.~Martel, G.~Nuckolls, and S.~G.
  Stubblebine.
\newblock Flexible authentication of {XML} documents.
\newblock In {\em {ACM} Conference on Computer and Communications Security},
  pages 136--45, 2001.

\bibitem{DH76}
W.~Diffie and M.~Hellman.
\newblock New directions in cryptography.
\newblock {\em IEEE Transactions on Information Theory}, IT-22(6):644--54,
  1976.

\bibitem{JMS+02}
R.~Johnson, D.~Molnar, D.~Song, and D.~Wagner.
\newblock Homomorphic signature schemes.
\newblock In {\em Proceedings of the RSA Security Conference Cryptographers
  Track}, volume 2271 of {\em Lecture Notes in Computer Science}, pages
  244--62. Springer, February 2002.

\bibitem{MR02}
S.~Micali and R.~L. Rivest.
\newblock Transitive signature schemes.
\newblock In B.~Preneel, editor, {\em Proceedings of The Cryptographer's Track
  at the RSA Conference (CT-RSA 2002)}, volume 2271 of {\em Lecture Notes in
  Computer Science}, pages 236--243. Springer, December 2002.

\bibitem{FPC-b}
{Office of the Federal Privacy Commissioner}.
\newblock My privacy my choice - your new privacy rights.
\newblock Available online.
\newblock [Last accessed: July 31, 2002].
\newline\footnotesize \textbf{}
  \texttt{URL: http://www.privacy.gov.au/privacy\_rights/npr.html}

\bibitem{FPC-a}
{Office of the Federal Privacy Commissioner}.
\newblock Privacy in {A}ustralia.
\newblock Available online, October 2001.
\newblock [Last accessed: July 12, 2002].
\newline\footnotesize \textbf{}
  \texttt{URL: http://www.privacy.gov.au/publications/pia.html}

\bibitem{FPC-c}
{Office of the Federal Privacy Commissioner}.
\newblock Announcement: Transurban privacy review completed.
\newblock Available online, May 2002.
\newblock [Last accessed: July 31, 2002].
\newline\footnotesize \textbf{}
  \texttt{URL: http://www.privacy.gov.au/news/media/02\_9.html}

\bibitem{Orm02}
H.~Orman.
\newblock Data integrity for mildly active content.
\newblock In {\em Proceedings of Third Annual International Workshop on Active
  Middleware Services}, pages 73--7. IEEE Computer Society, March 2002.

\bibitem{Riv00}
R.~Rivest.
\newblock Two signature schemes.
\newblock Available online, October 2000.
\newblock Slides from talk given at {C}ambridge {U}niversity. [Last accessed:
  February 19, 2003].
\newline\footnotesize \textbf{}
  \texttt{URL: http://theory.lcs.mit.edu/~rivest/publications.html}

\bibitem{RSA78}
R.~Rivest, A.~Shamir, and L.~Adleman.
\newblock A method for obtaining digital signatures and public-key
  cryptosystems.
\newblock {\em Communications of the ACM}, 21(2):120--8, 1978.

\bibitem{SBZ02}
R.~Steinfeld, L.~Bull, and Y.~Zheng.
\newblock Content extraction signatures.
\newblock In {\em Proceedings of The 4th International Conference on
  Information Security and Cryptology (ICISC 2001)}, volume 2288 of {\em
  Lecture Notes in Computer Science}, pages 285--304. Springer, December 2001.

\end{thebibliography}

\end{document}
