IRT object and authentication schemes
Hi, someone's prodded me wrt. the IRT object registration. This finally made me take a closer look at the available documentation defining this object type. I have one question (well, I may have more, but this one is the most important one, I think): In section 5 of http://www.ripe.net/ripe/docs/irt-object.html I find the following text: When adding a reference to an irt object the update of an inet[6]num should pass the following authorisation checks: * from the irt object itself as specified in one of the "auth:" attribute * from any of the mntner objects that protect the inet[6]num object (i.e. referenced using "mnt-by:" attribute). Is there a logical AND between these two items? (I think there is, but it really ought to be said explicitly, and the "should pass" phrase should be replaced by "must pass both of".) This is pretty crucial when evaluating what should be registered in the IRT object, as unwise choices (no overlap between irt auth: and mntnr auth:) on this front will at best make it very cumbersome to add IRT references to inetnum / inet6num objects, requiring nested signatures (I wonder, does the RIPE DB support that?). Oh, yes, I also think the IRT definition document needs to say a few words about what specific roles the admin-c and tech-c of an IRT object is supposed to fill. Regards, - Håvard
Havard Eidnes wrote: Håvard,
someone's prodded me wrt. the IRT object registration. This finally made me take a closer look at the available documentation defining this object type. I have one question (well, I may have more, but this one is the most important one, I think):
In section 5 of
[SNIP]
Is there a logical AND between these two items? (I think there is, but it really ought to be said explicitly, and the "should pass" phrase should be replaced by "must pass both of".)
Indeed, there is a logical AND. Both the auth: for (any of the) maintainers AND the auth: for the IRT object MUST pass. So, yes, it should (or must?) be a "MUST pass".
This is pretty crucial when evaluating what should be registered in the IRT object, as unwise choices (no overlap between irt auth: and mntnr auth:) on this front will at best make it very cumbersome to add IRT references to inetnum / inet6num objects, requiring nested signatures (I wonder, does the RIPE DB support that?).
The usage of two separate auth: keys is meant to be and yes the database supports double authorization. First the LIR can make the request to add the mnt-irt: attribute to the inet[6]num, sign it and pass this on to the IRT. The IRT in turn signs the signed request to show that the IRT agrees.
Oh, yes, I also think the IRT definition document needs to say a few words about what specific roles the admin-c and tech-c of an IRT object is supposed to fill.
In fact this is no different than with most other objects that (can) have admin-c and tech-c fiels. E.g. the admin-c can be the head of the IRT and tech-c can be his/her co-workers. Both can be either references to person or role objects. Regards, Menno Pieters -- Menno Pieters - Stelvio Postbus 2171, 3800 CD Amersfoort, the Netherlands Zonnehof 41, 3811 ND Amersfoort, the Netherlands phone: +31-33-4.697.340 / fax: +31-33-4.697.341 XOIP: +31-84-8.720.349 / Web: http://www.stelvio.nl/
participants (2)
-
Havard Eidnes -
Menno Pieters