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
signature.asc
Description: OpenPGP digital signature
