On Mon, Sep 25, 2023 at 12:56 PM Gould, James <jgo...@verisign.com> wrote:
> The Security Considerations states: > > Servers MAY exclude the redacted members for RDAP fields that are > considered a privacy issue in providing a data existence signal. > > This really seems like a 5th method of Redaction that should have its own > entry in Section 3. Or alternatively, should be documented in the 3.1 > Section. > (as in, this is not a security consideration, but an explicit feature) > > JG - This language is associated with the exclusion of the redacted member > in the redacted extension due to privacy concerns with providing a signal > of the existence of redacted data. The data in the response has been > redacted according to one of the methods in Section 3, but providing the > signal that it has been redacted via the redacted extension may cause > leakage of privacy information by the server. The potential of leaking > privacy information by the server based on redacted members being returned > in the redacted extension is the reason it's contained in the security > considerations, and it doesn't change how data itself is redacted, so it's > not applicable for Section 3. > This is re-stating the document text, and I still believe that a new feature should not be introduced in the Security Considerations section. In this case we have: 3.1. Redaction by Removal Method 3.2. Redaction by Empty Value Method 3.3. Redaction by Partial Value Method 3.4. Redaction by Replacement Value Method While the first 3.1 entry suggests "removal", it is really a Redaction by Replacement with a "redacted" statement. The Security Considerations introduce a real Redaction by Removal Method. I do still believe this belongs in Section 3, and is not a Security Consideration for an implementer to be aware about, but a Redaction Feature that needs implementing like the other 4 methods from Section 3. Moving the entire Security Considerations to a Section 3.1.1 or Section 3.5 and renaming it Redaction Privacy" makes more sense to me. Implementers reading the text will then know this is something that requires implementation. Since Section 3 extensively uses terminology from Section 4, I think it > makes > more sense to change the order of these two sections. > > JG - I believe it's best to describe the methods of redaction first prior > to describing how to signal the redaction methods in the extension; > otherwise, the extension will jump directly into the protocol prior to > setting the context for the inclusion of the extension. > That's fair, but I was reading a lot of things in the examples of Section 3 that are only introduced in Section 4, eg, "prePath", "postPath", "pathLang", "replacementPath". But if the authors prefer the current order, that is okay with me. Paul
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
