On 05/11/2018 16:12, Edward Shryane wrote:
This has been the behaviour at least since the re-implementation in 2012, we retained the existing behaviour for compatibility.
I would not mind breaking this compatibility for a slight increase in security. Since the current behaviour has been in place for 6 or more years.
The RIPE database does validate key expiry but only adds a warning to the response. Should the RIPE database refuse to apply updates signed with an expired key?
I will strongly PREFER if updates signed with an expired key is refused.
Should the RIPE database refuse to apply updates that were signed more than 'n' minutes ago (or in the future) ?
I would say YES to this one. And prefer at most 1 hour of maximum accepted time since the message was signed. Before the update message will not be accepted and an error returned to the sender.
Revoked keys indeed cannot be used any more. To revoke a key, you will need to update the existing key-cert object with the revoked version. You can also delete the key-cert object.
Is it enough to update or delete a revoked key? Should the RIPE database process key revocation certificates?
o If emailed to auto-dbm@. I suggest it be processed and queued for automatic removal from the DB. o Having a regular scan of existing keys in the DB. And automatically remove the ones recently expired with a warning message to the maintainer of the automatic removal. Is what I will strongly prefer. (Similar process to how unreferenced person objects is removed today) Christoffer