XML is rapidly gaining developer and business mindshare. XML based Web services will require security fundamentals such as signature, encryption, authentication, authorization and trust service mechanisms.
Java and Solaris Platforms provide platform level security in terms of fine grained access control and also on the wire security in terms of encryption and digital signatures. With XML, components and applications are supposed to work in a disjointed fashion. This poses interesting problems in terms of trust and context management.
Sun is extremely interested in XKMS as it relates to the Java 2 Platform, Standard Edition [J2SE], Java 2 Platform, Enterprise Edition [J2EE], Java 2 Platform, Micro Edition [J2ME], Java Card and Solaris Operating System in general and other related products, such as the iPlanet Trustbase Transaction Manager, in particular.
J2SE contains APIs, tools and functionality for signing and verifying digital signatures (and code), building and validating certification paths (as of version 1.4) and managing keys. We are interested in understanding the implications of XKMS towards these APIs and our implementations of them.
The following are our expectations from this workshop:
- Definition and scope of a Trust Service
- Implications on other XML tools - Parser, Signature and Encryption
- Guidelines and protocol for building a Registration/Trust Server (as per XKMS note)
- The X.509 certificate validation algorithm uses trust anchor and certificate policy information as inputs. How does the Trust Service know which trust anchors and certificate policies to use when building a chain of X.509 certificates on behalf of a certain XKMS client?
- Protocol for Key Registration, Revocation and Recovery
- Guidelines and rules for delegation of say, <ds:KeyInfo> elements.
- Rules on how Roles are handled - say, a XML document has been signed by 3 different parties, each party has a different role. How is the registration done? When this document is presented to a client, rules for processing this document with a role may need to be specified.
- We would like to understand if we need to provide support (guidelines) for application based context rules that could be embedded in the document.
- Can an application delegate encrypting/decrypting a document? If yes, how is the message conveyed to the trust service?
- XKMS and its implications to low memory devices.
- Sun (internally and in products) supports several different standards or processes for trust semantics and it will be of interest to see how
this may be affected at all.
- It might be useful to compare and contrast XKMS with the DPD/DPV/SCVP protocols that are being worked on in the IETF PKIX WG which allow a relying party to delegate certpath discovery and validation to a trusted service.
Sun is actively involved in the following Java Specification Requests (JSRs), which have been approved and being defined by the Java Community (as part of the Java Community Process) for various XML security related activities.
JSR Number Title Description 104 XML Trust Service APIs This JSR is to define a standard set of APIs and a protocol for a "Trust Service" to support the delegation by an application to a service of the processing of XML Signature Key Information associated with an XML signature, XML encryption, or other public key. Its functions include the location of required public keys and the binding of such keys to identification information. 105 XML Digital Signature APIs This JSR is to define a standard set of APIs for XML digital signatures services. 106 XML Digital Encryption APIs This JSR is to define a standard set of APIs for XML digital encryption services.
Sun is also actively involved in Security Assertion Markup Language(SAML), eXtensible Access Control Markup Language (XACML) and other security related standards work as well.
The authors would like to thank the following, in particular, for providing input for this paper: Yassir Elley, Chris Ferris, Eduardo Gutentag, Eve Maler, Craig McMillan, Sean Mullan, and David Turvey, all from Sun Microsystems.