| Network Working Group | R.J.G. Upton |
| INTERNET DRAFT | Altruists International |
| <rupton-look-2-ietf.xml> | July 2010 |
| Category: Experimental | |
| Expires: January 2011 |
LOOK – Links by Owners Of Keys to URIs
rupton-look-2-ietf.xml
CONFORMANCE UNDEFINED.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at <http://www.ietf.org/ietf/1id-abstracts.txt>.
The list of Internet-Draft Shadow Directories can be accessed at <http://www.ietf.org/shadow.html>.
This Internet-Draft will expire in January 2011.
Copyright (C) The Internet Society (2010). All Rights Reserved.
Most authors of data on WWW have difficulty securely asserting authorship of their online content, since they cannot use the methods available to webmasters. This document specifies LOOK, a standard for creators of online content to associate their cryptographic identities with online resources over which they may have only partial control. In contrast to existing general purpose digital signature formats, LOOK is designed to be flexible enough to fit within constraints of existing publishing frameworks.
1
Introduction
1.1
Requirements Language
1.2
Whitespace Language
2
Core Syntax
2.1
Flexibility
3
Components
3.1
uri
3.2
uri-prefix
3.3
key
3.4
meaning
3.5
sign
3.6
value
4
Publication Format
4.1
XML Processing Instruction
4.2
XML Element
4.3
XML Comment
4.4
XML Attribute
4.5
Hyperlink
4.6
Text
4.7
Choice of Format
5
Processing
5.1
Applicability
5.2
Validation
5.3
Interpretation
6
Security Considerations
6.1
Integration with WWW
6.1.1
Single user Websites
6.1.2
Multiple User Websites
6.2
Re-publication of Documents
6.3
Reliability
7
IANA Considerations
8
Acknowledgements
9
TO-DO
10
OPEN-QUESTIONS
§
Normative References
§
Informative References
§
Author's Address
§
Intellectual Property and Copyright
Statements
Digital signature standards allow key holders to associate their key with a particular set of data. However, these formats have a tight syntax which prevents their application in many contexts. For example, websites typically offer users only partial control over what they can publish. Whilst webmasters can publish arbitrary XML, they rarely extended this privilege to users, preventing the direct approach of digitally signing published data. Moreover, web pages may interpolate unpredictable dynamic content such as banner ads, which would break signatures. However, the need not to change hyperlinks is widely understood, so that URLs are relatively stable.
The Links by Owners Of Keys (LOOK) standard is an alternative to signing of online data. Instead it associates cryptographic keys with URIs, alerting the reader that the data my be augmented, say by a conventionally signed copy, by data published elsewhere. WWW has a lot of data, but was conceived around a DNS-centric security model. This standard is intended to bridge the cryptographic gap between WWW and future systems which have a more direct, data-centric cryptographic model. LOOK tackles the question of how users of WWW can adopt new systems without either discarding their data on WWW or requiring work from webmasters to implement new cryptographic systems.
LOOK has multiple formats to facilitate inclusion within different publishing constraints, to ease the migration of data from WWW to more cryptographically secure, XML-centric personal publishing systems (Friend2Friend systems) that allow publication of content without the restrictions of most websites.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
References made to "whitespace" refer to the LWSP element of [RFC5234], that is, a sequence of one or more of horizontal tab (%x09), space (%x20) or linefeed (%x0A) plus carriage return (%x13).
The syntax definitions below use ABNF according to [RFC5234]:
LOOKs MUST adhere to the standard above, so it is erroneous to assume that LOOK has the extra flexibility of XML, such as by allowing single quotes instead of double quotes, or allowing the components to be in any order. However, consuming software may choose to permit such looseness in parsing LOOKs. Unrecognized components SHOULD be ignored.
A LOOK uses the XML cryptography standards specified in [W3DSIG2]. Three components are REQUIRED and one is OPTIONAL, which MUST serialised in the order below and formatted in the style of XML attributes using double quotes (") separated by whitespace. For example:
<?LOOK uri="http://example.com/~foo" uri-prefix="http://example.com/~foo/ http://example.com/~foo?" key="MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD83 rVEbA1Q5sf5dx5jbxIVlLFm5jkevCKxBkxKccJB3mNKfeRremvm6d5p 7sc1+f+6fh+7kEaOWhEusGyY2aJEItmykKEIwYKYnU4JOIY03j9Q8 LeHtBDKTMHtG0FxpvTYQhw8tWVOpUaiYGqq7i/phEOnkoiPiSUXH cQ5P0K4WwIDAQAB" value="dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK" meaning="http://f2f.name/LOOK/owner" ?>
This component is REQUIRED if the uri-prefix component is not present. It specifies URI(s) to associate with the cryptographic key. Multiple URIs are separated by whitespace. LOOK aware agents MUST be able to handle a ‘uri' component of at least 65535 characters.
This component is REQUIRED if the uri component is not present. It specifies set(s) of URIs to associate with the cryptographic key. A Multiple URI prefixes are separated by whitespace. LOOK aware agents MUST be able to handle a ‘uri-prefix' component of at least 65535 characters.
This REQUIRED component is the public key to associate with the URI(s), in Privacy-Enhanced Mail (PEM) format[RFC1421], that is, as a Base64 representation of a DER encoded key. LOOK aware agents MUST be able to handle a ‘key' component of at least 8191 characters.
If present, this component immediately follows 'key', and is a URI to indicate the nature of the relationship between the URI component(s) and the key component. It defaults to "http://f2f.name/LOOK/owner". LOOK aware agents MUST be able to handle a ‘meaning' component of at least 1023 characters.
If present, this component immediately proceeds 'meaning', and is a URI to indicate a signature method. It defaults to "http://www.w3.org/2000/09/xmldsig#dsa-sha256", which MUST be supported by LOOK aware agents, so that this component may be omitted. LOOK aware agents MUST be able to handle a sign' component of at least 1023 characters.
LOOK aware agents MUST be able to handle a ‘value' component of at least 8191 characters. They SHOULD discard whitespace. This REQUIRED component is a function of the other components, created as follows:
The core value of a LOOK expressed in Section 2 may be expressed in a variety of semantically equivalent formats to suit different publishing constraints.
The namespace prefix can be any legal namespace prefix bound to "http://f2f.name/LOOK/".
The namespace prefix can be any legal namespace prefix bound to "http://f2f.name/LOOK/".
A "#" character is prepended to hyperlinks to disable their usual function as hyperlinks.
Since LOOK is intended for software to process, the ideal format for a LOOK is easily machine readable, but minimally disruptive to the reader who does not have suitable software installed. This is often infeasible due to publishing platforms' restrictions on what users can publish, even on their ‘own' pages.
Where possible, it is recommended that users publish a LOOK as a processing instruction, since it is easily detected, will not be rendered and is unlikely to violate any schemas or disrupt transforms carried out on the page. Comments have similarly desirable properties, but may be more likely to be automatically discarded by LOOK unaware software(@@@ Is this true?). Namespaced attributes are easily detected and do not display, but may break schemas.Many web pages allow users to input arbitrary hyperlinks, which is preferred over the most widely acceptable format, plain text, since browsers' rendering of text fields pollute the page of LOOK unaware browsers.
The choice of format is intended to overcome limitations on publication of the LOOK, not to express a semantic difference. Interpretation (see Section 5.3) SHOULD not vary according to publication format.
The first step of processing a LOOK is to compare whether it is applicable. Applicable LOOKs MUST be validated. Valid LOOKs are then interpreted.
Applicability is determined by comparing the source URL from which the LOOK is retrieved to the 'uri' and 'uri-prefix' components. It is applicable if one or both of the following is true:
Otherwise, it is inapplicable. LOOK aware agents MAY alert the user to the presence of inapplicable LOOKS, and may validate them, but SHOULD treat them differently from applicable LOOKS in any case.
To validate a LOOK, its 'value' component is recomputed according to Section 3.6; the LOOK is valid if and only if the two are identical. The default signature algorithm, http://www.w3.org/2000/09/xmldsig#dsa-sha256, MUST be supported by any agents which support this specification. Support for other algorithms is OPTIONAL. If an agent detects a signature algorithm which it does not support, it MUST not consider the LOOK to be valid. Agents SHOULD alert the user to applicable but invalid LOOKS, and SHOULD treat them differently from valid LOOKs.
The meaning of a LOOK is defined by the meaning component. This defaults to 'http://f2f.name/LOOK/owner', which is used to claim authorship a website. A valid LOOK is does not proof of authorship of a set of data by a key holder, but that the key holder chose to associate their key with a particular URI and that it was uploaded there (usually by that person, but see Section 6.2). The meaning parameter allows LOOKs to assume a context specific meaning. On a commerce website, for example, they could be used to indicate receipt of goods, on a voting website, to give assent to a proposition. Multiple identical LOOKs may apply to the same URI, with different 'key' and or 'meaning' components.
Misunderstanding the aim of this specification may be a significant cause of problems. A LOOK provides no evidence that the holder of a specific cryptographic key created a particular document, merely that the holder of a cryptographic key wished to associate it in a particular way with a particular URI, and that they could publish it online at a particular URL. The usual cryptographic issues apply to the encryption, as specified in Section 8 of [W3DSIG2].
Inference about authorship from existing WWW content should not be regarded as secure, since any party which can upload data to that URI can insert a valid LOOK. LOOKs are designed for use by holders of cryptographic keys who are already trusted, and whose cryptographic identity is previously established in an alternate publishing system. It allow them to assert relationships (such as ownership) of multiple accounts, providing a mechanism for browsing software to make inference about the ownership of WWW pages, which they can present to users.
The simplest case is that in which the owner of a cryptographic key has exclusive access to a website. Whilst this case presents the least security issues, it also presents the least benefit, since users have full access to other methods such as HTTPS and publication of signed XML with which to establish their cryptographic identity.
Most online user data is held by a relatively small number of very large sites run by third parties. By publishing a LOOK, users can establish a cryptographic link with a small part of such websites, such as their personal page(s).
Many websites permit unauthorised third parties to publish content on a user's page, for example as a comments or news feeds. LOOK aware agents should therefore be aware of the possibility of multiple applicable LOOKs, all valid, each associating different keys with a particular URI.
Site-specific knowledge might be effective at interpreting the meaning of multiple valid LOOKs, for example discerning a webpage's 'owner' from others who could published a LOOK on that page. A more robust approach would be to allow users to define these roles, presenting them with information by querying alternative systems so that they were presented with meaningful data instead of cryptographic keys.
Where users re-publish an online document containing a LOOK, it may still be syntactically valid, and may not even be rendered. This presents a potential method for key holders who could predict a URI at which a document would be published to use social engineering to indirectly insert a valid LOOK into a URI to which they have no ability to publish directly.
For reasons explained in Section 6.1.2 and Section 6.2 it is RECOMMENDED that automated tools avoid assuming that publication of a valid LOOK indicates 'ownership' of a URI without subsidiary evidence. It MAY be appropriate to make inferences having queried one or more of the personal publishing system(s) of which they are aware. Reorganisation of URLs will break LOOKs, just as it will break hypertext links.
This memo includes no request to IANA.
Thanks to the universe. It's cosmic.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC1421] | Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |
| [RFC4051] | Eastlake, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| [W3DSIG2] | Roessler, T., Hirsch, F., Solo, D., Reagle, J. and D. Eastlake, "XML Signature Syntax and Processing (Second Edition)", World Wide Web Consortium Recommendation REC-xmldsig-core-20080610, June 2008. |
| Robin Upton | |
| Altruists International | |
| 3
Firs Rd, West Mersea | |
| Colchester, Essex CO5 8JS | |
| UK | |
| Phone: | +44 1206 382726 |
| EMail: | robin-f2f@altruists.org |
| URI: | http://f2f.RobinUpton.com |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at <http://www.ietf.org/ipr>.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2010). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.