Cryptovolense
draft-steele-spice-cryptovolense-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Orie Steele | ||
| Last updated | 2024-01-13 (Latest revision 2024-01-02) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-steele-spice-cryptovolense-00
Secure Patterns for Internet CrEdentials O. Steele
Internet-Draft Transmute
Intended status: Informational 2 January 2024
Expires: 5 July 2024
Cryptovolense
draft-steele-spice-cryptovolense-00
Abstract
Digital presentations enable a holder of digital credentials to
present proofs to a verifier. Using QR Codes for digital
presentations introduces challenges regarding maximum transmission
size, error correction and confidentiality. This document describes
a generic optical transmission protocol suitable for digital
credential presentations.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://OR13.github.io/draft-steele-spice-cryptovolense/draft-steele-
spice-cryptovolense.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-steele-spice-
cryptovolense/.
Discussion of this document takes place on the Secure Patterns for
Internet CrEdentials Working Group mailing list
(mailto:spice@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/spice/. Subscribe at
https://www.ietf.org/mailman/listinfo/spice/.
Source for this draft and an issue tracker can be found at
https://github.com/OR13/draft-steele-spice-cryptovolense.
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 https://datatracker.ietf.org/drafts/current/.
Steele Expires 5 July 2024 [Page 1]
Internet-Draft cryptovolense January 2024
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 5 July 2024.
Copyright Notice
Copyright (c) 2024 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Transmission . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Profile Discovery . . . . . . . . . . . . . . . . . . . . . . 7
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
7.1. transmute.codes . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8.1. Public Key Discovery . . . . . . . . . . . . . . . . . . 8
8.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . 8
8.3. Context Binding . . . . . . . . . . . . . . . . . . . . . 9
8.4. Browser APIs . . . . . . . . . . . . . . . . . . . . . . 9
8.5. Proximal and Remote Presentations . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
Steele Expires 5 July 2024 [Page 2]
Internet-Draft cryptovolense January 2024
1. Introduction
The data density limitations of a single QR Code can be overcome
through the use of animated QR Codes, where each frame of the
animation is a valid QR Code.
Because QR Codes were originally developed to support transmission of
text, not binary, it is desirable to apply specific base encoding,
compression and forward error correction, to provide a generic binary
content transmission capability through animated qr codes.
[RFC6330] describes a fully specified error correction scheme,
[RFC9285] describes an optimal base encoding for QR Codes, and
[RFC2397] describes a content identifier scheme suitable for encoding
binary data of a known content type.
This document describes how to use these ingredients to transmit
arbitrary content of a known type from a sender to a receiver through
the presentation of an animated QR Code by the sender to the
receiver.
Steele Expires 5 July 2024 [Page 3]
Internet-Draft cryptovolense January 2024
.----------.
holder --> | Content |
'----+-----'
|
v
.----+-------.
/ Encryption /
'------+-----'
|
v
.----+-----.
| Data URL |
'----+-----'
|
v
.----+-----------.
/ Fountain Codes /
'------+---------'
|
v
.----+--------.
/ Compression /
'------+------'
|
v
.----+-----.
/ Base45 /
'------+---'
|
v
.----+-------------.
| Animated QR Code | --> verifier
'------------------'
2. Terminology
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
message: The data (bytes / octets) to be transmitted.
message data url: The message encoded as a data URL, including its
content type.
transmission configuration: The raptor q details necessary to
Steele Expires 5 July 2024 [Page 4]
Internet-Draft cryptovolense January 2024
recover the message data url from a series of raptor q packets.
transmission packets: The raptor q packets produced from the message
data url interpretted as bytes.
compressed transmission packets: The transmission packets compressed
by a protocol parameter "compression algorithm".
base encoded transmission configuration: The base45 encoded
transmission configuration (without compression).
base encoded transmission packets: The base45 encoded compressed
transmission packets.
qr encoded transmission configuration: The base encoded transmission
configuration expressed as an image, for example image/svg+xml or
image/jpeg.
qr encoded transmission packets: The base encoded transmission
packets expressed as images, for example image/svg+xml or image/
jpeg.
transmission images: The unordered set of images composed of qr
encoded transmission configuration and qr encoded transmission
packets.
animated transmission image: An animated image, constructed from a
frame and duration for each of the transmission images,
represented for example as image/gif, or image/webp.
3. Usage
Although this document describes a generic data transmission
capability, the primary motivating use case for developing this
approach is transmission of large encrypted credential presentations,
post quantum capable public keys, and hybrid public keys.
Large binary data can quickly exceed the limitations of single QR
Code presentations, motivating a need for animated qr codes and
forward error correction capabilities.
4. Transmission
The sender MUST prepare their message for transmission by first
encoding their data as a message data url according to the process
described in [RFC2397].
Steele Expires 5 July 2024 [Page 5]
Internet-Draft cryptovolense January 2024
Next, the message data url MUST be converted to bytes, and the Raptor
Q encoding algorithm described in [RFC6330] must be applied.
The result is transmission configuration as bytes, and transmission
packets as bytes.
Edtiors note: We might need to define a content type for transmission
configuration, ending in +json or +cbor.
In cases where this protocol is used with static transmission
configuration, those details may be hard coded or discovered through
some reliable out of band mechansism.
Editors note: We may want to define fountain code agility, such that
coding schemes other than RaptorQ can be used.
Next, the packet bytes produced by [RFC6330] are compressed using
gzip as described in [RFC1952] or zstd as described in [RFC8878].
Edtior note: Need to decide if compression agility is valuable, how
to signal it, or which compression scheme to require.
Next, the transmission configuration and compressed transmission
packets are encoded using [RFC9285].
Finally, the base encoded transmission configuration and base encoded
transmission packets are converted to QR Codes, and each of the
transmission images is used as a frame in the resulting animated QR
Code.
5. Recovery
The receiver MUST read the frames of the animated transmission image,
storing each unique base45 encoded text string.
Once the transmission configuration has been recovered, the recovery
of the original message data url can be attempted using [RFC6330].
The recovery process ends when either:
1. a timeout set by the verifier is reached, a failure result
indicated by a null / nil MUST be returned.
2. a data url is recovered successfully, a valid Data URL MUST be
returned.
Steele Expires 5 July 2024 [Page 6]
Internet-Draft cryptovolense January 2024
6. Profile Discovery
The transmission configuration MAY include additional data elements,
for example the compression algorithm, or public key discovery
related meta data in the case that authenticated encryption capable
content types are transmitted, for example auth mode hpke as
described in [I-D.draft-rha-jose-hpke-encrypt] or
[I-D.draft-ietf-cose-hpke].
In the case the transmission configuration contains parameters beyond
what are required by [RFC6330], it should be encoded as a data url,
with a content type expressing the serialization of the parameters,
for example appliation/json or application/cbor.
data:application/cose;base64,SGVsb...xkIQ==
Figure 1: Example Encrypted Data URL
The transmission configuration, and other protocol parameters, such
as supported compression or encryption algorithms MAY be discovered
out of band.
7. Implementation Status
Note to RFC Editor: Please remove this section as well as references
to [BCP205] before AUTH48.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [BCP205].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [BCP205], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Steele Expires 5 July 2024 [Page 7]
Internet-Draft cryptovolense January 2024
7.1. transmute.codes
An open-source implementation was initiated and is maintained by the
Transmute Industries Inc. - Transmute, and is available at:
* transmute-industries/transmute.codes (https://github.com/
transmute-industries/transmute.codes)
An application demonstrating these concepts is available at
https://transmute.codes (https://transmute.codes).
The code's level of maturity is considered to be "prototype".
The current version ('main') implements the transmission and recovery
algorithms of this draft.
The project and all corresponding code and data maintained on GitHub
are provided under the Apache License, version 2.
The implementation uses a wasm module, built from this rust
implementation of RaptorQ [RFC6330], maintained at: - cberner/raptorq
(https://github.com/cberner/raptorq)
Several other dependencies are used, but the RaptorQ implementation
is the most relevant.
8. Security Considerations
TODO Security
8.1. Public Key Discovery
When encrypting data to a public key, it is important that the sender
believe the corrosponding private key is under exclusive control of
the receiver. There are many different mechanisms for delivering a
public key to a sender, such that the sender can be assured of this
property. A detailed analysis of identifier to public key binding,
and recommendations suitable for use cases is outside the scope of
this document.
8.2. Encryption
Note that [RFC6330] and [RFC9285] and Base64 as used in [RFC2397] are
encoding schemes, NOT encryption schemes, and they provide no
confidentiality.
Steele Expires 5 July 2024 [Page 8]
Internet-Draft cryptovolense January 2024
Because the data that is encoded within QR Codes is visible to any
system that can see the images, any sensitive data should be
encrypted before transmission.
In the context of this specification, this means the message data url
MUST include a content type for an encryption envelope, suitable for
the confientiality requirements of the use case.
In the case that an encrypted message is transmitted as a Data URL,
the content type of the message MUST be registered
[IANA.media-types], for example application/jose might be used to
transmit a JSON Web Encryption as described in [RFC7516], and
application/cose might be used to transmit a cose encrypt envelope as
described in [RFC9053].
8.3. Context Binding
It is recommended that encryption envelopes supporting multiple key
agreement and content encryption schemes ensure that ciphertexts
commit to the specific keys and algorithms used.
Additional context binding such as external aad in HPKE might be
useful to achieve this.
8.4. Browser APIs
WICG/identity-credential (https://github.com/WICG/identity-
credential) discusses a similar proposal related to invoking a
presentation from a mobile device running a mobile operating system,
to a browser requesting a presentation on behalf of a web origin.
It is possible that some content types could be shared between this
browser API use case, and the QR Code transport use case.
8.5. Proximal and Remote Presentations
It is possible to transmit animated QR Codes from a holder's handheld
device to a verifier's camera / scanner, and to transmit animated QR
Codes over an established video channel. Additional security
guidance is required regarding replay attack and proxy attacks on in
person and remote presentations, that is beyond the scope of this
document.
9. IANA Considerations
This document has no IANA actions.
10. References
Steele Expires 5 July 2024 [Page 9]
Internet-Draft cryptovolense January 2024
10.1. Normative References
[IANA.media-types]
IANA, "Media Types",
<http://www.iana.org/assignments/media-types>.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/rfc/rfc1952>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998,
<https://www.rfc-editor.org/rfc/rfc2397>.
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
and L. Minder, "RaptorQ Forward Error Correction Scheme
for Object Delivery", RFC 6330, DOI 10.17487/RFC6330,
August 2011, <https://www.rfc-editor.org/rfc/rfc6330>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
and the 'application/zstd' Media Type", RFC 8878,
DOI 10.17487/RFC8878, February 2021,
<https://www.rfc-editor.org/rfc/rfc8878>.
[RFC9285] Fältström, P., Ljunggren, F., and D.W. van Gulik, "The
Base45 Data Encoding", RFC 9285, DOI 10.17487/RFC9285,
August 2022, <https://www.rfc-editor.org/rfc/rfc9285>.
10.2. Informative References
[BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[I-D.draft-ietf-cose-hpke]
Tschofenig, H., Steele, O., Daisuke, A., and L. Lundblade,
"Use of Hybrid Public-Key Encryption (HPKE) with CBOR
Object Signing and Encryption (COSE)", Work in Progress,
Steele Expires 5 July 2024 [Page 10]
Internet-Draft cryptovolense January 2024
Internet-Draft, draft-ietf-cose-hpke-07, 22 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
hpke-07>.
[I-D.draft-rha-jose-hpke-encrypt]
Reddy.K, T., Tschofenig, H., Banerjee, A., Steele, O., and
M. B. Jones, "Use of Hybrid Public-Key Encryption (HPKE)
with Javascript Object Signing and Encryption (JOSE)",
Work in Progress, Internet-Draft, draft-rha-jose-hpke-
encrypt-01, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-rha-jose-
hpke-encrypt-01>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/rfc/rfc7516>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
Acknowledgments
TODO acknowledge.
Author's Address
Orie Steele
Transmute
Email: orie@transmute.industries
Steele Expires 5 July 2024 [Page 11]