Network Working Group | R.J.G. Upton |
INTERNET DRAFT | Altruists International |
<rupton-look-0-ietf.xml> | June 2010 |
Category: Experimental | |
Expires: December 2010 |
LOOK – Links by Owners Of Keys to URIs
rupton-look-0-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 December 2010.
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
2
Signatures
2.1
Generation
2.1.1
uri
2.1.2
key
2.1.3
sign
2.1.4
value
2.2
Core Syntax
2.3
Flexibility
2.4
Publication Format
2.4.1
XML Processing Instruction
2.4.2
XML Element
2.4.3
XML Comment
2.4.4
XML Attribute
2.4.5
Hyperlink
2.4.6
Text
2.5
Choice of Format
3
Interpretation
3.1
Activation
3.2
Validation
4
Security Considerations
4.1
Integration with WWW
4.1.1
Single user Websites
4.1.2
Multiple User Websites
4.2
Re-publication of Documents
4.3
Reliability
5
IANA Considerations
6
Acknowledgements
7
TO-DO
8
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].
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 (") and one or more whitespace characters as separators. For example:
<?LOOK uri="http://example.com/~foo" key="MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD83 rVEbA1Q5sf5dx5jbxIVlLFm5jkevCKxBkxKccJB3mNKfeRremvm6d5p 7sc1+f+6fh+7kEaOWhEusGyY2aJEItmykKEIwYKYnU4JOIY03j9Q8 LeHtBDKTMHtG0FxpvTYQhw8tWVOpUaiYGqq7i/phEOnkoiPiSUXH cQ5P0K4WwIDAQAB" value="dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK"?>
To produce a LOOK, first choose the 'uri' component which specifies which URIs to associate, and the 'key' component, which is the key with which to associate them. LOOK creation tools MUST silently discard horizontal tab (%x09), linefeed (%x0A), carriage return (%x13) or space (%x20) characters in the 'key' component before the key is used. The contents of the 'uri' component are signed by the algorithm indicated by the ‘sign' component. The result is base64-encoded and set equal to the ‘value' component.
This REQUIRED component is the URI(s) to associate with the cryptographic key. Multiple URIs are separated by one or more whitespace characters. LOOK aware agents MUST be able to handle a ‘uri' 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 (RFC 1421), 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 8192 characters.
If present, this component immediately proceeds 'value', 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.
This REQUIRED component contains the base 64 encoded output of the signature algorithm. LOOK aware agents MUST be able to handle a ‘value' component of at least 8192 characters. They SHOULD discard whitespace characters.
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.
The above syntax defines the core value of a LOOK, which 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 3) SHOULD not vary according to publication format.
A verified LOOK cannot securely be construed as a claim of authorship of a set of data, but as evidence that a specific key holder chose to associate their key with a particular URI and that it was uploaded there (usually by that person, but see Section 4.2). The interpretation of LOOKs is context specific. 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. In some contexts, multiple LOOKs might apply to the same URI.
Each LOOK specifies a set of URIs to which it applies, the contents of its uri component. If retrieved from a different URI it is termed inactive. LOOK aware agents MAY alert the user to the presence of inactive LOOKS, but SHOULD treat them differently from active LOOKS.
The first step of processing an active LOOK is validation. To validate a LOOK, the contents of its value component are compared with the output of the Section 2.1; the LOOK is valid 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 invalid LOOKS, and SHOULD treat them differently from valid LOOKs.
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 with a particular URI, and that they could publish it online at that URI. 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 their 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 active 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 4.1.2 and Section 4.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 links from other websites.
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. |
[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.