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 <jgo...@verisign.com> 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 > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Victor Zhou <z...@namefi.io> > *Date: *Thursday, October 17, 2024 at 5:59 PM > *To: *"regext@ietf.org" <regext@ietf.org> > *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. > >
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
