<?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.3.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-privacy-token-01" category="exp" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.2.1 -->
  <front>
    <title abbrev="HTTP Privacy Token">The Privacy Token HTTP Authentication Scheme</title>
    <seriesInfo name="Internet-Draft" value="draft-privacy-token-01"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="F." surname="Jacobs" fullname="Frederic Jacobs">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <country>United States of America</country>
        </postal>
        <email>frederic.jacobs@apple.com</email>
      </address>
    </author>
    <author initials="C.A." surname="Wood" fullname="Christopher A. Wood">
      <organization>Cloudflare</organization>
      <address>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date year="2021" month="September" day="07"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This documents defines an authentication scheme for HTTP called Privacy Token.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/tfpauly/privacy-proxy"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document defines a new HTTP authentication scheme <xref target="RFC7235" format="default"/>
named "PrivacyToken".</t>
      <t>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 <xref target="RSASIG" format="default"/>.</t>
      <section anchor="requirements" numbered="true" toc="default">
        <name>Requirements</name>
        <t>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&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="struct" numbered="true" toc="default">
      <name>Privacy Token Structure</name>
      <t>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 <xref target="RSASIG" format="default"/>, and determines the
rest of the structure contents.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
struct {
    uint8_t version;
    uint8_t key_id[32];
    uint8_t message[32];
    uint8_t signature[Nk];
} Token;
]]></artwork>
      <t>The structure fields are defined as follows:</t>
      <ul spacing="normal">
        <li>"version" is a 1-octet integer. This document defines version 1.</li>
        <li>"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.</li>
        <li>"message" is a 32-octet random message that is signed by the
signature.</li>
        <li>"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.</li>
      </ul>
    </section>
    <section anchor="scheme" numbered="true" toc="default">
      <name>PrivacyToken Authentication Scheme</name>
      <t>The "PrivacyToken" authentication scheme defines one parameter, "token".
All unknown or unsupported parameters to "PrivacyToken" authentication
credentials MUST be ignored.</t>
      <t>The value of the "token" parameter is a Privacy Token Structure <xref target="struct" format="default"/>,
encoded using base64url encoding <xref target="RFC4648" format="default"/>.</t>
      <t>As an example, a Proxy-Authorization field in an HTTP request would look like:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
Proxy-Authorization: PrivacyToken token=abc...
]]></artwork>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document registers the "PrivacyToken" authentication scheme in the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
established by <xref target="RFC7235" format="default"/>.</t>
      <t>Authentication Scheme Name:  PrivacyToken</t>
      <t>Pointer to specification text:  <xref target="scheme" format="default"/> of this document</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC7235" target="https://www.rfc-editor.org/info/rfc7235">
        <front>
          <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
          <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems.  This document defines the HTTP Authentication framework.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7235"/>
        <seriesInfo name="DOI" value="10.17487/RFC7235"/>
      </reference>
      <reference anchor="RSASIG" target="https://www.ietf.org/archive/id/draft-irtf-cfrg-rsa-blind-signatures-02.txt">
        <front>
          <title>RSA Blind Signatures</title>
          <author initials="F." surname="Denis" fullname="Frank Denis">
            <organization>Fastly Inc.</organization>
          </author>
          <author initials="F." surname="Jacobs" fullname="Frederic Jacobs">
            <organization>Apple Inc.</organization>
          </author>
          <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
            <organization>Cloudflare</organization>
          </author>
          <date month="August" day="2" year="2021"/>
          <abstract>
            <t>   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.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-rsa-blind-signatures-02"/>
      </reference>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="S. Bradner">
            <organization/>
          </author>
          <date year="1997" month="March"/>
          <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.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="B. Leiba">
            <organization/>
          </author>
          <date year="2017" month="May"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/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"/>
        <seriesInfo name="DOI" value="10.17487/RFC4648"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAEy8N2EAA81X624bNxb+z6fgyn+SQjOwZCVxVBSoIieNu4ntWgqCIugG
nBlKYj0znJKcKFNDeZZ9ln2y/Q5J3Rpnd39uYCAcXs71O985SpKEOeVKOebz
leQ3Rn0Secfn+k7W/PV8fsMnrVvJ2qlcOKVrPstXspJMZJmRn8bhytErVui8
FhUEFkYsXNKEw8TRYXI6YBAkl9p0Yy4/N4ypxoy5M611w9PT56dDdie7tTbF
mF/WTppauuSCBDFmnaiLj6LUNYR30rJGjfkHp/M+t9o4IxcWq66ixW+MCRiu
zZjxhHH8U7WFjym/EW3Z+Z1g5VxXVXewq81yzCdNU0oYkKd+z0K4dGN+Xct4
dCPMHX8vwpNcOXgzbRtpnKp1n09FqRba1Erw509OB6NwS7e1I7ff1crJgs8c
AmG5XvBJJQ3i62/JSqgSAWnIoB8FKUtzXR158SrlP4tcZ/bAjVdGFiTl8OT/
w5VFtCz93Vt25FN0aJryScrfa10ceDRdGWWdblbSHJ16r6albotFKYw8VJWL
9Y8rKRpVLzPlbArwMJYkCRcZ/BY5vuYrZTkg2lYANVZyoWqYLmoujoFuPdA5
fA8gz0VZwtUjrKdBeqWKopSMnRBkjS7a3Eu4P1EHn5u/6N6r5rVcBx0Pm3B/
/7fbV9Nnw7Mnmw2j2BS8F83wVvTSKDrexyprVem40zyTvLV4gOWBcEnfjdGf
lUTJtBbx4jhkN9jqkokvHPVnMALxRPr4Qsmy6PO1citYnJWqLrhVy1q41kDc
SjiOAOk1+UOSOwYVn5D3RRdPeV4q8nsl6I6nAy8B1mUdvRKAXN4ipxwU0IcP
zqvTrWOqIMsXXTQ0iko9ZylgUImSlFkyGCh0x9FAGmRdhChkkvmAeEduZxP+
wrsy27pifbhnk9nlTz9cJhepMm6R5AuzTIwVifc72fltNxvE/uSE38o/WmWk
xxQlQ5ILnGjM8t7bd7N5rx/+51fXfn378pd3l7cvL2g9ez1582a3YPHG7PX1
uzcX+9X+5fT67duXVxfhMXb50RbrvZ38ihNwJe9d38wvr68mb3qIQYjKDn7C
yAgQCo9pjKRKFpYV0uZGZfjAmxfTm3/9czCKGBwOBs83m/hxPng2wscaoAra
dF128RM56hgKXSKZkAJkoH4a5UQJvCH/dqXXBC0jET/UzXHfmaEd5B5X9yfW
r1E8Ex47SYSOIhTZ3U2PsUwuwSdbkBKswW9Z5+IxcufRb5nYooUg9FBRxuM+
HwDzK5Wv9o+poAAy5s3xpQRzUHKCYAX8fQNUAVObTYhVgWibyquiwsMVF4Ar
D3zKNQEXPMbYly9fWDjg957xWmTt/KPbGvr90SbA91EVH86Gvx3vV9JasZRf
H+wQ/eHqDkebkIjvvVoP571Rngish08IFoEGNOmLfwxC5L1oUy/kaJDo3Enn
YbaU5r9EnA9SLyO4EEXkkK7oNEGgFM0BnkZWMa2BHFSIpa+8Lec1nn4l83Hd
+hgtwN9S1tKIgHuO6hs+efqoaVHk+UdIeUypB0T5fot5cy5e3iayzjVRyqzN
fpe5u/FX/i67y3qhufZ7gLwxO8oKQsi64GDMRfTwbBijZIAOXW0zFR20B0RJ
cNm74kXtPqOwq7so7AEoBom5pnB7WVFTyvkrtLpdFvqQErgzwN7rtupPuYVp
GPb2uCBUV6IjQkEY+/zsfNRHr+ZPBsOUIGQJzwb5a3Ttc0PGDU9H57h6+mwY
ymJ0+vwpR+umMAH2U0/zMKLCyEBooWDuTOSeUG3bNJj+9ullZGUkAfgAc2GC
lw670gO2CWTz4HxLxOMXmwD/4377jT69RTLmU2pmaNSocVC0i016AhZs67ua
qA+BaetoOmK7u24pMv9RG8tpnqqp5dkQAaLwZa2xnQZrP4my3eUpqt+rCBj5
JuPeR8bd9NkW42FAIIJ7OmpNyf0+bYVGMHo6OveNcOLnKPlZULr6XsnX84Tn
D98U4g8Mg95J9LfWLQ5Kre94qe7kOJDeAyLGxwn0/v0gsjxN00BYJ3wm89Zg
lOVTXVvwg/EPLaU1niCxV3rbGChOVLsXFBvfxgRfga8oGdvR47CI/VyzzT5V
NH8PtKGr2HaBfQItZGCSQQXXbZUh6MjGngHQBIO6HbFZXzs6h3EpewH9jR/P
Kq+CQvmX+0i6W0vyfq15AUpUdR6qBsAHzrwk5msAgjKRqZLCYf8w7lHDv+PD
f5ydPU4xr8JkNLccuaUfT9J4XogTh3BOVo1jR+5GMGhIDkVKY+/kavJ1qJWo
xVdTr0GLti6Sz/9WV350kaz3uqNfJfKz43OwpF0gqkAHfv/pkj8iKD3+RjHf
ep2m6zHgTCAJdhX47HCyJvw++PrK/xo5whxjN9pPTQQQ28h8Hx6yD7dRRoE/
Nrt5dBsC9m9Mp6kbdA8AAA==

-->

</rfc>
