[DBWG] Making mnt-by mandatory on person objects

[Michel ODOU]

Dear DBWG members,

Please note that to fix this issue, the following features are currently
tested and will be deployed with the next WHOIS release:

1. Every time someone creates an unprotected (no mnt-by attribute)
person object, a maintainer will be generated and associated with this
person object. This maintainer will have an auto-generated password that
will be sent to all the emails specified in the person object. The
generated maintainer will be locked and the user will not be able to
modify it.

2. The auto-generated maintainer will be deleted automatically when it
is no more in use (i.e when the person object is protected with another
maintainer and the generated one is not referenced anymore).

3. For all the person objects that are in the DB that do not have an
mnt-by, a maintainer will be generated and associated to the object and
the password of this maintainer will be sent to the email address
specified in the person object if it exists or the notify email address
otherwise. Note that some objects have no email address at all. They
will still be protected. We don't expect these objects to be ever
claimed but in case it happens, the "owner" will have to prove the
hostmasters that he is the legit owner.

Regards,
Michel


On 13/12/2016 16:15, Michel ODOU wrote:
> Just one thing though: making the mnt-by mandatory for person objects is
> not an easy thing since you need a person object first to create a mntner.
> 
> So, to protect a person object, you need ... a person object. It is
> therefore not really possible to make it mandatory. But as said in my
> previous mail, we can put the person object into quarantine for some
> time until it is protected and delete if after otherwise. And of course,
> as you suggested, forbid the use of unprotected objects if they are to
> be referenced.
> 
> Regards,
> Michel
> 
> On 05/12/2016 19:35, fransossen at yahoo.com wrote:
>>
>>
>>  
>> Hi list,
>>
>> I noticed that person objects can be created and then referenced away in the AFRINIC Database without any maintainer listed on them as mnt-by, which means they also can get updated without any maintainer.
>>
>> This is at the moment an issue on potential data quality and nuisance but will become an even greater issue once the transfer policy kicks in, as "hijacking" a person will be rather easy, simply change the email address and place a maintainer under your control on the person object, it doesn't give you the maintainer listed on the resources...but you're almost there.
>>
>>
>> An immediate action that could can be taken is that the AFRINIC does not allow to issue resources to organisation that have unprotected person objects, basically, if a person's nic-hdl is listed in myAFRINIC, it must have a mnt-by.
>>
>> Any nic-hdl referenced on resources issued by AFRINIC *must* have a mnt-by, if the nic-hdl referenced is a role object, all persons within that role object must have an mnt-by:
>>
>> This can be pointed out in the very first interaction with the LIR, thus not delaying anything in most cases.
>> Further actions would need to be taken to clear up all the objects without maintainer that already exist and will not have contact with the hostmasters for the coming period of time, but that's the part that requires planning. 
>>
>> I haven't looked up the numbers, so I do not know the size of the issue, I just noticed that some LIRs old and new had that issue in their records.
>>
>>
>>
>> Cheers,
>> David Hilario
>>
>> _______________________________________________
>> DBWG mailing list
>> DBWG at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/dbwg
>>
> 
> 
> 
> _______________________________________________
> DBWG mailing list
> DBWG at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20170116/3dce0a1e/attachment.sig>