Contact us Heritage collections Image license terms
HOME ACL ACD C&A INF CCD CISD Literature
Further reading □ Overview □ 1998 □ 123456789101112 □ 1999 □ 131415161718192021222324 □ 2000 □ 252627282930313233343536 □ 2001 □ 373839404142434445464748 □ 2002 □ 495051525354555657585960 □ 2003 □ 616263646566676869707172 □ 2004 □ 737475767778798081828384 □ 2005 □ 858687888990919293949596 □ 2006 □ 979899100101102103104105106107108
Harwell Archives Contact us Heritage archives Image license terms

Search

   
CISD and DCILiteratureW3C UK News (1998-2006)
CISD and DCILiteratureW3C UK News (1998-2006)
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
1998
123456789101112
1999
131415161718192021222324
2000
252627282930313233343536
2001
373839404142434445464748
2002
495051525354555657585960
2003
616263646566676869707172
2004
737475767778798081828384
2005
858687888990919293949596
2006
979899100101102103104105106107108

Issue 6: June 1998

DSig 1.0

W3C has just released DSig 1.0 as an official W3C Recommendation. Its full name is PICS Signed Labels (DSig) 1.0 Specification.

It is important for Web users to have a reliable mechanism for deciding what Web content they can trust and this is the issue that DSig 1.0 addresses. If I have added a filter system to my Browser that stops material that is labelled offensive, how can I be sure that the labels reflect the content of the pages? The pages may have been labelled correctly and somebody changed them later. Alternatively, the system defining the labels might not be one that is highly regarded.

So Web publishers and labelling bureaux need a way of stating the authenticity and integrity of their PICS 1.1 labels; that is, they need a means of making assertions about their labels and then signing the assertions. DSig 1.0 concerns itself with how you make these (digitally) signed assertions and then associate them with PICS 1.1 labels. In doing this, the mechanisms used need to be independent of any specific cryptographic algorithm or key-management infrastructures.

Assertion

In broad terms, DSig 1.0 provides a way for a signer to make a statement about an information resource:

signer believes statement about information resource

For example,

Fred believes that a Violence Rating of 3 for the page with this url is correct. 

Digital Signature

Publishers need a means to assure authenticity of what they have generated and users need to verify it. Both of these needs are addressed by attaching digital signatures to on-line documents identifying the origin of the label.

In a simple scenario, if A defines a label and B reads it, the attached digital signature should allow B to know that A signed it, that the label that arrived was the one attached by A, and A cannot deny the origin.

Additional complications arise when it is necessary for the signature to be separate from the information resource.

The PICS and DSig Architecture

To understand DSig 1.0, one needs to understand how PICS works. In PICS, an organisation defines a rating system (for example, that rates pages according to sex and violence on a scale 1 to 5).

A different organisation can set up a rating service that rates pages according to that rating system (and defines where the labels recording the ratings will be stored and how they will be accessed).

A labeller is employed by the rating service (or is authorised by them to create its labels). PICS allows specific labels to be attached to individual pages and generic labels to be attached to all the pages in a hierarchy.

In DSig 1.0, a signer adds a signature to an assertion label (what the labeller has asserted in one or more labels about the resource). The signer does not have to be the labeller. The signature effectively states that the signer believes the assertion.

The information is encrypted with a secret key. The presence of the digital signature states that the signer had both the secret key and the assertion label when the assertion was signed.

Finally, attached with the signature must be some hashing of the content in the information resource to ensure that it has not been changed since the label was created.

An Example

The DSig Signature is effectively another label to be attached to the resource and so it is defined as a PICS label with an identification that states it is a signature. It is possible to have a number of signatures attached to a resource just as you can have a number of labels.

For example:

(PICS-1.1 "http://www.ral.org/ratings/V1.html"
     by "Bob Hopgood"
     labels for "http://www.w3.org/PICS/DSig/Overview"
        on "1998.05.05T08:15-0500"
        ratings (science 2 gifs 1))

is how a labeller might rate the DSig Overview based on a RAL rating system (which indicates how much science there is in the publication and the frequency of gifs). To this the signer would need to add something like:

 extension  (optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"
("http://www.ral.org/SHA1-1_0" "aba21241241=")
 ("http://www.ral.org/MD5-1_0" "cdc43463463=" 
 "1997-02-05T08:15-0500"))

which says what two algorithms were used to hash the resource and the actual hashes used together with a date saying when this took place.

The signature block is then attached. This gives information about the signer and his authorisation levels and this information is digitally signed creating a signature block that is also added as an optional extension. For more information see: http://www.w3.org/TR/REC-DSig-label.

Tim Berners-Lee has indicated that DSig 1.0 is an important first step in our longer-term vision of improving trust on the Web. I hope that experience in using signed PICS labels will provide valuable input when we are ready to propose work on a Recommendation for signing RDF metadata.

So we may anticipate continuing work in this area connected with RDF (Resource Description Framework) to allow more extensive and complex assertions about web resources.

Implementations

Most of the DSig functionality is built on PICS labels using optional extensions (so browsers are allowed to ignore them). This means that if you have a PICS-aware browser, you could be using digital signatures now.

If you want to gain familiarity with DSig 1.0, there is a publicly accessible implementation in Java at: http://www.w3.org/PICS/refcode/.

There is also a version of the W3C Amaya browser available (under Linux so far) that supports PICS based filtering and accepts PICSRules to define the filtering strategy. This can be accessed from the above url.

The Web of the Future Event

A one-day technical workshop entitled The Web of the Future will take place on 17 July 1998 at RAL.

The workshop has been designed to highlight the new tools and techniques that are determining the shape of the Web of the future. Everyone is welcome although the workshop is targeted for people with a technical background. There is no charge for attendance but we do require registration in advance.

Items to be covered in the talks include architectural issues, performance issues and enhanced functionality, with topics including HTTP1.1, XML, RDF, CSS, PNG, CGM and SMIL. These are put into the context of the shift to new underlying technologies and the implications of this shift for users of the Web.

W3C Advisory Committee

The next W3C Advisory Committee meeting will be at CERN in Geneva on 24-25 June. Sending off your joining instructions for W3C this week will get you a seat at the meeting!

New Members

Membership of W3C continues to rise and has now reached 266 with a regional break down of:

Full Affiliate
Americas 34 125
Europe 33 41
Asia-Oceania 15 18

Recent new members are:

A pity there were no European members this month! Over the last few months there has been a noticeable increase in the number of companies joining from an engineering background. That will increase the demand for support for schematic graphics on the Web. It is likely that a new Working Group will be started to formulate Recommendations in that area. If this is important to your organisation, you need to join W3C! Joining details are available at: http://www.w3.org/Consortium/Prospectus/Joining.html.

With XML and RDF coming into play, it must be timely for the product data community to sort out their requirements for the Web. Converting between STEP and an XML DTD with RDF defining the semantics of the tags sounds like a worthwhile project.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site