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

Zhiyi Zhang Zhiyi.Zhang at ucla.edu
Mon May 4 22:26:21 PDT 2020 

I think there can be two choices?

The first choice is to have two copies of Data:
Since there can be two different chains, it is reasonable to generate two
copies with different key locators.
I would further assume that two packets should have different names to
indicate they belong to different chains?

The second choice is to prepare two copies of Key Bundle:
Let's encrypt still uses one key name for both certificate chains, but
depending on requester's browser version, the producer can prepare two key
bundles:
If the browser's version is new enough, the producer should provide the key
bundle to ISRG; otherwise, provide the key bundle with IdenTrust as the
anchor.

But in either case, I think it requires application knowledge (e.g.,
client's browser version) to treat different clients differently.

Best,
Zhiyi

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

> I think his scenario is that both chains exist simultaneously (not one
> taking over another).  And he doesn’t want to have multiple copies of the
> same data with different key locators (but signed with the same key bits),
> which does cause a problem since you don’t know which copy you end up
> fetching.
>
> Lan
>
> On May 5, 2020, at 12:04 AM, Zhiyi Zhang <Zhiyi.Zhang at ucla.edu> wrote:
>
> 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/86551260/attachment-0001.html>

More information about the Ndn-interest mailing list