On storing CBOR encoded items on stable storage
draft-ietf-cbor-file-magic-00

Document Type Active Internet-Draft (cbor WG)
Author Michael Richardson 
Last updated 2021-03-24 (latest revision 2021-03-07)
Replaces draft-richardson-cbor-file-magic
Stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd Christian Amsüss
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to christian@amsuess.com
CBOR Working Group                                         M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Best Current Practice                      6 March 2021
Expires: 7 September 2021

            On storing CBOR encoded items on stable storage
                     draft-ietf-cbor-file-magic-00

Abstract

   This document proposes an on-disk format for CBOR objects that is
   friendly to common on-disk recognition systems like the Unix file(1)
   command.

   This document is being discussed at: https://github.com/mcr/cbor-
   magic-number

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

Copyright Notice

   Copyright (c) 2021 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 Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Richardson              Expires 7 September 2021                [Page 1]
Internet-Draft               cbor-file-magic                  March 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements for a Magic Number . . . . . . . . . . . . . . .   3
   3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  The CBOR Protocol Specific Tag  . . . . . . . . . . . . .   4
     3.2.  CBOR Tag Wrapped  . . . . . . . . . . . . . . . . . . . .   4
     3.3.  CBOR Tag Sequence . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  CBOR Sequence Tag . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Example from Openswan  . . . . . . . . . . . . . . .   7
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Since very early in computing, operating systems have sought ways to
   mark which files could be processed by which programs.

   For instance, the Unix file(1) command, which has existed since 1973
   ([file]), has been able to identify many file formats for decades.
   Many systems (Linux, MacOS, Windows) will select the correct
   application based upon the file contents, if the system can not
   determine it by other means: for instsance, MacOS maintains a
   resource fork that includes MIME information and therefore ideally
   never needs to know what anything about the file.  Other systems do
   this by file extensions.

   While having a MIME type associated with the file is a better
   solution in general, when files become disconnected from their type
   information, such as when attempting to do forensics on a damaged
   system, then being able to identify a file type can become very
   important.

   It is noted that in the MIME type registration, that a magic number
   is asked for, if available, as is a file extension.

Richardson              Expires 7 September 2021                [Page 2]
Internet-Draft               cbor-file-magic                  March 2021

   A challenge for the file(1) program is often that it can be confused
   by the encoding vs the content.  For instance, an Android "apk" used
   to transfer and store an application may be identified as a ZIP file.
   Both OpenOffice or MSOffice files are XML files, but appear as ZIP.
   Unless they OpenOffice files are flat (fodp) files, in which case
Show full document text