Internet DRAFT - draft-palmer-signature-link-relation
draft-palmer-signature-link-relation
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:
<link rel="signature" href="index.html.sig">
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 <a href="software.tar.gz"
rels="signature software.tar.gz.sig">software</a>.
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,
<https://www.hyperelliptic.org/tanja/vortraege/talk-
30C3.pdf>.
[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]
