Crypto-Conditions
draft-thomas-crypto-conditions-03

Document Type Active Internet-Draft (individual)
Last updated 2017-07-18
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          S. Thomas
Internet-Draft                                              R. Reginelli
Intended status: Standards Track                          A. Hope-Bailie
Expires: January 19, 2018                                         Ripple
                                                           July 18, 2017

                           Crypto-Conditions
                   draft-thomas-crypto-conditions-03

Abstract

   The crypto-conditions specification defines a set of encoding formats
   and data structures for *conditions* and *fulfillments*.  A condition
   uniquely identifies a logical "boolean circuit" constructed from one
   or more logic gates, evaluated by either validating a cryptographic
   signature or verifying the preimage of a hash digest.  A fulfillment
   is a data structure encoding one or more cryptographic signatures and
   hash digest preimages that define the structure of the circuit and
   provide inputs to the logic gates allowing for the result of the
   circuit to be evaluated.

   A fulfillment is validated by evaluating that the circuit output is
   TRUE but also that the provided fulfillment matches the circuit
   fingerprint, the condition.

   Since evaluation of some of the logic gates in the circuit (those
   that are signatures) also take a message as input the evaluation of
   the entire fulfillment takes an optional input message which is
   passed to each logic gate as required.  As such the algorithm to
   validate a fulfillment against a condition and a message matches that
   of other signature schemes and a crypto-condition can serve as a
   sophisticated and flexible replacement for a simple signature where
   the condition is used as the public key and the fulfillment as the
   signature.

Feedback

   This specification is a part of the Interledger Protocol [1] work.
   Feedback related to this specification should be sent to
   ledger@ietf.org [2].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Thomas, et al.          Expires January 19, 2018                [Page 1]
Internet-Draft              Crypto-Conditions                  July 2017

   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 http://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 January 19, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Types . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Simple and Compound Types . . . . . . . . . . . . . . . .   5
     3.2.  Defining and Supporting New types . . . . . . . . . . . .   5
   4.  Features  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Multi-Algorithm . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Multi-Signature . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Multi-Level . . . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Crypto-conditions as a signature scheme . . . . . . . . .   7
     4.5.  Crypto-conditions as a trigger in distributed systems . .   8
     4.6.  Smart signatures  . . . . . . . . . . . . . . . . . . . .   9
   5.  Validation of a fulfillment . . . . . . . . . . . . . . . . .   9
     5.1.  Subfulfillments . . . . . . . . . . . . . . . . . . . . .  10
   6.  Deriving the Condition  . . . . . . . . . . . . . . . . . . .  10
     6.1.  Conditions as Public Keys . . . . . . . . . . . . . . . .  10
   7.  Format  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Encoding Rules  . . . . . . . . . . . . . . . . . . . . .  11
Show full document text