[Ndn-interest] [EXT]Re: KeyLocator name vs Certificate name

Mon May 4 22:04:30 PDT 2020

Hi Junxiao,

I thought of the same question triggered by a question asked by an
undergrad in our group.
At that time, my answer is to use a different key name (with the same
identity name) if you have multiple chains.

Does this solve the problem?
Let's say we have:
/lets-encrypt/KEY/*X3*/ISRG/35=%01
/lets-encrypt/KEY/*X3-temp*/IdenTrust/35=%01

Before ISRG's cert gets installed by all major browsers, Let's Encrypt can
use /lets-encrypt/KEY/X3-temp to sign the packets so verifiers won't fetch
a wrong certificate.
After ISRG's cert gets installed, Let's Encrypt can gradually start to
use /lets-encrypt/KEY/X3.

Best,
Zhiyi

On Mon, May 4, 2020 at 12:02 PM Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

> OK, I suggest discussing these two questions at the Friday call too.
>
> Lan
>
> On May 4, 2020, at 1:48 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Hi Lan
>
> For (2), it's not an operational issue.
>
> Today's testbed certificates are (directly or indirectly) created with *ndnsec
> cert-gen* command, which is part of ndn-cxx codebase.
> In ndn-cxx KeyChain, signing operation is at the granularity of "key",
> whose name ends with the KeyId component. This is what causes KeyLocator to
> only have KeyId component.
>
> Future testbed certificates are created with NDNCERT v0.3.
> If it's believed that certificates should have exact names in the
> KeyLocator field, I think Zhiyi should make that happen in his CA
> implementation.
> I have another independent NDNCERT v0.3 implementation in NDNts codebase,
> and I can certainly make this change as well.
>
> Yours, Junxiao
>
> On Mon, May 4, 2020 at 1:41 PM Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
>
>> *External Email*
>> I see.  I think (1) can be discussed further at the weekly call on
>> Friday.  For (2), you can discuss with John.
>>
>> Lan
>>
>> On May 4, 2020, at 12:32 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>> Hi Lan
>>
>>
>> 1. I think the KeyLocator field could be extended to contain multiple
>>> locators if the situation you mentioned below is to be supported.
>>>
>>
>> For a scenario with multiple unrelated trust anchors, having more than
>> one Name in the KeyLocator still leaves the question of "which certificate
>> to fetch". However, the consumer could always pursue every certificate
>> chain, and find the one trust anchor.
>>
>> 2. For the current testbed, why is there a need to use exact name of the
>>> certificate given there is only one trust anchor?
>>>
>>
>> There's no guarantee that "NDN Testbed Root" is the only trust anchor.
>> Application can create an "overlay" that uses a different trust anchor.
>> If I publish a certificate following a different trust anchor and it
>> somehow gets into the cache, future validations that expect "NDN Testbed
>> Root" trust anchor will fail.
>>
>>
>>>
>>> 3. I’m just curious why you are encountering a problem right now (maybe
>>> this is related to 2).
>>>
>>
>> I published a self-signed certificate in a repo. This isn't invalid
>> action, because a self-signed certificate is a valid Data packet.
>> However, this breaks validation, because the validator's certificate
>> retrieval Interest is being satisfied by the self-signed certificate, and
>> then it cannot trace back to the trust anchor.
>>
>> Yours, Junxiao
>>
>>
>>> Lan
>>>
>>> On May 4, 2020, at 11:03 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
>>> wrote:
>>>
>>> Hi Lan
>>>
>>> Putting the exact or full name of the certificate in KeyLocator is
>>> certainly an option.
>>> It works well in the common case, where each key is used under only one
>>> trust model.
>>>
>>> It becomes suboptimal in an uncommon use case:
>>>
>>>    - There are two distinct groups of consumers that want to fetch my
>>>    Data.
>>>    - Both groups use the hierarchical trust model, but with different
>>>    trust anchors.
>>>    - Currently, I could:
>>>       - Obtain a certificate under each trust anchor, with different
>>>       IssuerId.
>>>       - Publish the Data only once with KeyLocator ending at the KeyId
>>>       component.
>>>       - Suppose the consumers can *magically* figure out the IssuerId
>>>       for their group, they can verify the Data successfully.
>>>    - If the KeyLocator should be exact/full names, I'll have to publish
>>>    the Data twice.
>>>
>>>
>>> However, given today's testbed has a single trust anchor, should the
>>> KeyChain implementations default to putting the exact name of the
>>> certificate into KeyLocator?
>>> To start, the certificates issued by testbed infrastructure should have
>>> exact names in KeyLocator.
>>>
>>> Yours, Junxiao
>>>
>>> On Mon, May 4, 2020 at 11:46 AM Lan Wang (lanwang) <lanwang at memphis.edu>
>>> wrote:
>>>
>>>> *External Email*
>>>> If the KeyLocator uses the full name of the certificate, would there
>>>> still be a problem?  If not, then the application just needs to use the
>>>> certificate name.
>>>>
>>>> There is also a KeyDigest option defined in the spec.  That may be
>>>> another solution.
>>>>
>>>> A KeyLocator specifies either Name that points to another Data packet
>>>> containing certificate or public key or KeyDigest to identify the
>>>> public key within a specific trust model (the trust model definition is
>>>> outside the scope of the current specification). Note that although
>>>> KeyLocator is defined as an optional field in SignatureInfo block,
>>>> some signature types may require presence of it and some require
>>>> KeyLocator absence.
>>>>
>>>> KeyLocator = KEY-LOCATOR-TYPE TLV-LENGTH (Name / KeyDigest)
>>>> KeyDigest = KEY-DIGEST-TYPE TLV-LENGTH *OCTET
>>>>
>>>> See Name specification
>>>> <https://named-data.net/doc/NDN-packet-spec/current/name.html#name> for
>>>> the definition of Name field.
>>>> 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
>>>> [BZA+13]
>>>> <https://named-data.net/doc/NDN-packet-spec/current/signature.html#testbed-key-management> 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.
>>>>
>>>>
>>>> Lan
>>>>
>>>> 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.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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>
>>>>
>>>>
>>>
>>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20200504/fe03abbd/attachment-0001.html>