Handles privati - Role Objects - Proposta di implementazione

[Francesco ORLANDO]

Salve,

- Rif1: Art.4 delle Regole di Naming V 3.6
[ http://www.nic.it/NA/regole-naming-curr.html ]
- Rif2: Procedure Tecniche di Registrazione V 3.5
[ http://www.nic.it/NA/procedure-curr.html ]
- Rif3: Comunicato RA "Nuovo Controllo Sintattico" del 19/02/2002

Per facilitare i controlli sull'univocità delle registrazioni con il Codice Fiscale
propongo di creare un nuovo role-object con i seguenti records:

role: Codice Fiscale - ITA Personal TAX Code
pin: IT-ABCDEFaamddloccC
domain: domain.it                               # ** Individuals can register only one domain name **
person: Nome COGNOME
nicdb-hdl:     HANDLE-ITNIC
nic-hdl: ABCDEFaamddloccC-ITNIC
notify: admin-c a email
created: yyyymmdd
mnt-by: RA-MNT
upd-mnt: domain.it--MNT
changed:    domain a nic.it yyyymmdd
source: IT-NIC

l'oggetto può essere creato a partire dai records già presenti nel DB del Nic.it,
importando i campi secondo il seguente schema:

[pin ; pin > nic-hdl; domain ; admin-c > nicdb-hdl ; created ; mnt-by > upd-mnt] dal DB dei domini (persone fisiche)

[person ; domain ; email > notify] dal DB dei Nic-handles

l'interrogazione di questo DB tramite whois, permetterà di bloccare i moduli elettronici con PIN già presente nel DB (come già succede)
ed avvertire un utente (dopo una ricerca sul solo codicefiscale "PIN" ) che ha già un dominio intestato.(invece di aspettare l'invio di un modulo elettronico per verificarlo)

allo stesso modo potrebbe essere creato un role-object per i soggetti IVA, partendo sempre dai dati attuali ( e magari normalizzandoli tramite il DB di Infocamere)

role: Partita IVA - ITA V.A.T. Code
pin: IT-numeropartitaiva
domain: domain.it; domain1.it; domain2.it;                          ### ammessi valori multipli
domain: domain3.it
org: NomeSocietà
person: Nome COGNOME                                             ### ammessi valori multipli (fornire documentazione adeguata per delega /
personal-pin: IT-ABCDEFaamddloccC                            ### ammessi valori multipli                             assegnamento pro tempore
nicdb-hdl:     HANDLE-ITNIC                                        ### ammessi valori multipli
nic-hdl: numeropartitaiva-ITNIC
notify: admin-c a email
created: yyyymmdd
mnt-by: RA-MNT
upd-mnt: domain.it--MNT
upd-mnt: domain1.it--MNT
changed:    domain a nic.it yyyymmdd
source: IT-NIC

l'interrogazione di questo DB tramite whois, permetterà di verificare i moduli elettronici con PIN già presente nel DB (come già succede)
e segnalare automaticamente i dati dell'admin-c autorizzato a firmare (nell'ottica di una futura implementazione della LAR in PDF fornita automaticamente da RA); segnalare errori di diverso nic-handle; fornire un elenco univoco dei domini registrati da una partita IVA e/o dal PIN del Rappresentante Legale.

Si potrebbe anche prevedere di importare i certificati (e relative crl) pubblici di AIPA (da tutti gli enti certificatori) ed utilizzarli sia per l'autentica, che per creare un campo "direct-auth:" anche nei nuovi role-object [con gestione delle verifiche sulla firma digitale AIPA del mittente ed inoltro al maintainer per l'approvazione delle modifiche al record].

Per ottenere un beneficio "bidirezionale" dalla firma AIPA, RA potrebbe comunicare agli enti certificatori i domini/codicifiscali e domini/partiteIva, per rendere più snelli (e completi) i controlli fatti per verificare gli indirizzi di email di domini italiani. E gli Enti Certificatori AIPA comunicherebbero il rilascio di nuovi certificati per codici fiscali/partite IVA, autorizzandone quindi l'uso per gli scopi previsti da AIPA e spero presto "fatti propri" dalle Regole di Naming, con l'introduzione della Firma Elettronica dei Moduli in formato PDF, TIFF, etc. e dalle Procedure Tecniche, con la verifica della firma digitale AIPA per i messaggi inviati a auto-dbm a nic.it .

saluti
Francesco ORLANDO