draft-shearer-desmet-calvelli-lumionsrfc-00.txt

Lumions Working Group                                         D. Shearer
Internet-Draft                                                R. De Smet
Intended status: Informational                               C. Calvelli
Expires: 4 August 2022                                           LumoSQL
                                                         31 January 2022


 Lumions: Portable, Private, Secure, Unique, Updatable Data Primitives
              draft-shearer-desmet-calvelli-lumionsrfc-00

Abstract

   This memo defines Lumions, a new kind of secure, unique data
   encapsulation primitive designed for reliable, fine-grained storage
   and movements of arbitary data between arbitary storage mechanisms
   and across arbitary networks.  Lumions are also compatible with
   decentralised, distributed key management.  To illustrate the main
   use case, Lumions would not be needed if JSON had sophisticated
   privacy and encryption features, with a single unique JSON namespace
   and a standard way of referring to other JSON objects.

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

   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 4 August 2022.

Copyright Notice

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



Shearer, et al.           Expires 4 August 2022                 [Page 1]

Internet-Draft                 lumionsrfc                   January 2022


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Feature Levels  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Mandatory Minimum Requirements  . . . . . . . . . . . . .   4
     3.2.  Optional: Key Authority . . . . . . . . . . . . . . . . .   5
     3.3.  Optional: Versioning  . . . . . . . . . . . . . . . . . .   5
     3.4.  Optional: Access Control  . . . . . . . . . . . . . . . .   5
     3.5.  Optional: Checksums . . . . . . . . . . . . . . . . . . .   5
   4.  Properties of Lumions . . . . . . . . . . . . . . . . . . . .   5
   5.  Description of Lumions  . . . . . . . . . . . . . . . . . . .   6
   6.  Lumions and Key Management  . . . . . . . . . . . . . . . . .   7
   7.  Goals and Constraints . . . . . . . . . . . . . . . . . . . .   8
   8.  Lumion Data Format  . . . . . . . . . . . . . . . . . . . . .   8
   9.  Lumion Data Formal ABNF Specification . . . . . . . . . . . .   9
   10. Lumion UUID Format  . . . . . . . . . . . . . . . . . . . . .  10
   11. List of Lumion Ciphers, Signatures and Hashes . . . . . . . .  10
   12. Example Use Cases . . . . . . . . . . . . . . . . . . . . . .  10
     12.1.  Data Tracking and Portability  . . . . . . . . . . . . .  11
     12.2.  Time Travelling Data for Snapshotting  . . . . . . . . .  11
     12.3.  Non-Fungible Token (NFT) Applications  . . . . . . . . .  11
     12.4.  Online Backups . . . . . . . . . . . . . . . . . . . . .  11
   13. Performance Considerations  . . . . . . . . . . . . . . . . .  11
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   15. Related Work  . . . . . . . . . . . . . . . . . . . . . . . .  12
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     16.1.  Content-type registration for 'apoplication/lumion'  . .  12
   17. Informative References  . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   A Lumion is a one-dimensional array of data signed with a public key
   which MUST contain a checksum, a version number and a universally
   unique identifier.  A Lumion is binary data and MUST be stored in
   network byte order.









Shearer, et al.           Expires 4 August 2022                 [Page 2]

Internet-Draft                 lumionsrfc                   January 2022


   In addition a Lumion MAY be encrypted with one or more schemes
   defined in this standard which together implement various forms of
   Role-based Access Control.  These schemes offer different levels of
   access depending on the token supplied.  After being updated with a
   valid write access, a Lumion will have an updated checksum.  The
   updated signature will be valid in all situations where the previous
   version of the signature was valid.

   A Lumion has keys implemented as public/private key pairs, and there
   can be any (or no) key management authorities.  The simplest case of
   a key management authority is where a program on a device creates a
   Lumion, making that program on that device the issuing authority.
   That program may subsequently be uninstalled, or the private key data
   it created be deleted or lost, making it a very transient key
   manaagement authority.

   Distinct from any other key management scheme users may implement,
   there is one specific key management authority scheme described in
   this RFC which stores lists of Lumion keys in an application of a
   public blockchain.  This gives Lumions the optional ability to have a
   decentralised, globally distributed key authority.

   Situations where Lumion properties are helpful include internet-
   connected devices such as mobile phones; transparency requirements
   related to privacy; and data portability requirements between clouds.

   A new media type "application/lumion" is defined as a helpful hint
   for high-level applications.

1.1.  Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

2.  Definitions

   Lumion Generator: software that can produce a Lumion for any supplied
   raw data.  A Generator may be standalone or built into eg a database.
   A Lumion Generator must also be able to read Lumions, and is a full
   implementation of this RFC.

   Lumion Reader: is software that can access at least some data inside
   a Lumion, provided it has a key to do so, where a key is required by
   a particular Lumion.  A Lumion Reader implements some of the
   verification and reading functionality in this RFC.





Shearer, et al.           Expires 4 August 2022                 [Page 3]

Internet-Draft                 lumionsrfc                   January 2022


   Lumion Recogniser: is very simple software, perhaps a function or a
   script, that can detect the unique naming convention used by Lumions
   as defined in this RFC, and extract the universally unique identifier
   used by a particular Lumion.  A Recogniser can extract Lumions from
   non-Lumion data, and search for a particular Lumion.  A Recogniser
   will not be able to reliably determine whether any given Lumion is
   valid or not.

   Payload Data: an arbitary binary string within a Lumion of arbitary
   length less than 2^64 bytes.

   Payload Metadata: A checksum or version number specific to the
   Payload Data.

   Metadata: all data to do with access control, checksums and version
   numbers for the Lumion as a whole, the UUID and more.

   Access Control: The RBAC system implemented for Lumions, where valid
   users are anyone who has a valid key.  A valid key can only be used
   to sign a Lumion if it is used for the correct purpose.  For example,
   a read-only key cannot produce a valid signature for a Lumion after
   writing to it.

   Key Management Authority: a scheme selected by users to manage their
   Lumion keys.  This could be any system at all, from a plain text file
   on a server on the internet to a Kerberos server.  In the case of an
   embedded database library, the key management authority will often be
   either an individual app on the device (eg a banking app) or the
   device's platform-wide key management authority (eg the identity
   systems built into many versions of Android, and Apple phones.)

   Lumion Registry: One particular key management authority defined in
   this RFC for storing Lumion keys in a public blockchain.

3.  Feature Levels

3.1.  Mandatory Minimum Requirements

   A Lumion will always:

   *  Have a standardised Lumion UUID
   *  Be signed

   We would not expect plain text Lumions to be common, but they are
   valid.  A plain text Lumion with a signature is no different in
   principle to a signed plain text MIME email.  So long as the
   signature is valid we know that the data has not been changed.




Shearer, et al.           Expires 4 August 2022                 [Page 4]

Internet-Draft                 lumionsrfc                   January 2022


   There is no requirement for a key management authority, even on a
   device, because it is also valid (and may sometimes be useful) for a
   Lumion Generator to discard all knowledge of keys once it has
   generated a Lumion.

3.2.  Optional: Key Authority

   There are multiple ways of implementing a Key Authority.  They are
   all explained in the section "Lumion Key Management".

3.3.  Optional: Versioning

   Both payload and metadata can be versioned with 64-bit version
   numbers.  These versions are internal versions, incremented each time
   the Lumion is updated and re-signed.

3.4.  Optional: Access Control

   This is a simple version of Role-based Access Control, with a list of
   valid keys stored in the Lumion Metadata.

3.5.  Optional: Checksums

   A signature is already a form of a checksum.  But in addition to this
   overall Lumion checksum, a checksum is also used as part of the
   Access Control system.

4.  Properties of Lumions

   Standardised: A Lumion can be operated on by any software that
   complies with this RFC.

   Integrity: Corruption can always be detected, at multiple levels
   (overall, or in the payload, or in the metadata).

   Uniquely Recognisable Among All Data: A Lumion will always be
   recognisable as a Lumion from its name-based UUID.

   Uniquely Identifiable Among All Lumions: A Lumion will always be
   unique among all Lumions due to the one-way hash part of its UUID.

   Secure: If there is no valid key available (because the original
   Lumion Generator did not store the key correctly, or the key was
   lost, etc) then a Lumion cannot be decrypted.

   Portable: Can be copied across architectures, networks, storage
   systems without losing or gaining any information.




Shearer, et al.           Expires 4 August 2022                 [Page 5]

Internet-Draft                 lumionsrfc                   January 2022


   Non-repudiable: The original key authority might be unreliable and
   transient (ifor example, because the originating phone got swallowed
   by a diprodoton) but any Lumions generated on that phone and intended
   to have a common local authority will always be identifiable as
   having the same original source.

   Self-contained security: no external key authority or integrity
   authority is needed.  Discriminated access control is provided solely
   from the information within the Lumion.

   Globally distributed namespace: Just by having a Lumion UUID, that
   means every Lumion is part of an ad hoc global storage system.

   Sequenced Internally: Since Lumions have an internal version number,
   anyone with copies of all version of a Lumion can view them as a
   time-sequenced stream.  (It is possible for a Lumion to keep all
   previous versions of its payload within itself, although whether this
   is scaleable or feasible is highly application-dependent.)

   Sequenced Externally: Lumions have fields of Left, Right, Below and
   Above, sized to contain a Lumion UUID.  The contents of these fields
   can be updated at any time, meaning that Lumions can optionally and
   frequently will form part of a logical structure such as a Merkle
   tree, thus creating a sequence that can be navigated forward/back/up/
   down, depending on the structure.  This sequence data can also be
   interpreted as time sequence data, if the Lumion Generator intended
   to produce that.  Timestamps are not required to be assigned by the
   Lumion Generator for time sequence data, because if a sequence of
   Lumions is ordered then a Lumion Reader can interpret that according
   to any temporal origin and offset it chooses.

   Time Travelling: Sequences of either the internal or external
   versioning can be interpreted as snapshotted point-in-time state
   information.  Such information can always be played back to
   reconstruct a view of the world at any point in time.  Even where
   there are no timestamps, the relative versions can still be replayed
   in either direction.

5.  Description of Lumions

   Any of the three types of data may be in plain text, although they
   usually will not be plain text because much of the value of a Lumion
   is in its encrypted properties.  A plain text Lumion is still signed,
   and still has a universally unique ID.

   Data in a Lumion may be automatically generated by one of these kinds
   of processes:




Shearer, et al.           Expires 4 August 2022                 [Page 6]

Internet-Draft                 lumionsrfc                   January 2022


   *  cryptographic checksums
   *  symmetric encryption
   *  public key encryption
   *  public key signing
   *  one-way hashes appended to a name-based uniqueness algorithm

   For each of these there are multiple possible ciphers and
   implementation techniques.

   Portability requires that data is stored in Network Byte Order.

6.  Lumions and Key Management

   There are four different levels of scope that involve key management:

   1.  The system within a Lumion, ie implementing access control so
       that a validly-signed Lumoion remains validly signed even after
       it has been updated by someone with a valid write key, and only
       allows reads by someone with a valid read or read+write key.  All
       of that is about how the Lumion is maintained as a data artefact.
       These valid keys could have been generated by anyone anywhere,
       and stored anywhere.  The Lumion neither knows nor cares.  But it
       still has to do some degree of key management because it has list
       of keys and their access rights inside it.

   2.  How a Lumion Generator creates the Lumion in the first places and
       the list of keys inside the Lumion.  There will also be the other
       half of keys to be stored somewhere (presumably inside a LumoSQL
       database, in a Lumion.)  That incldues symmetric keys, and
       signatures.  So this too is key management.  New users, the
       extent to which revocation is supported, etc.  I expect this will
       be mostly internal to LumoSQL, driven by the SQL interface (?)

   3.  Key management via an Authority, any authority.  A LumoSQL user
       is building an app, and might choose to make LDAP or Active
       Directory or Kerberos the Authority, or an Oracle database, etc.
       LumoSQL doesn't know or care, only that the keys are in the right
       places at the right time.  Will this be done through the C API,
       or SQL only?

   4.  Key management via the Lumion Registry, which is the only (and
       totally optional) scheme that LumoSQL is configured to support.
       This is the scheme I described where Lumions are stored in a
       blockchain, specifically Ethereum, as an implementation of a
       standard Ethereum smart contract.  This is where we could have
       many billions of rows with their UUID registered and also the
       users with access rights registered there too.  See the later
       section headed "Lumion Registry".



Shearer, et al.           Expires 4 August 2022                 [Page 7]

Internet-Draft                 lumionsrfc                   January 2022


7.  Goals and Constraints

   XXXX THIS SECTION DOES NOT EXIST YET XXXX

8.  Lumion Data Format

   A Lumion is laid out like this:

      +--------+-----------------+------------------------+---------+
      |  UUID  | Metadata Block  | Payload Metadata Block | Payload |
      +--------+-----------------+------------------------+---------+

   These fields are always present in a Lumion.

   The UUID is described in the section "Lumion UUID Format", and is
   always 256 bits wide.

   The Metadata Block is laid out like this:

      +-----------+----------+-------------------------+--------------+
      | Signature | Features | Payload Metadata Offset | Other Metad. |
      +-----------+----------+-------------------------+--------------+

   The Lumion Signature is a digital signature from one of those allowed
   in this RFC.  See the section "Lumion Ciphers, Signatures and
   Hashes".

   The Lumion Feature list is a 32-bit bitmask with values as in the
   following table:

   XXXXX MORE GOES HERE XXXXX

   Payload Metadata Offset is a 64-bit integer.

   Other Metadata contains all RBAC metadata, and some non-RBAC
   Metadata:

   *  Left, Right, Below and Above pointers.  These pointers are Lumion
      UUIDs, meaning that trees, lists and other structures can be
      implemented with Lumions.  At least one of these fields MUST be
      non-zero if the External Lumion Version Count is non-zero.
   *  List of valid Lumion Access Keys
   *  XXXXX MORE GOES HERE XXXXX

   The Payload Metadata Block is laid out like this:






Shearer, et al.           Expires 4 August 2022                 [Page 8]

Internet-Draft                 lumionsrfc                   January 2022


      +----------------+---------------------+------------------------+
      | Payload Length | Payload Vers. Count | Other Payload Metadata |
      +----------------+---------------------+------------------------+

   Payload Length is a 64-bit integer.

   Payload Version Count is a 64-bit integer.

   Other Payload Metadata relates to RBAC, such as Last Edited By, which
   is a keyid listed in the Metadata Block.  XXXXX

9.  Lumion Data Formal ABNF Specification

   A Lumion has the following ABNF [RFC5234] definition:

   (this is NOT valid Lumion ABNF because we're still at the high-level
   sketch stage.  But it is quite atmospheric, don't you think?  A bit
   like mood music.)

     SYSLOG-MSG      = HEADER SP STRUCTURED-DATA [SP MSG]

     HEADER          = PRI VERSION SP TIMESTAMP SP HOSTNAME
                       SP APP-NAME SP PROCID SP MSGID
     PRI             = "<" PRIVAL ">"
     PRIVAL          = 1*3DIGIT ; range 0 .. 191
     VERSION         = NONZERO-DIGIT 0*2DIGIT
     HOSTNAME        = NILVALUE / 1*255PRINTUSASCII

     APP-NAME        = NILVALUE / 1*48PRINTUSASCII
     PROCID          = NILVALUE / 1*128PRINTUSASCII
     MSGID           = NILVALUE / 1*32PRINTUSASCII

     TIMESTAMP       = NILVALUE / FULL-DATE "T" FULL-TIME
     FULL-DATE       = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
     DATE-FULLYEAR   = 4DIGIT
     DATE-MONTH      = 2DIGIT  ; 01-12
     DATE-MDAY       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                               ; month/year
     FULL-TIME       = PARTIAL-TIME TIME-OFFSET
     PARTIAL-TIME    = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
                       [TIME-SECFRAC]
     TIME-HOUR       = 2DIGIT  ; 00-23
     TIME-MINUTE     = 2DIGIT  ; 00-59
     TIME-SECOND     = 2DIGIT  ; 00-59
     TIME-SECFRAC    = "." 1*6DIGIT
     TIME-OFFSET     = "Z" / TIME-NUMOFFSET
     TIME-NUMOFFSET  = ("+" / "-") TIME-HOUR ":" TIME-MINUTE




Shearer, et al.           Expires 4 August 2022                 [Page 9]

Internet-Draft                 lumionsrfc                   January 2022


     STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
     SD-ELEMENT      = "[" SD-ID *(SP SD-PARAM) "]"
     SD-PARAM        = PARAM-NAME "=" %d34 PARAM-VALUE %d34
     SD-ID           = SD-NAME
     PARAM-NAME      = SD-NAME
     PARAM-VALUE     = UTF-8-STRING ; characters '"', '\' and
                                    ; ']' MUST be escaped.
     SD-NAME         = 1*32PRINTUSASCII
                       ; except '=', SP, ']', %d34 (")

     MSG             = MSG-ANY / MSG-UTF8
     MSG-ANY         = *OCTET ; not starting with BOM
     MSG-UTF8        = BOM UTF-8-STRING
     BOM             = %xEF.BB.BF

     UTF-8-STRING    = *OCTET ; UTF-8 string as specified in RFC 3629

     OCTET           = %d00-255
     SP              = %d32
     PRINTUSASCII    = %d33-126
     NONZERO-DIGIT   = %d49-57
     DIGIT           = %d48 / NONZERO-DIGIT
     NILVALUE        = "-"

10.  Lumion UUID Format

   This is a combination of a name-based namespace and a robust hash,
   similar to type 5 UUIDs in [RFC4122].

   RFC4122 UUIDs MUST NOT be used because of the constrained
   environments many Lumion-using applications are deployed in and which
   therefore do not have knowledge of namespaces that look like DNS or
   which imply a network even exists.  In addition RFC4122 does not
   include any hash more recent than SHA-1, which is now deprecated.

   XXXXX MORE GOES HERE XXXXX

11.  List of Lumion Ciphers, Signatures and Hashes

   *  SHA-3/SHA-256
   *  BLAKE3
   *  Curve 25519
   *  XXXXX MORE CIPHERS HERE XXXXX

12.  Example Use Cases






Shearer, et al.           Expires 4 August 2022                [Page 10]

Internet-Draft                 lumionsrfc                   January 2022


12.1.  Data Tracking and Portability

   XXXXX EXPLAIN HERE - THIS IS AN EASY AND OBVIOUS ONE XXXXX

12.2.  Time Travelling Data for Snapshotting

   This is about using the versioning information embedded within
   Lumions (either internal or external) to come up with time series
   data.  It might in fact be more about ordinal data, because wallclock
   time is not part of the Lumion definition in this RFC.  A

   Each Lumion MUST have pointers called Left, Right, Below, Above, as
   well as an external or internal version number.

12.3.  Non-Fungible Token (NFT) Applications

   *  Compatible with existing NFT registries
   *  First-ever updatable NFTs

   XXXXX MORE GOES HERE XXXXX

12.4.  Online Backups

   A time-ordered lists of Lumions is also a form of backups.  Ad-hoc
   backups will be possible so long as the smallest unit is a Lumion and
   only whole Lumions are transferred.  The UUID, versioning and ordinal
   information optionally contained in a Lumion means that a consistent
   backup can always be calculated assuming a reasonable percentage of
   Lumions are present.

13.  Performance Considerations

   XXXXXX

14.  Security Considerations

   While a valid Lumion is entirely self-contained from a security point
   of view, it is important to remember that Lumions do NOT provide any
   guarantee of anonymity.  Lumions MAY be used for this purpose despite
   the presence of a UUID if the Lumion Generator is implemented in a
   very particular way (for example, the Lumion Generator only ever
   produces a single Lumion before being deleted permanently.)
   Transparency and traceability is vital to the Lumion concept, which
   is why it has a UUID.  For normal usage the UUID prevents Lumions
   providing anonymity.






Shearer, et al.           Expires 4 August 2022                [Page 11]

Internet-Draft                 lumionsrfc                   January 2022


15.  Related Work

   XXXXX

16.  IANA Considerations

   This memo calls for IANA to register a new MIME content-type
   application/pidf+xml, per [MIME].

   The registration template for this is below.

16.1.  Content-type registration for 'apoplication/lumion'

   To: ietf-types@iana.org Subject: Registration of MIME media type
   application/lumion

   MIME media type name: application

   MIME subtype name: lumion

   Required parameters: (none) Optional parameters: (none)

   Encoding considerations: (none)

   Security considerations:

     This content type carries a payload with metadata, where the only
     information that can be deduced relates to the Lumion envelope.
     Everything else is encrypted. A Lumion thus is self-contained from
     a security point of view.

   Interoperability considerations: This content type provides a common
   format for transporting data in a secure and privacy-compliant
   manner.

   Published specification: (none)

   Applications which use this media type: Databases

   Additional information: Magic number(s): XXXX File extension(s):
   .lumion (optional)

   Person & email address to contact for further information: Dan
   Shearer EMail: dan@shearer.org

   Intended usage: Globally, at scale

   Author/Change controller: (none)



Shearer, et al.           Expires 4 August 2022                [Page 12]

Internet-Draft                 lumionsrfc                   January 2022


17.  Informative References

   [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/info/rfc2119>.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              DOI 10.17487/RFC4122, July 2005,
              <https://www.rfc-editor.org/info/rfc4122>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

Authors' Addresses

   Dan Shearer
   LumoSQL

   Email: dan@shearer.org, dan@lumosql.org


   Ruben De Smet
   LumoSQL

   Email: me@rubdos.be


   Claudio Calvelli
   LumoSQL

   Email: webmaster@lumosql.org
















Shearer, et al.           Expires 4 August 2022                [Page 13]