]> Transmute

orie@transmute.industries

Security Secure Patterns for Internet CrEdentials fountain codes animated qr codes digital presentations hpke 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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. describes a fully specified error correction scheme, describes an optimal base encoding for QR Codes, and 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. | Content | '----+-----' | v .----+-------. / Encryption / '------+-----' | v .----+-----. | Data URL | '----+-----' | v .----+-----------. / Fountain Codes / '------+---------' | v .----+--------. / Compression / '------+------' | v .----+-----. / Base45 / '------+---' | v .----+-------------. | Animated QR Code | --> verifier '------------------' ]]>

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 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 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.

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.

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 . Next, the message data url MUST be converted to bytes, and the Raptor Q encoding algorithm described in 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 are compressed using gzip as described in or zstd as described in . 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 . 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.

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 . 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.

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 or . In the case the transmission configuration contains parameters beyond what are required by , 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.

Example Encrypted Data URL

The transmission configuration, and other protocol parameters, such as supported compression or encryption algorithms MAY be discovered out of band.

Implementation Status Note to RFC Editor: Please remove this section as well as references to 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 . 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 , "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".

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

An application demonstrating these concepts is available at 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 , maintained at: - cberner/raptorq Several other dependencies are used, but the RaptorQ implementation is the most relevant.

Security Considerations TODO Security

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.

Encryption Note that and and Base64 as used in are encoding schemes, NOT encryption schemes, and they provide no confidentiality. 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 , for example application/jose might be used to transmit a JSON Web Encryption as described in , and application/cose might be used to transmit a cose encrypt envelope as described in .

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.

Browser APIs 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.

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.

IANA Considerations This document has no IANA actions.

References Normative References A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK] This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects. RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required. The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK] This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes. This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME. Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. This document replaces and obsoletes RFC 8478. IANA 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. 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. Informative References JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Transmute Security Theory LLC This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with COSE. Nokia Nokia Transmute independent This specification defines Hybrid public-key encryption (HPKE) for use with Javascript Object Signing and Encryption (JOSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in JOSE is provided by JOSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with JOSE.

Acknowledgments TODO acknowledge.