<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="">
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="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 Oct 1, 2019, at 12:51 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="">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" 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 class=""><br class="">
</div>
</div>
</div>
_______________________________________________<br class="">
Ndn-interest mailing list<br class="">
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br class="">
</div>
</blockquote>
</div>
<br class="">
</body>
</html>