public-l AT list.denic.de
Subject: Public DENIC mailinglist
List archive
- From: "Sabine Dolderer/Denic" <dolderer AT denic.de>
- To: Markus Warg <markus AT mail.du.gtn.com>
- Cc: noc AT entire-systems.com, public-l AT denic.de
- Subject: Re: Re: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!
- Date: Wed, 8 Nov 2000 18:55:03 +0100
Hallo Markus,
On 08.11.00 16:49 Markus Warg <markus AT mail.du.gtn.com> wrote:
>
> Daniel,
>
> On Mit, 08 Nov 2000, Daniel Roesen wrote:
>
> > On Wed, Nov 08, 2000 at 02:09:08PM +0000, Lutz Donnerhacke wrote:
> > > Dann freuen wir uns alle schon mal auf fehlende Handles auf INETNUM
> > > Objekten.
> >
> > Das kann eigentlich nicht passieren. Allerdings bedeutet es eben
> > doppelte Datenpflege. Als haette man sonst nichts zu tun. *sigh*
>
> Wie waere es mit einer globalen Handle-Meta-Datenbank, in der die
> moeglichst kompletten Stammdaten eines Users sowie die entsprechenden
> Handlenamen bei diversen Diensten in Verbindung gebracht werden?
>
> Dann haette man aber Probleme mit Handles, die sich per definitionem
> nicht Aendern lassen...
da sind wir beim Kern der Sache, jede Person mit allen Daten nur einmal
zentral verwaltet. Das klingt natürlich schön und wünschenswert, aber ....
Wenn man diese Personen nur noch an einer Stelle verwaltet und jeder sich
auf die Richtigkeit dieser Daten verlässt, muß man zwangsläufig zum
Ergebnis kommen, daß man auch erhebliche Anforderungen an die
Zuverlässigkeit dieser Daten stellen muß und die Vorraussetzungen für
Veränderungen dieser Daten dürften auch erheblich sein.
Damit dürften sich die folgenden Fragen leicht beantworten lassen.
Darf ein X-beliebiger Provider den Inhalt des Handle seines Kunden ändern?
Eigentlich nur nach exakter Prüfung der vom Kunden übermittelten Daten
(Vorlage Personalausweis, Telefonrechnung ...), um Mißbrauch zu vermeiden.
Wer garantiert, daß eine eingetragene Änderung richtig ist?
Der Provider, der das Handle zuerst kreiert hat, der Provider der etwas
geändert hat oder der Kunde, wenn man ihn denn erreicht.
Was wenn keiner der oben genannten Provider Kundenbeziehungen mit der
Person hat, deren Handle es betrifft, aber möglicherweise ein dritter
Provider inzwischen das Handle für den Kunden nutzt?
Wer ist für Updates zuständig?
Wer garantiert die Richtigkeit?
Wer bezahlt, wenn "versehentlich" mal eine Domain gelöscht wurde, weil
niemand das Handle gepflegt hat und deswegen niemand erreichbar war?
Das sind zwar alle lösbare Fragen. Aber wenn wir nicht eine
Superregistratur aufbauen wollen, wo jeder Kunde vor der
Domainregistrierung eine Handleregistrierung machen muß und darüber einen
Handlepflegevertrag abschließen muß, liese sich wohl keine rechtliche
Sicherheit erreichen. Und ob das verständlicher, wartbarer und komfortabler
ist, bezweifle ich ernsthaft.
Die pragmatische Alternative dazu ist, diverse Daten redundant
abzuspeichern und dies heißt eben, daß ein Kunde, wenn er eine Domain
beantragt, beim Provider seines Vertrauens eine Kundennummer bekommt und
unter dieser seine Daten abgelegt werden und jedesmal, wenn er den Provider
wechselt, bekommt er bei einem neuen Provider eine neue Kundennummer und
muß auch dort seine Daten angeben.
Damit nun diese Kunden nicht mit jeder Domain übertragen werden müssen, ist
eben die Möglichkeit gedacht für jeden dieser Kunden wieder individuelle
Kundennummern in der DENIC-Datenbank anzulegen, um die Referenzierbarkeit
einfacher zu machen. Jeder Provider ist dazu verpflichtet für seine Kunden
die Updates durchzuführen und wenn wir jemanden unter einer angegebenen
Adresse nicht erreichen, wenden wir uns an denjenigen, der den
Personeneintrag betreut.
DAs ist natürlich nicht die technisch und logisch eleganteste Lösung, aber
wenn man den ursprünglichen Vorschlag zu Ende denkt, wäre es doch am
einfachsten
<begin - kein ernst zu nehmender Vorschlag>
das Personalausweisregister der Bundesrepublik ins Netz zu stellen und als
zentrale Referenz für alle Internetdienstleistungen die
Personalausweisnummer sozusagen das BUND-HDL zu nehmen. Die Pflege der
BUND-HDL übernehmen dann die lokalen Meldestellen.
Der Vorteil ist, man hat dann nur eine Datenbank. Diese ist hinreichend
korrekt und wenn man das noch mit der Schufa verknüpft, dürften eigentlich
keine Wünsche mehr offen sein. Oder? ;-)
</end - kein ernst zu nehmender Vorschlag>
Ich plädiere im Licht der Argumente deswegen um Verständnis dafür, daß wir
uns eben nicht an einer Großlösung versuchen, sondern einen pragmatisch
gangbaren Weg suchen.
Viele Grüße
Sabine Dolderer
>
> just my .02
>
> Markus
>
> --
> VIA NET.WORKS Deutschland GmbH
m.warg AT via-net-works.de
> Bismarckstr. 120 www.via-net-works.de fon: +49 203
3093-101
> D-47057 Duisburg Deutsches Provider Network fax: +49 203
3093-112
>
>
Sabine Dolderer
DENIC eG
Wiesenhüttenplatz 26
D-60329 Frankfurt
eMail: Sabine.Dolderer AT denic.de
Fon: +49 69 27235 0
Fax: +49 69 27235 235
- Re[4]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, (continued)
- Re[4]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/08/2000
- RE: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Christian Storch, 11/08/2000
- Re: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Lutz Donnerhacke, 11/08/2000
- RE: Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Christian Storch, 11/08/2000
- Re[4]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/08/2000
- Re: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Daniel Roesen, 11/08/2000
- Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/08/2000
- Re: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Eric Schaetzlein, 11/09/2000
- Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/09/2000
- Re: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Lutz Donnerhacke, 11/09/2000
- Re: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Daniel Roesen, 11/08/2000
- Re[4]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/08/2000
- Re: Re: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Sabine Dolderer/Denic, 11/08/2000
- Re: Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Sabine Dolderer/Denic, 11/08/2000
- Re[4]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/09/2000
- Re[5]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/09/2000
- Re[4]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/09/2000
- Re: Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, henning . brauer, 11/09/2000
- Re: Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Gert Doering, Netmaster, 11/09/2000
- Re[4]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Florian Effenberger, 11/09/2000
- Re: [public-l] unzureichende Sicherheit der DomainsvorManipulationen!!!!, Carsten Schiefner, 11/10/2000
- Re: Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Gert Doering, Netmaster, 11/09/2000
- Re: Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, henning . brauer, 11/09/2000
- Re: Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Gert Doering, Netmaster, 11/10/2000
- [public-l] Re: unzureichende Sicherheit der Domains vorManipulationen!!!!, Daniel Roesen, 11/10/2000
- Re: Re[2]: [public-l] unzureichende Sicherheit der Domains vorManipulationen!!!!, Gert Doering, Netmaster, 11/10/2000
Archive powered by MHonArc 2.6.19.