February 2019 - db-wg - mailman.ripe.net

Whois Release 1.93
by Edward Shryane 04 Mar '19

04 Mar '19

Dear Working Group, RIPE Database release 1.93 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Monday, 25th February. Release 1.93 includes the following main changes: * Improved email address validation. * Do not allow expired public keys to authenticate updates, and expire signed messages after 1 hour. * Validate bogon space in route(6) creation. * Warn the user if the resource abuse-c is identical to the organisation's abuse-c. * Allow use of elliptic curve algorithm in key-cert objects (updated cryptography library). * Fixed NRTM client parsing end of stream comment in keepalive mode. * Filter out comment in autocomplete API (used by the DB web application) * Only validate reserved words in primary key on create, so existing objects can be updated. * Database schema changes for 2017-02 Abuse-c Validation implementation. The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt The release notes will also be published shortly: https://www.ripe.net/manage-ips-and-asns/db/release-notes More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 2

No more personal objects in the RIPE Database?
by Hans Petter Holen 23 Feb '19

23 Feb '19

Following Denis’s presentation at the last database working group meeting and Elvis’s messages to the RIPE NCC members list I think it is time to have a new discussion on the need for personal objects in the RIPE Database. https://ripe77.ripe.net/presentations/63-PERSONobjects.pdf https://ripe77.ripe.net/archives/video/2298/ https://www.ripe.net/ripe/mail/archives/members-discuss/2019-February/00329… This is not questioning previous legal assessments of GDPR compliance, but taking a step back and looking at how would we do this if we were to design the RIPE Database with today's privacy requirements in mind. The ccTLD for .NO, Norid made an update to their service last year to completely remove person objects from their database. https://www.norid.no/uploads/2017/12/Datamodell-revidert-en-v2.pdf In terms of the RIPE Database, that would mean that resources would refer to organisational objects and roles, not to personal objects. Perhaps Denis and/or Elvis would propose a policy change in this respect? Hans Petter

3 3

Re: [db-wg] Idea: magic mntner for all LIR contacts
by Tore Anderson 19 Feb '19

19 Feb '19

* Aleksi Suhonen > On 03/12/2018 10:35, Tore Anderson via db-wg wrote: >> So I was thinking: is this mandatory and error-prone duplication of work >> really necessary? Wouldn't it be possible to instead have some kind of >> magic mntner object that is is kept automatically up to date with «auth: >> SSO»-attributes for all the LIR user accounts? > > I second this idea. Perhaps this should be a different object type tho, to make it clear that editing the magic maintainer by hand will have undesired results. It should be interchangeable with normal maintainers of course, a bit like person objects and role objects are. Or maybe just expand the existing SSO attribute to accept a RegID. For example: mntner: FOOBAR-MNT auth: SSO no.foobar Which would allow maintenance by all registered user accounts in LIR no.foobar (except for accounts with the «billing» privilege level). > Do you want someone to co-author a PDP on this? I was hoping that a PDP wouldn't be necessary, to be honest. That is, if the NCC thought it was a good idea they could just go ahead and implement it. (If I recall correctly, the «auth: SSO» functionality was added without there being a community policy demanding it.) That said, if you want to write a proposal to this effect I'd be happy to put my name on it. Tore

9 44

Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects
by Christoffer Hansen (Lists) 11 Feb '19

11 Feb '19

Dear DB WG, It came to my attention the RIPE NCC Database does not do validation of signed updates. (Other than checking the key is allowed to sign updates for object(s) in question) I got the understanding from writing to DB-WG-Chairs this was a decision made years back. I think is less than optimal from a security perspective an signed update (with GPG and/or X509 certs) is not validated against (1) when the update was signed (E.g. signing was done 10 minutes ago) and (2) that the expiration date for the keys are not validated. Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used any more. But the RIPE NCC Database does still allow this currently. This is relevant in the case I ever lose a private GPG-key|X509-cert to less than friendly 3rd-parties. And the lost private GPG-key|X509-cert is the one used for signing updates to the database. What I have in mind. Is the RIPE NCC Database begins verifying validity (not revoked and/or expired) of GPG-key|X509-cert used to sign updates with. Christoffer

7 10