Internet Engineering Task Force (IETF)              Zainan (Victor) Zhou
Internet-Draft                                                    Namefi
                                                           zzn@namefi.io
Intended status: Standards Track                        November 2, 2024
Expires: May 1, 2025


     Domain Transfer Authorization Using Cryptographic Signatures
                   draft-zzn-authcodesec-00

Abstract

  This document specifies a mechanism to enhance domain transfer
  security by transitioning from a shared-secret authorization model
  to a cryptographic signature-based validation system that enables
  authorization based on PKIs (Public Key Identification) and hands
  over control of the domain to a specific next controller identified
  by their PKI. The process is designed to be fully backward compatible
  with existing EPP systems through staged incremental upgrades.

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 May 1, 2025.

Copyright Notice

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

Table of Contents

   1. Status of This Memo ..................................... TBD
   2. Introduction ........................................... TBD
      2.1. Description of the Current Process ................ TBD
   3. Protocol Elements and Mechanisms ....................... TBD
      3.1. EPP Extension Overview ............................ TBD
      3.2. Enhanced Authorization Information Format .......... TBD
      3.3. Digest Generation ................................ TBD
      3.4. Signature Generation ............................. TBD
      3.5. Format in EPP Extension Element .................. TBD
           3.5.1. Required Fields ........................... TBD
           3.5.2. XML Schema Definition ..................... TBD
   4. Verification Flow .................................... TBD
      4.1. Verification Models Overview ....................... TBD
      4.2. Losing Side Authorization Models ................ TBD
      4.3. Gaining Side Authorization Models ................ TBD
   5. Security Considerations ............................... TBD
   6. Draft Notes: Unresolved Feedbacks and Design Questions. TBD
      6.1. Threat Analysis ................................. TBD
           6.1.6.1. Cross-Registrant Misuse ................ TBD
           6.1.6.2. Double-Selling Protection ............... TBD
           6.1.6.3. Audit Trail Limitations ................ TBD
      6.2. Choosing between pwAuthInfo and extAuthInfo ...... TBD
   7. References ........................................... TBD
      7.1. RFCs ........................................... TBD
      7.2. Other Documents ................................. TBD

1. Status of This Memo

  (TODO: add status of this memo)

2. Introduction

This document specifies a mechanism to enhance domain transfer security
by transitioning from a shared-secret authorization model to a
cryptographic signature-based validation system that enable authorization
based on PKIs (Public Key Identification) and hand over the control of
the domain to specific next controller identified by their PKI. The
process is designed to be fully backward compatible with existing EPP
systems with staged incremental upgrades inspired by the DNSSEC, HTTPS,
and Credit Card Chip migration.

The current transfer process relies on the presentation of an 
authentication code (authcode) by the gaining registrar as proof of 
transfer authority. 

This specification defines an extended authorization information format
that incorporates cryptographic signatures, enabling registries to
validate multiple aspects of the transfer request:

  * that it originates from the legitimate domain registrant
  * that it contains the correct receiving registrant information
  * that it includes proper approval signature or signatures from
    designated parties when required (such as administrative contacts 
    or other stakeholders)

To ensure smooth transition and maintain interoperability with existing 
systems, this specification includes backward compatibility mechanisms 
allowing registries and registrars to support both the legacy authcode 
format and the new signature-based format simultaneously. 

The specification provides guidance for gradual migration while 
maintaining existing transfer workflows, enabling deployments without 
requiring synchronized updates across all participants in the domain 
registration ecosystem.

2.1 Description of the Current Process

The current EPP transfer request process defined in RFC-5730 involves
the following sequence:

2.1.1. The losing registrar sets or updates the authInfo for a domain
      object through an EPP <update> command to the registry. The
      registry MUST store this authInfo value in its database.

2.1.2. The losing registrar provides this authInfo code to the current
      registrant. The method of this transmission is out of scope of
      the EPP protocol.

2.1.3. The current registrant provides this authInfo code to the
      gaining registrar. This transmission method is also out of scope
      of the EPP protocol.

2.1.4. The gaining registrar submits a transfer request to the registry
      through EPP <transfer> command, which MUST include this authInfo
      in the request.

2.1.5. The registry MUST validate that the provided authInfo matches
      the one stored in the registry database for this domain.

2.1.6. Upon successful validation, the registry MUST notify both
      registrars, update the domain object status to "pendingTransfer",
      and MUST change the authInfo to a new value known only to the
      registry.

This validation mechanism relies solely on the matching of a shared
secret between parties, which presents several security limitations
that this specification aims to address. The fact that the authInfo
must be transmitted between multiple parties out-of-band increases the
risk of compromise.

2.2. Threat Model

The extension intends to address the following advanced security issues
in the context of authInfo-based domain transfer mechanism:

* Man-in-the-Middle Attacks during out-of-band transmission
* Insider Threats from registrar employees and support staff
* Lack of Transfer Intent Binding
* Revocation Management Issues
* Replay Attacks, including:
  - No temporal validity constraints
  - Multiple use vulnerability
  - Lack of transfer context binding
  - Missing nonce protection
* Cross-Registrant Vulnerabilities:
  - AuthInfo leakage and reuse
  - Double-selling risks
  - Insufficient audit trails

2.3. Extensibility Assumptions

This specification builds upon several extensibility aspects of
RFC-5730 (EPP):

2.3.1. AuthInfo Structure Extensibility

    According to RFC-5730 Section 2.7.1, EPP provides an extension
    framework that allows for definition of both new protocol 
    operations and object extensions:

    * The <extension> element MUST contain up to one instance of any 
      object extension elements
    * Any object extension element MAY extend any object element, 
      including the <authInfo> element
    * Extension elements MUST be qualified by a XML namespace
      declaration

    This extensibility mechanism allows for the enhancement of the
    authInfo structure while maintaining backward compatibility.

2.3.2. Password Element Size

    After reviewing RFC-5730, it's worth noting that the specification
    does not explicitly define size limitations for the domain:pw
    element. In current practice most authcodes are 6-8 characters long.
    but transitioning to a signature-based system will require a longer
    authcode.

2.3.3. Verification Assumptions

    The following verification behavior is defined in RFC-5730 
    Section 2.9.3.4:

    * The server MUST validate the authorization information provided
      when a <transfer> command is processed
    * The server MAY reject requests that contain authorization
      information that has aged beyond a server-specific date or time

    This existing verification requirement provides the foundation
    for extending the validation process to include cryptographic
    signature verification.

2.3.4. Implementation Considerations

    Given the extensibility mechanisms provided by RFC-5730 and the
    lack of explicit size constraints:

    * This specification MUST use proper XML namespace declarations
      for all new elements
    * New elements MUST be added within the <extension> framework
    * Implementations MUST maintain compatibility with existing
      authInfo processing
    * Size limitations MUST be specified for all new elements
    * The extension SHOULD allow for future cryptographic algorithm
      updates

3. Protocol Description

This section defines the protocol elements and mechanisms for the new
cryptographic signature-based domain transfer authorization system.

3.1. EPP Extension Overview

    The protocol leverages EPP extensions to convey the enhanced
    authorization information, including the authorization information,
    cryptographic digest, and associated signatures. These extensions
    augment existing EPP transfer request operations.

3.2. Enhanced Authorization Information Format

    The enhanced authorization information format includes:
      * The approver's PKI
      * The approver's authority type: registrant, registrar (and it 
        can be extended to allow other types of authorities such as 
        law enforcement or judicial bodies)
      * Anti-replay protection mechanisms (e.g., expiration timestamp,
        nonce)
      * Additional authorization parameters

    The authorization information is encoded in XML format as an EPP
    extension element.

3.3. Digest Generation

    The protocol defines standardized steps and methods for generating
    cryptographic digests from the authorization information. This
    includes:
      * Specification of supported hash algorithms
      * Canonicalization of input data
      * Digest computation procedure

3.4. Signature Generation

    The protocol specifies the process for generating cryptographic
    signatures, including:
      * Supported signature algorithms
      * Key requirements and formats
      * Signature computation procedure using the registrant's key

3.5 Format in EPP Extension Element

    The enhanced authorization information is encoded in XML format as
    an EPP extension element as followed:

3.5.1 Required Fields

    The enhanced authorization information consists of the following
    required fields:

    * version - Schema version number
    * domainName - The domain name being transferred
    * nonce - Incremental number to prevent replay attacks
    * receiverInfo - Container for receiver details:
      * receiverType: Type of receiving entity (registrant/registrar)
      * receiverKey: PKI of the receiver
      * receiverIdentifier: Unique identifier of the receiver
    * approverInfo - Container for approver details:
      * approverType: Type of approving entity (registrant/registrar)
      * approverKey: PKI of the approver
      * approverIdentifier: Unique identifier of the approver
    * digestInfo - Container for digest details:
      * digestAlgorithm: Hash algorithm used
      * digestValue: Hexadecimal representation of the computed digest

3.5.2 XML Schema Definition

BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:epp:authcodesec-1.0"
        xmlns:authcodesec="urn:ietf:params:xml:ns:epp:authcodesec-1.0"
        xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
        xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
<import namespace="urn:ietf:params:xml:ns:epp-1.0"/>

<annotation>
  <documentation>
    Extension to EPP extAuthInfoType for secure domain transfers
  </documentation>
</annotation>

<element name="secData" type="authcodesec:secDataType" 
substitutionGroup="eppcom:extAuthInfo"/>

<complexType name="secDataType">
  <complexContent>
    <extension base="eppcom:extAuthInfoType">
      <sequence>
        <element name="version" type="token" fixed="1.0"/>
        <element name="nonce" type="token"/>
        <element name="receiverInfo" type="authcodesec:entityInfoType"/>
        <element name="approverInfo" type="authcodesec:entityInfoType"/>
        <element name="digestInfo" type="authcodesec:digestInfoType"/>
      </sequence>
    </extension>
  </complexContent>
</complexType>

<complexType name="entityInfoType">
  <sequence>
    <element name="type" type="authcodesec:entityTypeEnum"/>
    <element name="key" type="base64Binary"/>
    <element name="identifier" type="token"/>
  </sequence>
</complexType>

<simpleType name="entityTypeEnum">
  <restriction base="token">
    <enumeration value="registrant"/>
    <enumeration value="registrar"/>
    ... TODO add other types of authorities such as
    <enumeration value="lawEnforcement"/>
  </restriction>
</simpleType>

<complexType name="digestInfoType">
  <sequence>
    <element name="algorithm" type="authcodesec:digestAlgorithmEnum"/>
    <element name="value" type="hexBinary"/>
  </sequence>
</complexType>

<simpleType name="digestAlgorithmEnum">
  <restriction base="token">
    ... TODO: add supported algorithms / standard to define digesting
  </restriction>
</simpleType>

</schema>
END

3.5.3. Signature in domain:pw

The signature value in domain:pw is the Base64-encoded value of the
signature computed over the digest:

C:        <domain:authInfo>
C:          <domain:pw>Base64EncodedSignatureValueComputedOverTheDigest
...</domain:pw>
C:        </domain:authInfo>

3.5.4 Example Usage

Example of a domain transfer request with enhanced authorization 
information:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <transfer op="request">
C:      <domain:transfer xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:authInfo>
C:          <domain:pw>Base64EncodedSignatureValueComputedOverTheDigest
            ...</domain:pw>
C:        </domain:authInfo>
C:      </domain:transfer>
C:    </transfer>
C:    <extension>
C:      <authcodesec:secData 
C:       xmlns:authcodesec="urn:ietf:params:xml:ns:epp:authcodesec-1.0">
C:        <authcodesec:version>1.0</authcodesec:version>
C:        <authcodesec:domainName>example.com</authcodesec:domainName>
C:        <authcodesec:nonce>f7027456abc8903d</authcodesec:nonce>
C:        <authcodesec:receiverInfo>
C:          <authcodesec:type>registrant</authcodesec:type>
C:          <authcodesec:key>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC...
C:          </authcodesec:key>
C:          <authcodesec:identifier>RECV-12345</authcodesec:identifier>
C:        </authcodesec:receiverInfo>
C:        <authcodesec:approverInfo>
C:          <authcodesec:type>registrant</authcodesec:type>
C:          <authcodesec:key>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC...
C:          </authcodesec:key>
C:          <authcodesec:identifier>APPR-67890</authcodesec:identifier>
C:        </authcodesec:approverInfo>
C:        <authcodesec:digestInfo>
C:          <authcodesec:algorithm>sha256</authcodesec:algorithm>
C:          <authcodesec:value>2CF24DBA5FB0A30E73043362938B9824...
C:          </authcodesec:value>
C:        </authcodesec:digestInfo>
C:      </authcodesec:secData>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>


4. Verification Flow

The protocol specifies the process for verifying cryptographic
signatures, including:

  * Signature verification procedure using the registrant's key
  * Verification of anti-replay protection mechanisms
  * Verification of additional authorization parameters

This specification defines three models of transfer verification to
ensure smooth transition from traditional authInfo to the new
cryptographic signature-based system.

4.1. Verification Models Overview

    The verification process consists of two components: the losing
    side authorization and the gaining side verification. Each
    component can operate in one of three models, allowing for
    staged migration:

    +----------------+------------------------------------------+
    | Model          | Description                              |
    +----------------+------------------------------------------+
    | Model A        | Full cryptographic model with registrant |
    |               | signatures and keys                       |
    | Model B        | Semi-cryptographic model with registrar  |
    |               | signatures and keys                       |
    | Model C        | Traditional authInfo model               |
    +----------------+------------------------------------------+
  
  The three models are designed to allow for staged migration from the
  current authInfo-based mechanism to the new cryptographic
  signature-based mechanism.

  Model A is the strongest and most secure model, but also requires the
  most significant changes to existing workflows. Model C is the weakest
  and least secure model, but also requires the least changes to
  existing workflows.

  Any party, registrant, registrar or registry can start by supporting
  Model C and then move to Model B or Model A as needed.

  Any party can add their support for Model A or Model B at any time, 
  when transfer counter party doesn't support the same model, the
  transfer can still be completed by falling back to a lower model, as
  described in section 4.4.

4.2. Model A. Full Cryptographic Model

4.2.1 Request to update the PKI

* Any current registrant can request its current registrar to update its 
  registrant information with the enhanced authorization information
  including the PKI.
  * If such the current registrant already is registered with 
    a PKI, such request MUST include a crypography signature to prove
    the ownership of the PKI and apporval of the update request.
    Otherwise, the registrar MUST validate the authenticity of the  
  
  (TODO: define the update flow and EPP command)

  * And then the current registrar MUST submit a transfer request to
    the registry with the enhanced authorization information to trigger
    the transfer process. Assuming the registry supports Model A, the
    transfer request MUST be rejected if the enhanced authorization
    information is missing, the signature is invalid, or the PKI is not
    updated.
  
  (TODO: define the error codes and error messages)

4.2.2. Request to update the AuthInfo (optional)

This step can be skipped if all parties in the transfer chain support
Model A.
But for backward compatibility, the current authInfo-based mechanism can
be used as a fallback.

The current registrant can authorize a transfer of domain by signing the
enhanced authorization information demonstrated in section 3.5.4. by 
cryptographic signing with its PKI.
(TODO: define an example of payload to be signed and digesting 
algorithm)

The signature value denoted as `sig` will be placed in the domain:pw 
element as defined in section 3.5.3.

The current registrant will then submit a transfer request to the 
registrar, and the registrar will submit a transfer request to the 
registry.

The registry will verify the signature of the current registrant using 
the PKI and the enhanced authorization information, and it will save 
the signature value in the registry database for future reference.

4.2.3. The gaining registrar will submit a transfer request to the 
registry

Supposedly the gaining registrar supports Model A, the gaining 
registrant (it could be the same as the current registrant or someone 
who bought the domain from the current registrant) will submit a 
transfer request to the registry with the enhanced authorization 
information.

The gaining registrar will first verify the signature of the gaining 
registrant using the PKI and the enhanced authorization information, 
and then it will submit a transfer request to the registry with the 
enhanced authorization information.

The registry will verify the signature of the gaining registrant using 
the PKI and the enhanced authorization information, if the signature is 
valid, the registry will complete the transfer process by updating the 
domain new owner to the gaining registrant, including the PKI.

(TODO: define example EPP command, and define the error codes and error
messages)

4.3. Fallback based on support of PKI

If the registry doesn't support PKI, the transfer process will fallback
to Model C.

Else if any of the registrars doesn't support PKI, the transfer process
will fallback to Model C.

Else if both registrars support PKI, the transfer process will fallback
to Model B.

But even if registry doesn't support PKI, if both registrars support
PKI, the authcode can be verified using PKI which is stronger than
merely Model C.

This incremental upgrade mechanism enables each individual registrar to
benefit from adding the PKI support without waiting for the other
registrar to add support, similar to the approach of DNSSEC, HTTPS
deployment and bank credit card chips rollout.

5. Security Considerations
  
  TODO: limitation due to lack of finalization of decentralized
  ledgers.
  

6. Draft Notes

6.1. Description of Threat Model

  The RFC aims at addressing the following advanced threat models:

6.1.1. Man-in-the-Middle Attacks

    Since the authInfo transmission between registrant and registrars
    occurs out-of-band and often through insecure channels (e.g., 
    email, control panel screenshots, support tickets):
      * The authInfo can be intercepted during transmission
      * There is no cryptographic binding between the authInfo and 
        the intended receiving registrant
      * A malicious actor can initiate an unauthorized transfer using
        an intercepted authInfo

6.1.2. Insider Threats

    The shared-secret nature of authInfo creates vulnerabilities to
    insider threats:
      * Any employee at the losing registrar with access to the
        control panel can view or extract authInfo values
      * Support staff handling customer requests can potentially
        misuse authInfo codes they've accessed
      * There is no cryptographic proof that the actual domain
        registrant initiated or approved the transfer

6.1.3. No Binding to Transfer Intent

    The authInfo serves only as a shared secret without any binding to:
      * The identity of the intended receiving registrant
      * The intended timing of the transfer
      * Additional authorization requirements (e.g., corporate domain
        transfers requiring multiple approvals)
      * The specific transfer request itself, allowing replay attacks

6.1.4. Revocation Challenges

    Once an authInfo has been compromised:
      * There is no standardized mechanism to revoke it without
        performing a domain update
      * The registrant may not realize the compromise until after
        an unauthorized transfer occurs
      * The registry cannot distinguish between legitimate and
        unauthorized uses of a valid authInfo

6.1.5. Replay Attacks

The current authInfo-based mechanism lacks several essential
protections against replay attacks:

6.1.5.1. Temporal Validity

  * The authInfo has no built-in expiration mechanism
  * Once generated, it remains valid until explicitly changed
  * A captured authInfo can be used at any future time until the
    losing registrar or registrant updates it
  * There is no standard way to limit the validity period of an
    authInfo

6.1.5.2. Multiple Use

  * The same authInfo can be used multiple times for different
    transfer attempts
  * A malicious actor can:
      - Capture a valid authInfo during a legitimate transfer
      - Store it for future unauthorized transfers
      - Use it again after the domain returns to the original
        registrar
  * The registry cannot distinguish between the original intended
    use and subsequent replay attempts

6.1.5.3. Transfer Context

  * The authInfo is not bound to any specific transfer context
  * The same code can be used to initiate transfers:
      - To different gaining registrars
      - At different times
      - With different receiving registrant details
  * There is no cryptographic binding between the authInfo and the
    intended transfer parameters

6.1.5.4. No Nonce Protection

  * The protocol lacks a nonce or similar mechanism to ensure
    uniqueness of each transfer request
  * Transfer requests cannot be uniquely identified or tracked
  * Makes it impossible to implement replay detection at the
    protocol level

6.1.6. Cross-Registrant Vulnerabilities within Same Registrar

The current authInfo mechanism lacks isolation between different
registrants at the same registrar:

6.1.6.1. Leaked AuthInfo Reuse

  * A registrar employee or system with access to multiple
    registrants' authInfo could:
      - Extract authInfo from one registrant's domain
      - Use it for transfers of another registrant's domain
  * The registry cannot detect this cross-registrant misuse as
    the authInfo format and validation is identical
  * No cryptographic binding exists between the authInfo and
    the specific registrant identity

6.1.6.2. Double-Selling Protection

  * A malicious registrar could:
      - Generate valid authInfo for the same domain
      - Provide them to different potential buyers
      - Allow multiple transfer attempts using different authInfo
  * The current mechanism cannot prevent or detect:
      - Multiple valid authInfo existing simultaneously
      - Which registrant was the legitimate intended transferee
      - Whether the authInfo was generated with proper
        authorization

6.1.6.3. Audit Trail Limitations

  * No cryptographic proof of:
      - Which registrant authorized the authInfo generation
      - When the authorization was granted
      - The intended receiving registrant
  * Makes dispute resolution difficult in cases of:
      - Unauthorized cross-registrant transfers
      - Double-selling incidents
      - Employee misconduct

6.2. Unresolved Quesiton: How to choose between pwAuthInfo and
     extAuthInfo?

Scott says in 

> Having said that, I designed EPP in a way that allows for
> specification of other approaches. Section 4.2 of RFC 5730 includes
> the schema that defines authorization information. Note the
> "pwAuthInfoType" and the "extAuthInfoType" type definitions.
> "extAuthInfoType" can be used as a "hook" to define a new type.
> Given that the capability exists, I'd suggest that you send a note
> to the IETF REGEXT working group mailing list asking if anyone is
> interested in the possibility of defining an extension for a new
> PKI-based authorization information type. You'd be better of
> measuring people's interest in the topic before you invest a lot of
> time working on a proposal.
> -- S. Hollenbeck, 2024-03-19

https://mailarchive.ietf.org/arch/msg/regext/pRSTKwvDRM4WM_s-nme2PRig4Z4/

In practice it domain:ext has not been widely used. And since we want
to maintain backward compatibility with existing systems. The author of
this document propose that we should choose pwAuthInfo over extAuthInfo
for better backward compatibility.

7. References

7.1. RFCs
    * RFC 1034 by P. Mockapetris
    * RFC 1035 by P. Mockapetris
    * RFC 5730 by S. Hollenbeck
    * RFC 5731 by S. Hollenbeck
    * RFC 5732 by S. Hollenbeck
    * RFC 7451 by S. Hollenbeck
    * RFC 7848 by G. Lozano
    * RFC 8334 by J. Gould, W. Tan, G. Brown
    * RFC 8807 by J. Gould, M. Pozun
    * RFC 9095 by J. Yao, L. Zhou, H. Li, N. Kong, J. Xie
    * RFC 9154 by J. Gould, R. Wilhelm
    * draft-ietf-regext-verificationcode-06 by J. Gould, R. Wilhelm, 

7.2. Other Documents
- Presentation: Transfer Authcodes at .se and .nu by Eric Skoglund
  (Apr 2024)
- Discussion: [\[regext\]Fwd: Idea about AuthCodeSEC: use PKI
  Cryptography for AuthCode]
  (https://mailarchive.ietf.org/arch/msg/regext/WPNywS9VAFhE3sJTRn9cR7FcRA4/)
(TODO: add other documents)

Author's Address

   Zainan (Victor) Zhou
   Namefi
   Email: zzn@namefi.io