Network Working Group S. Palmer Internet-Draft Independent Expires: June 10, 2016 December 8, 2015 Signature Link Relation for Cryptographic Resource Verification draft-palmer-signature-link-relation-00 Abstract This document specifies a way to associate web resources with their corresponding digital signatures. A signature can then be verified automatically during the process of downloading a resource. Infomation presented to the user about the verification results may enable them to make wiser security decisions about downloaded content. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 10, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Palmer Expires June 10, 2016 [Page 1] Internet-Draft Signature Link Relation December 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Link relation . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Hypertext attribute . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction Links to downloadable content on the web are sometimes accompanied by a further link to a digital signature. The digital signature proves that the content is signed, and hence endorsed, by the owner or owners of a secret cryptographic key. Digital signature links are, however, presently embedded in documents in an ad hoc fashion making the automatic checking of signatures difficult. As a result, user workflow is to download content and signatures individually, requiring them to locate both files in the local filesystem and pass them to verification software external to their web client. Verification software is often terminal based, and has attracted criticism for poor user interface decisions [DJB]. The existing signature workflow exacerbates this problem, and makes it much less likely that a user will verify content compared to if their client had performed these steps for them. For signature verification to be automated, content must be associated with signatures through metadata in a structured and machine-readable way. This document provides such metadata in the form of a link relation called "signature" (Section 2). An HTML attribute called "rels" (Section 3) is also provided, which allows the link relations of a resource to be known before any request is made. When a web client such as a browser implements this metadata, the user can be automatically presented with a summary of the verification process, including whether it succeeded or failed, and what the claimed identity and web of trust characteristics are of the signing key. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Palmer Expires June 10, 2016 [Page 2] Internet-Draft Signature Link Relation December 2015 2. Link relation This section defines a new link relation called "signature". The value of this link relation is a cryptographic digital signature of the resource to which the link relation applies. The value SHOULD identify an OpenPGP detached signature as defined in Section 11.4 of [RFC4880], with the syntax specified in Section 6.2 of [RFC4880]. The target resource SHOULD be served with the media type "application/pgp-signature" as defined in [RFC3156]. Other formats MUST be distinguished either by a separate media type, or by extension of the OpenPGP syntax specified in Section 6.2 of [RFC4880]. Example of the use of this relation in HTML: In formats which use URLs as properties, the following URL may be used as a link relation property once registered with the IANA per Section 6.2.1 of [RFC5988]: http://www.iana.org/assignments/relation/signature 3. Hypertext attribute This section defines a "rels" attribute, for use on all elements where "rel" is permitted in HTML ([RFC2854]) and in all contexts where HTML content is permitted such as in applications of XML ([XML]). The syntax of the "rels" attribute value is a whitespace separated sequence of whitespace separated pairs of link relations and URL values. Relative URL values are resolved against the current resource URL as a base, not the target of the "href" attribute. The effect is that each pair of link relations and URL values applies to the resource identified by the "href" attribute. The "rels" attribute allows the discovery of the link relationships of a hyperlinked resource before any request is made. It may, for example, be used in conjunction with "signature" link relation: You may download the signed software. 4. Security Considerations The extensive security considerations listed in Section 14 of [RFC4880] also apply here. Palmer Expires June 10, 2016 [Page 3] Internet-Draft Signature Link Relation December 2015 5. Acknowledgements Reviews and comments were received from Daniel Gruno, David P. Kendal, and John Cowan. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC2854] Connolly, D., "The 'text/html' Media Type", June 2000. [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", August 2001. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", November 2007. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", January 2005. [RFC5988] Nottingham, M., "Web Linking", October 2010. 6.2. Informative References [DJB] Bernstein, D., Heninger, N., and T. Lange, "The Year in Crypto", December 2013, . [XML] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", November 2008. Author's Address Sean B. Palmer Independent Palmer Expires June 10, 2016 [Page 4]