Out group within the Institute for Applied Information Processing and Communications (IAIK) is working in the field of public-key-infrastructures and Java-Cryptography. Within PKI, we are consulting to local companies setting up such structures and their pilot service was based on our software. We also were involved in consulting to austrian governmental bodies concerning digital signature legislation. Concerning Java-Cryptography, we have developed and are currently selling a Java-Cryptor toolkit, providing encryption and digital signature software as well as PKCS-implementations, S/MIME and SSL. Other groups within the institute do research in the areas of networking, VLSI design, and IT security. Current networking activities are in the field of ATM and ISDN. In IT security we design crypto chips, co-processors for smart cards, and are interested in WWW security. As a university institute we teach courses at all levels for students of Mathematics and Telematik (CS&EE).
When we participated in the Digital Signature Initiative, we were already convinced that we need a way to add semantics to signatures. The core of our ideas was to be able to express things like subject X says statment Y about object Z. With DSig we did not quite achive that goal, mainly because the aim of that initiative was driven by W3C towards PICS and we had to be PICS-compliant. Furthermore, RDF was on its way and we saw its potential to finally achieve our initial goal. Now RDF is here and we are ready to continue!
Obviously it makes sense to provide for a general solution to signed XML, and not for RDF only.
Not only for historic reasons we are very interested in active partizipation in these activities. Signed XML seems to become very important. We have the following plans to work on or use signed RDF or XML
work on and provide an implementation within our Java-Crypto-Toolkit, based on the standard-to-be-developed;
use signed XML as (one of the) ingredients for developing a secure digital signature solutions;
design and develop applications based on signed XML for public administration and health-sector.
We find the following things to be important for Signed RDF:
We need a general solution for signing XML-statements. This general mechanism should then be used for signing RDF to produce signed Metadata.
While I don't believe that it will be possible to be compatible to DSig 1 (which does not seem necessary too), good points from DSig 1 (as well as anything else worthwhile :-) should be incorporated. IMHO some of the good points were
Separation of Attibution Info (Info about the Signer including certificates or pointer to these), Manifest (Information about the Object(s) to be signed) and Signatures
Signature-Suites, defining standard-algorithm-combinations
Multiple Signatures using multiple Signature-Suites
Ability to specifically include or exclude sections into the signature. (Authenticated versus not-authenticated sections)
One should be able to make statements about multiple objects by including either references to these objects together with their hashes or the objects themself. This solves the problem for dynamic data where a reference does not help, and will be useful for objects without an (accessible) adress.
A standard vocabulary for standard-signature-applications would be worth while considering. Things like
I claim to be the author of that document.
I have seen the document and agree to the content.
This is an authenticated document by xxx Inc and we are legally bound to the content.
There seems to be a decision to be made whether signed-XML shall be pursued within the W3C or the IETF. Basically, I don't care that much. If there are the right people willing to work, both groups could move things forwards fast. It might be more difficult to get an agreement within the IETF due to the openness of the process, OTOH this openness tends to be a good thing too. While we would be willing to actively participate in the discussions, design and implementation within either group, the W3C-working-style we experienced within DSig makes us believe that results would be achieved faster within W3C.