[Ndn-interest] KeyLocator name vs Certificate name

[Junxiao Shi]

Dear folks

Looking over mailing list threads, it turns out that IssuerId is not the
only missing information between KeyLocator name and successful retrieval
of a certificate that conforms the validator's expected trust model. We are
also missing the ForwardingHint.

https://www.lists.cs.ucla.edu/pipermail/nfd-dev/2018-October/003398.html
*NDNCERT developers have suggested that *validators need to use
ForwardingHint to retrieve the certificates issued by NDNCERT and published
on NDNCERT server, if these certificates are not otherwise published by the
producer itself. The *ForwardingHint necessary to reach the certificates
should be placed as an extension field in the SignatureInfo*.

This is, in principle, as bad as putting IssuerId as part of the KeyLocator
name.
Putting IssuerId into KeyLocator name restricts the Data packet to be
verifiable only by validators using one particular trust model.
Putting ForwardingHint into SignatureInfo restricts certificate retrieval
steps to communicate with one particular Certificate Authority, which is
equivalent, from trust model point of view, to limiting to one particular
IssuerId.

Yours, Junxiao

On Tue, Oct 1, 2019 at 1:51 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Dear folks
>
> I wonder what's the relation between KeyLocator name and Certificate name?
>
> Packet format spec
> <https://named-data.net/doc/NDN-packet-spec/0.3/signature.html#keylocator>
> says this on KeyLocator name:
> The specific definition of the usage of Name and KeyDigest options in
> KeyLocator field is outside the scope of this specification. Generally, *Name
> names the Data packet with the corresponding certificate*. However, it is
> up to the specific trust model to define whether this name is a full name
> of the Data packet or a prefix that can match multiple Data packets. For
> example, the hierarchical trust model
> <https://named-data.net/publications/techreports/trpublishkey-rev2/> uses
> the latter approach, requiring clients to fetch the latest version of the
> Data packet pointed by the KeyLocator (the latest version of the public key
> certificate) in order to ensure that the public key was not yet revoked.
>
> Certificate format spec
> <https://named-data.net/doc/ndn-cxx/0.6.6/specs/certificate-format.html#name>
> defines certificate name to be:
> /<SubjectName>/KEY/[KeyId]/[IssuerId]/[Version]
>
> *KeyId* is an opaque name component to *identify an instance of the
> public key *for the certificate namespace. The value of Key ID is *controlled
> by the namespace owner *and can be an 8-byte random number, SHA-256
> digest of the public key, timestamp, or a simple numerical identifier.
>
> *Issuer Id* is an opaque name component to *identify issuer of the
> certificate*. The value is *controlled by the certificate issuer* and,
> similar to KeyId, can be an 8-byte random number, SHA-256 digest of the
> issuer’s public key, or a simple numerical identifier.
>
> In today's testbed, most applications are setting the KeyLocator name to
> be /<SubjectName>/KEY/[KeyId].
> For example, ivoosh server's Data packet /ndn/web/video/research_questions/hls/playlist.m3u8/%FD01/%00%00
> uses KeyLocator name /ndn/web/KEY/%29%964%F6%11%12%1C%9A .
> After expressing an Interest for that name, I receive a certificate named
> /ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%00%00%01i%FE%FD~%BF .
>
> Everything seems to be working fine. However, *what if there are more
> than one certificates associated with the key?*
> Suppose the namespace owner requests me to issue a new certificate to his
> existing public key, I could execute:
> ndnpeek /ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%00%00%01i%FE%FD~%BF |
> base64 | ndnsec cert-gen -i X - | base64 -d > X.data
> and then let him publish the new certificate:
> /ndn/web/KEY/%29%964%F6%11%12%1C%9A/X/%FD%00%00%01m%88%1E%0A%07
>
> Now, *anyone who asks for a certificate using the KeyLocator name*
> /ndn/web/KEY/%29%964%F6%11%12%1C%9A *could receive either of the two
> certificates*.
> The validator, depending on the trust model, could be expecting one of
> these certificates.
> If it happens to receive the other certificate, validation would fail
> because the signer does not match policy.
>
> So, what's the solution space?
>
> Trying to *ensure there is only one issuer per key* defeats the purpose
> of having IssuerId name component in the first place.
> The reason to have IssuerId is that, a namespace owner can obtain
> certificates from multiple issuers on the same public key, so that the same
> content can be made available under multiple trust models.
>
> *Adding IssuerId to KeyLocator name* seems to fix the problem of
> validator receiving the wrong certificate.
> However, this would require the namespace owner to generate separate Data
> packets for each trust model.
> In this case, she may as well use separate keys.
>
> *Providing all certificates in a bundle* could solve the problem.
> The producer would include certificates from multiple distinct trust
> models in the certificate bundle
> <https://redmine.named-data.net/issues/2766#note-30>, and then the
> validator should attempt to validate the original packet using each
> certificate matching the KeyLocator name, and accept the original packet if
> any certificate chain leads to a trust anchor configured in the validator.
> A drawback of this solution is inflation of certificate bundle size.
>
> *Appending an IssuerId component in the validator *appears to be the best
> solution. The validator needs to know, through static configuration, what
> IssuerId to append to each KeyLocator name.
> For example, a validator configured to work with ndncert-legacy's
> certificate chain could be configured to always append 'NA' as IssuerId.
> Given the KeyLocator name shown above, the validator would fetch
> certificate using /ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA and it would
> receive the expected certificate.
>
> Please REPLY-ALL with your thoughts on this topic.
>
> Yours, Junxiao
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20191002/9ff667ab/attachment.html>