Re: [regext] CDS/CDNSKEY vs. EPP update prohibited

[Eric Skoglund <[e-mail]>]

To add my 2 cents I agree with Scott here given what the spec says. We've (Swedish internet foundation) interpreted it in our implementation to mean that we shouldn't
allow the change to go through.

// Eric Skoglund
________________________________
From: regext <[e-mail]> on behalf of Hollenbeck, Scott <shollenbeck=[e-mail]>
Sent: 02 December 2022 15:13
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [regext] CDS/CDNSKEY vs. EPP update prohibited

> -----Original Message-----
> From: regext <[e-mail]> On Behalf Of Michael Bauland
> Sent: Friday, December 2, 2022 8:55 AM
> To: [e-mail]
> Subject: [EXTERNAL] Re: [regext] CDS/CDNSKEY vs. EPP update prohibited
>
> 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.
>
> Hi,
>
> On 02.12.2022 14:07, Gould, James wrote:
> > Michael,
> >
> > The prohibited statuses apply to client requests, which matches Case 2.
> > The
> prohibited statuses can apply to client requests via multiple channels
> (e.g., EPP
> or Web UI).  The prohibited statuses don't apply to server actions (e.g.,
> auto
> renew, transitioning RGP statuses).  Use of CDS/CDNSKEY records to signal a
> server-side change is an interesting case, where does posting CDS/CDNSKEY
> records represent a client request that is processed by the server
> asynchronously?  I view the CDS/CDNSKEY as a new operation (e.g., DNSSEC
> automation update), supported by IETF RFCs, that does not apply to the
> existing
> EPP prohibited statuses.  All domain changes come down to an update, but EPP
> included prohibited statuses on a per operation / command basis.
> >
> > I would then define Case 3, where CDS/CDNSKEY records represent is a new
> client operation that does not apply to the existing EPP prohibited
> statuses.  If
> we did want to prohibit this new operation via EPP, then a new prohibited
> status would be warranted.
>
> I tend to agree. Changing the DNSSEC data here is not an operation
> requested/initiated by the client (i.e., registrar), but it's something the
> server
> (registry) does, because it got triggered via the DNS. For this reason the
> clientUpdateProhibited flag should be ignored.

[SAH] You can't assume that "client" always means "registrar". That's
precisely why you don't see the word "registrar" in the specification. Note,
also, what 5731 actually says about the status (the other RFCs say the same
thing):

"Status values that can be added or removed by a client are prefixed with
"client"."

It's about who can manage the status value. It's not about who can perform the
update.

"Requests to update the object (other than to remove this status) MUST be
rejected."

Again, there's nothing here about *who* is performing the update. This use
case is covered by the existing specification text.

Scott

_______________________________________________
regext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/regext