[Ndn-interest] KeyLocator name vs Certificate name

[Junxiao Shi]

Dear folks

I'm running into this issue again recently.
Any ideas on how to resolve this?

Yours, Junxiao

On Fri, Oct 4, 2019 at 11:33 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> 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/20200503/3664447f/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/20200503/3664447f/attachment-0001.png>