RFC 
 TOC 
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

Status of this Memo

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 Notice

Copyright (C) The Internet Society (2010). All Rights Reserved.

Abstract

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.


 RFC 
 TOC 

Table of Contents

Introduction
 1.1  Requirements Language
 1.2  Whitespace Language
Core Syntax
 2.1  Flexibility
Components
 3.1  uri
 3.2  uri-prefix
 3.3  key
 3.4  meaning
 3.5  sign
 3.6  value
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
Processing
 5.1  Applicability
 5.2  Validation
 5.3  Interpretation
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
IANA Considerations
Acknowledgements
TO-DO
10  OPEN-QUESTIONS
  Normative References
  Informative References
  Author's Address
  Intellectual Property and Copyright Statements


 TOC 

1  Introduction

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.

1.1  Requirements Language

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].

1.2  Whitespace Language

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).


 TOC 

2  Core Syntax

The syntax definitions below use ABNF according to [RFC5234]:

LOOK-core = uris key [meaning] [ sign ] value [ LWSP ]
uris = ( uri [ uri-prefix ] ) / uri-prefix
uri = LWSP "uri=" DQUOTE URI *(LWSP URI) DQUOTE
uri-prefix = LWSP "uri-prefix=" DQUOTE URI *(LWSP URI) DQUOTE
key = LWSP "key=" DQUOTE *base64 DQUOTE
meaning = LWSP "meaning=" DQUOTE URI DQUOTE
sign = LWSP "sign=" DQUOTE URI DQUOTE
value = LWSP "value=" DQUOTE *base64 DQUOTE
DQUOTE = <Defined in [RFC5234]>
URI = <Defined in [RFC3986]>
LWSP = <Defined in [RFC5234]>
LOOK = LOOK-pi / LOOK-element / LOOK-comment / LOOK-attribute / LOOK-link / LOOK-text
;Defined in Section 4

2.1  Flexibility

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.


 TOC 

3  Components

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" ?>

3.1  uri

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.

3.2  uri-prefix

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.

3.3  key

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.

3.4  meaning

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.

3.5  sign

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.

3.6  value

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:

  1. Canonicalise the 'key', 'meaning', 'prefix' and 'sign' components by discarding whitespace.
  2. Canonicalise the 'uri' and 'uri-prefix' components by replacing each whitespace section with a single space (%x20) character.
  3. Construct a signed info string as follows, using the definitions of SP and DQUOTE in [RFC5234]:
    LOOK-signed-info = SP "meaning=" DQUOTE <canonicalised 'meaning' component> DQUOTE [ SP "uri=" DQUOTE <canonicalised 'uri' component> DQUOTE ] [ SP "uri-prefix=" DQUOTE <canonicalised 'uri-prefix' component> ]
  4. Sign this string according to [W3DSIG2], using the algorithm specified by the 'sign' value and the private key corresponding to the public key specified by the 'key' component. The result is base64-encoded and set equal to the ‘value' component.


 TOC 

4  Publication Format

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.

4.1  XML Processing Instruction

LOOK-pi = "<?look " LOOK-core "?>"

4.2  XML Element

LOOK-element = "<" <namespace prefix> ":LOOK " DQUOTE LOOK-core DQUOTE "/>" / "<LOOK " DQUOTE LOOK-core DQUOTE "/>" ; If the xmlns attribute sets the namespace

The namespace prefix can be any legal namespace prefix bound to "http://f2f.name/LOOK/".

4.3  XML Comment

LOOK-comment = "<!-- " LOOK-core " -->"

4.4  XML Attribute

LOOK-attribute = <namespace prefix> ":LOOK=" DQUOTE LOOK-core DQUOTE

The namespace prefix can be any legal namespace prefix bound to "http://f2f.name/LOOK/".

4.5  Hyperlink

LOOK-link = "<a href=" DQUOTE "#" LOOK-core DQUOTE ">" LOOK-anchor "</a>" LOOK-anchor = *()
; Some publishing contexts require the anchor.

A "#" character is prepended to hyperlinks to disable their usual function as hyperlinks.

4.6  Text

LOOK-text = "[LOOK=" DQUOTE LOOK-core DQUOTE "]"

4.7  Choice of Format

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.


 TOC 

5  Processing

The first step of processing a LOOK is to compare whether it is applicable. Applicable LOOKs MUST be validated. Valid LOOKs are then interpreted.

5.1  Applicability

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:

  1. The 'uri' component contains the exact source URL.
  2. The 'uri-prefix' component contains one or more URIs which is an exact prefix of the source URL.

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.

5.2  Validation

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.

5.3  Interpretation

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.


 TOC 

6  Security Considerations

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].

6.1  Integration with WWW

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.

6.1.1  Single user Websites

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.

6.1.2  Multiple User Websites

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.

6.2  Re-publication of Documents

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.

6.3  Reliability

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.


 TOC 

7  IANA Considerations

This memo includes no request to IANA.


 TOC 

8  Acknowledgements

Thanks to the universe. It's cosmic.


 TOC 

9  TO-DO

Fix the example. It is random


 TOC 

10  OPEN-QUESTIONS

'Uri-prefix' is a bit messy, for the sake of a simple spec? Maybe add some intelligence to the spec, so not to trip people up? e.g. uri-prefix= 'FOO' should match FOO/BAR or FOO?BAR, but not FOOBAR?
How about publishing in images via matrix codes?
How about a free TEXT field for comments so people can declare how they mean to use a look??
Priority to LOOKs earlier up a page???
Website specific policies so that site owners can declare how their site works???
How to deal with querystrings? Have a 'meta-format' to allow wildcarding?? Or even just a 'anything added beyond this URI' option?
How tightly to define the LOOK? c.f. Section Section 3.3
Do we need more on Encoding? CR/LF???
Tighten 2.3.5 – are hypertext links with "'" still legal?
XSD for the look element?
Can we do better as far as naming? "Look" grabs the attention, but the acronym is a bit unconvincing...
Handling moving of URIs?
Something about HTTP codes in Section 6.3?


 TOC 

Normative References

[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

 TOC 

Informative References

[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.

 TOC 

Author's Address

 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
 

 TOC 

Intellectual Property Statement

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.

Disclaimer of Validity

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 Statement

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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.