[regext] Thoughts on AuthCodeSEC

2024-11-04 Thread Christian Simmen 

Hi Victor,

If I got you right the gaining registrar needs to be known at the time 
the AuthCode is submitted to the registry. AFAIK there are some use 
cases out there where this is not applicable. Can you describe how 
AuthCodeSEC would work in this case?


Thanks in advance
Christian

--
Christian Simmen
Product Owner Registry Services

DENIC eG | Theodor-Stern-Kai 1 | 60596 Frankfurt am Main | GERMANY
E-Mail: sim...@denic.de | Fon: +49 69 27235-464
https://www.denic.de

Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Thomas Keller, Martin Küchenthal, Andreas Musielak, Sebastian 
Röthler

Vorsitzender des Aufsichtsrats: Daniel Rink
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht 
Frankfurt am Main


Allgemeiner Hinweis zur Erfüllung unserer Informationspflichten gemäß 
Art. 13, Art. 14 DS-GVO: Informationen zur Verarbeitung 
personenbezogener Daten durch DENIC finden Sie unter 
https://www.denic.de/datenverarbeitung-allgemein/




smime.p7s
Description: Kryptografische S/MIME-Signatur
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Thoughts on AuthCodeSEC

2024-11-04 Thread Victor Zhou 
Christian,

Yes the goal is the receiver will need to be known at the time
AuthCode(SEC) is submitted to the registry.

Assuming you are talking about Model B
In the Model B, the receiver is Gaining Registrar. (As opposed to in Model
A the receiver is the Gaining Registrant.)

In Model B,
1. The registrant retrieves the public key identifier (PKI) of Gaining
Registrar(GR)
-- note: it can be retrieved by getting it from published by GR or its
website
2. The registrant asks its Losing Registrar to generate a AuthCodeSEC by
providing a PKI of GR.
3. Instead of randomly generating shared passwords, Losing Registrar signs
a RFC-AuthCodeSEC signature including PKI of GR.
LR gives AuthCodeSEC to the Registrant
4. The registrant gives AuthCodeSEC to the GR
-- note: Here we are skipping backward compatibility step: LR also submits
AuthCodeSEC to registry to be stored because In Model B, the registry is
required to support RFC-AuthCodeSEC
5. GR submits AuthCodeSEC to Registry with extInfo
6. The registry verifies the AuthCodeSEC and approves the transfer
-- note: skipping details about Pending Transfer, LR time to rejection etc


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



On Mon, Nov 4, 2024 at 6:37 AM Christian Simmen 
wrote:

> Hi Victor,
>
> If I got you right the gaining registrar needs to be known at the time
> the AuthCode is submitted to the registry. AFAIK there are some use
> cases out there where this is not applicable. Can you describe how
> AuthCodeSEC would work in this case?
>
> Thanks in advance
> Christian
>
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: draft-ietf-regext-rdap-x-media-type-02 Feedback

2024-11-04 Thread Mario Loffredo 

Hi,

please find my comments inline prefixed with [ML].

Il 01/11/2024 12:49, Gould, James ha scritto:


Upon a re-review of draft-ietf-regext-rdap-x-media-type with 
draft-ietf-regext-rdap-x-media-type-02, I have the following feedback:


*Section 2 "RDAP-X: The RDAP With Extensions Media Type" *

Needs to be updated to support the Extension Version Identifier 
implicitly or explicitly, defined in Section 3.1 "Extension Version 
Identifier" of draft-ietf-regext-rdap-versioning.  The mailing list 
feedback 
https://mailarchive.ietf.org/arch/msg/regext/L377YVNleqV7s7tJPWTGBLJIIG4/ provided 
an implicit (compatible) recommendation with 
draft-ietf-regext-rdap-versioning, and below is an explicit 
recommendation as well.


Implicit Support included in 
https://mailarchive.ietf.org/arch/msg/regext/L377YVNleqV7s7tJPWTGBLJIIG4/


 1. In Section 2: Change "This media type has a parameter of
"extensions" which is a whitespace-separated list of RDAP
extensions as defined in the IANA RDAP Extensions registry" to
"This media type has a parameter of "extensions" which is a
whitespace-separated list of RDAP extensions, *such as* defined in
the IANA RDAP Extensions registry”.
 2. In Section 3: Change “the values in the media type's extension
parameter SHOULD match the values in the rdapConformance array in
the return JSON.” to “the extension identifier values in the media
type's extension parameter SHOULD match the values in the
rdapConformance array in the return JSON.”

Explicit Support

 1. Make "I-D.ietf-regext-rdap-versioning" a Normative Reference
instead of an Informative Reference
 2. Add RFC5234 as a Normative Reference to leverage ABNF to formally
define the format of the “extensions” parameter.
 3. Update Section 2 to be modeled after Section 3.2.1” Versioning
Query Parameter” in draft-ietf-regext-rdap-versioning, by using
ABNF and referencing the extension-versioning-identifier ABNF rule
from draft-ietf-regext-rdap-versioning, as in:

The media type defined by this document is "application/rdap-x+json". 
This media type has a parameter of "extensions" that is a list of one 
or more Extension Version Identifiers, as defined in Section 3.1 of 
[I-D.ietf-regext-rdap-versioning 
], 
separated by whitespace.  This media type, RDAP with Extensions, is 
referred to as RDAP-X.  The Augmented Backus-Naur Form (ABNF) grammar 
 [RFC5234 
] format for the "extensions" 
parameter, using the "extension-version-identifier" rule from Figure 1 
of [I-D.ietf-regext-rdap-versioning 
], 
is:


extensions = "extensions=" DQUOTE extension-version-identifier *(WSP 
extension-version-identifier) DQUOTE


Examples of RDAP-X:

applications/rdap-x+json;extensions="rdap_level_0 rdapx"
applications/rdap-x+json;extensions="rdap_level_0 rdapx fred"

Note - It looks like the "rdapx" extension identifier is missing from 
the example, so I added it.



[ML] Agreed.


*Section 3 "Using The RDAP-X Media Type"*

My initial thought upon re-review of this section was to reuse the 
existing "application/rdap+json" media type by adding the optional 
parameter "extensions", or better "rdapx" to the media type 
registration, but then I got to Appendix B.1 that makes a good point 
with the language in RFC 6838.  I really don't want to include RDAP-X 
in the content-type header of the response, since it duplicates the 
rdapConformance member, and requires updating RFC 7480 with no real 
positive value.  Updating RFC 7480 may also trigger the need to bump 
rdap_level_0 to rdap_level_1, which is certainly not desired.  We 
should re-evaluate the language of RFC 6838 in its application to an 
RDAP extension.  How about adding support for RDAP-X in the accept 
header of the request and to have the response content-type header 
remain using the existing media type of "application/rdap+json"?  This 
would meet the need of the client providing the RDAP extension hints 
without the negative side effects of updating RFC 7480 and bumping 
rdap_level_0 to rdap_level_1.


*Section 4 "Usage of RDAP Links"*

The point of this section is recursing the RDAP extension hints in the 
links, which would also apply to the use of the query parameter of the 
versioning extension.  We can review for this applicability in the 
versioning draft.


*Section 6 "Security Considerations"*

You can remove the second paragraph, since that would be covered in an 
extension that supports query parameters, such as the versioning 
extension.



[ML] Agreed (see below the comment on Appendix B.2 for more details).


*Section 7 "IANA Considerations"*

I would add an RDAP Extensions Registry registration for "rdapx".

[ML] I agree that this specification is itself an extension insofar it 
extends the "app

[regext] Last Call: (Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values) to Proposed Standard

2024-11-04 Thread The IESG 

The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Extensible Provisioning
Protocol (EPP) mapping for DNS Time-To-Live
   (TTL) values'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2024-11-18. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document describes an extension to the Extensible Provisioning
   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
   (TTL) value for domain name delegation records.

About this draft

   This note is to be removed before publishing as an RFC.

   The source for this draft, and an issue tracker, may can be found at
   https://github.com/gbxyz/epp-ttl-extension.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/



No IPR declarations have been submitted directly on this I-D.





___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org