portal gui should send out email reminders when any cert in the chain will soon expire

[sraustein]

the pseudo arin root cert expired without anyone noticing. the portal gui is now digesting the rcynic cache, and should be able to send out email notifications ahead of time.

also see ticket #97 which is relating to the BPKI certs.

Trac ticket #104 component gui priority major, owner melkins, created by randy on 2011-10-13T21:13:08Z, last modified 2012-07-09T18:37:21Z

[sraustein]

how do i sign up for which notifications i want? i guess if i have a gbr, i want to be notified. but what if i am not a gbr owner?

Trac comment by randy on 2011-10-13T21:14:36Z

[sraustein]

for handles that are hosted on the same gui/rpkid, pull out the email address from all the web user accounts that are allowed to manage them, and perhaps cc the rpkid host as well?

gui should probably add a contact field for its children, so it can optionally send email reminding them to update certs as well.

Trac comment by melkins on 2011-10-13T21:20:12Z

[sraustein]

for a Parent object, Parent.ta.getNotBefore() and getNotAfter() will give me the validity period for the TA we received from the parent. And Parent.certificate is the cross-certificate issued under my TA. Both should be checked for expiration.

Trac comment by melkins on 2012-01-25T17:30:26Z

[sraustein]

The expiration checking process also needs to verify that RPKI certs issued to children are not due to expire soon. There are a couple of ways to get the expiration dates:

1) use left-right query to rpki for each handle. the response contains the base64 encoded object. the type of object can be inferred from the filename extension in the URI, since this is specified in the RFC. the disadvantage here is that there is added latency of making the calls to rpkid. this is fine for a script run under cron, but if the gui needs to do live reporting it will be annoying to the user

2) the rcynic cache is already digested into the web portal's database, so we can easily find all certs issued directly under each RPKI holder's resource certs. disadvtange of this approach is that already expired certs won't show up in the database because they will be culled by rcynic, and we only store information about currently valid objects in the web portal database. however if the intent here is to warn ahead of time before expiration happen, this would be a valid approach.

Trac comment by melkins on 2012-07-05T18:04:16Z

[sraustein]

Determining to which child a particular resource cert was issued is not straightforward using either of the solutions outlined in [https://trac.rpki.net/ticket/104#comment:5]. The problem is that the IRDB only contains requests, and rpkid actually creates and publishes the certificates. The <list_published_objects/> request via left-right doesn't contain the information about what request prompted a particular object to be created.

Trac comment by melkins on 2012-07-06T16:57:55Z

[sraustein]

For resource holders hosted on the same rpkid instance, I can cheat by looking at the <list_received_resources/> cache and comparing the URIs.

Trac comment by melkins on 2012-07-06T17:10:27Z

[sraustein]

rpkid.pdf SQL Fairy diagram of rpkid.sql Trac attachment by sra on 2012-07-09T18:37:21Z

[sraustein]

Well, rpkid of course knows to which child it issued any particular certificate. See attached diagram of the SQL.

Do you need something added to the response?

Trac comment by sra on 2012-07-06T17:40:56Z

[sraustein]

For resource certs, I would need the child.child_handle in the response.

Trac comment by melkins on 2012-07-06T17:48:37Z

[sraustein]

For resource certs, I would need the child.child_handle in the response.

Should be doable. Anything else for other objects?

Trac comment by sra on 2012-07-06T18:04:10Z

[sraustein]

Not sure for roas. Ideally, it would be nice to be able to somehow link the roa request in the IRDB positively to the published ROA, but I'm not sure how we'd do that.

For ghostbusters, specifying the parent.parent_handle (if present) would probably be useful.

Neither of those is important for the purposes of this ticket, however.

Trac comment by melkins on 2012-07-06T18:10:58Z

[sraustein]

Added child_handle attribute to , it only appears for child certificates.

The others (ROAs and Ghostbusters) are a different kind of problem, as rpkid doesn't really know the exact information you're looking for, it just knows what it did based on what it found (via queries to irdbd) at the time it created the objects in question, it doesn't really remember why. Arguably this is a design bug, but if so it's probably not a trivial fix.

Trac comment by sra on 2012-07-06T19:48:48Z

[sraustein]

In [changeset:4590]: {{{

!CommitTicketReference repository="" revision="4590"

use the client_handle specified in the response to determine child. references #104. }}}

Trac comment by melkins on 2012-07-06T20:16:17Z

[sraustein]

change [4592] implements the last piece of this bug report which is the addition of sending email to the ghostbuster contacts.

Trac comment by melkins on 2012-07-09T18:37:21Z

[sraustein]

Closed with resolution fixed