The di (DIGEST) URI Scheme
draft-hallambaker-digesturi-01

Abstract

A URI scheme for referencing static data abjects by means of a cryptographic digest mechanism is specified. The format is designed to resist content type substitution attacks and supports a choice of digest algorithms.

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 April 05, 2012.

Copyright Notice

Copyright (c) 2011 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.

Table of Contents

• 1. Definitions
• 1.1. Requirements Language
• 1.2. Defined Terms
• 2. Requirements
• 2.1. Examples of Use
• 2.1.1. Simple Digest
• 2.1.2. Digest with Meta-Data
• 2.1.3. Digest with Locator
• 2.1.4. Digest with Decryption Key
• 3. The di (DIGEST) URI TYPE
• 3.1. Syntax
• 3.1.1. Encoding Considerations
• 3.1.1.1. Use of base64url Encoding
• 3.1.1.2. Query Parameter Encoding
• 3.2. Semantics
• 3.2.1. Digest Algorithms
• 3.2.2. Parameters
• 3.2.2.1. Content Type (ct)
• 3.2.2.2. HTTP Locator (http & https)
• 3.2.2.3. Encryption and MIME Encryption Specifiers (enc & menc)
• 4. Security Considerations
• 4.1. Integrity
• 4.2. Confidentiality
• 4.3. Weak Digest Algorithm
• 5. IANA Considerations
• 5.1. Assignment of URI Scheme di
• 5.2. Assignment of Well Known URI prefix di
• 5.3. Specification of Additional Cryptographic Algorithms
• 5.4. Creation of di parameter registry
• 6. References
• 6.1. Normative References
• 6.2. Non Normative References
• Appendix A. Test Vectors
• Appendix A.1. Example: Hello World !
• Authors' Addresses

1. Definitions

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 RFC 2119 [RFC2119].

1.2. Defined Terms

The following terms are used in this document:

URI

2. Requirements

Provides a strong reference to a static data object.

Does not provide a means of resolution.

Allows an authenticated data source to provide an authenticated reference to a static data object.

Intended applications include creating references from

• Web pages delivered over HTTP/TLS
• DNS resource records signed using DNSSEC
• Data values embedded in certificates, CRLs, OCSP tokens and other signed data objects.

2.1. Examples of Use

2.1.1. Simple Digest

For example, the following digest URI specifies a reference to the text "Hello World !" using the SHA-2 algorithm with 256 bit output:

di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

2.1.2. Digest with Meta-Data

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:

di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain

2.1.3. Digest with Locator

A digest identifier MAY provide a location from which the referenced content MAY be available. Note however that since it is statistically unlikely that a given identifier will correspond to more than one content sequence, the actual location from which the data is retrieved is immaterial.

di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?http=di.example.com

The corresponding content MAY be retrieved from the URL:

http://di.example.com/.well-known/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

A digest identifier MAY specify multiple locations from which the content MAY be obtained:

di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc? http=one.example.com&http=two.example.com

Asserts that the content may be retrieved from either of the following URIs:

http://one.example.com/.well-known/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc http://two.example.com/.well-known/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

2.1.4. Digest with Decryption Key

A digest identifier MAY provide a key for decrypting the referenced data.

di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc? enc=aes-cbc:Fw3x20nEKfq6FDGzq7ttIQ

If the mechanism outlined on the list but not here is used, the digest portion of the URI may be truncated at 128 bits and a value generated from the key portion used to defeat birthday attack:

di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=aes-cbc:Fw3x20nEKfq6FDGzq7ttIQ

3. The di (DIGEST) URI TYPE

3.1. Syntax

The DIGEST URI Type has the following format:

"di:" algorithm ":" digest [ "?" tag "=" value [ "&" tag "=" value ] * ]

3.1.1. Encoding Considerations

3.1.1.1. Use of base64url Encoding

Section 2.2 of [RFC4395] states [URI schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." and ".." (dot-segments).]

Consequently the encoding of the digest value is effected using the base64url encoding specified in Section 5 of [RFC4648] which avoids the use of the forward slash '/' character.

3.1.1.2. Query Parameter Encoding

The query segment of a URI is NOT hierarchical. Thus escape encoding of slash '/' characters is NOT required.

Section 3.4 of [RFC3986] states [The characters slash ("/") and question mark ("?") may represent data within the query component.]

Consequently no special escaping mechanism is required for the query parameter portion of the URI. URI escaping is however frequently imposed automatically by scripting environments. Thus to ensure interoperability, implementations SHOULD NOT generate URIs that employ URI character escaping and implementations MUST accept and URIs that employ URI character escaping.

3.2. Semantics

3.2.1. Digest Algorithms

Implementations MUST support the sha-256 algorithm as specified in [RFC4055].

Implementations MAY support other algorithms specified in the Data Structure for the Security Suitability of Cryptographic Algorithms registry 'Cryptographic Algorithms' [RFC5698].

3.2.2. Parameters

3.2.2.1. Content Type (ct)

The Content Type "ct" parameter specifies the MIME Content Type of the associated data as defined in [RFC4288]

3.2.2.2. HTTP Locator (http & https)

The http and https parameters are used to specify a possible means of resolving the referenced content. Mulltiple locator parameters MAY be used to specify alternative sources for accessing the content.

The http and https parameters take a single argument, the domain name to be used for resolution. To permit the use of digest URIs in ASCII-only environments, the ASCII encoding (aka punycode) of the domain name MUST be used.

To resolve such a location reference, a client first transforms the digest URI to obtain a http or https url as follows:

URL = prefix + domain + "/.well-known/" + digest

Where:

prefix

Is the string "http://" for the http parameter type and is the string "https://" for the https parameter type.

domain

Is the value associated with the parameter.

digest

Is the digest portion of the digest URI.

Implementations MUST NOT disclose any other data. In particular implementations MUST NOT disclose the query parameter portion of the URI.

3.2.2.3. Encryption and MIME Encryption Specifiers (enc & menc)

The encryption and MIME encryption specifiers are used to provide a means of obtaining the plaintext of a reference to encrypted content.

The enc specifier is used when the encrypted object consists of the encrypted content alone. The menc spcifier is used when the encrypted object consists of a MIME header containing metadata followed by the binary object encoding.

The encryption specifiers both take an agrument of the form:

algorithm ":" base64url (key) [":" base64url (iv)]

Where

algorithm

Is the algorithm used to encrypt the associated content

key

Is the value of the cryptographic key

iv (optional)

Is the value of the cryptographic Initialization Vector.

If the IV is not spcified for a block cipher mode that requires one, the IV MUST be prepended to the encrypted content.

[Actually the IV does not provide any additional security for this application but explaining the reason would be more effort than it is worth and what I really care about is saving bytes in the identifier, not the resulting data package.]

4. Security Considerations

4.1. Integrity

No secret information is required to generate a DIGEST URI. Therefore a DIGEST URI only provides a proof of integrity for the referenced object and the proof of integrity provided is only as good as the proof of integrity for the DIGEST URI value.

4.2. Confidentiality

Disclosure of a DIGEST URI value does not necessarily entail disclosure of the referenced object but may enable an attacker to determine the contents of the referenced object by reference to a search engine or other data repository.

4.3. Weak Digest Algorithm

[The digest algorithm MUST be strong]

[For most use cases collision resistance is a requirement]

5. IANA Considerations

5.1. Assignment of URI Scheme di

The procedures for registration of a URI scheme are specified in RFC 4395 [RFC4395]. The following is the proposed assignment template.

URI scheme name: di

Status: Permanent

URI scheme syntax. See Section 3.1

URI scheme semantics. See Section 3.2

Encoding considerations. See Section 3.1.1

Applications/protocols that use this URI scheme name: General applicability with initial use cases provided by WEBSEC and DECADE

Interoperability considerations: TBS

Security considerations: See Section 4

Contact: IETF / Phillip Hallam-Baker

Author/Change controller: IETF / Phillip Hallam-Baker

References: As specified in this document

5.2. Assignment of Well Known URI prefix di

The procedures for registration of a Well Known URI entry are specified in RFC 5785 [RFC5785]. The following is the proposed assignment template.

URI suffix: di

Change controller: IETF

Specification document(s): This document

Related information: None

5.3. Specification of Additional Cryptographic Algorithms

[Added in case it is decided to specify truncated forms of the cryptographic digests]

The procedures for registration of a Cryptographic Algorithm identifier are specified in RFC 5698 [RFC5698]. The following is the proposed assignment template.

Textual name of the algorithm: SHA-128

OID of the algorithm: [TBS]

Reference: This document.

5.4. Creation of di parameter registry

This specification creates a new IANA registry entitled "DI URI Parameter Definitions".

The policy for future assignments to the registry is "RFC Required".

6. References

6.1. Normative References

6.2. Non Normative References

Appendix A. Test Vectors

Appendix A.1. Example: Hello World !

The Digest URI of the text file "Hello World !" is computed as follows:

• Scheme di
• Algorithm Identifier: sha-256
• sha-256 ("Hello World !") 07 f2 bd ef 34 ed 16 e3 a1 ba 0d bb 7e 47 b8 fd 98 1c e0 cc b3 e1 bf e5 64 d8 2c 42 3c ba 7e 47
• BASE64URI (sha-256 ("Hello World !")): B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
• Content Type Parameter 'text/plain' ct=text/plain

Depending on the context, the digest URI MAY be specified using the digest value alone or the digest valur plus content type parameter:

di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain

Authors' Addresses