If we used hash functions alone, then this would limit us to material that was available and known when the last issue of the catalogue was published. Almost all published medical information is of this nature; it changes relatively slowly owing to safety protocols that insist on thorough peer review and validation. However, there is a demand for a small number of dynamic pages in the system holding `hot' news such as recently advised drug side effects and other safety notices, or operational data such as test results. What we do not want to do is say something like `for recent notices on test results X, look at URL Y for a message signed by a key certified to belong to Z' as this would suddenly involve reliance on a second root.

The effect would be that the referenced information was no longer part of the same trust structure, introducing complexity and making liability potentially uncertain. We therefore want to say something like `for recent notices on test results X, look at URL Y for a message signed by a key whose hash is Z'. We will now describe the details.

The owner of the dynamic page creates a signature keypair and embeds the public key as follows:

...see <A
HREF="https://www.med.abc.ac.uk/bloodtest"
HASHMETHOD="TIGER" HASHVALUE="987654321..."
HASHPARENT="https://www.cert.med.ac.uk">here
</A> for today's blood test results for the Fisher medical practice...

which refers to this:

...
<HASHBODY>
...
The blood test results for the Fisher practice
on 22/8/98 are as follows:
...
<HASH
URL="https://www.med.abc.ac.uk/bloodtest"
METHOD="SHA-1"
PUBLICKEYVALUE="ABCDEF01234.......89ABC"
ALGORITHM="RSAE3"
PARENT="https://www.cert.bma.org.uk">
<HASH
URL="https://www.med.abc.ac.uk/bloodtest"
METHOD="TIGER"
PUBLICKEYVALUE="ABCDEF01234.......89ABC"
ALGORITHM="RSAE3"
PARENT="https://www.cert.med.ac.uk">
</HASHBODY>
<HASH METHOD="SHA-1" VALUE="12345678..."
PARENT="https://www.cert.bma.org.uk"
SIGNATURE-VALUE="FEDCBA987..........76543"
ALGORITHM="RSAE3">
...

The reason that the public key's presence is not made clear in the parent page is to preserve bandwidth (keys are relatively large) and because we could find no reason why someone when clicking on a link should know in advance whether it is statically or dynamically protected. It also makes the implementation simpler.

Note that although we are using public key cryptography, we have no need of an X.509 certification mechanism. All the trust links created by the public keys are local and transient. So there is no need for long-term secrets; everything gets suddenly much simpler, more manageable and more exportable.

Previous: Basic (static) mechanism Up: The Eternal Resource Locator Next: Other applications