Re: [certtest] Welcome to the certification test

  • To: Woeber@localhost
  • From: Robert Kisteleki robert@localhost
  • Date: Sat, 31 May 2008 12:47:57 +0200
  • Organization: RIPE NCC

Hello,

(Disclaimer: I'm speaking as one who has been working in the inter-RIR resource certification architecture design team from the NCC.)

Wilfried Woeber, UniVie/ACOnet wrote:
Dear Tim,

thanks for this ingtroduction and preview of activities!

Disclaimer: I am not an expert in certification technology, so
please be patient :-)

After reading he proposal I am wondering how and where this is
supposed to get us "in the end", or for a production stage.

I do understand that the initial steps will be focused on providing
a web-based, "hosted" (at the NCC) set of services. However my feeling
is that web-based services are difficult to script and automate.

The interface that will be opened for you in this hosted case is really the "command and control" channel. You'll really only use it if you want to alter the behavior of the system we run for you, or if you want to instruct it to do something specific. Otherwise the "RPKI engine" is envisioned to highly automated, so it will do most of the magic on its own. Therefore it probably has little value to make this communication scriptable.

Of course, if there is sufficient need for this, then the implementation team will surely act accordingly.

So - are there any plans (already) to provide remotely usable tools
for access to, eg., the ROA repository?

The repositories themselves are going to be public (they have to be, in order to enable relying parties to fetch the contents), accessibe through rsync. There are tools already out there to do fetching/verification, but you have to realize this is a work in progress, so they are not yet complete.

My feeling is that the provision of CRL info is already pointing into
this direction as I wouldn't need access to those lists as long as all
the verifications have to be done (manually) at the hosted services
site? Correct?

CRLs (or indeed, some form of revocation information) are a must in this system, and they will be used by any verification software, be it a hosted on a CLI version. This is a part of the "relying party toolset".

Best regards,
and looking forward to test-drive all that stuff,
Wilfried (from LACNIX XI in Bahia)

PS: I presume I can find the pointer to the modified version of OpenSSL
somewhere (in the vicinity of APNC?), but could you distribute that info
here on the list (in due time), too?

RFC3779 support has been a part of the official OpenSSL package since 0.9.8e, thanks to Rob Austein (ISC). Thus you'll very probably find it in your favorite distribution. Note though that this is a very low level tool in the RPKI world.

Regards,
Robert