Internet DRAFT - draft-hallambaker-mesh-callsign

draft-hallambaker-mesh-callsign







Network Working Group                                 P. M. Hallam-Baker
Internet-Draft                                      ThresholdSecrets.com
Intended status: Informational                              28 June 2023
Expires: 30 December 2023


         Mathematical Mesh 3.0 Part VII: Mesh Callsign Service
                   draft-hallambaker-mesh-callsign-03

Abstract

   The Mesh Callsign Registry is a name registry that provides a mapping
   from human-friendly callsigns to root of trusts and a service
   assigned by the callsign holder to service the account bound to that
   callsign.  An append only sequence authenticated by means of a Merkle
   Tree and periodic third party notarizations provides ground truth for
   the integrity of the registry and for all the assertions enrolled in
   the sequence.

   https://mailarchive.ietf.org/arch/browse/mathmesh/
   (http://whatever)Discussion of this draft should take place on the
   MathMesh mailing list (mathmesh@ietf.org), which is archived at .

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 30 December 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.







Hallam-Baker            Expires 30 December 2023                [Page 1]

Internet-Draft            Mesh Callsign Service                June 2023


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Wafer-Thin Registry Model . . . . . . . . . . . . . . . .   4
     1.2.  Transparency  . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Dispute Resolution  . . . . . . . . . . . . . . . . . . .   6
     1.4.  Name resolution . . . . . . . . . . . . . . . . . . . . .   7
     1.5.  Trusted Third Parties . . . . . . . . . . . . . . . . . .   8
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.1.  Related Specifications  . . . . . . . . . . . . . . . . .   9
     2.2.  Defined Terms . . . . . . . . . . . . . . . . . . . . . .   9
     2.3.  Requirements Language . . . . . . . . . . . . . . . . . .   9
     2.4.  Implementation Status . . . . . . . . . . . . . . . . . .  10
     2.5.  Reserved Callsigns  . . . . . . . . . . . . . . . . . . .  10
   3.  Callsign Syntax . . . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Reserved Characters . . . . . . . . . . . . . . . . . . .  12
     3.2.  Additional character pages  . . . . . . . . . . . . . . .  12
     3.3.  Callsign Delegation . . . . . . . . . . . . . . . . . . .  13
     3.4.  Transitive Callsign . . . . . . . . . . . . . . . . . . .  13
     3.5.  Mapping to DNS Names  . . . . . . . . . . . . . . . . . .  13
       3.5.1.  DNS record validations  . . . . . . . . . . . . . . .  14
   4.  Registry Sequence . . . . . . . . . . . . . . . . . . . . . .  14
     4.1.  Callsign Assignment . . . . . . . . . . . . . . . . . . .  15
       4.1.1.  Aliases . . . . . . . . . . . . . . . . . . . . . . .  15
       4.1.2.  Initial Registration  . . . . . . . . . . . . . . . .  15
       4.1.3.  Update  . . . . . . . . . . . . . . . . . . . . . . .  16
       4.1.4.  Voluntary Transfer  . . . . . . . . . . . . . . . . .  17
       4.1.5.  Administrative Transfer . . . . . . . . . . . . . . .  17
     4.2.  Character Page Description  . . . . . . . . . . . . . . .  18
     4.3.  Notarization  . . . . . . . . . . . . . . . . . . . . . .  18
     4.4.  Accreditation . . . . . . . . . . . . . . . . . . . . . .  20
   5.  Callsign Registration Interaction . . . . . . . . . . . . . .  20
   6.  Callsign Resolution . . . . . . . . . . . . . . . . . . . . .  21
   7.  Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     7.1.  Callsign log entries  . . . . . . . . . . . . . . . . . .  23
       7.1.1.  Profile and account registration  . . . . . . . . . .  23
       7.1.2.  Structure: ProfileRegistry  . . . . . . . . . . . . .  23
       7.1.3.  Structure: ProfileResolver  . . . . . . . . . . . . .  23
       7.1.4.  Callsign registration and transfer  . . . . . . . . .  23
       7.1.5.  Structure: Registration . . . . . . . . . . . . . . .  23
       7.1.6.  Structure: CatalogedRegistration  . . . . . . . . . .  23
       7.1.7.  Character page definition . . . . . . . . . . . . . .  24



Hallam-Baker            Expires 30 December 2023                [Page 2]

Internet-Draft            Mesh Callsign Service                June 2023


       7.1.8.  Structure: Page . . . . . . . . . . . . . . . . . . .  24
       7.1.9.  Structure: CharacterSpan  . . . . . . . . . . . . . .  24
       7.1.10. Structure: Canonical  . . . . . . . . . . . . . . . .  24
       7.1.11. Structure: MapChar  . . . . . . . . . . . . . . . . .  24
       7.1.12. Structure: MapString  . . . . . . . . . . . . . . . .  24
       7.1.13. Notarization  . . . . . . . . . . . . . . . . . . . .  25
       7.1.14. Structure: Notarization . . . . . . . . . . . . . . .  25
       7.1.15. Trust Assertions  . . . . . . . . . . . . . . . . . .  25
       7.1.16. Structure: Challenge  . . . . . . . . . . . . . . . .  25
     7.2.  Message Classes . . . . . . . . . . . . . . . . . . . . .  25
       7.2.1.  Structure: CallsignRegistrationRequest  . . . . . . .  25
       7.2.2.  Structure: CallsignRegistrationResponse . . . . . . .  25
       7.2.3.  Structure: ProcessResultCallsignRegistration  . . . .  26
       7.2.4.  Application Entry . . . . . . . . . . . . . . . . . .  26
       7.2.5.  Structure: CatalogedApplicationCallsign . . . . . . .  26
       7.2.6.  Structure: ProcessResultCallsign  . . . . . . . . . .  26
     7.3.  Registry service  . . . . . . . . . . . . . . . . . . . .  26
       7.3.1.  Registry Account  . . . . . . . . . . . . . . . . . .  26
       7.3.2.  Structure: CatalogedRegistry  . . . . . . . . . . . .  26
       7.3.3.  Structure: ActivationApplicationRegistry  . . . . . .  27
       7.3.4.  Structure: ApplicationEntryRegistry . . . . . . . . .  27
     7.4.  Registrar service . . . . . . . . . . . . . . . . . . . .  27
       7.4.1.  Shared Classes  . . . . . . . . . . . . . . . . . . .  27
       7.4.2.  Transactions  . . . . . . . . . . . . . . . . . . . .  27
     7.5.  Transaction: Query  . . . . . . . . . . . . . . . . . . .  27
       7.5.1.  Message: QueryRequest . . . . . . . . . . . . . . . .  27
       7.5.2.  Message: QueryResponse  . . . . . . . . . . . . . . .  28
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
     8.1.  Names . . . . . . . . . . . . . . . . . . . . . . . . . .  28
       8.1.1.  Impersonation . . . . . . . . . . . . . . . . . . . .  28
       8.1.2.  Homograph attack  . . . . . . . . . . . . . . . . . .  28
       8.1.3.  Malicious Intellectual Property Claim . . . . . . . .  28
     8.2.  Credential Loss . . . . . . . . . . . . . . . . . . . . .  28
       8.2.1.  Loss  . . . . . . . . . . . . . . . . . . . . . . . .  28
       8.2.2.  Disclosure  . . . . . . . . . . . . . . . . . . . . .  28
     8.3.  Breach of Faith . . . . . . . . . . . . . . . . . . . . .  28
       8.3.1.  Registrar . . . . . . . . . . . . . . . . . . . . . .  28
       8.3.2.  Registry  . . . . . . . . . . . . . . . . . . . . . .  28
     8.4.  Quantum Cryptanalysis . . . . . . . . . . . . . . . . . .  28
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
   11. Appendix A: Latin Character Page  . . . . . . . . . . . . . .  28
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  34
   13. Informative References  . . . . . . . . . . . . . . . . . . .  34







Hallam-Baker            Expires 30 December 2023                [Page 3]

Internet-Draft            Mesh Callsign Service                June 2023


1.  Introduction

   The Mesh Callsign registry performs three principal functions:

   *  Provides ground truth for notarized records.

   *  Provides a quasi-permanent mapping from human-friendly callsigns
      to root of trusts.

   *  Provides a means of discovering the service currently servicing an
      account bound to a root of trust.

   For example, Alice registers the callsign @alice, binding the
   callsign to her Mesh account profile and her current Mesh service
   provider (@provisional).  The callsign may now be used (subject to
   the relevant authorization criteria) to contact Alice through any
   Mesh messaging protocol or through any of the Internet protocols
   specified in the contact declaration(s) Alice has published to that
   account.

   Unlike traditional Internet account addresses, callsign registrations
   are the property of the holder, do not require any maintenance fees
   or rent and cannot be reassigned without the consent of the holder
   except in exceptional circumstances according to a well-defined
   dispute resolution process.

   Mesh accounts are likewise the property of the holder and not the
   service provider servicing them.  Should Alice be dissatisfied with
   the service provided by @provisional, she can change to another
   provider at any time.

   As with the URIs that support the World Wide Web, Mesh callsigns are
   conceptually distinct from the Mesh itself.  While the primary
   purpose of the callsign registry is to provide for Mesh 'account
   portability' similar to the 'number portability' required of
   telephone providers, the infrastructure established is general
   purpose and may be applied to obtain roots of trust for use with
   IPSEC, DNSEC, TLS, etc.

1.1.  Wafer-Thin Registry Model

   Providing a permanent name assignment on the basis of a one-off fee
   requires close attention to be paid to the allocation of costs within
   the system.  An architecture that requires a registry to perform
   ongoing services with respect to a registration cannot do so on the
   basis of a one-time fee.





Hallam-Baker            Expires 30 December 2023                [Page 4]

Internet-Draft            Mesh Callsign Service                June 2023


   In the DNS naming infrastructure overseen by ICANN, a distinction is
   made between a Registry responsible for the administration of a 'top
   level domain' and the Registrars responsible for servicing domain
   name holders as customers.  While this 'thin registry' model offloads
   the cost of customer service to the registrars, the Registry is
   responsible for the difficult and expensive task of providing the
   authoritative DNS service for the zone.

   In the wafer-thin registry model, the task of providing the callsign
   query function is performed by the registrars and others from the
   append only logs published by the registry.  This has the effect of
   assigning only the fixed one-time registration costs to the registry
   and placing the variable costs on the registrar (Figure xxx).

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-callsign-03.html for artwork.)

      Figure 1: Callsign Registry Principals and Communication Graph.

   In the DNS thin registry model, the registry is a single point of
   failure and a successful denial of service attack against the
   registry would result in loss of service for every Internet user.
   Consequently, such registries must be over-built and over-provisioned
   to ensure such attacks cannot possibly succeed.  In the wafer-thin
   registry model, the query service is distributed across multiple
   registrars, each of which services a specific community.  The single
   point of failure is eliminated and the responsibility for query
   service placed with parties that are much better placed to
   distinguish legitimate query traffic from abuse.

1.2.  Transparency

   The technical implementation of the callsign registry is designed to
   provide transparency, that is the ability for any party to audit the
   actions of any other party using only publicly available information.

   The callsign registry is realized an append only sequence
   authenticated by means of a Merkle Tree.  Each callsign registration
   or update is made by means of a signed assertion appended to the end
   of the sequence.

   The callsign registry periodically issues a signed witness token
   asserting that the apex value of the Merkle Tree has a particular
   value and incorporates witness tokens issued by others in its own log
   as a notarization event.  Over time, these interactions between the
   Registry, the Registrars and their customers establishes a Mesh of
   Trus such that it is impossible for any party to defect undetected
   unless every other party colludes in the deception.  For example,



Hallam-Baker            Expires 30 December 2023                [Page 5]

Internet-Draft            Mesh Callsign Service                June 2023


   consider the following circumstance in which Alice, Bob, their
   providers and the registry perform the following series of cross
   notarization events:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-callsign-03.html for artwork.)

       Figure 2: Mesh of Trust generated through Cross-Notarization.

   At the start of the process, the only party with proof of the
   integrity of Bob's sequence is Bob. Creation of a witness token that
   is enrolled in the provider @provisional increases the support
   structure by one, etc.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-callsign-03.html for artwork.)

       Figure 3: Support structure for integrity of Bob's sequence at
                                  time 0.

   After a short series of interactions, the trust mesh is complete and
   each of the participants can validate Bob's sequence according to
   themselves as the ultimate root of trust.  Thus Alice can validate
   Bob's claim that a document was created by a certain date relying on
   herself as the root of trust:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-callsign-03.html for artwork.)

                Figure 4: Notarization Trust Relationships.

1.3.  Dispute Resolution

   Except in exceptional circumstances, callsign registrations cannot be
   transferred without the express permission of the holder as evidenced
   by a digital assertion signed under a key authorized by the callsign
   registration.

   One such exceptional circumstance is the case in which an
   intellectual property claim is made against the use of the callsign.
   A set of principles for resolving such disputes and a dispute
   resolution process for deciding them is therefore required.  Such
   questions are outside the scope of this document, the provision of
   technical infrastructure to support them is not.







Hallam-Baker            Expires 30 December 2023                [Page 6]

Internet-Draft            Mesh Callsign Service                June 2023


   While there are many jurisdictions that might assert sovereignty with
   respect to intellectual property claims, it is in practice only
   necessary to consider those capable of enforcing their decisions.
   Fortunately, this very fact has resulted in international treaties
   such as the Madrid protocol.

1.4.  Name resolution

   The WebPKI provides a means of authenticating organizations by
   reducing the validation criteria to the determination that a specific
   process was used to validate certificate requests.  This approach has
   been successful largely because organizations and in particular
   corporations are entities that come into being by the specific act of
   registration by a government entity.

   Natural persons do not come into being through government action.
   Consequently, attempts to apply this approach to identification of
   natural persons have met with limited success at best.  The problem
   of establishing a PKI for identification of natural persons has long
   been recognized as one of the hardest challenges in the security
   field.

   Callsigns provide a solution to this by establishing a name space in
   which the registration of a name is coextensive with the registration
   of the root of trust in which the name is to be interpreted.  Since
   this is a completely new name space with no pre-existing commitments,
   we are free to design the namespace to meet the needs of the PKI
   rather than having to adapt the PKI to the vagaries of the namespace.

   While introducing a new namespace solves the problem of establishing
   a PKI for natural persons, it leaves us with the problem of how to
   make use of the new infrastructure on devices and protocols that only
   understand the legacy namespaces.  While Alice does not respond to
   HTTP requests, she owns many devices that do and these should be
   accessible through the trust and naming contexts established by
   Alice's callsign registration.

   These requirements are addressed by mapping the names established by
   the callsign registry to an unused portion of DNS.  Devices bound to
   Alice's callsign '@alice' being accessible through the DNS pseudo-
   domain alice.mesh.

   For example, is Alice buys a thermostat and binds it to her Mesh
   profile, the device is assigned the sub-callsign hvac@alice and the
   DNS name hvac.alice.mesh.  The device may then be provisioned with
   all the credentials and discovery services required to provide Alice
   with seamless thermostat service within her home:




Hallam-Baker            Expires 30 December 2023                [Page 7]

Internet-Draft            Mesh Callsign Service                June 2023


   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-callsign-03.html for artwork.)

              Figure 5: Thermostat connected to Alice's Mesh.

1.5.  Trusted Third Parties

   The Mesh Trust architecture is based on the principle that every
   person has the right to be their own root of trust.  This principle
   is realized in the application of cross notarization through which
   the ultimate authority for Alice on entries in Bob's personal
   catalogs is Alice herself.

   But trust management is a difficult and time-consuming task and just
   as it likely that Alice outsources the trusted task of guarding her
   money to her bank, it is likely that Alice will delegate at least
   some trust management decisions to trusted third parties of her
   choosing.

   In the WebPKI, Trusted Third Parties (CAs) enable Internet commerce
   by establishing accountability.  The fact that a Web site is owned by
   a registered business in a particular jurisdiction does not in itself
   guarantee that the Web site owner is trustworthy.  But the fact that
   they are registered in that jurisdiction means that they are
   accountable to it should they breach the terms of a contract or
   attempt to perpetrate some fraud.

   Trusted Third Parties provide additional information to parties
   relying on a callsign through accreditations.  An accreditation is a
   trust assertion that states that the holder of a callsign has been
   determined to meet some criteria according to a specific set of
   practices meeting a given policy.  For example:

   *  The holder is a registered business.

   *  The holder is approved by some business accreditation service.

   *  The holder is the registered holder of a specific trademark.

   The ability to bind registered trademarks to a callsign holder is of
   particular interest when Mesh Messaging is being used for a
   transaction requiring a particular degree of trust.









Hallam-Baker            Expires 30 December 2023                [Page 8]

Internet-Draft            Mesh Callsign Service                June 2023


   For example, Alice might opt to use her Internet connected watch as a
   second factor authentication device connected to her brokerage
   account.  When Alice attempts to perform a high value transaction
   purchasing a large number of penny stocks, she receives a
   confirmation message on her watch.  The accredited trademark of the
   brokerage is used to authenticate the message to Alice before she
   reads and responds to it.

2.  Definitions

   This section presents the related specifications and standards....

2.1.  Related Specifications

   The Mesh Callsign registry is a component part of the Mathematical
   Mesh [draft-hallambaker-mesh-architecture] and makes use of the data
   formats and service formats described therein.  In particular:

   Uniform Data Fingerprint [draft-hallambaker-mesh-udf].  Describes the
      UDF format used to represent cryptographic nonces, keys and
      content digests in the Mesh and the use of Encrypted Authenticated
      Resource Locators (EARLs) and Strong Internet Names (SINs) that
      build on the UDF platform.

   Data at Rest Encryption [draft-hallambaker-mesh-dare].  Describes the
      cryptographic message and append-only sequence formats used in
      Mesh applications and the Mesh Service protocol.

   JSON-BCD Encoding [draft-hallambaker-jsonbcd].  Describes extensions
      to the JSON serialization format to allow direct encoding of
      binary data (JSON-B), compressed encoding (JSON-C) and extended
      binary data encoding (JSON-D).  Each of these encodings is a
      superset of the previous one so that JSON-B is a superset of JSON,
      JSON-C is a superset of JSON-B and JSON-D is a superset of JSON-C.

2.2.  Defined Terms

   This document makes use of the terms defined in
   [draft-hallambaker-mesh-architecture].

2.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].






Hallam-Baker            Expires 30 December 2023                [Page 9]

Internet-Draft            Mesh Callsign Service                June 2023


2.4.  Implementation Status

   The implementation status of the reference code base is described in
   the companion document [draft-hallambaker-mesh-developer].

   The examples in this document were created on 28-Jun-23 5:01:01 PM.
   Out of 250 examples, 50 failed.

2.5.  Reserved Callsigns

   The following callsigns are reserved identifiers in the callsign
   registry.  When used in this document, these callsigns refer to the
   following parties:

   @alice, @bob, @carol, @doug  The generic end users, Alice, Bob, Carol
      and Doug.

   @callsign, @callsign1, @callsign2  Generic callsigns

   @corporation, @customer, @competitor  A generic corporation and its
      customer and competitor.

   @eve  An eavesdropper

   @grace  A government representative

   @heidi  A malicious designer for cryptographic standards

   @judy  A judge who may be called upon to resolve a potential dispute
      between participants.

   @mallet  A malicious party engaged in an active attack

   @provider, @provisional  Mesh Service Providers

   @quartermaster  The callsign of the registry quartermaster.

   @registry  The callsign registry provider.

   @sybil, @sybil0, @sybil-1, @sybil-n  A pseudonymous attacker, who
      usually uses a large number of identities.

   @ted  A trusted arbitrator, who acts as a neutral third party.

   @wendy  A whistleblower, who is an insider with privileged access
      capable of divulging information.

   @Firstname_Lastname  A generic user whose name is 'Firstname



Hallam-Baker            Expires 30 December 2023               [Page 10]

Internet-Draft            Mesh Callsign Service                June 2023


      Lastname'

3.  Callsign Syntax

   A canonical Callsign consists of one or more canonical Unicode
   characters that are specified in a single character page as defined
   by a Registry character page registration.

   A presentation form of a callsign consists of the symbol '@' followed
   by a string of one or more Unicode characters which has the canonical
   form of the callsign as defined by a Registry character page
   registration.

   This approach responds to lessons learned from the experience of
   internationalized DNS names, in particular the threat of a homograph
   attack in which similar or identical looking characters from
   different character sets are combined to create a domain name that
   looks like a name that has already been registered.

   Specifications for two-character pages are proposed in this document:

   CharacterPageDigits  The digits [0-9] are canonical.

      The spacing characters ' ' and '_' are non-canonical and map to
      the empty string.

   CharacterPageLatin  Includes the CharacterPageDigits page by
      reference

      The characters [a-z] are canonical.

      The characters [A-Z] and accented Latin characters are non-
      canonical and map to the characters [a-z] according to usage.

   Each callsign has a single, unique canonical form that is determined
   by replacing each non-canonical character with the replacement
   specified in the character page registration.

   For example, Alice may register her callsign as @alice, @Alice,
   @Alic?, etc.  All of which have the same canonical form 'alice'.

   Bob can send a message to Alice by entering any callsign presentation
   that maps to the same canonical form as the callsign registered by
   Alice.  But when Bob receives a message from Alice, her callsign
   SHOULD be presented in the registered presentation if this is known.






Hallam-Baker            Expires 30 December 2023               [Page 11]

Internet-Draft            Mesh Callsign Service                June 2023


   Character page definitions are published through the registry.  This
   allows new code pages to be added at any time without the need to
   update existing clients (unless the client lacks the fonts required
   to present the callsign).

   Character page definitions MAY be extended by adding additional
   variants.  A variant consists of a mapping of a single variant
   character to a group of one or more canonical characters.  A variant
   character mapping MUST NOT specify any character that is canonical in
   that code page as its source.

   It is of course inevitable that the process of canonicalization will
   result in two or more words that have distinct and different meanings
   mapping to the same callsign just as it is inevitable that any
   technological infrastructure that attempts to span diverse cultural
   practices arising from centuries of use will not be able to satisfy
   everyone.

3.1.  Reserved Characters

   The following characters are reserved and MUST NOT be used in a
   callsign

   @  Reserved to prevent confusion and to enable use in transitive
      naming.

   .  Reserved to enable interoperability with DNS names.

   :  Reserved to avoid ambiguity when used in URIs

   #  Reserved to avoid ambiguity with URI fragment identifier syntax.

   %  Reserved for future use to allow URI percent-encoding of callsigns
      to be specified.

3.2.  Additional character pages

   Additional character pages will be added after a proof-of-concept
   deployment has been achieved for the Latin character page.  Character
   pages to be considered include:

   Emoji character page  Why not?  Will map to a specific set of symbols
      via some escape sequence.

   Arabic, Chinese, Cyrillic, Devanagari, Hebrew, etc.  Just need to
      have a domain expert specify how to do these.





Hallam-Baker            Expires 30 December 2023               [Page 12]

Internet-Draft            Mesh Callsign Service                June 2023


3.3.  Callsign Delegation

   The form delegate@callsign MAY be used to create a subordinate
   callsign.

   *  Provide names for IoT devices

   *  Roles within an organization

   For example, Alice might assign the callsign hvac@alice to the
   thermostat controlling her home heating and ventilation system.

   If Alice works for @corporation, she might be assigned the
   subordinate callsign alice@corporation for the duration of her
   employment.  This allows for a smooth transfer of responsibilities
   when Alice eventually leaves.  It is clear to anyone who interacts
   with Alice through the callsign alice@corporation, that the 'end' of
   the communication and the trust relationship in this case is
   @corporation and not Alice.

   In circumstances in which Mesh callsigns are used in combinaton with
   RFC822 email addresses, the DNS pseudo domain .mesh MAY be used for
   disambiguation.  Thus @alice MAY be written as @alice.mesh and
   alice@corporation MAY be written as alice@corporation.mesh.

3.4.  Transitive Callsign

   The form callsign1@@callsign2 MAY be used to specify the party that
   the party holding callsign2 knows as callsign1.

   This format MAY be used to support SPKI/SDSI forms of transitive
   naming.  This may be of use in constructing identifiers to refer to
   elements of Notarization proof chains. 'registry@@provider' being an
   identifier for a Witness token generated by @registry and enrolled by
   @provider.

3.5.  Mapping to DNS Names

   The DNS pseudo domain .mesh is used to provide a reserved space to
   which Mesh callsigns MAY be mapped through assertions specified in
   Registry entries.  The .mesh domain is conceptually distinct from
   those currently offered by ICANN.  Instead of the zone being
   maintained as a DNS zone delegated from the DNS root, the zone
   entries are determined from the entries in the callsign registry:

   For example: To resolve the domain hvac.alice.mesh, a Mesh aware
   application requests callsign resolution on @alice.




Hallam-Baker            Expires 30 December 2023               [Page 13]

Internet-Draft            Mesh Callsign Service                June 2023


   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-callsign-03.html for artwork.)

                Figure 6: DNS resolution of hvac.alice.mesh.

   The callsign entry for @alice does not specify a DNS field but it
   does specify that the callsign is serviced by @provider.  The
   callsign entry for @provider specifies a DNS entry for an
   authoritative name server for all the DNS zones being serviced by the
   provider.  This includes service for the zone alice.mesh which
   contains an IP address for hvac.alice.mesh.

   A provider of DNS resolution service MAY provide delegation service
   for the complete .mesh domain by determining the corresponding
   delegation entries from the callsign registry as they are entered:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-callsign-03.html for artwork.)

            Figure 7: DNS resolution of Callsign Pseudo-Domain.

3.5.1.  DNS record validations

   Delegations in the DNS pseudo domain .mesh are authenticated by means
   of the signatures on the Mesh callsign registrations and notarization
   of the registry sequence through witness entries.  While this does
   not provide a DNSSEC validation path, the path provided does not
   require the constant maintenance of resigning the zone required in
   DNSSEC.

   The delegated domains (e.g. alice.mesh) MAY be DNSSEC signed.  The
   signing key for the domain being authenticated by means of a security
   policy.

4.  Registry Sequence

   The Registry Append Only Sequence is a DARE Sequence of type Merkle
   Tree.  The following entry types are defined:

   Registration  Registration of a callsign, accreditation or challenge.

   Page  Specification of a character page specifying characters allowed
      in a callsign.

   Notarization  Entry of a signed witness token from another sequence
      (e.g. a sequence maintained by a registrar).





Hallam-Baker            Expires 30 December 2023               [Page 14]

Internet-Draft            Mesh Callsign Service                June 2023


4.1.  Callsign Assignment

   Callsigns are registered by means of a Registration entry containing
   an enveloped callsign signed by the callsign holder.

   The callsign entry contains all the information necessary to audit
   future requests to update or transfer the callsign registration.

4.1.1.  Aliases

   A callsign registration MAY contain an alias entry directing
   resolution requests to another callsign.

   One very important difference between callsigns and DNS names is that
   a callsign resolver has access to the entire callsign registry.
   Consequently, it is not necessary to place limits on the length of
   path resolution for aliases etc. since these can be calculated during
   processing of the sequence.  Detection of indirection loops is still
   required of course.

4.1.2.  Initial Registration

   Initial registration records have the reason field 'Initial'.

   Alice registers the callsign alice it has the canonical form alice.

   {
     "Callsign":{
       "Id":"alice",
       "Presentation":"alice",
       "Holder":"MBHS-EKNA-7EJZ-VMUQ-HI5U-4FH3-RV3T",
       "Service":"provisional"}}

   The registrar receives the request and forwards it to the registry
   which creates a registration record that is enrolled in the callsign
   log:















Hallam-Baker            Expires 30 December 2023               [Page 15]

Internet-Draft            Mesh Callsign Service                June 2023


   {
     "Registration":{
       "Id":"NAVQ-OJVT-PRML-SR5S-BUH6-QAUM-UPTM",
       "Entry":[{
           "dig":"S512"},
         "ewogICJDYWxsc2lnbiI6IHsKICAgICJJZCI6ICJhbGljZSIsCiAgICAiUH
     Jlc2VudGF0aW9uIjogImFsaWNlIiwKICAgICJIb2xkZXIiOiAiTUJIUy1FS05BLTd
     FSlotVk1VUS1ISTVVLTRGSDMtUlYzVCIsCiAgICAiU2VydmljZSI6ICJwcm92aXNp
     b25hbCJ9fQ",
         {
           "signatures":[{
               "alg":"S512",
               "kid":"MBHS-EKNA-7EJZ-VMUQ-HI5U-4FH3-RV3T",
               "signature":"EeTMZx7MAVskcP87n7bj3yz9ukgGs22etareDWrf
     jBSmtcbv3p6zYuamKlVrgO3LdHpC7TDNLcuAEBc2OMj2ycTj_blGkAX9sw1RuUREy
     M4S3HV0g-PUwSzDFkBItBKMpE0nVKq35d8SehWdA9CSCDMA"}
             ],
           "PayloadDigest":"IKtQPyuBxPdM81GeFEMCsTK1WG4xyp_xsI3yUjyu
     URfIIAGgYVh0JVd5M59V742SHthSC5abV30gCu3W4q6_FA"}
         ],
       "Submitted":"2021-04-03T14:47:49Z",
       "Reason":"Initial"}}

4.1.3.  Update

   A callsign holder MAY update their callsign registration at any time.

   *  To change the presentation form of their callsign.

   *  To specify an alias to which attempts at resolving the callsign
      should be mapped.

   *  To change their service provider.

   *  To make changes to their Profile or DNS entries.

   Callsign updates MUST NOT change the canonical form of a callsign.
   Such changes are by definition a registration of a different
   callsign.

   Alice decides to change her service provider to provider.  She also
   decides that her callsign looks better with an initial capital and so
   changes the presentation form to Alice.  This change does not require
   require a new callsign to be registered as this has tghe same
   canonical form alice.






Hallam-Baker            Expires 30 December 2023               [Page 16]

Internet-Draft            Mesh Callsign Service                June 2023


   {
     "Callsign":{
       "Id":"alice",
       "Presentation":"Alice",
       "Holder":"MBHS-EKNA-7EJZ-VMUQ-HI5U-4FH3-RV3T",
       "Service":"provider"}}

   The registrar receives the request and forwards it to the registry
   which creates a registration record that is enrolled in the callsign
   log:

   {
     "Registration":{
       "Id":"NBBT-SEMX-O32L-D7M3-IHP6-GJO4-XSED",
       "Entry":[{
           "dig":"S512"},
         "ewogICJDYWxsc2lnbiI6IHsKICAgICJJZCI6ICJhbGljZSIsCiAgICAiUH
     Jlc2VudGF0aW9uIjogIkFsaWNlIiwKICAgICJIb2xkZXIiOiAiTUJIUy1FS05BLTd
     FSlotVk1VUS1ISTVVLTRGSDMtUlYzVCIsCiAgICAiU2VydmljZSI6ICJwcm92aWRl
     ciJ9fQ",
         {
           "signatures":[{
               "alg":"S512",
               "kid":"MBHS-EKNA-7EJZ-VMUQ-HI5U-4FH3-RV3T",
               "signature":"l5kZXYUpcoieHn8uIIRLnF4aP3uyi7Ekk6bpWkeg
     7NWLwcImhXPDrXJo4HRPMWFExJtPpv41gPcAcAlgTIe3RISgI5_GNcuIaBJdwGytp
     1dbl0HsiciPvxDKaTC1RWUPA1wG_UXzC4Xc-gO64ZK4BzQA"}
             ],
           "PayloadDigest":"Et8xDoEm1MDB4X3o9vAUiDWvbjlZNVR5ZsQMQeX6
     vX8OCcEzL5lkD9zDxPwc8ecug_CCxdNpMoVhOeecygZ2Wg"}
         ],
       "Submitted":"2021-04-03T14:47:49Z",
       "Reason":"Initial"}}

4.1.4.  Voluntary Transfer

   A callsign holder MAY transfer their holdership of the callsign to
   another party in the same mannaer as making an update but specifying
   the Reason 'Transfer' instead of 'Update'.  This tells relying
   parties that ownership of the callsign has been transferred and that
   messages sent to that callsign will be received by a different party.

4.1.5.  Administrative Transfer

   The reason 'administrative' is used to inform relying parties that
   the callsign was transferred without the permission of the callsign
   holder and that the signature on the callsign record is that of the
   administrative entity that authorized the transfer.



Hallam-Baker            Expires 30 December 2023               [Page 17]

Internet-Draft            Mesh Callsign Service                June 2023


   The administrative criteria and processes under which administrative
   transfers occur are outside the scope of this document.  Such
   processes MAY require registration of a Challenge assertion to put
   the callsign holder on notice that their holdership has been
   challenged.  Mesh Service Providers acting on behalf of their users
   SHOULD alert callsign holders when their callsign is challenged.

4.2.  Character Page Description

   Character page descriptions specify a set of characters which MAY be
   used within a following callsign registration.  The Page record
   specifies the range of characters that are canonical and the mapping
   of variant characters to canonical form.

   For example, the CharacterPageDigits Page specifies ten canonical
   characters, the digits, 0,1,2,...,9 and two variant characters which
   MAY be used to space letters when presenting a callsign.  Both
   variants map to the empty string meaning that they are simply
   discarded when compiling the canonical form.

   {
     "Page":{
       "Id":"CharacterPageDigits",
       "CharacterSpans":[{
           "Canonical":{
             "First":48,
             "Last":57}},
         {
           "MapString":{
             "First":32,
             "Target":""}},
         {
           "MapString":{
             "First":95,
             "Target":""}}
         ]}}

   Page records MAY incorporate other Page records by reference provided
   that they have been defined earlier in the sequence.

4.3.  Notarization

   The registry produces DARE Witness tokens at periodic intervals as
   determined by policy.  For example, policy might dictate that a
   Witness token be produced every day or every hour or that the
   interval between witness token generation be determined by the rate
   at which entries are added to the sequence.




Hallam-Baker            Expires 30 December 2023               [Page 18]

Internet-Draft            Mesh Callsign Service                June 2023


   Registrars MAY also produce DARE Witness tokens and request that they
   be enrolled in the log as notarization entries.  A notarization entry
   is not signed directly but is instead authenticated by the Merkle
   Tree authenticating the sequence as a whole.

   The first time that the Mesh service provider provisional requests
   Notarization by the Registry, it creates a witness token on its local
   log:

   {
     "Witness":{
       "Id":"provisional",
       "Issuer":"provisional",
       "Apex":"z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_SpIdNs6c5H0NE8XYXys
     P-DGNKHfuwvY7kxvUdBeoGlODJ6-SfaPg"}}

   The witness value is signed by provisional to create a Notarization
   of the witness value:

   {
     "Notarization":{
       "Entries":[[{
             "dig":"S512"},
           "ewogICJXaXRuZXNzIjogewogICAgIklkIjogInByb3Zpc2lvbmFsIiwK
     ICAgICJJc3N1ZXIiOiAicHJvdmlzaW9uYWwiLAogICAgIkFwZXgiOiAiejRQaE5YN
     3Z1TDN4VkNoUTFtMkFCOVlnNUFVTFZ4WGNnX1NwSWROczZjNUgwTkU4WFlYeXNQCi
     AgLURHTktIZnV3dlk3a3h2VWRCZW9HbE9ESjYtU2ZhUGcifX0",
           {
             "signatures":[{
                 "alg":"S512",
                 "kid":"MAG2-SFGU-YIE3-YY56-CFQQ-XE52-XOWA",
                 "signature":"uGmMvEKz73JsGPP91MktmumFeOgx_plUqtvn5P
     4Xf396XVuBRl7gdmJsdOq4_UUFo8jM222XNcUA4HlzN0OZU9jcOKi7svesib__jnM
     2mjuiLrx2dQImPKquw7_VLOlxeNsfwttixS3iRKbZQrpswxkA"}
               ],
             "PayloadDigest":"J9_gKXKo_Q7JWwc2IvoNt23Sb6oF3HWYpCQosA
     WflDcCSrsfMxIsSNmpkQmIpRsFGoItTK-5TDhXIEV3MTCN6w"}
           ]
         ]}}

   The Notarization value is sent to the registry which enrolls the
   Notarization in its local log, creates a Witness value on the entry
   containing the provider Notarization, and returns its own
   Notarization token containing the Witness value it has most recently
   created.






Hallam-Baker            Expires 30 December 2023               [Page 19]

Internet-Draft            Mesh Callsign Service                June 2023


   The next time that the service provider requests Notarization, it
   creates a Witness token as before and includes a Proof path to the
   previous token:

   {
     "Notarization":{
       "Entries":[[{
             "dig":"S512"},
           "ewogICJXaXRuZXNzIjogewogICAgIklkIjogInByb3Zpc2lvbmFsIiwK
     ICAgICJJc3N1ZXIiOiAicHJvdmlzaW9uYWwiLAogICAgIkFwZXgiOiAiejRQaE5YN
     3Z1TDN4VkNoUTFtMkFCOVlnNUFVTFZ4WGNnX1NwSWROczZjNUgwTkU4WFlYeXNQCi
     AgLURHTktIZnV3dlk3a3h2VWRCZW9HbE9ESjYtU2ZhUGcifX0",
           {
             "signatures":[{
                 "alg":"S512",
                 "kid":"MAG2-SFGU-YIE3-YY56-CFQQ-XE52-XOWA",
                 "signature":"uGmMvEKz73JsGPP91MktmumFeOgx_plUqtvn5P
     4Xf396XVuBRl7gdmJsdOq4_UUFo8jM222XNcUA4HlzN0OZU9jcOKi7svesib__jnM
     2mjuiLrx2dQImPKquw7_VLOlxeNsfwttixS3iRKbZQrpswxkA"}
               ],
             "PayloadDigest":"J9_gKXKo_Q7JWwc2IvoNt23Sb6oF3HWYpCQosA
     WflDcCSrsfMxIsSNmpkQmIpRsFGoItTK-5TDhXIEV3MTCN6w"}
           ]
         ],
       "Proof":{}}}

   [NB, generation and verification of proof is not currently supported
   in the reference code]

   This time, the Registry verifies the proof path before entering the
   token.

4.4.  Accreditation

   Issue and use of third party accreditations is outside the scope of
   this document.

5.  Callsign Registration Interaction


   The CallSign registry operates as a standard Mesh Account with the
   callsign @registry.

   The registry periodically fetches callsign registration requests and
   processes them to produce a valid log.






Hallam-Baker            Expires 30 December 2023               [Page 20]

Internet-Draft            Mesh Callsign Service                June 2023


   Callsigns are registered and updated by sending a request message
   containing a valid signed CallsignBinding with the necessary proof of
   payment (if required).


6.  Callsign Resolution

   The callsign resolution protocol supports the Hello and Query
   transactions.

   Request specifies the Callsign

   Response returns the binding (if it exists) and a statement
   specifying how current the callsign provider's data is.


   Alice adds an Internet connected Thermostat to her home.  The
   thermostat has a built in Web server to allow the settings to be set
   by a Web browser.  During the onboarding process, the thermostat is
   assigned a domain name {Policies.ThermostatDns}

   Alice's Mesh Service Provider maintains an authoritative DNS server
   for Alice's Callsign DNS zone {Policies.AliceDns}. The IP addresses
   of this server are specified in the callsign registration of her Mesh
   Service Provider:

   {
     "Callsign":{
       "Id":"provider",
       "Presentation":"provider",
       "Holder":"MC33-EPHG-GILF-YB7P-RQF4-DPWZ-TRYY",
       "Service":"@provider",
       "Dns":["10.2.1.1",
         "10.2.1.2",
         "2001:db8::1001"
         ]}}

   The authoritative DNS server publishes a link from which a Mesh DNS
   Profile specifying the security policy for the zone MAY be obtained:

   [This is probably a prefixed TXT record of some sort.]

   The security policy for the zone states that the DNS zone is signed
   using DNSSEC and the thermostat supports TLS/1.2 transport layer
   security:






Hallam-Baker            Expires 30 December 2023               [Page 21]

Internet-Draft            Mesh Callsign Service                June 2023


   {
     "ProfileDns":{
       "SecurityPolicies":[{
           "CName":["alice.mesh"
             ],
           "Protocol":["dns"
             ],
           "Enhancements":["dnssec"
             ],
           "Roots":[{
               "Udf":"MBHS-EKNA-7EJZ-VMUQ-HI5U-4FH3-RV3T",
               "PublicParameters":{
                 "PublicKeyECDH":{
                   "crv":"Ed448",
                   "Public":"p0H30Oh6fm2HxxcYTqhWNJGLUHD7SQgBHjtRUIE
     zdCGDzAo9ytlAgDwQ_0UT6uF3jBWSnqmJtxMA"}}}
             ]},
         {
           "CName":["hvac.alice.mesh"
             ],
           "Protocol":["http",
             "https"
             ],
           "Enhancements":["tls1.2"
             ],
           "Require":true,
           "Roots":[{
               "Udf":"MBHS-EKNA-7EJZ-VMUQ-HI5U-4FH3-RV3T",
               "PublicParameters":{
                 "PublicKeyECDH":{
                   "crv":"Ed448",
                   "Public":"p0H30Oh6fm2HxxcYTqhWNJGLUHD7SQgBHjtRUIE
     zdCGDzAo9ytlAgDwQ_0UT6uF3jBWSnqmJtxMA"}}}
             ]}
         ]}}

   A non Mesh-aware browser can access the Web site and establish a TLS
   connection to the thermostat provided that 1) the browser uses a DNS
   service that supports use of Mesh callsign zones and 2) the device
   provides a certificate set that allows the browser to build a valid
   path to a root it trusts.

   A Mesh aware browser can access the Web site directly and enforce the
   security policy directly.  Thus preventing a downgrade attack to an
   insecure site.

7.  Schemas




Hallam-Baker            Expires 30 December 2023               [Page 22]

Internet-Draft            Mesh Callsign Service                June 2023


7.1.  Callsign log entries

7.1.1.  Profile and account registration

7.1.2.  Structure: ProfileRegistry

   Describes a callsign registry.

   [No fields]

7.1.3.  Structure: ProfileResolver

   Describes a callsign resolver.

   EnvelopedProfileRegistry: Enveloped (Optional)  The registry that
      this resolver resolves.

7.1.4.  Callsign registration and transfer

   The following classes are used as common elements in Mesh profile
   specifications.

7.1.5.  Structure: Registration

   A callsign or Notarization registration

   Id: String (Optional)  Unique registration identifier

   Entry: Enveloped (Optional)  The signed callsign binding

   Submitted: DateTime (Optional)  The UTC time instant that the claim
      was submitted.

   Registrar: String (Optional)  Callsign of the registrar that made the
      registration request

   PriorId: String (Optional)  If present, specifies a previous
      registration with the same identifier.

   Reason: String (Optional)  Reason for creating a registration:
      Initial/ Update/ Voluntary/ Administrative/ Revoke

7.1.6.  Structure: CatalogedRegistration

   Canonical: String (Optional)  The canonical form of the callsign.

   Id: String (Optional)  Unique registration identifier




Hallam-Baker            Expires 30 December 2023               [Page 23]

Internet-Draft            Mesh Callsign Service                June 2023


   EnvelopedRegistration: Enveloped (Optional)  The registration entry
      for the item.

7.1.7.  Character page definition

7.1.8.  Structure: Page

   Id: String (Optional)  Character page identifier

   Allow: String [0..Many]  Additional allowed pages.

7.1.9.  Structure: CharacterSpan

   First: Integer (Optional)  The first character in the range
      (inclusive)

   Last: Integer (Optional)  The last character in the range
      (inclusive), if ommitted or equal to zero, this is the same as
      Last.

7.1.10.  Structure: Canonical

   Inherits: CharacterSpan

   Canonical character span.

   [No fields]

7.1.11.  Structure: MapChar

   Inherits: CharacterSpan

   Specifies a variant mapping the range of characters First..First+n to
   a range of characters Target..Target+n.  Where n = Last - First+1

   Target: Integer (Optional)  The character that First is mapped to.

7.1.12.  Structure: MapString

   Inherits: CharacterSpan

   Specifies a mapping of non canonical characters in the range
   specified by First..Last to the string Target.

   Target: String (Optional)  Specifies a character string that the
      Source character(s) are mapped to.  If count is greater than 1,
      all the characters map to the same string.




Hallam-Baker            Expires 30 December 2023               [Page 24]

Internet-Draft            Mesh Callsign Service                June 2023


7.1.13.  Notarization

7.1.14.  Structure: Notarization

   Entries: Enveloped [0..Many]  Enveloped witness value of a specific
      append only log.

   Proof: Proof (Optional)  Proof path validating the previous notary
      token that was entered in the log.

7.1.15.  Trust Assertions

7.1.16.  Structure: Challenge

   Registers a challenge to one or more callsigns that have been
   registered.

   Subjects: String [0..Many]  The callsigns subject to challenge

   Basis: String [0..Many]  The basis for the challenge

7.2.  Message Classes

7.2.1.  Structure: CallsignRegistrationRequest

   Connection request message.  This message contains the information

   EnvelopedCallsignBinding: Enveloped (Optional)  The enveloped
      binnding of the callsign to the profile.

   Profiles: Enveloped [0..Many]  One or more profiles under which the
      EnvelopedCallsignBinding is validlty signed.

7.2.2.  Structure: CallsignRegistrationResponse

   Registered: Boolean (Optional)  True if and only if a new
      registration was created.

   CatalogedRegistration: CatalogedRegistration (Optional)  The
      resulting catalog entry if accepted or the prior registration
      otherwise.

   Reason: String (Optional)  Reason for refusing the registration (if
      refused)

   Callsign: String (Optional)  The value specified as the Canonical
      field in the callsign request if present, otherwise the value
      specified in the Display field, otherwise null.



Hallam-Baker            Expires 30 December 2023               [Page 25]

Internet-Draft            Mesh Callsign Service                June 2023


7.2.3.  Structure: ProcessResultCallsignRegistration

   CallsignRegistrationResponse: CallsignRegistrationResponse
   (Optional)

7.2.4.  Application Entry

7.2.5.  Structure: CatalogedApplicationCallsign

   Application entry tracking the status of a callsign binding request

   CallSign: String (Optional)  The registered callsign in canonical
      form.

   RequestId: String (Optional)  The MessageId of the request message

   EnvelopedCallsignBinding: Enveloped (Optional)  The callsign binding

   CatalogedRegistration: CatalogedRegistration (Optional)  The
      resulting catalog entry if accepted or the prior registration
      otherwise.

   Reason: String (Optional)  Reason for refusing the registration (if
      refused)

7.2.6.  Structure: ProcessResultCallsign

   CatalogedApplicationCallsign: CatalogedApplicationCallsign
   (Optional)  The cataloged application

7.3.  Registry service

7.3.1.  Registry Account

7.3.2.  Structure: CatalogedRegistry

   MaximumRequestLength: Integer (Optional)

   MaximumCallsignLength: Integer (Optional)

   EnvelopedConnectionAddress: Enveloped (Optional)  The connection
      allowing control of the registry.

   EnvelopedProfileRegistry: Enveloped (Optional)  The Mesh profile

   EnvelopedActivationCommon: Enveloped (Optional)  The activation data
      for the registry.




Hallam-Baker            Expires 30 December 2023               [Page 26]

Internet-Draft            Mesh Callsign Service                June 2023


7.3.3.  Structure: ActivationApplicationRegistry

   AccountEncryption: KeyData (Optional)  Key used to decrypt registry
      messages.

   AdministratorSignature: KeyData (Optional)  Key or capability used to
      sign the registry log

7.3.4.  Structure: ApplicationEntryRegistry

   EnvelopedActivation: Enveloped (Optional)

   EnvelopedConnectionService: Enveloped (Optional)  Signed connection
      service delegation allowing the device to access the account.

7.4.  Registrar service

7.4.1.  Shared Classes

   HTTP Well Known Service Prefix: /.well-known/tbs1

7.4.2.  Transactions

7.5.  Transaction: Query

   Request: QueryRequest

   Response: QueryResponse

   Request resolution of a profile bound to a callsign or registration
   identifier.  Returns an envelope containing the signed registration
   (if found).

7.5.1.  Message: QueryRequest

   Request resolution of a profile bound to a callsign or registration
   identifier.

   CallSign: String (Optional)  The callsign being requested in
      canonical form.

   RegistrationId: String (Optional)  The registration identifier of a
      registration in the log.

   LogId: String (Optional)  The unique identifier of an append only log
      whose signed Notarization entry is requested.





Hallam-Baker            Expires 30 December 2023               [Page 27]

Internet-Draft            Mesh Callsign Service                June 2023


7.5.2.  Message: QueryResponse

   Return the result of a QueryRequest

   Result: Enveloped (Optional)  The registration specified in the
      result (if found).

   Notarization: Enveloped (Optional)  The latest notarization entry
      corresponding to the specified log.

8.  Security Considerations

8.1.  Names

8.1.1.  Impersonation

8.1.2.  Homograph attack

8.1.3.  Malicious Intellectual Property Claim

8.2.  Credential Loss

8.2.1.  Loss

8.2.2.  Disclosure

8.3.  Breach of Faith

8.3.1.  Registrar

8.3.2.  Registry

8.4.  Quantum Cryptanalysis

9.  IANA Considerations

   This document requires no IANA actions.

10.  Acknowledgements


11.  Appendix A: Latin Character Page









Hallam-Baker            Expires 30 December 2023               [Page 28]

Internet-Draft            Mesh Callsign Service                June 2023


   {
     "Page":{
       "Id":"CharacterPageLatin",
       "Allow":["CharacterPageDigits"
         ],
       "CharacterSpans":[{
           "Canonical":{
             "First":97,
             "Last":122}},
         {
           "MapChar":{
             "First":65,
             "Last":90,
             "Target":97}},
         {
           "MapString":{
             "First":192,
             "Target":"a"}},
         {
           "MapString":{
             "First":193,
             "Target":"a"}},
         {
           "MapString":{
             "First":194,
             "Target":"a"}},
         {
           "MapString":{
             "First":195,
             "Target":"a"}},
         {
           "MapString":{
             "First":196,
             "Target":"ae"}},
         {
           "MapString":{
             "First":197,
             "Target":"aa"}},
         {
           "MapString":{
             "First":198,
             "Target":"ae"}},
         {
           "MapString":{
             "First":199,
             "Target":"c"}},
         {
           "MapString":{



Hallam-Baker            Expires 30 December 2023               [Page 29]

Internet-Draft            Mesh Callsign Service                June 2023


             "First":200,
             "Target":"e"}},
         {
           "MapString":{
             "First":201,
             "Target":"e"}},
         {
           "MapString":{
             "First":202,
             "Target":"e"}},
         {
           "MapString":{
             "First":203,
             "Target":"e"}},
         {
           "MapString":{
             "First":204,
             "Target":"i"}},
         {
           "MapString":{
             "First":205,
             "Target":"i"}},
         {
           "MapString":{
             "First":206,
             "Target":"i"}},
         {
           "MapString":{
             "First":207,
             "Target":"i"}},
         {
           "MapString":{
             "First":208,
             "Target":"d"}},
         {
           "MapString":{
             "First":209,
             "Target":"n"}},
         {
           "MapString":{
             "First":210,
             "Target":"o"}},
         {
           "MapString":{
             "First":211,
             "Target":"o"}},
         {
           "MapString":{



Hallam-Baker            Expires 30 December 2023               [Page 30]

Internet-Draft            Mesh Callsign Service                June 2023


             "First":212,
             "Target":"o"}},
         {
           "MapString":{
             "First":213,
             "Target":"o"}},
         {
           "MapString":{
             "First":214,
             "Target":"oe"}},
         {
           "MapString":{
             "First":215,
             "Target":"x"}},
         {
           "MapString":{
             "First":217,
             "Target":"u"}},
         {
           "MapString":{
             "First":218,
             "Target":"u"}},
         {
           "MapString":{
             "First":219,
             "Target":"u"}},
         {
           "MapString":{
             "First":220,
             "Target":"u"}},
         {
           "MapString":{
             "First":221,
             "Target":"y"}},
         {
           "MapString":{
             "First":223,
             "Target":"ss"}},
         {
           "MapString":{
             "First":224,
             "Target":"a"}},
         {
           "MapString":{
             "First":225,
             "Target":"a"}},
         {
           "MapString":{



Hallam-Baker            Expires 30 December 2023               [Page 31]

Internet-Draft            Mesh Callsign Service                June 2023


             "First":226,
             "Target":"a"}},
         {
           "MapString":{
             "First":227,
             "Target":"a"}},
         {
           "MapString":{
             "First":228,
             "Target":"ae"}},
         {
           "MapString":{
             "First":229,
             "Target":"aa"}},
         {
           "MapString":{
             "First":230,
             "Target":"ae"}},
         {
           "MapString":{
             "First":231,
             "Target":"c"}},
         {
           "MapString":{
             "First":232,
             "Target":"e"}},
         {
           "MapString":{
             "First":233,
             "Target":"e"}},
         {
           "MapString":{
             "First":234,
             "Target":"e"}},
         {
           "MapString":{
             "First":235,
             "Target":"e"}},
         {
           "MapString":{
             "First":236,
             "Target":"i"}},
         {
           "MapString":{
             "First":237,
             "Target":"i"}},
         {
           "MapString":{



Hallam-Baker            Expires 30 December 2023               [Page 32]

Internet-Draft            Mesh Callsign Service                June 2023


             "First":238,
             "Target":"i"}},
         {
           "MapString":{
             "First":239,
             "Target":"i"}},
         {
           "MapString":{
             "First":240,
             "Target":"o"}},
         {
           "MapString":{
             "First":241,
             "Target":"n"}},
         {
           "MapString":{
             "First":242,
             "Target":"o"}},
         {
           "MapString":{
             "First":243,
             "Target":"o"}},
         {
           "MapString":{
             "First":244,
             "Target":"o"}},
         {
           "MapString":{
             "First":245,
             "Target":"o"}},
         {
           "MapString":{
             "First":246,
             "Target":"oe"}},
         {
           "MapString":{
             "First":247,
             "Target":"-"}},
         {
           "MapString":{
             "First":249,
             "Target":"u"}},
         {
           "MapString":{
             "First":250,
             "Target":"u"}},
         {
           "MapString":{



Hallam-Baker            Expires 30 December 2023               [Page 33]

Internet-Draft            Mesh Callsign Service                June 2023


             "First":251,
             "Target":"u"}},
         {
           "MapString":{
             "First":252,
             "Target":"u"}},
         {
           "MapString":{
             "First":253,
             "Target":"y"}}
         ]}}

12.  Normative References

   [draft-hallambaker-jsonbcd]
              Hallam-Baker, P., "Binary Encodings for JavaScript Object
              Notation: JSON-B, JSON-C, JSON-D", Work in Progress,
              Internet-Draft, draft-hallambaker-jsonbcd-23, 23 October
              2022, <https://datatracker.ietf.org/doc/html/draft-
              hallambaker-jsonbcd-23>.

   [draft-hallambaker-mesh-architecture]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
              Architecture Guide", Work in Progress, Internet-Draft,
              draft-hallambaker-mesh-architecture-21, 23 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-architecture-21>.

   [draft-hallambaker-mesh-dare]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data
              At Rest Encryption (DARE)", Work in Progress, Internet-
              Draft, draft-hallambaker-mesh-dare-16, 23 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-dare-16>.

   [draft-hallambaker-mesh-udf]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform
              Data Fingerprint.", Work in Progress, Internet-Draft,
              draft-hallambaker-mesh-udf-17, 23 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-udf-17>.

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

13.  Informative References



Hallam-Baker            Expires 30 December 2023               [Page 34]

Internet-Draft            Mesh Callsign Service                June 2023


   [draft-hallambaker-mesh-developer]
              Hallam-Baker, P., "Mathematical Mesh: Reference
              Implementation", Work in Progress, Internet-Draft, draft-
              hallambaker-mesh-developer-10, 27 July 2020,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-developer-10>.













































Hallam-Baker            Expires 30 December 2023               [Page 35]