One document matched: draft-miller-saag-key-discovery-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.26 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-miller-saag-key-discovery-00" category="std">

  <front>
    <title abbrev="KDS">Key Discovery Service</title>

    <author initials="M." surname="Miller" fullname="Matthew Miller">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>mamille2@cisco.com</email>
      </address>
    </author>
    <author initials="S." surname="Nandakumar" fullname="Suhas Nandakumar">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>snandaku@cisco.com</email>
      </address>
    </author>

    <date year="2015" month="July" day="06"/>

    <area>Security</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>A typical requirement with any cryptographic key management system is to provide discovery, retrieval, distribution, and management of keys across entities needing to perform the necessary security operations. However there exists no standard mechanism to automatically discovery the keys, but rather the keys are either provisioned statically or shared beforehand via non standard mechanisms. This document defines machanisms for an entity to automatically discover the key(s) associated with other entities using the WebFinger protocol.</t>



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">

<t>With the increase in efforts towards ensuring end to end encryption for communications on the Internet, it has become necessary to improve the experience around how cryptographic primitives such as keys and certificates are discovered, distributed, and mananged. Efforts such as <xref target="I-D.barnes-acme"/> attempts to automate aspects of certificate retrieval and manangement, whereas efforts such as <xref target="I-D.abiggs-saag-key-management-service"/> provides mechanisms for dealing with keys required for secure group communications. However, today’s standard efforts lack mechanisms for easy discovery of keys associated with an entity or a resource on the Internet. For example, any  public key cryptograpy based system relies on being able to have acquired the public key(s) of the target entity in order to establish a secure communication with that entity. For these scenarios, the entities wanting to acquire such keys are either provisioned with the keys statically (as part of the configuration) or distributed by non standard (application specific) means.</t>

<t>This document describes mechanisms for entities to automatically discover the cryptographic keys associated with entities (users/resources) using WebFinger <xref target="RFC7033"/> as the protocol mechanism. Such a mechanism provides an added benefit of separating key discovery from its retrieval and management.</t>

<t>The rest of this document is organized as follows. <xref target="locate_public_key"/> shows using WebFinger protocol for entity’s public key using an ‘acct’ URI <xref target="RFC7565"/>, followed by <xref target="locate_res_key"/> showing the same procedure for retrieving a secret key for a file resource.</t>

</section>
<section anchor="terms" title="Terminology">

<t>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 <xref target="RFC2119"/>.</t>

</section>
<section anchor="locate_public_key" title="Locating an Entity’s Public Keys">

<t>The examples below show query and response on the WebFinger resource for retrieving the public key(s), using an ‘acct’ URI <xref target="RFC7565"/>:</t>

<t>Query WebFinger:</t>

<figure><artwork><![CDATA[
GET /.well-known/webfinger?
    resource=acct%3Abilbo.baggins%40hobbiton.example
    HTTP/1.1
Host: hobbiton.example

]]></artwork></figure>

<t>The WebFinger response then includes links to the entity’s public keys:</t>

<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Access-Control-Allow-Origin: hobbiton.example
Access-Control-Allow-Methods: GET OPTIONS
Content-Type: application/jrd+json

{
  "subject": "acct:bilbo.baggins@hobbiton.example",
  ...
  "links": [
    ...
    {
      "rel":  "public-key",
      "href": "https://hobbiton.example/~bilbo.baggins/
               pubkeyset.json",
      "type": "application/jwk-set+json"
    }
  ]
}
]]></artwork></figure>

<t>The “rel” value is ‘public-key’. The “href” MUST be a HTTPS URI that the entity’s public key(s) is retrieved from, formatted as a JWK or JWK-set (as defined in <xref target="RFC7517"/>):</t>

<figure><artwork><![CDATA[
{
  "keys": [
    {
      "kty": "EC",
      "kid": "bilbo.baggins@hobbiton.example",
      "use": "sig",
      "crv": "P-521",
      "x":   "AHKZLLOsCOzz5cY97ewNUajB957y-C-U88c3v13nmGZx6sYl_o
              JXu9A5RkTKqjqvjyekWF-7ytDyRXYgCF5cj0Kt",
      "y":   "AdymlHvOiLxXkEhayXQnNCvDX4h9htZaCJN34kfmC6pV5OhQHi
              raVySsUdaQkAgDPrwQrJmbnX9cwlGfP-HqHZR1"
    },
    {
      "kty": "RSA",
      "kid": "bilbo.baggins@hobbiton.example",
      "use": "sig",
      "n":   "n4EPtAOCc9AlkeQHPzHStgAbgs7bTZLwUBZdR8_KuKPEHLd4rH
              VTeT-O-XV2jRojdNhxJWTDvNd7nqQ0VEiZQHz_AJmSCpMaJMRB
              SFKrKb2wqVwGU_NsYOYL-QtiWN2lbzcEe6XC0dApr5ydQLrHqk
              HHig3RBordaZ6Aj-oBHqFEHYpPe7Tpe-OfVfHd1E6cS6M1FZcD
              1NNLYD5lFHpPI9bTwJlsde3uhGqC0ZCuEHg8lhzwOHrtIQbS0F
              Vbb9k3-tVTU4fg_3L_vniUFAKwuCLqKnS2BYwdq_mzSnbLY7h_
              qixoR7jig3__kRhuaxwUkRz5iaiQkqgc5gHdrNP5zw",
      "e":   "AQAB"
    },
    {
      "kty": "RSA",
      "kid": "bilbo.baggins@hobbiton.example",
      "use": "enc",
      "e":   "AQAB",
      "n":   "uTWZBa8bjLQNJ9cBrdxGV_H_pmHEDuAXpCR1NnyYQYkUGJ8F3a
              y_OM6sw82fS2ZcAXHpCVYlp30pd4D6BYwwixDt_eSkY-NLhPA3
              ouE4YwtaUVZYBZT909pISRK4WOr3nXeJ0lltrgPQ7StBR1C776
              KJnsHbBPdXO7tpAfph9GnjNUJxrpoFmhiZx3hbpEUpsxTsDuB9
              doVN9cFCpsjPpoiAvkr_Doyckbi1TnR4zwzDQyfSkhNYghFuqh
              vAQQ8yMQ29HOHYdfON2Z8yCjgAnyJCs1lnywkYaAaZGyxhozXr
              F6_Np2BHteL_XRNekhY72gt1nRZYCQArjJMACx_3iw"
    }
  ]
}
]]></artwork></figure>

</section>
<section anchor="locate_res_key" title="Locating a Resource’s Key">

<t>The example below shows WebFinger query and response for retrieving the secret key associated with a resource controlled by erebor.com, identified using a ‘key’ URI scheme defined in <xref target="iana-key"/>.  The URI to query could have been determined as per <xref target="determine-keyid"/>.</t>

<t>Query WebFinger:</t>

<figure><artwork><![CDATA[
GET /.well-known/webfinger/
    ?resource=key%3Asha-256.GJa85ytSaK1pX6uwyBIEZFRLn5ZjrDd36emx
    NmAGP_s@erebor.eample
    HTTP/1.1
Host: erebor.example

]]></artwork></figure>

<t>WebFinger Response:
The “rel” value is ‘secret-key’. The “href” indicates where to retrieve the secret key.</t>

<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Access-Control-Allow-Origin: hobbiton.example
Access-Control-Allow-Methods: GET OPTIONS
Content-Type: application/jrd+json

{
  "subject": "key:sha-256.GJa85ytSaK1pX6uwyBIEZFRLn5ZjrDd36emxNmAGP_s
              @erebor.eample",
  ...
  "links": [
    ...
    {
      "rel":  "secret-key",
      "href": "kms://rivendell.example/key/
               c8e84a7d-2ae1-435a-9738-bb00e4c8dc7a",
      "type": "application/jwk+json"
    }
  ]
}
]]></artwork></figure>

<t>If “href” is an HTTPS URI, the type SHOULD be “application/jwk+json” or “application/jwk-set+json”.  Other protocols might use different container formats.</t>

</section>
<section anchor="iana" title="IANA Considerations">

<section anchor="iana-key" title="“key:” URI Scheme">

<t>In accordance with the guidelines and registration procedures for new URI schemes <xref target="RFC4395"/>, this section provides the information needed to register the ‘key’ URI scheme.</t>

<section anchor="iana-key-name" title="URI Scheme Name">

<t>key</t>

</section>
<section anchor="iana-key-status" title="Status">

<t>permanent</t>

</section>
<section anchor="iana-key-syntax" title="URI Scheme Syntax">

<t>The ‘key’ URI syntax is defined here in Augmented Backus-Naur Form (ABNF) <xref target="RFC5234"/>, borrowing the ‘host’ and ‘unreserved’ rules from <xref target="RFC3986"/>:</t>

<figure><artwork><![CDATA[
keyuri = "key" ":" keyid "@" host
keyid  = 1 * unreserved
]]></artwork></figure>

</section>
<section anchor="iana-key-semantics" title="URI Scheme Semantics">

<t>The ‘key’ URI scheme identifies cryptographic keys provided by organizations, identified by domain name. It is used only for identification, not for interaction. A protocol (other than the one specified in this document) that employs the ‘key’ URI scheme is responsible for specifying how a ‘key’ URI is dereferenced in the context of that protocol.</t>

</section>
<section anchor="iana-key-encoding" title="Encoding Considerations">

<t><list style="symbols">
  <t>The keyid consists of unreserved characters as defined in <xref target="RFC3986"/>.</t>
  <t>The host consists only of Unicode code points that conform to the rules in <xref target="RFC5892"/>.</t>
  <t>Internationalized domain name (IDN) labels are encoded as A-labels <xref target="RFC5890"/>.</t>
</list></t>

</section>
<section anchor="iana-key-apps" title="Applications/Protocols That Use This URI Scheme Name">

<t>At the time of this writing, only this protocol uses the ‘key’ URI scheme, in conjunction with WebFinger. However, use is not restricted to this protocol, and the scheme might be considered for use in other protocols.</t>

</section>
<section anchor="iana-key-interop" title="Interoperability Considerations">

<t>There are no known interoperability concerns related to the use of the ‘key’ URI scheme.</t>

</section>
</section>
</section>
<section anchor="security" title="Security Considerations">

<t>As this document is in essence a profile of WebFinger <xref target="RFC7033"/>, all of the security considerations from that draft apply.</t>

<t>Because anyone with the symmetric secret key can use it for decryption, access to symmetric secret keys SHOULD require authorization.  Such authorization enforcement SHOULD be at the URI for the key, and MAY also be enforced on the WebFinger query.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml2rfc.ietf.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml2rfc.ietf.org/public/rfc/xml/rfc2119.xml' />
</reference>



<reference anchor='RFC3986'>

<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource.  This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier.  This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>

<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='214067' target='http://xml2rfc.ietf.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml2rfc.ietf.org/public/rfc/xml/rfc3986.xml' />
</reference>



<reference anchor='RFC4395'>

<front>
<title>Guidelines and Registration Procedures for New URI Schemes</title>
<author initials='T.' surname='Hansen' fullname='T. Hansen'>
<organization /></author>
<author initials='T.' surname='Hardie' fullname='T. Hardie'>
<organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'>
<organization /></author>
<date year='2006' month='February' />
<abstract>
<t>This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes.  It also updates the process and IANA registry for URI schemes.  It obsoletes both RFC 2717 and RFC 2718.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>

<seriesInfo name='RFC' value='4395' />
<format type='TXT' octets='31933' target='http://www.rfc-editor.org/rfc/rfc4395.txt' />
</reference>



<reference anchor='RFC5234'>

<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
<format type='TXT' octets='26359' target='http://www.rfc-editor.org/rfc/rfc5234.txt' />
</reference>



<reference anchor='RFC5890'>

<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5890' />
<format type='TXT' octets='54245' target='http://www.rfc-editor.org/rfc/rfc5890.txt' />
</reference>



<reference anchor='RFC5892'>

<front>
<title>The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).</t><t> It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5892' />
<format type='TXT' octets='187370' target='http://www.rfc-editor.org/rfc/rfc5892.txt' />
</reference>



<reference anchor='RFC7033'>

<front>
<title>WebFinger</title>
<author initials='P.' surname='Jones' fullname='P. Jones'>
<organization /></author>
<author initials='G.' surname='Salgueiro' fullname='G. Salgueiro'>
<organization /></author>
<author initials='M.' surname='Jones' fullname='M. Jones'>
<organization /></author>
<author initials='J.' surname='Smarr' fullname='J. Smarr'>
<organization /></author>
<date year='2013' month='September' />
<abstract>
<t>This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods.  WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.</t></abstract></front>

<seriesInfo name='RFC' value='7033' />
<format type='TXT' octets='61552' target='http://www.rfc-editor.org/rfc/rfc7033.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='I-D.barnes-acme'>
<front>
<title>Automatic Certificate Management Environment (ACME)</title>

<author initials='R' surname='Barnes' fullname='Richard Barnes'>
    <organization />
</author>

<author initials='P' surname='Eckersley' fullname='Peter Eckersley'>
    <organization />
</author>

<author initials='S' surname='Schoen' fullname='Seth Schoen'>
    <organization />
</author>

<author initials='A' surname='Halderman' fullname='Alex Halderman'>
    <organization />
</author>

<author initials='J' surname='Kasten' fullname='James Kasten'>
    <organization />
</author>

<date month='May' day='13' year='2015' />

<abstract><t>Certificates in the Web's X.509 PKI (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names.  Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate.  Today, this verification is done through a collection of ad hoc mechanisms.  This document describes a protocol that a certificate authority (CA) and an applicant can use to automate the process of verification and certificate issuance.  The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-barnes-acme-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-barnes-acme-02.txt' />
</reference>



<reference anchor='I-D.abiggs-saag-key-management-service'>
<front>
<title>Key Management Service Architecture</title>

<author initials='A' surname='Biggs' fullname='Andrew Biggs'>
    <organization />
</author>

<author initials='S' surname='Cooley' fullname='Shaun Cooley'>
    <organization />
</author>

<date month='July' day='3' year='2015' />

<abstract><t>In the interest of addressing pervasive threats to the confidentiality and integrity of online communications identified by the Internet community [I-D.barnes-pervasive-problem] this specification introduces an open architecture for the establishment, management, and secure distribution of cryptographic keys for use in the end-to-end (E2E) encryption of online communications and shared content.  This architecture allows for the independent deployment of dedicated key management services in a manner that supports the adoption of third-party communications and data sharing services by individuals and organizations that require full and exclusive discretion over the confidentiality of their data.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-abiggs-saag-key-management-service-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-abiggs-saag-key-management-service-02.txt' />
</reference>



<reference anchor='RFC4648'>

<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'>
<organization /></author>
<date year='2006' month='October' />
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='4648' />
<format type='TXT' octets='35491' target='http://www.rfc-editor.org/rfc/rfc4648.txt' />
</reference>



<reference anchor='RFC6234'>

<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
<author initials='D.' surname='Eastlake' fullname='D. Eastlake'>
<organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'>
<organization /></author>
<date year='2011' month='May' />
<abstract>
<t>Federal Information Processing Standard, FIPS</t></abstract></front>

<seriesInfo name='RFC' value='6234' />
<format type='TXT' octets='236573' target='http://www.rfc-editor.org/rfc/rfc6234.txt' />
</reference>



<reference anchor='RFC7517'>

<front>
<title>JSON Web Key (JWK)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'>
<organization /></author>
<date year='2015' month='May' />
<abstract>
<t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.  This specification also defines a JWK Set JSON data structure that represents a set of JWKs.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t></abstract></front>

<seriesInfo name='RFC' value='7517' />
<format type='TXT' octets='93906' target='http://www.rfc-editor.org/rfc/rfc7517.txt' />
</reference>



<reference anchor='RFC7565'>

<front>
<title>The 'acct' URI Scheme</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2015' month='May' />
<abstract>
<t>This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.</t></abstract></front>

<seriesInfo name='RFC' value='7565' />
<format type='TXT' octets='18244' target='http://www.rfc-editor.org/rfc/rfc7565.txt' />
</reference>




    </references>


<section anchor="determine-keyid" title="Determining a URI from Encrypted Content for Key Discovery">

<t>In most cases, the URI on which to perform key discovery will be known.  Chat rooms, conferencing services, and even shared files oft-times have a URI for addressing the resource.  Occasionally protected content will be disseminated in a manner that an explicit URI cannot be known or conveyed, but a domain name for where the content originated from might be known.  The following is an algorithm that can be used to determine a URI for discoverying the key is such cases.</t>

<t><list style="numbers">
  <t>Start with the encrypted content, C.</t>
  <t>Perform a SHA-2 <xref target="RFC6234"/> hash (e.g., SHA-256) over the encrypted content, to produce I’.</t>
  <t>Perform the URL-safe Base64 encoding <xref target="RFC4648"/> over I’ to produce I.</t>
  <t>Concatenate the following to produce the URI for key discovery, U:
  <list style="symbols">
      <t>The scheme “key:”;</t>
      <t>The name of the hash used in Step 2 (as registerd in the IANA Hash Function Textual Names registry; e.g., “sha-256”), H;</t>
      <t>The character “.” (U+002E FULL STOP);</t>
      <t>The base64url-encoded hash from Step 2, I;</t>
      <t>The character “@” (U+0040 COMMERCIAL AT); and</t>
      <t>The domain name, D</t>
    </list></t>
</list></t>

<t>Expressed as an algorithm:</t>

<figure><artwork><![CDATA[
U := "key:" || H || "." || BASE64URL(SHA2(C)) || "@" || D
]]></artwork></figure>

<t>For example, suppose one has some encrypted content for which they do not have the key, but is known to come from “erebor.example”.  If the SHA-256 hash of the encrypted content were (in hex):</t>

<figure><artwork><![CDATA[
1896bce72b5268ad695fabb0c8120464544b9f9663ac3777e9e9b13660063feb
]]></artwork></figure>

<t>The URI to use for key discovery is then:</t>

<figure><artwork><![CDATA[
key:sha-256.GJa85ytSaK1pX6uwyBIEZFRLn5ZjrDd36emxNmAGP_s@erebor.eample
]]></artwork></figure>

<t>From here, the receiver of the encrypted content uses the calculated URI to perform key discovery for a resource as described in <xref target="locate_res_key"/>.</t>

</section>


  </back>
</rfc>