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

[Junxiao Shi]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20200504/4b67886f/attachment-0001.html>