<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
I see. I think (1) can be discussed further at the weekly call on Friday. For (2), you can discuss with John.<br class="">
<div class=""><br class="Apple-interchange-newline">
<span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Lan</span>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On May 4, 2020, at 12:32 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" class="">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">Hi Lan<br class="">
</div>
<br class="">
<div class="gmail_quote"><br class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" class="">
<div class="">1. I think the KeyLocator field could be extended to contain multiple locators if the situation you mentioned below is to be supported.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" class="">
<div class="">2. For the current testbed, why is there a need to use exact name of the certificate given there is only one trust anchor?</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">There's no guarantee that "NDN Testbed Root" is the only trust anchor. Application can create an "overlay" that uses a different trust anchor.</div>
<div class="">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.<br class="">
</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" class="">
<div class=""><br class="">
</div>
<div class="">3. I’m just curious why you are encountering a problem right now (maybe this is related to 2).<br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I published a self-signed certificate in a repo. This isn't invalid action, because a self-signed certificate is a valid Data packet.</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Yours, Junxiao<br class="">
</div>
<div class=""><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" class="">
<div class="">
<div class=""><br class="">
<span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; display: inline; float: none;" class="">Lan</span>
</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On May 4, 2020, at 11:03 AM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank" class="">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">
<div class="">Hi Lan</div>
<div class=""><br class="">
</div>
<div class="">Putting the exact or full name of the certificate in KeyLocator is certainly an option.</div>
<div class="">It works well in the common case, where each key is used under only one trust model.</div>
<div class=""><br class="">
</div>
<div class="">It becomes suboptimal in an uncommon use case:</div>
<div class="">
<ul class="">
<li class="">There are two distinct groups of consumers that want to fetch my Data.<br class="">
</li><li class="">Both groups use the hierarchical trust model, but with different trust anchors.</li><li class="">Currently, I could:</li><ul class="">
<li class="">Obtain a certificate under each trust anchor, with different IssuerId.<br class="">
</li><li class="">Publish the Data only once with KeyLocator ending at the KeyId component.</li><li class="">Suppose the consumers can <i class="">magically</i> figure out the IssuerId for their group, they can verify the Data successfully.</li></ul>
<li class="">If the KeyLocator should be exact/full names, I'll have to publish the Data twice.<br class="">
</li></ul>
</div>
<div class=""><br class="">
</div>
<div class="">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?<br class="">
</div>
<div class="">To start, the certificates issued by testbed infrastructure should have exact names in KeyLocator.</div>
<br class="">
<div class="">Yours, Junxiao<br class="">
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, May 4, 2020 at 11:46 AM Lan Wang (lanwang) <<a href="mailto:lanwang@memphis.edu" target="_blank" class="">lanwang@memphis.edu</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">
<p style="text-align:center" class=""><font color="red" class=""><b class="">External Email</b><br class="">
</font></p>
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.
<div class=""><br class="">
</div>
<div class="">There is also a KeyDigest option defined in the spec. That may be another solution.</div>
<div class=""><br class="">
</div>
<div class="">
<div style="margin:0px 0px 0.5em;padding:0px;box-sizing:border-box;font-size:14px;direction:ltr;font-family:"Helvetica Neue",Helvetica,Helvetica,Arial,sans-serif;line-height:1.6em;color:rgb(34,34,34);font-variant-ligatures:normal;background-color:rgb(255,255,255)" class="">
A <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyLocator</span></code> specifies
either <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">Name</span></code> that points
to another Data packet containing certificate or public key or <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyDigest</span></code> 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 <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyLocator</span></code> is
defined as an optional field in <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">SignatureInfo</span></code> block,
some signature types may require presence of it and some require <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyLocator</span></code> absence.</div>
<div style="margin:0px;padding:0px;box-sizing:border-box;font-size:14px;direction:ltr;color:rgb(34,34,34);font-family:"Helvetica Neue",Helvetica,Helvetica,Arial,sans-serif;font-variant-ligatures:normal;background-color:rgb(255,255,255)" class="">
<div style="margin:0px 0px 0.8em;padding:3px;box-sizing:border-box;direction:ltr;background-color:rgb(238,238,236);border-top:2px solid rgb(221,221,221);border-bottom:2px solid rgb(221,221,221)" class="">
<pre style="margin-top:0px;margin-bottom:0px;padding:1.5em;box-sizing:border-box;font-size:0.9em;direction:ltr;background-color:rgb(247,247,247);border-width:2px;border-style:solid none;border-color:rgb(198,201,203)" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class=""></span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyLocator</span> <span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">=</span> <span style="margin:0px;padding:0px;box-sizing:border-box" class="">KEY</span><span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">-</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">LOCATOR</span><span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">-</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">TYPE</span> <span style="margin:0px;padding:0px;box-sizing:border-box" class="">TLV</span><span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">-</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">LENGTH</span> <span style="margin:0px;padding:0px;box-sizing:border-box" class="">(</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">Name</span> <span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">/</span> <span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyDigest</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">)</span>
<span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyDigest</span> <span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">=</span> <span style="margin:0px;padding:0px;box-sizing:border-box" class="">KEY</span><span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">-</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">DIGEST</span><span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">-</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">TYPE</span> <span style="margin:0px;padding:0px;box-sizing:border-box" class="">TLV</span><span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">-</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">LENGTH</span> <span style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(102,102,102)" class="">*</span><span style="margin:0px;padding:0px;box-sizing:border-box" class="">OCTET</span>
</pre>
</div>
</div>
<div style="margin:0px 0px 0.5em;padding:0px;box-sizing:border-box;font-size:14px;direction:ltr;font-family:"Helvetica Neue",Helvetica,Helvetica,Arial,sans-serif;line-height:1.6em;color:rgb(34,34,34);font-variant-ligatures:normal;background-color:rgb(255,255,255)" class="">
See <a href="https://named-data.net/doc/NDN-packet-spec/current/name.html#name" style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(253,120,0);text-decoration:none;line-height:inherit" target="_blank" class="">Name specification</a> for the definition
of Name field.</div>
<div style="margin:0px 0px 0.5em;padding:0px;box-sizing:border-box;font-size:14px;direction:ltr;font-family:"Helvetica Neue",Helvetica,Helvetica,Arial,sans-serif;line-height:1.6em;color:rgb(34,34,34);font-variant-ligatures:normal;background-color:rgb(255,255,255)" class="">
The specific definition of the usage of <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">Name</span></code> and <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyDigest</span></code> options
in <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">KeyLocator</span></code> field is
outside the scope of this specification. Generally, <code style="margin:0px;padding:1px;box-sizing:border-box;font-weight:bold;background:rgb(238,238,236) none repeat scroll 0% 0%;font-size:13px" class=""><span style="margin:0px;padding:0px;box-sizing:border-box" class="">Name</span></code> 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 <a href="https://named-data.net/doc/NDN-packet-spec/current/signature.html#testbed-key-management" id="gmail-m_39192948250418898gmail-m_-7538157830038799108id3" style="margin:0px;padding:0px;box-sizing:border-box;color:rgb(253,120,0);text-decoration:none;line-height:inherit" target="_blank" class="">[BZA+13]</a> 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.</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><br class="">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline;float:none" class="">Lan</span>
</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Oct 4, 2019 at 11:33 AM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank" class="">shijunxiao@email.arizona.edu</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="">
<div class="">Hi Lan</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class="">
<div class="">
<div class=""><span id="gmail-m_39192948250418898gmail-m_-7538157830038799108cid:ii_k1ca0d5d1" class=""><image.png></span><br class="">
</div>
</div>
</div>
<div class=""><br class="">
</div>
<div class="">The equivalent in NDN would be "Authority X3" key has two certificates:</div>
<div class=""><font face="monospace" class="">/lets-encrypt/KEY/X3/ISRG/35=%01</font></div>
<div class=""><font face="monospace" class="">/lets-encrypt/KEY/X3/IdenTrust/35=%01</font></div>
<div class=""><br class="">
</div>
<div class="">
<div class="">On a packet signed by "Authority X3" key, the KeyLocator name would be
<font face="monospace" class="">/lets-encrypt/KEY/X3</font>.</div>
<div class=""></div>
</div>
<div class="">Suppose we have a validator that ONLY knows IdenTrust as a trust anchor, but does not recognize "ISRG Root X1" as a trust anchor.</div>
<div class="">When it sends an Interest for <font face="monospace" class="">/lets-encrypt/KEY/X3</font> , it could receive the certificate
<font face="monospace" class="">/lets-encrypt/KEY/X3/ISRG/35=%01</font> that have a KeyLocator
<font face="monospace" class="">/isrg-root/KEY.X1</font> .</div>
<div class="">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).</div>
<div class="">Eventually, validator rejects the original packet.</div>
<div class=""><br class="">
</div>
<div class="">What SHOULD happen is that, the validator needs to retrieve the <font face="monospace" class="">
/lets-encrypt/KEY/X3/IdenTrust/35=%01</font> certificate instead of (or in addition to) <font face="monospace" class="">/lets-encrypt/KEY/X3/ISRG/35=%01</font> certificate.</div>
<div class="">This would allow it to continue validation toward a known trust anchor.</div>
<div class=""><br class="">
</div>
<div class="">The question here is: how could the validator know to retrieve the <font face="monospace" class="">/lets-encrypt/KEY/X3/IdenTrust/35=%01</font> certificate?</div>
<div class=""><br class="">
</div>
<div class="">Yours, Junxiao</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2019 at 8:19 AM Lan Wang (lanwang) <<a href="mailto:lanwang@memphis.edu" target="_blank" class="">lanwang@memphis.edu</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">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:
<div class=""><br class="">
</div>
<div class=""><span style="background-color:rgb(255,255,255)" class=""><span style="font-family:"Lucida Grande",LucidaGrande,Lucida,Helvetica,Arial,sans-serif;font-variant-ligatures:normal" class="">A. Gawande, J. Clark, D. Coomes, </span><b style="font-family:"Lucida Grande",LucidaGrande,Lucida,Helvetica,Arial,sans-serif;font-variant-ligatures:normal" class="">L.
Wang</b><span style="font-family:"Lucida Grande",LucidaGrande,Lucida,Helvetica,Arial,sans-serif;font-variant-ligatures:normal" class="">, "</span><a href="http://web0.cs.memphis.edu/~lanwang/paper/ICN19-npchat.pdf" style="font-family:"Lucida Grande",LucidaGrande,Lucida,Helvetica,Arial,sans-serif;font-variant-ligatures:normal" target="_blank" class="">Decentralized
and Secure Multimedia Sharing Application over Named Data Networking</a><span style="font-family:"Lucida Grande",LucidaGrande,Lucida,Helvetica,Arial,sans-serif;font-variant-ligatures:normal" class="">," in </span><i style="font-family:"Lucida Grande",LucidaGrande,Lucida,Helvetica,Arial,sans-serif;font-variant-ligatures:normal" class="">Proceedings
of ACM Conference on Information Centric Networking</i><span style="font-family:"Lucida Grande",LucidaGrande,Lucida,Helvetica,Arial,sans-serif;font-variant-ligatures:normal" class="">, Sept. 2019</span></span><br class="">
<div class=""><br class="">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline" class="">Lan</span>
</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Oct 2, 2019, at 8:35 AM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank" class="">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">
<div class="">Hi Lan</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class="">Suppose there are two certificate versions from the same issuer:</div>
<div class="">
<ul class="">
<li class=""><font face="monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%01</font></li><li class=""><font face="monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%02</font></li></ul>
</div>
<div class="">Using RDR protocol, the validator could ask: <font face="monospace" class="">
/ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/32=metadata</font> CanBePrefix=1 MustBeFresh=1, and get a reply that
<font face="monospace" class="">%FD%02</font> is the latest version.</div>
<div class=""><br class="">
</div>
<div class="">However, <b class="">knowing the latest version does not help when there are multiple issuers</b>.</div>
<div class="">In the example given in <a href="https://www.lists.cs.ucla.edu/pipermail/ndn-interest/2019-October/002600.html" target="_blank" class="">
my last post</a>, there are certificates issued by two separate issuers:</div>
<div class="">
<ul class="">
<li class=""><font face="monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%00%00%01i%FE%FD~%BF<br class="">
</font></li><li class=""><font face="monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%1C%9A/X/%FD%00%00%01m%88%1E%0A%07</font><br class="">
</li></ul>
</div>
<div class="">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 <font face="monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%1C%9A/X/%FD%00%00%01m%88%1E%0A%07</font>
as its version component has a greater number. However, if the validator is expecting ndn-testbed-root-v2 trust anchor, the validation will fail.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><b class="">Enumerating the namespace</b> using <a href="https://redmine.named-data.net/issues/4666" target="_blank" class="">namespace catalog protocol</a> might help. The validator can:</div>
<div class="">
<ol class="">
<li class="">Enumerate <font face="monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%1C%9A</font> namespace, and find there are two issuerIds "NA" and "X".</li><li class="">Fetch the latest certificate under each issuerId.</li><li class="">Determine which certificate(s) to follow up according to trust schema.</li></ol>
</div>
<div class="">However, isn't it better to make issuerId part of the trust schema itself, so that the validator could skip the namespace enumeration step.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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?</div>
<div class=""><br class="">
</div>
<div class="">Yours, Junxiao</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 8:52 AM Lan Wang (lanwang) <<a href="mailto:lanwang@memphis.edu" target="_blank" class="">lanwang@memphis.edu</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">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.<br class="">
<div class=""><br class="">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline" class="">Lan</span>
</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Oct 1, 2019, at 12:51 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank" class="">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">
<div class="">Dear folks</div>
<div class=""><br class="">
</div>
<div class="">I wonder what's the relation between KeyLocator name and Certificate name?<br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://named-data.net/doc/NDN-packet-spec/0.3/signature.html#keylocator" target="_blank" class="">Packet format spec</a> says this on KeyLocator name:</div>
<div style="margin-left:40px" class="">The specific definition of the usage of Name and KeyDigest options in KeyLocator field is outside the scope of this specification. Generally,
<b class="">Name names the Data packet with the corresponding certificate</b>. 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
<a href="https://named-data.net/publications/techreports/trpublishkey-rev2/" target="_blank" class="">
hierarchical trust model</a> 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.</div>
<br class="">
<div class=""><a href="https://named-data.net/doc/ndn-cxx/0.6.6/specs/certificate-format.html#name" target="_blank" class="">Certificate format spec</a> defines certificate name to be:</div>
<div style="margin-left:40px" class=""><font face="monospace" class="">/<SubjectName>/KEY/[KeyId]/[IssuerId]/[Version]</font></div>
<div style="margin-left:40px" class=""><br class="">
</div>
<div style="margin-left:40px" class=""></div>
<div style="margin-left:40px" class=""><b class="">KeyId</b> is an opaque name component to
<b class="">identify an instance of the public key </b>for the certificate namespace. The value of Key ID is
<b class="">controlled by the namespace owner </b>and can be an 8-byte random number, SHA-256 digest of the public key, timestamp, or a simple numerical identifier.<br class="">
</div>
<div style="margin-left:40px" class=""><br class="">
</div>
<div style="margin-left:40px" class=""><b class="">Issuer Id</b> is an opaque name component to
<b class="">identify issuer of the certificate</b>. The value is <b class="">controlled by the certificate issuer</b> 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.
</div>
<div class=""><br class="">
</div>
<div class=""></div>
<div class="">In today's testbed, most applications are setting the KeyLocator name to be /<SubjectName>/KEY/[KeyId].</div>
<div class="">For example, ivoosh server's Data packet <span style="font-family:monospace" class="">
/ndn/web/video/research_questions/hls/playlist.m3u8/%FD01/%00%00 </span>uses KeyLocator name
<span style="font-family:monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%1C%9A</span> .<br class="">
</div>
After expressing an Interest for that name, I receive a certificate named <span style="font-family:monospace" class="">
/ndn/web/KEY/%29%964%F6%11%12%1C%9A/NA/%FD%00%00%01i%FE%FD~%BF</span> .<br class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">Everything seems to be working fine. However, <b class="">what if there are more than one certificates associated with the key?</b></div>
<div class="">Suppose the namespace owner requests me to issue a new certificate to his existing public key, I could execute:</div>
<div class=""><span style="font-family:monospace" class="">ndnpeek /ndn/web/KEY/%29%964%F6%11%12%</span><span style="font-family:monospace" class="">1C%9A/NA/%FD%00%00%01i%FE%FD~%</span><span style="font-family:monospace" class="">BF | base64 | ndnsec cert-gen
-i X - | base64 -d > X.data</span><br class="">
</div>
<div class="">and then let him publish the new certificate: <font face="monospace" class="">
/ndn/web/KEY/%29%964%F6%11%12%1C%9A/X/%FD%00%00%01m%88%1E%0A%07</font></div>
<div class=""><br class="">
</div>
<div class="">Now, <b class="">anyone who asks for a certificate using the KeyLocator name</b>
<font face="monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%1C%9A</font> <b class="">
could receive either of the two certificates</b>.</div>
<div class="">The validator, depending on the trust model, could be expecting one of these certificates.</div>
<div class="">If it happens to receive the other certificate, validation would fail because the signer does not match policy.</div>
<div class=""><br class="">
</div>
<div class="">So, what's the solution space?</div>
<div class=""><br class="">
</div>
<div class="">Trying to <b class="">ensure there is only one issuer per key</b> defeats the purpose of having IssuerId name component in the first place.</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class=""><b class="">Adding IssuerId to KeyLocator name</b> seems to fix the problem of validator receiving the wrong certificate.</div>
<div class="">However, this would require the namespace owner to generate separate Data packets for each trust model.</div>
<div class="">In this case, she may as well use separate keys.</div>
<div class="">
<div class=""><br class="">
</div>
<div class=""><b class="">Providing all certificates in a bundle</b> could solve the problem.</div>
<div class="">The producer would include certificates from multiple distinct trust models in the
<a href="https://redmine.named-data.net/issues/2766#note-30" target="_blank" class="">
certificate bundle</a>, 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.</div>
<div class="">A drawback of this solution is inflation of certificate bundle size.</div>
<div class=""><br class="">
</div>
<div class=""></div>
</div>
<div class=""><b class="">Appending an IssuerId component in the validator </b>appears to be the best solution. The validator needs to know, through static configuration, what IssuerId to append to each KeyLocator name.<br class="">
</div>
<div class="">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 <span style="font-family:monospace" class="">/ndn/web/KEY/%29%964%F6%11%12%</span><span style="font-family:monospace" class="">1C%9A/NA</span> and
it would receive the expected certificate.</div>
<div class=""><br class="">
</div>
<div class="">Please REPLY-ALL with your thoughts on this topic.</div>
<div class=""><br class="">
</div>
<div class="">Yours, Junxiao</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br class="">
Ndn-interest mailing list<br class="">
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>