[regext] Re: Call for agenda items IETF 121

[Victor Zhou <[e-mail]>]

Greatly appreciated, James, for your detailed discussion. Yes, we are aware
of
RFC-9154 and are honored to have a response from you, the author of it, and
expressed your interest.

We are thinking about proposing two main things to further secure the
transfer:
1. Using a cryptography public-key authentication algorithm enabling
validation
   of the authenticity of the source of approval from the Name Holder or
   someone the Name Holder approves, such as a Registrar.
2. Ensuring specific and more directed approval of the transfer of a
domain, for example,
   to which new Name Holder, identified by a public key, the domain should
be
   transferred.

We will soon publish a newer version on
https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/README.md to
further discuss our proposal goals and how to achieve that.

Victor,
CEO & founder of Namefi <http://namefi.io>, tokenizing domain names for
trading, DeFi and future Internet. https://namefi.io



On Fri, Oct 18, 2024 at 4:57 AM Gould, James <[e-mail]> wrote:

> Victor,
>
>
>
> You’re probably aware of the Secure Authorization Information for Transfer
> RFC 9154 (https://datatracker.ietf.org/doc/html/rfc9154) which is
> focused on making the authinfo secure by having it short-lived, stored
> securely when needed (e.g., null outside a transfer process or stored as a
> 1-way hash during a transfer process in the registry), and use of a strong
> random authinfo value.  I view aspects of RFC 9154 being applicable to
> authinfo extensions as well, but it had not been considered.
>
>
>
> The Domain Name Mapping (RFC 5731) does include an extension point for the
> authinfo, using the <domain:authInfo><domain:ext> element if you have a
> different authinfo format to use.  I haven’t seen an attempt the extend the
> authinfo format, but there is an extension point, and there is support for
> the authinfo extension in the Verisign EPP SDK (
> https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks)
> but it hasn’t been tested with the lack of authinfo extensions.  I believe
> the authinfo extension would need to be signaled in the EPP greeting and
> the EPP login command, using the extension URI in a <extURI> element.
> Below is a potential example:
>
>
>
>    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
>
>    <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
>
>      <command>
>
>        <create>
>
>          <domain:create
>
>           xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>
>            <domain:name>example.com</domain:name>
>
>            <domain:period unit="y">2</domain:period>
>
>            <domain:ns>
>
>              <domain:hostObj>ns1.example.net</domain:hostObj>
>
>              <domain:hostObj>ns2.example.net</domain:hostObj>
>
>            </domain:ns>
>
>            <domain:registrant>jd1234</domain:registrant>
>
>            <domain:contact type="admin">sh8013</domain:contact>
>
>            <domain:contact type="tech">sh8013</domain:contact>
>
>            <domain:authInfo>
>
> *             <domain:ext>*
>
> *               <authcodesec:code*
>
> *
>                 xmlns:authcodesec="urn:ietf:params:xml:ns:epp:authcodesec-0.1">*
>
> *                   TBD*
>
> *               </authcodesec:code>*
>
> *            </domain:ext>*
>
>            </domain:authInfo>
>
>          </domain:create>
>
>        </create>
>
>        <clTRID>ABC-12345</clTRID>
>
>      </command>
>
>    </epp>
>
>
>
> The EPP greeting and the EPP login would include:
>
>
>
>    S:      <svcExtension>
>
>    S:        <extURI>urn:ietf:params:xml:ns:epp:authcodesec-0.1</extURI>
>
>    S:      </svcExtension>
>
>
>
> The EPP login command would include:
>
>
>
>    C:        <svcExtension>
>
>    C:        <extURI>urn:ietf:params:xml:ns:epp:authcodesec-0.1</extURI>
>
>    C:        </svcExtension>
>
>
>
> I’m interested in what enhancements you propose.
>
>
>
> Thanks,
>
>
>
> --
>
>
>
> JG
>
>
> [image: cid87442*image001.png@01D960C5.C631DA40]
>
>
> *James Gould *Fellow Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *Victor Zhou <[e-mail]>
> *Date: *Thursday, October 17, 2024 at 5:59 PM
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] [regext] Re: Call for agenda items IETF 121
>
>
>
> *Caution:* This email originated from outside the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> Dear REGEXT WG and chairs,
>
>
>
> Could we have 10min to talk about
>
>
>
> rfc-draft-AuthCodeSEC:
> https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/README.md
> <https://secure-web.cisco.com/1gpR78OCj-qila2syz-CTZMYBRFhxMKUWeNF9-OdsiEZ8HI6UoCU0MYVWj3Jda1_0FyOli802y3TwCSpKVY_YBUI9KP_EH6PNfYHMu5EUO5rCbrVIinS38TM6BhKRZX0zfTljtzsvjdBP5WRRAAgEiO6ZkZC6UpHaC5kao98mqO6cgHtcjhc6INbNjmK3zkIrJzLe-KkEtIKQ0UzDZ3W3k0S5wmOpDpfPH-F_T6jPFHjTzQNTeCmxuTqvYkg6BhogmuEbBoBDwhNNmSd996RryBEPKanJF_IR2wFWpOxkAHnDRHVRsSTgpqFSHG79CK5A/https%3A%2F%2Fgithub.com%2Fxinbenlv%2Frfc-draft-authcodesec%2Fblob%2Fmain%2FREADME.md>
>
>
> Victor Zhou,
>
> Building Namefi (https://namefi.io
> <https://secure-web.cisco.com/1Gauiz9q27EF_JqEdsdCddEk98WfEuiytOxDlIRxUEEPc2LYd-x6zWBfg7TlNo9aciDEiOKSXIaedA4RraRdHFbuNwmQj5kaSPUnHwS6uNXqY09APg45CZIbcHxbK60lSKjG2fWAPeSSGPdtOOmfgeZQXCOyGpcuNClGigfjsYwbUZYHdnm6Kr15AfDmTBE8vA60BZIZpDpn1j6ffeCOrVYGJPXo1mxaCQFRF-Lxqorche5PmlRWkV3_W3ap-K1QucHfC0jqvQZWNLO_O0GCN6HfbkVRHIyH8YbAChjPwEFaXFbzhQSE4g7GJTXoe1_Rh/https%3A%2F%2Fnamefi.io%2F>) by
> D3Serve Labs Inc (https://d3serve.xyz
> <https://secure-web.cisco.com/1mqI3ABKfW-w_ogEBU7OC79M4ILM5Bvw2OgvqpynzwTIfpaRHXeAMzk44yRllYVVw-7EHfW-sNn41ANaZTq7fdcY-TA88cUX2lgSKcZWsOtYRKa9UsOMGgwKLOWJkDQxtxOc9VvwTPvJsZ7FMDfm8x0XDYjWehP-DnAdwxdcJnFk946QI5vioYIAJ6D5tEWb0ZVeazxY6u7rn2I3Amdk6LAY8fCqMBUu3o06Vwi7lfhReBvtv96kxEWMGg0h-YrKgN9XJefuk9zAlTnlYcEekY7vG00iOntUuZQjdUsmJPAXnPwIIhSsMIqW0fJpRuJf7/https%3A%2F%2Fd3serve.xyz>
> )
>
>
>
> ---
>
>
>
> Dear REGEXT WG,
>
>
>
> This is a call for agenda items for IETF 121.
>
> Just as last time, we will have 2 slots in Dublin.
>
> 1 hour for administrative items and a 2 hour slot for new work with more technical in dept presentations.
>
>
>
> Please send any requests to the chairs or respond to this email.
>
>
>
> Please forgive me if I have missed requests already sent to the mailinglist in the past weeks. I’m trying to catch up after some weeks of absence.
>
> So far I have noted 1 request from James Gould on implementation experience with the EoH and EoQ drafts on the preliminary agenda.
>
>
>
> Regards,
>
>
>
> Your co-chairs Jim and Antoin.
>
>