Subject: [regext] Clarify on RFC 5731

From: Ulrich Wisser <[email-masked]>
Date: Wed, 16 Nov 2016 07:21:16 +0000

Greetings from Seoul!

At one of the last Centr meetings we came up with a clarifying question
about the domain:info response.

Today many implementations use the domain:authInfo as a token for domain
transfer.
That makes domain:authInfo really sensitive. Basically it puts it in the
same class as passwords.
As we have all learned in the past, passwords should be saved as salted
hashes.
But this makes it impossible to return the domain:authInfo to the client.

RFC 5731 makes the auth:pw part in the domain:info report optional in the
xml schema. But the text in section 3.1.2 says

-  An OPTIONAL <domain:authInfo> element that contains authorization
      information associated with the domain object.  This element MUST
      only be returned if the querying client is the current sponsoring
      client or if the client supplied valid authorization information
      with the command.

Does this mean that it is ok to never return domain:authInfo?

/Ulrich

-- 
Ulrich Wisser
[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 17 Nov 2016 22:25:15 +0000

From: regext [mailto:[email-masked]] On Behalf Of Ulrich Wisser
Sent: Wednesday, November 16, 2016 2:21 AM
To: [email-masked]
Subject: [regext] Clarify on RFC 5731

Greetings from Seoul!

At one of the last Centr meetings we came up with a clarifying question about the domain:info response.

Today many implementations use the domain:authInfo as a token for domain transfer.
That makes domain:authInfo really sensitive. Basically it puts it in the same class as passwords.
As we have all learned in the past, passwords should be saved as salted hashes.
But this makes it impossible to return the domain:authInfo to the client.

RFC 5731 makes the auth:pw part in the domain:info report optional in the xml schema. But the text in section 3.1.2 says

      with the command.

Ulrich, there are places in the RFC text where we had to use conformance language because of limitations in what could done with XML Schema. You can’t, for example, make authInfo required in some responses and not others using XMLSchema – I had to make the schema able to do both, and the special processing is described in the text. With respect to your specific question, authInfo should NOT be exposed to anyone but the sponsoring client or a client that has demonstrated that they already have it by including it with the query command.

Scott