The Privacy Token HTTP Authentication Scheme
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
tpauly@apple.com
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
frederic.jacobs@apple.com
Cloudflare
caw@heapingbits.net
Internet-Draft
This documents defines an authentication scheme for HTTP called Privacy Token.
Discussion Venues
Source for this draft and an issue tracker can be found at
.
Introduction
This document defines a new HTTP authentication scheme
named "PrivacyToken".
This scheme is built to be used to authenticate to proxies, using the
Proxy-Authorization header field, with a blind signature that allows a proxy
to verify that a client has a token signed by a particular key, but without
identifying the client. The initial version of this scheme is intended to be
used with RSA Blind Signatures .
Requirements
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 BCP 14 when, and only when, they
appear in all capitals, as shown here.
Privacy Token Structure
A privacy token is a structure that begins with a single byte that indicates
a version. This document defines version, 1, which indicates use of
private tokens based on RSA Blind Signatures , and determines the
rest of the structure contents.
The structure fields are defined as follows:
- "version" is a 1-octet integer. This document defines version 1.
- "key_id" is a collision-resistant hash that identifies the key used to produce
the signature. This is generated as SHA256(public_key), where public_key
is a DER-encoded SubjectPublicKeyInfo object carrying the public key.
- "message" is a 32-octet random message that is signed by the
signature.
- "signature" is a Nk-octet RSA Blind Signature that covers the
message. For version 1, Nk is indicated by size of the Token
structure and may be 256, 384, or 512.
These correspond to RSA 2048, 3072, and 4096 bit keys.
Clients implementing version 1 MUST support signature
sizes with Nk of 512 and 256.
PrivacyToken Authentication Scheme
The "PrivacyToken" authentication scheme defines one parameter, "token".
All unknown or unsupported parameters to "PrivacyToken" authentication
credentials MUST be ignored.
The value of the "token" parameter is a Privacy Token Structure ,
encoded using base64url encoding .
As an example, a Proxy-Authorization field in an HTTP request would look like:
Security Considerations
Note that the KeyID is only a hint to identify the public verification key. With
a sufficiently large number of public keys, KeyID collisions may occur.
By approximation, a KeyID collision between two distinct keys will occur
with probability sqrt(p * 2^33). In such cases, servers SHOULD attempt
verification using both keys.
IANA Considerations
This document registers the "PrivacyToken" authentication scheme in the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
established by .
Authentication Scheme Name: PrivacyToken
Pointer to specification text: of this document
Normative References
Hypertext Transfer Protocol (HTTP/1.1): Authentication
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.
RSA Blind Signatures
Fastly Inc.
Apple Inc.
Cloudflare
This document specifies the RSA-based blind signature scheme with
appendix (RSA-BSSA). RSA blind signatures were first introduced by
Chaum for untraceable payments [Chaum83]. It extends RSA-PSS
encoding specified in [RFC8017] to enable blind signature support.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/chris-wood/draft-wood-cfrg-blind-signatures.
Key words for use in RFCs to Indicate Requirement Levels
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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
The Base16, Base32, and Base64 Data Encodings
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]