
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">the inter-trust poster is based on the following model:<div>- each entity E has one controller T which holds the trust anchor (self-signed cert). i.e. everyone has one boss, and one boss only.</div><div><br></div><div>- T defines policies for how E treats input data, both intra- and inter-trust domains.</div><div>In your example below: entities in /appA follow Za's trust schema *only; Za defines rules of how to deal with data from /appB domain.</div><div><br></div><div>(I wonder why you think entities in /appA should care /appB's policies?)</div><div><div><div><br><blockquote type="cite"><div>On Apr 13, 2025, at 8:01 AM, Andre Madureira <andreluizromanomadureira@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="auto"><div>Dear Lixia,</div><div dir="auto"><br></div><div dir="auto">Thanks you for such a promptly and precise reply.</div><div dir="auto"><br></div><div dir="auto">My understanding from the Intertrust paper (please correct me if I'm wrong) is that if I have two apps (/appA and /appB), each with their own trust anchors (Za and Zb) and trust schemas, appA can consume packets from appB if Za signs Zb (resulting in a certificate Zb'). But after that I didn't understand how the solution would work .</div><div dir="auto"><br></div><div dir="auto">That is, if appA retrieve a data packet /appB/some_suffix, it can verify it's KeyLocator field to validate the certificate used to sign the data packet. However, that validation process requires the appB schema rules to work. How would that be implemented in Intertrust solution?</div><div dir="auto"><br></div><div dir="auto">From what I could deduce, appA has two approaches to the appB validation rules retrieval problem: I) retrieve the appB trust schema (or a subset of it, managed by appB zone controller) , or ii) embed appB rules (in entirety or as a subset, defined by the appB zone controller) inside appA trust schema.</div><div dir="auto"><br></div><div dir="auto">The first solution implies that appA nodes can use two schemas to validate data packets (the appA schema, and the subset of appB schema). However I do not know if that is feasible in current NDN architecture.</div><div dir="auto"><br></div><div dir="auto">The other solution would imply mutating appA schema to contain a subset of the validation rules from appB. In that case, for each trust zone, we would need to have a new version of the appA schema, containing the exported appB validation rules.</div><div dir="auto"><br></div><div dir="auto">I really don't know what approach was originally thought for Intertrust implementation.</div><div dir="auto"><br></div><div dir="auto">Any ideas or insights will be highly appreciated. </div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div><br></div><div data-smartmail="gmail_signature"><div dir="ltr">André Luiz Romano Madureira</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em sáb., 12 de abr. de 2025, 22:11, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-break:after-white-space">If /appX and /appY do not have a shared trust anchor, the two are in two different trust domains. <div><br><div>Verification across trust domains requires the establishment of security relations between the demains. Please see an early exploration on this issue"</div><div>"Intertrust: establishing inter-zone trust relationships"</div><div><a href="https://dl.acm.org/doi/abs/10.1145/3517212.3559489" target="_blank" rel="noreferrer">https://dl.acm.org/doi/abs/10.1145/3517212.3559489</a><div><br></div><div>Lixia</div><div><br></div><div><blockquote type="cite"><div>On Apr 12, 2025, at 1:26 PM, Andre Madureira via ndnSIM <<a href="mailto:ndnsim@lists.cs.ucla.edu" target="_blank" rel="noreferrer">ndnsim@lists.cs.ucla.edu</a>> wrote:</div><br><div><div dir="ltr"><div><br></div><div class="gmail_quote"><div dir="ltr"><div>Hello everyone,</div><div><br></div><div>I was currently working on an NDN App ( <b>/appX </b>) that needs to consume data produced in another App ( <b>/appY </b>). They both have their own trust schemas, with their own rules and certificate chains.</div><div><br></div><div>The issue I'm facing is how to validate data produced in the "<b>/appY"</b> zone inside the application "<b>/appX"</b>, if they have distinct trust schemas?</div><div><br></div><div>That is, <b>/appX </b>consumes data produced within the name hierarchy of <b>/appY.</b></div><div><b></b>How <b>appX</b> can validate those data packets created within <b>appY </b>?</div><div><br></div><div>Thanks in advance for any insights provided.</div><div><br></div><div>Best regards,</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">André Luiz Romano Madureira</div></div></div></div>

</div></div>

_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank" rel="noreferrer">ndnSIM@lists.cs.ucla.edu</a><br><a href="https://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank" rel="noreferrer">https://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br></div></blockquote></div><br></div></div></div></blockquote></div>

</div></blockquote></div><br></div></div></body></html>