| TOC |
To be effective, a framework for establishing trust between parties must be based on agreed protocols to exchange information on which trust decisions may be based. This in turn calls for broadly accepted standards. Obtaining the consensus needed for a technical specification to become a standard is very much easier if existing relevant standards work is used to the maximum extent possible. This note will survey and introduce some established and emerging Internet standards work (from IETF, W3C, OASIS, ISO, ITU) that may be relevant to deliberations about trust based architectures and decision making systems. It will touch on the following protocols: MIME, XML, RDF, HTTP, BEEP, SOAP, instant messaging protocols, XMLDSIG, XMLENC, X.509, XKMS, SAML, XACML.
This memo has been prepared for the first meeting of the Itrust Working Group, a research and technology transfer activity funded under the European Union's 5th Framework. The meeting is hosted by Strathclyde University, and takes place in Glasgow during 2nd to 4th September, 2002.
| TOC |
| TOC |
To be effective, a framework for establishing trust between parties must be based on agreed protocols to exchange information on which trust decisions may be based. This in turn calls for broadly accepted standards. Obtaining the consensus needed for a technical specification to become a standard is very much easier if existing relevant standards work is used to the maximum extent possible. This note will survey and introduce some established and emerging Internet standards work (from IETF, W3C and OASIS) that may be relevant to deliberations about trust based architectures and decision making systems.
The purpose of this paper is not to delve into great detail about these standards, or to present a definitive list of standards to be used, but to stimulate discussion about applicable existing standards work. Also, it is not intended to imply that the standards noted necessarily have a part to play in a trust modelling framework, rather that they represent existing technologies whose functions should not be duplicated by new designs, if possible.
The essence of Internet standards is to achieve interoperability and scalability for data communication services.
For interoperability, it is particularly important that communicating parties do not have to activate some kind of bilateral out-of-band agreement in order to start communicating with each other. This issue is particularly significant for establishing trust: if any form of bilateral already exists then some the biggest difficulties of establishing trust have already been solved. Both interoperability and scalability are served by keeping designs as simple as possible consistent with performing the required functions.
Scalability is further served by minimizing the dependence on a single authority, and restricting any such dependency to purely technical matters. Experience with PKI deployment (or non-deployment) shows that trying to force all users into a single operational model of trust management just does not work at Internet scale. Whatever the participants may wish for, there will be variations in national, corporate and personal policy that a scalable system must accommodate.
Successful Internet standards are generally made up from a number of simple interlocking pieces. This approach seems to permit common implementations of shared technical requirements, while allowing for local policy preferences. But we should not forget that interoperability requires that all of these interlocking pieces can work with each other.
This memo surveys existing standards work in the following areas. Protocols are distinguished from data formats:
Interoperability between trust handling components requires that they employ common protocols and data formats.
Section Generic data formats looks at generic data formats that are likely to be useful for a common trust framework.
Section Trust and security related data formats surveys data formats with particular relevance to security and/or trust management.
Section Generic protocols surveys general purpose protocols that are likely to be useful in a common trust framework.
Section Trust and security related protocols surveys protocols with particular relevance to security and/or trust management.
| TOC |
Formats have been selected for inclusion on the basis that I believe they are likely to play a fundamental role in any trust management deployment. In some cases, their use may be hidden by underlying protocol layers, and does not necessarily impact the trust framework design.
MIME is an IETF standard format for encapsulating and labelling arbitrary application data for transfer using Internet protocols. It has been designed as an extension of the standard Internet mail format , and is very widely used, by Internet email , web access  and other Internet application protocols.
Several Internet security mechanisms assume that data is MIME-encapsulated.
XML is a W3C format for encoding arbitrary data. It's design is an evolution of SGML/HTML markup for documents and hypertext, but is now finding widespread use for transferring application specific data across the Internet.
Much current standardization work in security and access control uses XML-based formats.
URIs are an IETF standard for a uniform identifier and network address format. URIs were originally used to indicate the target of World Wide Web network hypertext links in a fashion independent of the network protocol used to access the referenced target. They are now also being used in many applications as general purpose idcentifiers, in a fashion similar to the use of OIDs in ISO protocols .
Being so widely used, and inherrently capable of identifying any concept, I think it is very likely that URIs will be used for identifying the principals, resources and other concepts in any large scale deployment of trust management.
RDF is a W3C format for representing metadata and arbitrary information. It is based on an abstract graph model, for which an XML serialization is defined.
It is usually possible to use "home grown" XML for applications where RDF is applicable, but RDF offers the following distinguishing characteristics:
The power and value of using RDF in a trust modelling framework is the integration and sharing of information between applications. For an isolated application, there may be little practical value in using RDF, but when several applications need to exchange information, the common representation thus provided is most valuable. I liken this to the effect that Internet Protocol (IP) had on the deployment of communication services in allowing disparate systems to communicate with each other and enabling the development and deployment of new communication services. RDF fulfils a similar role with respect to information services.
| TOC |
S/MIME is an IETF standard for singing and encrypting MIME content, and providing other related security services. Can be used to provide end-to-end security for arbitrary MIME content.
OpenPGP is another IETF standard for singing and encrypting MIME content, and providing other related security services. Can be used to provide end-to-end security for arbitrary MIME content.
XMLDSIG (also ) is a joint IETF/W3C standard for signing XML data.
Unlike S/MIME and OpenPGP, this exploits the internal structure of XML to provide for selective signing and canonicalization of equivalent representations, allowing a message containing signed XML content to be manipulated (within certain bounds) without invalidating the signature.
XMLENC is a W3C standard for encrypting XML data.
X.509 is an ITU standard format for public key certificates.
PKIX is an IETF standard profile of X.509 for Internet use.
SAML is an OASIS standard format and protocol binding framework for conveying security assertions. A particular goal of SAML is support for single sign-on, a single user authentication being used to generate sufficient credentials to access resources in different domains.
XACML is an OASIS specification for using XML to expressing policies for information access over the Internet.
| TOC |
HTTP is the primary protocol used to fetch and update documents on the World Wide Web. This protocol is also being used for a range of other purposes which are not always clearly related to Web access -- see RFC3205 for discussion of some concerns about using HTTP in this way.
HTTP retrieves and delivers MIME-encapsulated data objects, with some small variations in the formatting details.
SMTP is the main protocol used for delivering Internet mail. A major distinguishing feature of SMTP is its use of relays, which means that the sender and receiver of a message to not need to be similtaneously connected to the Internet.
There are also a few attempts to use SMTP for limited application-to-application data transfers, but SMTP is not especially well suited to this (but see instant messaging).
BEEP is an application protocol framework rather than a single protocol. It can be used as a basis for new application protocols that have a commonly occurring set of characteristics, thus simplifying protocol design and allowing for code re-use.
SOAP is a messaging framework for XML. It evolved from an earlier work for using XML to perform remote procedure calls (XML-RPC), but in its present form the various protocol elements have been separated so that its use is not limited to RPC.
The main part of the SOAP specification defines a message envelope structure that can be used to carry arbitrary message structures. These messages can be transferred using a variety of underlying protocols.
in SOAP version 1.2 , HTTP bindings are defined for two message exchange patterns, request-response (corresponding to RPC) and response only (corresponding to HTTP GET). For data that is not presented in an XML encoding, a data encoding scheme is defined.
Instant messaging and presence protocols (IMPP) combine the loosely connected delivery features of email with a framework that allows timely and deterministic performance where appropriate. The presence protocol elements provide for asynchronous notifications to be delivered, following a publish-and-subscribe model.
While the immediate use for instant messaging is for person-to-person text messaging, a number of groups are looking at using the infrastructure for efficient application-to-application messaging.
Currently, there are a number of proprietary IMPP offerings (ICQ, AOL, MSN, Yahoo). There are also (at least) three efforts aiming for some kind of standard status: SIMPLE (SIP based) http://www.ietf.org/html.charters/simple-charter.html, APEX  (based on the email architecture), and Jabber http://www.jabber.org/.
| TOC |
TLS is a transport level protocol that applications can use to secure (authenticate and/or encrypt) connection based protocols. It provides a hop-by-hop security, which means that intermediate nodes must be trusted. (There are possibilities to tunnel HTTP through proxies, avoiding the need to trust the proxy intermediaries.)
The object security services described above (S/MIME, OpenPGP, XMLDSIG, etc.) can proviode end-to-end security services, which are regarded my many as being superior to channel-based security like TLS, which does not generally apply end-to-end. But, in practice, TLS and similar protocols have been easier to deploy in practice, and arguably provide better security on the basis that some deployed security is better than no deployed security.
SASL is the Simple Authentication and Security Layer protocol framework. This is not a stand-alone protocol, but a framework that can be used by application protocols to negotiate and embed security services within an application protocol.
Like TLS, SASL is not generally used to provide end-to-end security, so intermediary systems must be trusted.
Secure shell can be used to provide channel security for protocols that do not have security designed in. Secure shell is primarily a secure terminal access service, but has been enhanced with tunnelling capabilities that allow an application connection on one machine to be securely connected to an application port on a remote machine. There is an IETF working group to standardize SSH http://www.ietf.org/html.charters/secsh-charter.html.
XKMS is a W3C work in progress to provide key management services to XML applications. Part of the rationale for XKMS is to allow complicated and sensitive certificate processing to be separated from applications, providing a set of simple services that the applications need in order to get their job done in a secure fashion.
| TOC |
I adopt the following working definition of "trust":
The firm expectation that an entity will behave dependably and securely within a specified context.
The whole idea of trust management is intimately bound with security. Most security technologies convey trust in some way, though these alone cannot establish or create trust.
Most of the standards work conducted to data has focused on security mechanisms, and have left the establishment of trust as a "problem for the reader". The difficulty of establishing and describing trust underpins the failure to achieve meaningful large-scale deployment of a public key infrastructure: by simply focusing on the technology to transfer trusted assertions, much needed parts of the larger picture have been left unaddressed.
In focusing on the establishment of trust, I believe it is important that we do not forget that the mechanisms for conveying trust decisions must be reliable: the work that has gone into secure systems design, and the resulting designs and standards, are hightly relevant to our work in trust management. Hence the attention paid in this memo to data formats and protocols for data communication security.
| TOC |
|||Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.|
|||Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.|
|||Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.|
|||Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.|
|||Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.|
|||Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.|
|||Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.|
|||Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.|
|||Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.|
|||Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.|
|||Resnick, P., "Internet Message Format", RFC 2822, April 2001.|
|||Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.|
|||Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.|
|||Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.|
|||Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.|
|||Rose, M., Klyne, G. and D. Crocker, "The Application Exchange Core", RFC 3340, July 2002.|
|||Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Recommendation xml, October 2000.|
|||Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C Recommendation xml-names, January 1999.|
|||Lassila, O. and R. Swick, "Resource Description Framework (RDF) Model and Syntax Specification", W3C Recommendation rdf-syntax, February 1999.|
|||Brickley, D. and R. Guha, "Resource Description Framework (RDF) Schema Specification 1.0", W3C Candidate Recommendation CR-rdf-schema, March 2000.|
|||Eastlake, D., Reagle , J. and D. Solo, "XML-Signature Syntax and Processing", W3C Recommendation xmldsig-core, October 2000.|
|||Eastlake, D. and J. Reagle , "XML Encryption Syntax and Processing", W3C Candidate Recommendation xmlenc-core, August 2002.|
|||Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C Note soap11, May 2000.|
|||Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J. and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C Working Draft soap12-part1, June 2002.|
|||Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J. and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", W3C Working Draft soap12-part2, June 2002.|
|||Ford, W., Hallam-Baker, P., Fox, B., Dillaway, B., LaMacchia, B., Epstein, J. and J. Lapp, "XML Key Management Specification (XKMS)", W3C Note xkms, March 2001.|
|||Hallam-Baker, P. and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", OASIS Committee Specification sstc-core, May 2002.|
|||Godik, S. and T. Moses, "OASIS eXtensible Access Control Markup Language (XACML)", OASIS Committee Working Draft xacml-schema-policy, July 2002.|
|||International International Telephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, November 1988.|
|||International International Telephone and Telegraph Consultative Committee, "Specification of Abstract Syntax Notation One (ASN.1): Specification of Basic Notation", CCITT Recommendation X.680, July 1994.|
| TOC |
|Nine by Nine|
|14 Chambrai Close|
|Abingdon, Oxon OX14 4NT|
| TOC |
[[[Remove this section on final publication]]]
- 00a 12-Aug-2002:
- Document initially created.