Victor, The epp:pwType is only used for the login command pw and newPw elements. The authInfo element is based on the pwAuthInfoType that is an extension of the normalizedString, so it doesn’t have the same constraint. The Login Security Extension in RFC 8807 was created to support login passwords beyond the 16-character limit in RFC 5730. Let me know if you have any questions or feedback with the Login Security Extension.
Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Victor Zhou <[email protected]> Date: Monday, December 1, 2025 at 4:54 PM To: REGEXT Working Group <[email protected]>, "Hollenbeck, Scott" <[email protected]> Cc: Sami Mishal <[email protected]> Subject: [EXTERNAL] [regext] Clarification on RFC 5730: Normative status of pwType maxLength="16" 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 Scott Hollenbeck and members of the REGEXT Working Group, I am writing to seek clarification regarding the pwType definition found in RFC 5730 (Section 4). The XML Schema definition provided in the RFC explicitly restricts passwords (and by extension, authInfo codes in RFC 5731) to a maximum length of 16 characters: XML <simpleType name="pwType"> <restriction base="token"> <minLength value="6"/> <maxLength value="16"/> </restriction> </simpleType> However, current operational reality differs significantly from this constraint. Many modern registry backends (such as CentralNic) and registrars routinely generate and accept authentication codes up to 64 characters in length to support higher entropy and modern security standards. Consequently, strictly validating EPP traffic against the RFC 5730 XSD results in validation failures for these longer, more secure keys. My questions are: 1. Is the maxLength value="16" constraint in the Section 4 schema considered normative (mandatory for compliance), or is the schema intended to be demonstrative of the structure, allowing implementations to adjust lengths as needed? 2. If it is normative, does the working group consider the 64-character usage to be a violation of the standard, or is there an accepted "best practice" deviation regarding password length that supersedes the original XSD? Clarification on this would greatly assist implementers in determining whether they should enforce strict XSD validation or relax these specific length constraints to match the ecosystem. Thank you for your time and guidance. Sincerely, Victor, founder of Namefi by D3Serve Labs Inc.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
