NFD

I made some progress on this.

infoedit -f /etc/ndn/nfd.conf -d rib.auto_prefix_propagate
infoedit -f /etc/ndn/nfd.conf -d rib.localhop_security
curl -sfL https://named-data.net/ndnsec/ndn-testbed-root-x3.ndncert | base64 | tee /etc/ndn/certs/ndn-testbed-root-x3.ndncert
echo '
rule
{
  id "rib register command"
  for interest
  filter
  {
    type name
    regex ^<localhop><nfd><rib>[<register><unregister>]<>{3}$
  }
  checker
  {
    type customized
    sig-type ecdsa-sha256
    key-locator
    {
      type name
      regex ^<>*<KEY><>{1,3}$
    }
  }
}
rule
{
  id "hierarchy"
  for data
  filter
  {
    type name
    regex ^<>*<KEY><>{3}$
  }
  checker
  {
    type customized
    sig-type ecdsa-sha256
    key-locator
    {
      type name
      hyper-relation
      {
        k-regex ^(<>*)<KEY><>{1,3}$
        k-expand \\1
        h-relation is-prefix-of
        p-regex ^(<>*)$
        p-expand \\1
      }
    }
  }
}
trust-anchor
{
  type file
  file-name certs/ndn-testbed-root-x3.ndncert
}
' | infoedit -f /etc/ndn/nfd.conf -a rib.localhop_security

The pcap trace is my test result.
There are two (logical) end hosts connected to the same NFD router, one uses UDP and the other uses TCP.

All certificates are fetched into the router cache before sending the registration command.
This is for convenience, and does not affect validation logic in any way.

Frame 7 is a prefix registration command with a certificate name in the KeyLocator: /ndn/gr/edu/mmlab1/%40GUEST/robik29763%40sofiarae.com/KEY/36=%00%05%B8%BE%DBm%07%B0/NA/%FD%00%00%01v%F9%94%1E%1A.
This certificate and its ancestors all have key names in their KeyLocator fields.

Frame 22 is a prefix registration command with a key name in the KeyLocator: /ndn/gr/edu/mmlab1/%40GUEST/robik29763%40sofiarae.com/sunny5/KEY/%A2%3D%E3%06Fb%86%3F.
The referenced certificate is /ndn/gr/edu/mmlab1/%40GUEST/robik29763%40sofiarae.com/sunny5/KEY/%A2%3D%E3%06Fb%86%3F/NDNts-Personal-CA/35=%00%00%01wL%A5%91%22, retrieved in frame 20.
Its KeyLocator has a certificate name /ndn/gr/edu/mmlab1/%40GUEST/robik29763%40sofiarae.com/KEY/36=%00%05%B8%BE%DBm%07%B0/NA/%FD%00%00%01v%F9%94%1E%1A.

This test confirms that the given configuration snippet can accommodate both key name and certificate name in the KeyLocator of both signed Interest and Data.
However, current snippet only recognizes ECDSA signatures, but does not recognize RSA signatures.

This feature is merged.
Library issues discovered during code review are reported as #5145 and #4524.