<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 18, 2016, at 9:21 AM, Tomasz Gajc wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Jeff thanks for your explanation. I have feeling i've understood it like this way, so please confirm:<br><br></div>1. Before release and repository freeze a list of gpg keys needs to be generated from each rpm file in repository<br></div>2. This list must be uploaded to <a href="http://virtual-notary.org/">virtual-notary.org</a><br></div>3. List is signed by virtual-notary<br></div>4. List is placed on repository with a public certificate from virtual-notary<br></div>5. Done<br><br></div></div></div></div></div></div></blockquote><div><br></div>That's close to the procedure I suggested, but you are missing some essential steps.</div><div><br></div><div>The virtual-notary provides a confirmation that a document on the internet existed</div><div>(as in could be fetched) at a certain time and location. With a one-time non-repudiable</div><div>signature, the notarization is a guarantee of uniqueness: i.e. rpm hasn't "cheated" and</div><div>saved the private key in order to resign additional, possibly tampered/altered content.</div><div><br></div><div>The procedure above could use other trust chains, like signing the manifest with gpg/openssl,</div><div>to securely distribute content. In fact, you could sign the manifest before sending to virtual-notary.</div><div>SKS keyservers, or X.509 CA's, establish that trust chain for packages signed by the "official" keys,</div><div>and would provide a similar form of trust for a manifest.</div><div><br></div><div>It's the trusted timestamp provided by a digital notary that publishes the fact that the key</div><div>used by rpm to sign packages is unique (and hence non-repudiable). The attestation of the</div><div>location from which the manifest was retrieved starts to establish the origin (and validity)</div><div>of the mirrored content.</div><div><br></div><div>The other important points of a non-repudiable rpm signature are:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">  </span>1) There is no need to manage/protect private keys on the build system. rpmbuild</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>handles the non-repudiable signing, and publishing a manifest through a notary</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>starts to guarantee the uniqueness.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">    </span>2) There is no need to distribute "official" pubkeys to end-users, the non-repudiable</div><div><span class="Apple-tab-span" style="white-space:pre">      </span>pubkey is in every rpm package and will be installed when the package is installed.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>3) Using multiple non-repudiable signatures instead of an "official" key for securing</div><div><span class="Apple-tab-span" style="white-space:pre">      </span>package content greatly reduces the risk of the "official" key being compromised.</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>Everything signed by a compromised "official" key would need to be republished,</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>while a compromised non-repudiable signature is limited to republishing only the</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>packages produced in a single build.</div><div><br></div><div>Security protocols are a huge PITA: simple procedures make it easier to Get It Right! JMHO ...</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div><div><div><div><div>BTW: idea is very interesting :)<br><br></div>I have a couple of questions/ideas:<br></div>1. Would be nice if urpmi could verify a gpg key from a signed list taken from mirror.<br></div></div></div></div></blockquote><div><br></div>urpmi has no crypto inside, all package verification is through rpmlib. Using the non-repudiable</div><div>signature guarantees that rpm always has the pubkey needed to verify package integrity</div><div>no matter whether users have imported or distros have uploaded their pubkey or whether</div><div>rpm is permitted access to SKS key servers on build systems (by configuring a network) or</div><div>by configuring rpm to retrieve pubkeys on client machines.</div><div><br><blockquote type="cite"><div dir="ltr"><div><div>2. What about /updates directory on mirror? This directory is not frozen after release, so this means new packages will be arriving there. How to handle these packages with above solution ? IMHO recreating list each rpm got published and then upload it to virtual-notary and generate new certificate is a big effort. I wonder how virtual-notary will react if we will upload couple of lists per day.<br></div></div></div></blockquote><div><br></div>The official release and official updates likely should be signed by the "official" key</div><div>because that is the least surprising.</div><div><br></div><div>Yes free services like virtual-notary (and SKS keyservers) should not be abused.</div><div><br></div><div>(aside)</div><div>rpm could easily use SKS key servers as a notary with rpmbuild publishing the pubkey. The problem</div><div>there is that network access is routinely prohibited to rpm while building, and Yet More Network Access</div><div>to retrieve needed pubkeys that depend on distro security procedures is usually controversial.</div><div><br></div><div>Note that I have asked and received permission to use SKS keyservers, and anticipate having a similar</div><div>conversation with virtual-notary about load factors as well as discussing the security protocol.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div>Maybe update 1 time per day ? You know, user can install update just couple a seconds just after it got published on repository.<br><br></div></div></blockquote><div><br></div>Yes, basically *Mandriva could collect manifests and publish daily/weekly to taste. virtual-notary is</div><div>doing similarly, where all the attestations are collected, and then published into the bitcoin chain</div><div>periodically (or as needed).</div><div><br></div><div>(aside)</div><div>Exposing fresh builds to mirrors for users to "install update just couple of seconds after ... published"</div><div>has its own problems, including that there is only a couple of seconds of QA possible.</div><div><br></div><div>But let's not digress ...</div><div><br><blockquote type="cite"><div dir="ltr">3. Is there any API for <a href="http://virtual-notary.org/">virtual-notary.org</a> ?<br><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div>There is a REST API at virtual-notary iirc.</div><div><br></div><div>hth</div><div><br></div><div>73 de Jeff</div><div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-18 12:43 GMT+01:00 Jeff Johnson <span dir="ltr"><<a href="mailto:n3npq@mac.com" target="_blank">n3npq@mac.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Jan 18, 2016, at 5:56 AM, Jeff Johnson wrote:<br>
<br>
>><br>
>> I do not understand what non-repudiable means :(<br>
>><br>
><br>
> Apologies for the techno jargon (but I am reluctant to invent newer! better! bestest! terms)<br>
><br>
> A repudiation is a statement denying some claim like this:<br>
>       Q: Did you modify anything in the package?<br>
>       A: No.<br>
><br>
> So a non-repudiable signature is a public/global assertion that nothing whatsoever is changed.<br>
<br>
</span>Here is perhaps a better (i.e. more explicit) example of repudiation(s):<br>
<br>
        Claim:                  My machine was rooted by installing a *Mandriva rpm package from this mirror.<br>
        Repudiation #1: That package wasn't downloaded from this mirror.<br>
        Repudiation #2: That is not a *Mandriva package because its not signed with a Mandriva key.<br>
        Repudiation #3: That is not a package produced by rpm because (various reasons, like the<br>
                package might have been altered after being built).<br>
<br>
By including a non-repudiable signature, #3 provides a stronger/transparent mechanism that a<br>
package was not altered after being built.<br>
<br>
By registering a manifest with virtual-notary, *Mandriva would be providing some means to resolve<br>
the issues associated with #1 and #2, and avoiding issues related to "official" key compromises.<br>
<br>
hth<br>
<br>
73 de Jeff<br>
<br>
</blockquote></div><br></div>
</blockquote></div><br></body></html>