One document matched: draft-hallambaker-decade-ni-params-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5698.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3642 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3642.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!ENTITY RFC5395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5395.xml">
<!-- Defines the URI Syntax -->
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!-- Design guide -->
<!ENTITY RFC4395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4395.xml">
<!-- Defines the well known services URL positions -->
<!ENTITY RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!-- Defines the URI safe BASE64 encoding mechanism -->
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!-- Defines the Cryptographic Algorithm registry-->
<!ENTITY RFC5698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5698.xml">
<!-- Defines sha-256 identifier -->
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!--MIME Media Type Registry -->
<!ENTITY RFC4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-hallambaker-decade-ni-params-01" ipr="trust200902">
<front>
<title abbrev="ni Scheme Parameters">The Named Information (ni) URI Scheme: Parameters</title>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker">
<organization>Comodo Group Inc.</organization>
<address>
<email>philliph@comodo.com</email>
</address>
</author>
<author fullname="Rob Stradling" initials="R. N." surname="Stradling">
<organization>Comodo CA Ltd.</organization>
<address>
<email>rob.stradling@comodo.com</email>
</address>
</author>
<author fullname="Stephen Farrell" initials="S."
surname="Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Dublin</city>
<region></region>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dirk Kutscher" initials="D."
surname="Kutscher">
<organization>NEC</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<!-- Reorder these if your country does things differently -->
<city>Heidelberg</city>
<region></region>
<code></code>
<country>Germany</country>
</postal>
<phone></phone>
<email>kutscher@neclab.eu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Boerje Ohlman" initials="B" surname="Ohlman">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<code> S-16480</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>Borje.Ohlman@ericsson.com</email>
</address>
</author>
<date month="April" year="2012" />
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Cryptography</keyword>
<keyword>URI</keyword>
<abstract>
<t>
This document specifies an additional hash algorithm and
parameters that may be used in the query string of ni URIs.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The ni URI scheme <xref target="nischeme"/> supports extensibility
in terms of the algorithm used to derive a value (normally, but not
always a strong digest algorithm) and via support for a query-string
thay can contain a list of key=value pairs. This document defines
some uses for both of these extensibility points and creates IANA
registries that can be used to register additional algorithms and
key strings for use in the
query part of an ni name.
</t>
<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">RFC 2119</xref>.
</t>
<t>[[Comments are included in double-square brackets, like this.]]</t>
<t>[[Note that the features here are less mature than the
specification in the <xref target="nischeme"/> document. The intent is to develop these
as required for the various use-cases as we go. If something from
here appears to be as widely useful as the core ni scheme, then
the authors are willing to move features from this document to
the core document. We are also happy to incoroporate features
to handle additional use-cases here if those arise.]]
</t>
</section>
<section title="Additional Algorithm">
<t>This section specifies an additional algorithm that MAY be used
to handle hashes calculated over dynamically
changing objects.
</t>
<section title="Hashed Dynamic Content" anchor="dynamic">
<t>The ni scheme involves calculating digest values over content objects.
That works fine with static objects but is problematic for objects
whose value is dynamically generated. In this section we define an
algorithm that supports the same core "name-data integrity" service
for dynamic objects. The basic idea is simply to include a hash of
a public key in the ni name, and then for the dynamic object to
be digitally signed with the corresponding private key. With a
little work to handle the various useful formats, this allows a
client that is presented with the ni name and the signed object
to verify the binding between the name and the object data.
</t>
<t>Note that the signature scheme used might or might not
provide additional information, e.g. a name for the signer.
Applications might benefit from that, but it is not required
in order to provide the core "name-data integrity" service
for dynamically generated objects.
</t>
<t>Since there are a number of digital signing schemes that
might be used, our approach is to define a new algorithm for
the ni scheme that takes as input a specific public key
encoded in a specific way, and runs that through a digest
function. That is, the ni algorithm fields will specify
both a public key algorithm and a digest algorithm, just
as is done with digital signature algorithm identifiers.
</t>
<t>
Since it is possible that an ni algorithm might also
be defined where the value contains an actual
digital signature we need to be careful to ensure
there is no ambiguity. However, since the lengths
of signatures and hash outputs are (with current
algorithms) always different, we could use that
fact to disambigute between rsa-with-sha256 meaning
the value is a sha256 hash of an rsa public key and
the alternative meaning the the value is an
rsa-with-sha256 signature. However, we prefer to
use a new algorithm (see <xref target="IANAcons"/> to
disambiguate these.
</t>
<t>
We define one such algorithm, "pk-rsa-with-sha256" that
takes an RSA public key as input, with the input
bits formatted as a SubjectPublicKeyInfo as defined
by <xref target="nischeme"/> Note that this
does not mean that one cannot use e.g. PGP to
sign the actual object. It means that if you do
use PGP then in order to verify the name-data
integrity, the client needs to extract the signer's
PGP public key, then reformat that as a
SubjectPublicKeyInfo and then run that through
the sha-256 algorithm and make the relevant
comparison.
</t>
</section>
</section>
<section title="Query String Paramaeters">
<t>This section defines query string parameters that MAY be
used to indicate the type of content hashed or to specify
additional locations from which the named content can be
retrieved. We also define a way to specify how an
encryption key MAY be included in an ni URI that allows
for decryption of object content.</t>
<section title="Digest with Content Type">
<t>
The semantics of a digest being used to establish a secure
reference from an authenticated source to an external source
may be a function of associated meta data such as the content
type. This data MAY be specified by means of a parameter:
</t>
<t>ni:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain</t>
<t>
The Content Type "ct" parameter specifies the MIME Content Type of
the associated data as defined in <xref target="RFC4288" />
</t>
</section>
<section title="Additional Locators">
<t>
In addition to the algorithm for mapping an ni URI to an HTTP(S) URL
specified in the ni scheme definition <xref target="nischeme"/>, an ni name MAY provide
information about additional locations from which the referenced content
might be available. This is done via the inclusion of an "alt" or "alts"
key in the query string that can supply more values for the authority
field when constructing the HTTP or HTTPS URL. For example:
</t>
<t>ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?alt=ni.example.net</t>
<t>
The corresponding content might then also be retrieved from the URL:
</t>
<t>
http://ni.example.net/.well-known/ni/sha-256/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
</t>
<t>
A ni name MAY specify multiple locations from which the
content MAY be obtained:
</t>
<t>
ni:///sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?alt=one.example.com&alt=two.example.com
</t>
<t>
The above example asserts that the content might be retrieved from either of the following URIs:
</t>
<t>
http://one.example.com/.well-known/ni/sha-256/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
</t>
<t>
http://two.example.com/.well-known/ni/sha-256/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
</t>
<t>The "alt" parameter means "use HTTP" and the "alts" parameter means
use "HTTPS". </t>
<t>
The alt and alts parameters are used to specify a possible
means of resolving the referenced content. Multiple
locator parameters MAY be used to specify alternative sources
for accessing the content.
</t>
<t>
The alt and alts parameters take a single argument, the
authority to be used for resolution. To permit the use
of ni URIs in ASCII-only environments, the ASCII encoding
(aka punycode) of the domain name MUST be used. [[Note sure
if this is needed/correct.]]
</t>
</section>
<section title="Digest with Decryption Key">
<t>
An ni name MAY provide a key for decrypting the referenced
data. The use-case here is where the referenced data has be
distributed (somehow) in ciphertext form, probably with little
or no access control required (since the data is strongly
encrypted) and where a client wishing to decrypt that data
subsequently acquires an ni name for that data that provides
the required decryption key.
</t>
<t>
Clearly, to be of any benefit, access to the ni name that
includes the decryption key MUST be controlled so that
only the appropriate clients get access to the ni name
and of course this ni name MUST be strongly protected
via some (probably mutual) authentication and confidentiality
service such as can be provided by TLS. <xref target="RFC5246"/>
</t>
<t>ni///:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?enc=aes-cbc:Fw3x20nEKfq6FDGzq7ttIQ</t>
<t>
The "enc" specifier is used when the encrypted object consists of
the ciphertext alone. The "menc" spcifier is used when the
encrypted object consists of a MIME header containing metadata
followed by the binary object encoding. [[Note: there may be more
needed here.]]
</t>
<t>
The encryption specifiers both take an agrument of the form:
</t>
<t>
algorithm ":" base64url (key) [":" base64url (iv)]
</t>
<t>Where</t>
<t>
<list style="hanging">
<t hangText="algorithm">
Is the algorithm used to encrypt the associated content
</t>
<t hangText="key">
Is the value of the cryptographic key
</t>
<t hangText="iv (optional)">
Is the value of the cryptographic Initialization Vector.
</t>
<t>
If the IV is not spcified for a block cipher mode that
requires one, the IV MUST be prepended to the encrypted
content.
</t>
<t>
[[Note: Actually the IV does not provide any additional security for
this application but explaining the reason might be more
effort than it is worth and what we really care about is saving
bytes in the identifier, not the resulting data package.]
</t>
</list>
</t>
</section>
<section title="Wrapped URL" anchor="wrapped">
<t>The "ni" URI form can usefully "wrap" an HTTP URL in order to provide
a way for an HTTP client that has securely received an "ni" URI (e.g. embedded
within some HTML received via a TLS session) to validate the referred-to
content, at the same level of security as the embedding page. A good use
for this might be to provide data integrity for javascript or other files
referred to by an HTML page.</t>
<t>To achieve the above, we define the "url" parameter which allows
for the inclusion of any URL within the query string. The intent is that
the content accessed via that URL match the hash in the ni name.</t>
<t>[[TBD: say how to encode the URL]]</t>
</section>
</section>
<section title="Security Considerations" anchor="sec_cons">
<t>[[TBD for sure.]]</t>
</section>
<section title="IANA Considerations" anchor="IANAcons">
<section title="Additional algorithm in RFCXXXX registry">
<t>
We request IANA to add a new entry to the hash algorithm registry created in
[nischeme], Section 9.3, as follows:
</t>
<figure>
<artwork>
<![CDATA[
ID: 7
Hash string name: pk-rsa-with-sha256
Value length: 256
Reference: [RFC-THIS]
]]>
</artwork>
</figure>
</section>
<section title="Creation of ni parameter registry">
<t>
This specification creates a new IANA registry entitled "Named Information URI
Parameter Definitions".
</t>
<t>
The policy for future assignments to the registry is "RFC Required".
</t>
<t>
The initial contents of the registry are:
</t>
<figure>
<artwork>
<![CDATA[
Parameter Meaning Reference
----------- -------------------------------------------- ---------
ct Content Type [RFC-THIS]
alt Additional HTTP Locator [RFC-THIS]
alts Additional HTTPS Locator [RFC-THIS]
enc Encryption Key [RFC-THIS]
menc Encryption Key [RFC-THIS]
url Wrapped URL [RFC-THIS]]]>
</artwork>
</figure>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='nischeme'>
<front>
<title>Naming things with hashes</title>
<author initials='S' surname='Farrell' fullname='Stephen Farrell'>
<organization />
</author>
<author initials='D' surname='Kutscher' fullname='Dirk Kutscher'>
<organization />
</author>
<author initials='B' surname='Ohlman' fullname='Borje Ohlman'>
<organization />
</author>
<author initials='A' surname='Keranen' fullname='Ari Keranen'>
<organization />
</author>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'/>
<date month='April' year='2012' />
</front>
<seriesInfo name='Internet-Draft' value='draft-farrell-decade-ni-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-farrell-decade-ni-03.txt' />
</reference>
<!--&RFC1035;-->
&RFC2119;
<!--&RFC4033;-->
&RFC4288;
&RFC5246;
<!--&RFC5395;-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:35:57 |