<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" docName="draft-haberman-digital-emblem-00" ipr="trust200902">
 <front>
   <title abbrev="Digital Emblems">Digital Emblems Indicating Protections Under International Law</title>

   <author fullname="Brian Haberman" initials="B." surname="Haberman" role="editor">
      <organization abbrev="JHU APL">Johns Hopkins University Applied Physics Lab</organization>
      <address>
        <email>brian@innovationslab.net</email>
      </address>
   </author>
   <author fullname="Allison Mankin" initials="A." surname="Mankin">
      <organization abbrev="PCH">Packet Clearing House</organization>
      <address>
         <email>amankin@gmail.com</email>
      </address>
   </author>
   <author fullname="Bill Woodcock" initials="B." surname="Woodcock">
      <organization abbrev="PCH">Packet Clearing House</organization>
      <address>
         <email>woody@pch.net</email>
      </address>
   </author>
   <author fullname="Casey Deccio" initials="C." surname="Deccio">
      <organization abbrev="BYU">Brigham Young University</organization>
      <address>
         <email>casey@deccio.net</email>
      </address>
   </author>
   <author fullname="Antonio DeSimone" initials="A." surname="DeSimone">
      <organization abbrev="JHU APL">Johns Hopkins University Applied Physics Lab</organization>
      <address>
         <email>antonio.desinome@jhuapl.edu</email>
      </address>
   </author>

   <abstract>
   <t>International law defines a number of emblems, such as the blue helmets of United Nations peacekeeping forces,
   the blue and white shield of UNESCO, and the Red Cross of the International Committee of the Red Cross, as indicative
   of special protections under the Geneva Conventions. Similar protections attach to journalists who wear "Press" protective
   emblems on the battlefield, under Article 79 of Protocol I of the Geneva Conventions and Resolution 2222 of the United
   Nations Security Council. The emblems of national governments and inter-governmental organizations protect diplomatic
   pouches, couriers, and envoys under the Vienna Convention on Diplomatic Relations. Other marks enjoy protections against
   mis-use under the Paris Convention, the Madrid Protocol, and the Trade-Related Aspects of Intellectual Property Rights.</t>

   <t>Such physical emblems have a number of weaknesses (e.g., no real-time evaluation of their authenticity) and do not
   translate to the digital realm. This document describes a digital emblem which addresses the shortcomings of the physical
   emblems and makes possible the indication of protections of digital assets under international law.</t>
   </abstract>
 </front>

 <middle>
   <section anchor="intro" title="Introduction">

   <t>International law defines a number of emblems, such as the blue helmets of United Nations (UN) peacekeeping forces,
   the blue and white shield of UNESCO, and the Red Cross of the International Committee of the Red Cross (ICRC), as indicative
   of special protections under international law. Similar protections attach to journalists who wear "Press" protective
   emblems on the battlefield. The emblems of national governments and inter-governmental organizations protect diplomatic
	   pouches, couriers, and envoys, and international law protects certain marks against counterfeiting.</t>

   <t>Physical emblems suffer from a number of weaknesses:
   <list style="bullets">
	   <t>It is not possible to evaluate their authenticity in real-time,</t>
	   <t>They cannot be seen in the dark,</t>
	   <t>They may not be visible at a distance, at an oblique angle, or from the opposite side of an object,</t>
	   <t>They may be subject to wear, obfuscation, or vandalism,</t>
	   <t>No audit mechanism exists to prove that the presence of an emblem has been queried for,</t>
	   <t>No mechanism exists to prevent replay attacks,</t>
	   <t>No mechanism exists to prevent time-shifting attacks,</t>
	   <t>No mechanism exists to prevent location-shifting attacks,</t>
	   <t>No mechanism exists to correlate an emblem with a specific quantity of persons or items, or a physical extent,</t>
	   <t>No mechanism exists to correlate the validity of an emblem with its use in a specific place or time,</t>
	   <t>There is no centralized ability to revoke instances of emblems which have been compromised, are being abused, or are no longer relevant.</t>
   </list></t>

   <t>A digital emblem must meet certain criteria to perform its function of notification under law:
   <list style="bullets">
	   <t>It MUST provide a clearly detectable and unambiguous marking,</t>
	   <t>They MUST be machine readability,</t>
	   <t>The emblem MUST identify the authorizing party that issued it,</t>
	   <t>The emblem MUST be robust against misuse,</t>
	   <t>It MUST be possible to restrict the validity of an emblem by temporal or geographic scope,</t>
	   <t>It MUST be possible to associate the emblem with a range or specific quantity of persons or items,</t>
	   <t>It MUST be possible to associate the emblem with online services (e.g., websites, emails),</t>
	   <t>It MUST be possible to associate the emblem with data in transit or at rest,</t>
	   <t>It MUST be possible to associate the emblem with network-addressable equipment (e.g., routers, servers),</t>
	   <t>It MUST be possible to associate the emblem with a physical object (e.g., building, vehicle),</t>
	   <t>It MUST be possible to associate the emblem with a person or group of people,</t>
	   <t>It SHOULD be possible to view an emblem in-band via a communications network, optically (e.g., QR code), or wirelessly (e.g., RFID),</t>
	   <t>The digital emblem MUST be capable of carrying a visual representation of the emblem,</t>
	   <t>The emblem MUST carry an unambiguous indication of the international law or laws conferring protection upon the entity marked with the emblem,</t>
	   <t>The emblem MUST be capable of providing a reference to additional relevant information (e.g., photographs, unique identifiers) which can be
		   used to corroborate the association of the digital emblem with the entity bearing it,</t>
	   <t>Querying the existence of or validating a digital emblem MUST NOT impose undue risk or cost on any party to the transaction.</t>
   </list></t>

   <t>This document describes a protocol for the creation and publication of a digital emblem utilizing the
   Domain Name System (DNS) global infrastructure.</t>

   <section title="Conventions">
   <t>The capitalized 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
   <xref target="RFC2119" />.</t>
   </section>
   </section>

   <section title="Protocol Overview">
   <t> The objective of the protocol is to allow organizations to digitally signal that people, places, things, services, and data are
   entitled to protection under international law.</t>
   </section>

   <section title="Digital Emblem Material in DNS">
   <section title="Signing Credentials" anchor="creds">
   <t>Entities generate, publish, and maintain valid digital signing certificates for attesting to a Digital Emblem (DEM).
   These signing certificates MUST be published in the DNS via DNS-based Authentication of Named Entities (DANE) TLSA Record
   <xref target="RFC6698"/>.</t>

   <t>All TLSA records MUST be protected by DNS Security Extensions (DNSSEC)
   <xref target="RFC4033"/><xref target="RFC4034"/><xref target="RFC4035"/>.</t>
   </section>

   <section title="Digital Emblems" anchor="emblem">

   <section title="Digital Emblem Record" anchor="DER">
   <t>A DEM Record is a DNS record that declares use of a digital emblem. It is used to publish the certificate attesting to protection under international
   law. The DEM Record is a new DNS Resource Record Type.
   Multiple records MAY exist for the same name. Each DEM Record is placed in the DNS tree at the name to which it pertains.</t>

   <section title="DEM RDATA Wire Format">
   <figure>
   <artwork><![CDATA[
	                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cert. Usage   |    Selector   | Matching Type |               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
      /                                                               /
      /                 Certificate Association Data                  /
      /                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ]]></artwork>
   </figure>

   <section title="Certificate Usage Field">
   <t>A one-octet field where the value is selected from IANA's TLSA Certificate Usages registry <xref target="RFC6698"/>.</t>
   </section>

   <section title="Selector Field">
   <t>A one-octet field where the value is selected from IANA's TLSA Selectors registry <xref target="RFC6698"/>.</t>
   </section>

   <section title="Matching Type Field">
   <t>A one-octet field where the value is selected from IANA's TLSA Matching Types registry <xref target="RFC6698"/>.</t>
   </section>

   <section title="Certificate Association Data Field">
   <t>This field contains either raw data (either the full certificate or its public key information) or the hash of the raw data.</t>
   </section>
   </section>
   </section>

   <section title="DEM RR Presentation Format">
   <t>TBD</t>
   <t>Publication of a DEM follows all the rules for publishing DNS resource records described in <xref target="RFC1035"/>.
   The DEM MUST be protected by DNSSEC.</t>
   </section>
   </section>

   <section title="Digital Emblem Verification" anchor="verify">
   <t>Any entity can verify the existence and validity of a digital emblem. Anyone can perform the following tasks:
   <list style="numbers">
      <t>Perform a DNS lookup for a DEM Record.</t>
      <t>If a DEM does not exist, terminate process.</t>
      <t>Extract the certificate.</t>
      <t>Perform a DNS lookup for the TLSA record associated with the Issuer.</t>
      <t>If the TLSA exists, extract the key material. Otherwise, terminate process.</t>
      <t>Using the retrieved key material, verify the signature on the DEM certificate.</t>
   </list>
   If the signature verifies, the target system has protection from the digital emblem. In all other cases, it does not.</t>
   </section>
   </section>

   <section title="To Do List">
   <t>Add text on necessary DANE TLSA parameters for use with the Digital Emblem per <xref target="RFC7671"/></t>

   <t>Integrate underscored naming indicator per <xref target="RFC8552"/>.</t>

   <t>Presentation format</t>

   <t>Intermediate certificates.</t>

   <t>DEM certficate fields and usages (e.g., SANs).</t>

   <t>Investigate use of an updated LOC record.</t>

   <t>DEP, QTY, and TIME RRType usage.</t>

   <t>in-addr.foo.int, ip6.foo.int, and asn.foo.int namespace use.</t>

   <t>Signaling protection of IP addresses via reverse DNS.</t>

   <t>Legal/Policy considerations.</t>

   </section>

   <section title="IANA Considerations">
   <t>Two new IANA registries are required by this protocol.</t>
   <list style="bullets">
	   <t>Digital Emblem Registry - The principal key in this registry is the name of a digital emblem using organization, followed by the principal jurisdiction of incorporation, followed by any necessary locational disambiguation (in case there are multiple organizations of the same name incorporated within the same jurisdiction), followed by a list of domain apexes which MAY contain digital emblem records, each of which which MUST be under the control of the same named entity, followed by a field which encodes a list of numeric references to the bodies of international protective law embodied in the emblem, sorted by order of importance or relevance as deemed by the Digital Emblem's registrant. These codes should be drawn from a separate table, which may be seeded with the following values, with a canonical URL for each: Hague Conventions, Geneva Conventions, Third Geneva Convention, Fourth Geneva Convention, Geneva Protocol I, Geneva Protocol II, Geneva Protocol III, Rome Statute, Madrid Protocol, Vienna Convention on Diplomatic Relations of 1961.</t>
	   <t>ASN.ARPA Registry - This is a new delegation within .ARPA, to be managed jointly by the RIRs, or the NRO, in which RIRs may delegate NS and DS records to PTR RRs associated with Autonomous System Number assignments, analogous to the way they delegate the in-addr.arpa and ip6.arpa domains.</t>
   </list>
   </section>

   <section title="Security Considerations">
   </section>

   <section title="Contributors">
   </section>

   <section title="Acknowledgments">
   </section>
 </middle>

 <back>
   <references title="Normative References">
      <?rfc include="reference.RFC.1035" ?>
      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.RFC.4033" ?>
      <?rfc include="reference.RFC.4034" ?>
      <?rfc include="reference.RFC.4035" ?>
      <?rfc include="reference.RFC.6698" ?>
      <?rfc include="reference.RFC.7671" ?>
      <?rfc include="reference.RFC.8552" ?>
   </references>

   <references title="Informative References">
      <?rfc include="reference.RFC.7208" ?>
   </references>

 </back>
</rfc>
