Implementation of an XML Signature component
Presented at XML Signatures WG Face-to-Face meeting 21 Jan 2000.
Remtec Systems, Ltd.
- Design Principles
- About the basic requirements and principles for the design of the RPX
- Applications using the component
- Design Architecture
- Open Issues
"PKI is here"
- Public Key Infrastructure is being deployed widely
- The Finnish Population Register Centre is issuing Smart Cards for every
- There are commercial CAs in operation
- B2B applications are being developed based on XML technologies
- A digital signature syntax in XML is natural
- Secure information sharing and transactions are essential for B2B
- Currently based on the 1999/11 Working Draft
- First implementation is ready
- Is being used in some applications
- Collection of experience and further requirements
- Licensing is possible (model under work)
Easy integration into applications
- The applications are Web based
- The client is a Web browser
- Signatures are created in the browser
- The component needs to be accessible from an HTML page using scripting
- Signatures are verified on a Web server
- Win32, Microsoft CryptoAPI, Internet Explorer
Design Principles (contd.)
Utilizes PKI, Smart Cards and X.509v3 certificates
- The component uses X.509v3 certificates and key-pairs (digital
identities) for signature
- The user is allowed to make a choice of which digital identity to use for
Creating digital signatures
- "What you see is what you sign"
- XML data to be signed must be visible to the user
- The RPX Signature component is the only trusted module, other
code and data is visible on the HTML page for reference
Design Principles (contd.)
Verifying digital signatures
- The component only verifies the technical correctness of the
- It is in the application domain to verify that correct keys and valid
certificates were used for the signature
Built on existing technologies
- COM (or ActiveX) technology
- The component is implemented in C++ as an ActiveX component
- Available for Internet Explorer clients and on the server for any COM
- Microsoft CryptoAPI
- Used for crypto algorithms and Smart Card support
- Digitally signing on-line orders, reservations and other electronic
- How to specify what the fields of a transaction represent?
- The application needs to refer to a specification that specifies the
content of the fields
- The reference should be included in the signature object
- Using a forms application the user fills in form data using a user
interface that is specified by a form template
- Digitally signing the content of forms
- How to specify what form template was used to compose the content?
- A reference to a form template should be included in the signature
Gateways and front-ends
- A gateway could act as a transport for signed XML messages, and would only
allow through messages with a valid signature
- A front-end could be implemented for a "legacy" application, the
front-end would only run transactions of valid XML signed messages
- On-line shopping application
- Add items to a shopping basket
- Make a signed order
- Browse orders
- XML Forms
- Fill in a form
- Save the form and sign the content in XML format
- Browse signed forms
- The specification seems rather complex, does it need to be?
- Verifying signatures is by far the most difficult item
- XML Signature syntax allows rather complex signature objects to be created
- How does an application find that a specific signature object meets
all of the application’s requirements?
- What is XML Signature relation to Time Stamping Authorities (TSA)?
- Should the specification include a timestamp element?
- Time Stamping is essential for long-term digital signature verification
- Signed documents
- Stored transactions (reference, later verification)
Signing signed XML documents
- Does the signature element support multiple signers?
- The canonicalization method used by the component is currently
- KeyInfo element encoding
25Jan00 / Remtec Systems, Ltd.