- db-wg - mailman.ripe.net

Re: [ncc-services-wg] Re: [db-wg] The New "organisation object" Proposal
by azucena.hernandezperez＠telefonica.es 29 Aug '03

29 Aug '03

I support the view of Hans Petter regarding the additional identification of each organisation by a number making it a separate object in the database. I am in favor using the VAT number for organisations in EU countries and soon in the Eastern Europe Accessing countries and any other national registration number for those organisations established in non-EU countries. Azucena Hans Petter Holen <hpholen(a)tiscali.no> Enviado por: ncc-services-wg-admin(a)ripe.net 29/08/03 19:17 Para: Engin Gunduz <engin(a)ripe.net> cc: Hans Petter Holen <hpholen(a)tiscali.no>, DB-News <db-news(a)ripe.net>, <db-wg(a)ripe.net>, <ncc-services-wg(a)ripe.net> Asunto: [ncc-services-wg] Re: [db-wg] The New "organisation object" Proposal Clasificación: Uso Interno > I think that this is something too specific to have its own attribute. > "remarks:" attribute can be used for this I guess, just like it can > be used to point users to web pages etc. I dont agree: the point about the attribute would be to uniquely identify the organisation within a country. I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number. The good thing is that it stays unique and lives trough name changes. Hans Petter ___________________________________________________________________________ Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. ___________________________________________________________________________

3 2

another attribute for organisation object
by Engin Gunduz 29 Aug '03

29 Aug '03

Dear colleagues, >From the feedback we've got, it looks like we want another attribute in the organisation object, in which users can put an "organisation number" or an "organisation-id". This can be a VAT number, or a number assigned by a certain Chamber of Commerce, or any kind of other ID. We would propose calling it "business-id:". We have thought of "org-id:" but the org-ID is the string we will have in "organisation:" attribute, so calling another attribute "org-id:" would be confusing. "national-id:" would have been another idea, but some IDs might not be a national one, like an ID assigned uniquely in the EU. So the proposal is to add business-id: [optional] [multiple] as a new attribute. It is optional, as an organisation might not have such an ID. It is multiple, because an organisation might have multiple such IDs. Thanks and best regards, -- Engin Gunduz RIPE NCC Database Group

1 0

upd: draft agenda (v1*A*), for DB-WG meeting, RIPE 46, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

[ sorry, forgot to include one item: new I., I. became J. ] [ -WW ] Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting at RIPE 46 in Amsterdam, NL. As usual, if you have any comments, corrections or additions please get back to me directly and asap. As we do have 2 slots this time - which are _not_ adjacent (on different days!) Verion 2 will try to sort the items into the bins for day 1 (Wed., 14:00 - 15:30) and day 2 (Thursday 9:00 - 10:30) NOTE: I have seen some discussion about the ERX, so I'm trying to offer the opportunity for the community affected to give short (if possible ;-) presentations about - experience, - expectation, - suggestiosn for improvement, after an intro provided by the RIPE NCC (from their point of view). If you intend to do that, pls. let me know before the start of the session! Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 1. Draft approx. A. Administrative stuff (WW, chair) 10 min . scribe: N.N. B. Action Items 15 min C. WG mandate and charter, part I (WW, chair) 10 min . splitting the load between DB, Services, and? D. DB operational update (RIPE NCC, Shane K.) 20 min E. ERX status 30 min . status as from the point of view of the NCC 5 min . short reports about experience 20 min . proposals for improvements? 5 min F. The "status:" attribute (RIPE NCC, N.N.) 15 min G. The org: Object proposal revised (RIPE NCC, Engin G.) 15 min H. Revised PKI proposal (RIPE NCC, Shane K.) 30 min I. change of behavior/default of DB-SW (RIPE NCC, Shane K.) 10 min . if "mnt-lower: is absent: .. makedefault more consistent .. lean towards a more secure behavior J. WG mandate and charter, part II (WW, chair) 10 min . review of alignement with other WGs . summary . editorial finalisation Y. Input from other WGs . Z. AOB: . tent.: review of DB Architecture and Assumptions . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-AUG-2003 10:40:44 UTC _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

1 0

draft agenda (v1), for DB-WG meeting, RIPE 46, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting at RIPE 46 in Amsterdam, NL. As usual, if you have any comments, corrections or additions please get back to me directly and asap. As we do have 2 slots this time - which are _not_ adjacent (on different days!) Verion 2 will try to sort the items into the bins for day 1 (Wed., 14:00 - 15:30) and day 2 (Thursday 9:00 - 10:30) NOTE: I have seen some discussion about the ERX, so I'm trying to offer the opportunity for the community affected to give short (if possible ;-) presentations about - experience, - expectation, - suggestiosn for improvement, after an intro provided by the RIPE NCC (from their point of view). If you intend to do that, pls. let me know before the start of the session! Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 1. Draft approx. A. Administrative stuff (WW, chair) 10 min . scribe: N.N. B. Action Items 15 min C. WG mandate and charter, part I (WW, chair) 10 min . splitting the load between DB, Services, and? D. DB operational update (RIPE NCC, Shane K.) 20 min E. ERX status 30 min . status as from the point of view of the NCC 5 min . short reports about experience 20 min . proposals for improvements? 5 min F. The "status:" attribute (RIPE NCC, N.N.) 15 min G. The org: Object proposal revised (RIPE NCC, Engin G.) 15 min H. Revised PKI proposal (RIPE NCC, Shane K.) 30 min I. WG mandate and charter, part II (WW, chair) 10 min . review of alignement with other WGs . summary . editorial finalisation Y. Input from other WGs . Z. AOB: . tent.: review of DB Architecture and Assumptions . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-AUG-2003 10:40:44 UTC _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

1 0

call for agenda items, DB-WG meeting, RIPE 46 @ AMS, NL
by Wilfried Woeber, UniVie/ACOnet 21 Aug '03

21 Aug '03

"Somewhat" urgent: Call for agenda items! >Date: Tue, 12 Aug 2003 12:01:21 +0200 > >Dear WG Chair, > >We are less than three weeks away from the RIPE Meeting. To make sure >that we have all Working Group Agendas published and printed on time, I >kindly ask you to send us your agenda. > >The deadline is Wednesday 20 August. Although the deadline has passed already (and I am wading through and sorting and trashing a mail backlog of 5K+), we need an agenda for the WG meeting. I am going to include the "usual stuff" from my end, plus an item for discussion on WG mandate. And I have (during my absence for vacation - which I dearly needed ;-) received a couple of requests already which will make it into the 1st draft. Everything alse has to come from the community, so submit your input and ideas, please!! Thanks, see you in AMS, Wilfried.

1 0

Fwd: [db-wg] X.509 authentication in the RIPE Database, take II
by Joao Luis Silva Damas 20 Aug '03

20 Aug '03

On Friday, August 15, 2003, at 04:23 PM, Shane Kerr wrote: > Joao, > > Joao Luis Silva Damas wrote: >> adding a new strong authentication method to the Database, is in my >> own personal opinion, a good thing(tm), particularly if the same >> credential can be used for other interactions with the RIPE NCC, make >> user's life easier. >> I wonder however about a few questions: >> - will this auth method be available only to RIPE NCC members? Is it >> not seen as a valuable general addition for non-member users of the >> IRR part of the RIPE DB? > > Initially it will only be available for RIPE NCC members. Another interesting change in the model? When you say initially, does this mean it will be extended or not? Shall on read the current proposal as implicitly stating this? > There are three ways we could extend the service to non-LIRs: > > 1. Accept certificates from certain "well-known" CAs, for example > Thawte, Verisign, etc. > > 2. Issue certificates from a RIPE NCC CA established for this purpose, > and accept them. > > 3. Accept all certificates, including self-signed certificates. > > #1 is relatively easy - the main overhead would be maintaining the > Certificate Revokation Lists from the CAs. Deciding which CAs to > support may also be tricky. #2 is also relatively easy, since we > already have the technology. #3 is more difficult, and would require > a slight change of the design, and administration issues (see below). For DB authentication purposes, why do you need to verify the certificate? As with the PGP model[1], the only assumption one needs to make is that the message issuer is the holder of the private part of the certificate. If the RIPE DB is going to start making assertions about the real identity of the message sender, rather than just authorise or refuse updates, this seems to be a change in the model that warrants discussion in the working group. Is this so, or am I misinterpreting your description of the mechanism? > >> - Why the choice of not publishing the pulic part of the certificated >> in the DB? The choice to have a key-cert for the PGP method was not >> to do with issues of web of trust but rather for purposes of helping >> the users with their data maintenance. As a matter of fact the >> recommendation regarding the use of PGP in the RIPE DB, as described >> in the RFC and the minutes of the DBSEC TF, was to use a PGP key for >> this purpose that was not used elsewhere. > > When you receive a PGP-signed message, you need the public key of the > signer to verify the signature. The program that updates the Database > needs this information, and it is stored in the key-cert objects(*). > > With S/MIME, the certificate is sent with the message, and this > certificate is signed by the CA. Since the database is configured to > know how to verify certificates issued by specific CAs, we can verify > the signature. No key-cert is necessary. > > But if we decide to allow any certficate, including self-signed, then > we need some way to allow users to store this information in the > database, for example key-cert objects. Unfortunately, this may cause > problems, because (for instance) someone could create a key-cert > object for a CA run by another organisation with bogus data, > preventing users from using certificates *actually* issued by that CA. > > We could possibly require these sort of key-cert objects be reviewed > by some method, for example RIPE DBM. However, if the RIPE NCC has no > relationship with the CA, we have no real way to know the validity of > any one request. Why do you need to verify the certificate. Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features? Joao [1] RFC 2726

3 2

Re: [address-policy-wg] IP Addressing policy on personal contact info (kf)
by Shane Kerr 20 Aug '03

20 Aug '03

Pascale Julienne, Pascal Julienne wrote: > In France there is such a thing as unlisted phone numbers which > remain private and unknown. Further, the RIPE DB is becoming the > best spam list in the world. So yes, responsability lays with LIR, > yes let's clean the DB, yes respect privacy. I think there are two sides to this issue. One is what the RIPE NCC can and has done to increase the privacy of people who have contact information in the Database. We have been trying to increase the privacy protections in the Database over time: - person/role objects removed from public FTP site - DB automatically rate limits access to person/role objects - mntner/irt objects removed from public FTP site - .DE person object deletion - automatic cleanup of unreferenced person/role objects The Allocation Editor on the LIR Portal should allow LIRs to keep their contact data up-to-date. We have talked with the Dutch Data Protection Authority about the Database as well, to make sure that we don't run afoul of the EU privacy directives. There has been some discussion at the last RIPE meeting about how the Database both aids and hinders spammers. Suggestions such as checking validity of contact information, as well as possibly putting fake entries in the Database and tracking spam they receive were mentioned. The second issue is deciding on what contact data *should* be in the Database. This is the job of the address-policy-wg, and perhaps the db-wg. A related issue is how the data should be accessed, which is also something that can be decided by the same groups. Katri Forsberg did a service by raising the issue. As a final issue, I am curious why you say the RIPE Database is becoming the best spam list in the world! I think that it probably generates a lot of spam for LIRs, because they have their contact information on many objects in the Database. I don't know any way to avoid this if the Database is public. I hope that for the end users who's information is in the Database for only a small number of addresses that they do not get much spam originating from the publication in the Database. The RIPE NCC is certainly interested in mechanisms that we can set up to prevent such use, as it is explicitly *not* allowed by the license that we provide for the Database. -- Shane Kerr RIPE NCC

5 4

X.509 authentication in the RIPE Database, take II
by Shane Kerr 18 Aug '03

18 Aug '03

All, [Apologies for duplicate e-mails] Attached please find a proposal for X.509 authentication in the RIPE Database. From the Database point of view (that is, syntax and semantics), it is the same as the one sent 3 July 2003. The difference is that it contains only the specific details of the change, in a straightforward fashion. I hope that we have addressed questions about the use of X.509 that arose in earlier discussions. -- Shane Kerr RIPE NCC Addition of X.509 authentication to the Database Proposal: To add an X509 authentication type to the "auth:" attribute. Attributes with this type will use the Distinguished Name (DN) of the certificate to identify it. Motivation: X.509 allows a single authentication method to work for both e-mail and the web. LIRs can receive an X.509 certificate through the LIR Portal, and should be able to use this to update records they control in the Database. X.509 is "strong", like PGP, although a different trust model is used. Details: The "auth:" attribute of the mntner class will have a new authentication scheme, X509. The DN, as defined in RFC 2253, will be used to identify the specific certificate used. Note that there is no key-cert object for the X509 scheme. Instead, the certificate must be signed by a trusted authority. The trusted authority will be the RIPE NCC Certificate Authority (CA) that is currently only available to LIRs. It is possible to configure additional CAs in future, should this become desirable. For instance, existing commercial CAs could be allowed, or the RIPE NCC could create a CA to issue certificates to non-LIRs for this purpose only. Below is an example of a maintainer with X.509 authentication: mntner: EXAMPLE-MNT descr: Sample maintainer for example. admin-c: SWK1-RIPE tech-c: RD132-RIPE tech-c: HOHO-RIPE upd-to: ripe-dbm(a)ripe.net mnt-nfy: ripe-dbm(a)ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1 auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2 notify: ripe-dbm(a)ripe.net mnt-by: EXAMPLE-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030813 source: RIPE Usage: E-mail updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. Synchronous updates for objects maintained by a maintainer with X509 authentication must use an SSL connection using the private key from the issued certificate on the client side. Web updates for objects maintained by a maintainer with X509 authentication can use a browser with the certificate loaded. The web updates screens will allow users to specify that they want to identify themselves using the client-side private key, over an SSL connection.

3 3

Draft: "status:" re-evaluation
by Shane Kerr 15 Aug '03

15 Aug '03

All, We recently proposed changes to the "status:" attribute values in the RIPE Database: http://www.ripe.net/ripe/draft-documents/status-attributes.html We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on. In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that. Proposal: Add "SUB-ALLOCATED PA" to the allowed "status:" values. "SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object. A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice. -- Shane Kerr RIPE NCC

6 9

RIPE Whois Server version 3.2.0
by DB-News 14 Aug '03

14 Aug '03

Dear Colleagues, [ Apologies for multiple messages. ] The RIPE NCC is pleased to announce the release of version 3.2.0 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release adds several user-visible improvements: - dbupdate has been rewritten almost from scratch - the server now limits the number of concurrent connections per IP - transaction support is added on MySQL side - query parsing is revised Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.2.0 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.2.0.tar.gz If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Best regards, Engin Gunduz RIPE NCC Database Group

5 6