Dear all,
We have posted -02. It remains an individual, Experimental draft and we are not requesting adoption. Four breaking changes, made deliberately in a single revision while we are aware of no implementations. The extension identifier is now "reliabilityAssessment". The JSON member is renamed accordingly and carries an array of results rather than a single object, since results from more than one issuer on the same object are the natural case. scoreScheme and scoreIssuer are now required, and scoreIssuer must be a stable URI rather than an opaque local name. The additions respond to Vienna. There is a deployment model: the assessment service is not authoritative for registration data, it returns a minimal response instead of mirroring and enriching the authoritative one, and it does not belong in the RFC 9224 bootstrap. There is a section on subject binding, and one placing requirements on any scheme whose results are published: notification, a remediation and contestation period, a disclosure threat model. We also separate identity, trust and authenticity, and say plainly that authenticity is out of band in this revision rather than implying that scoreIssuer delivers it. The draft declares Opaque Versioning, per Section 6.1 of draft-ietf-regext-rdap-versioning. Mario, thank you for the clarification on NIS2. The Security Considerations now follow your formulation: the directive does not prohibit publication, but systematic and unauthenticated disclosure may be difficult to reconcile with the risk-based obligations of Article 21 where it substantially increases the exposure of the assessed entity. Two questions we would particularly like answered. 1. Does anything in RDAP today assume that a server answering /domain/<ldhName> is authoritative for that domain? Ours is not. It returns only enough to bind the response to the object, plus the extension member, rather than mirroring the authoritative response and adding to it. If that breaks an assumption somewhere, we would rather hear it now than after someone implements it. And if you would expect such a server to return more than the minimum, please say so. 2. Can object tagging (RFC 8521) be used by a server that is not authoritative for the registration data? We bind our entity objects to the assessed registrar with publicIds carrying the IANA Registrar ID, and we deliberately do not define a lookup by Registrar ID, since that would turn a response extension into a query extension. The consequence is that a client who knows both the registrar and the assessor still cannot construct the entity handle to query. Object tagging would solve that, but it was designed to reach the authoritative server, and we are not it. Finally, the comment that this may be a solution in search of a problem remains fair, and we would rather answer it with evidence than with argument. If you operate or plan to operate an assessment program, implement RDAP clients, or would consume this kind of data, we would like to hear from you. A statement that you would not use it, and why, is equally useful. Best regards, Alessandro Bertoldi (Bertoldi Cybersecurity) Simon Pietro Romano (University of Naples Federico II) draft: https://datatracker.ietf.org/doc/draft-bertoldi-regext-rdap-reliability-scoring/ "Empowering your business with cutting-edge cybersecurity solutions, safeguarding your digital assets and ensuring a seamless, secure experience for your customers." BertoldiCybersecurity GCVE Numbering Authority (GNA 128) Alessandro Bertoldi Owner T. +39 0185 799079 M. +39 348 5130136 E-Mail [email protected] www.bertoldicybersecurity.comhttps://bcsec.io
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
