[Ndn-interest] KeyLocator name vs Certificate name

[Junxiao Shi]

Hi Lan

Whether "both certificates are valid for the same key" depends on the trust
schema of the validator. I'm not dealing with multiple trust anchors here.

A real world example: when Let's Encrypt started, its root certificate
"ISRG Root X1" was not recognized by browsers, so they had their "Authority
X3" key cross-signed by IdenTrust.
[image: image.png]

The equivalent in NDN would be "Authority X3" key has two certificates:
/lets-encrypt/KEY/X3/ISRG/35=%01
/lets-encrypt/KEY/X3/IdenTrust/35=%01

On a packet signed by "Authority X3" key, the KeyLocator name would be
/lets-encrypt/KEY/X3.
Suppose we have a validator that ONLY knows IdenTrust as a trust anchor,
but does not recognize "ISRG Root X1" as a trust anchor.
When it sends an Interest for /lets-encrypt/KEY/X3 , it could receive the
certificate /lets-encrypt/KEY/X3/ISRG/35=%01 that have a KeyLocator
/isrg-root/KEY.X1 .
The validator will then retrieve the "ISRG Root X1" certificate, and see
it's a self-signed certificate but not a trust anchor (remember this
validator ONLY recognizes IdenTrust).
Eventually, validator rejects the original packet.

What SHOULD happen is that, the validator needs to retrieve the
/lets-encrypt/KEY/X3/IdenTrust/35=%01 certificate instead of (or in
addition to) /lets-encrypt/KEY/X3/ISRG/35=%01 certificate.
This would allow it to continue validation toward a known trust anchor.

The question here is: how could the validator know to retrieve the
/lets-encrypt/KEY/X3/IdenTrust/35=%01 certificate?

Yours, Junxiao

On Thu, Oct 3, 2019 at 8:19 AM Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

> If both certificates are valid (for the same key), why would the trust
> model expect only one of the certificates, not the other one?  The trust
> model should be updated to allow either one.  My recent ICN paper talks
> about supporting multiple trust anchors and schemas for this case.   This
> is something the application can do, although maybe library support will
> help.  For more information, you can read:
>
> A. Gawande, J. Clark, D. Coomes, *L. Wang*, "Decentralized and Secure
> Multimedia Sharing Application over Named Data Networking
> <http://web0.cs.memphis.edu/~lanwang/paper/ICN19-npchat.pdf>," in *Proceedings
> of ACM Conference on Information Centric Networking*, Sept. 2019
>
> Lan
>
> On Oct 2, 2019, at 8:35 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Hi Lan
>
> Finding the latest certificate name ("latest" as in "latest version") is a
> solved problem: Realtime Data Retrieval (RDR) protocol allows a validator
> to identify which version is the latest.
> Suppose there are two certificate versions from the same issuer:
>
>    - /ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%01
>    - /ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%02
>
> Using RDR protocol, the validator could ask:
> /ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/32=metadata CanBePrefix=1
> MustBeFresh=1, and get a reply that %FD%02 is the latest version.
>
> However, *knowing the latest version does not help when there are
> multiple issuers*.
> In the example given in my last post
> <https://www.lists.cs.ucla.edu/pipermail/ndn-interest/2019-October/002600.html>,
> there are certificates issued by two separate issuers:
>
>    - /ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%00%00%01i%FE%FD~%BF
>    - /ndn/web/KEY/%29%964%F6%11%12%1C%9A/X/%FD%00%00%01m%88%1E%0A%07
>
> RDR cannot currently operate on this level, but can easily be extended to
> do so. Then, the latest version among these two certificates would be
> /ndn/web/KEY/%29%964%F6%11%12%1C%9A/X/%FD%00%00%01m%88%1E%0A%07 as its
> version component has a greater number. However, if the validator is
> expecting ndn-testbed-root-v2 trust anchor, the validation will fail.
>
>
> *Enumerating the namespace* using namespace catalog protocol
> <https://redmine.named-data.net/issues/4666> might help. The validator
> can:
>
>    1. Enumerate /ndn/web/KEY/%29%964%F6%11%12%1C%9A namespace, and find
>    there are two issuerIds "NA" and "X".
>    2. Fetch the latest certificate under each issuerId.
>    3. Determine which certificate(s) to follow up according to trust
>    schema.
>
> However, isn't it better to make issuerId part of the trust schema itself,
> so that the validator could skip the namespace enumeration step.
>
>
> A related problem: both RDR and namespace catalog protocol need some way
> to verify the response Data packets come from the namespace owner. If we
> don't yet have the certificate of the namespace owner, how can we trust the
> responses?
>
> Yours, Junxiao
>
> On Wed, Oct 2, 2019 at 8:52 AM Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
>
>> It seems to me that a separate system is needed to find the latest
>> certificate name (e.g., through NDNS).  That’s an orthogonal issue to the
>> KeyLocator format which seems to be fine the way it is.
>>
>> Lan
>>
>> On Oct 1, 2019, at 12: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/20191004/eedadadb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 53139 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20191004/eedadadb/attachment-0001.png>