On Mon, Jun 05, 2017 at 03:17:46PM -0700, Axel wrote: > > I think that indirection just confuses the issue, so better to put the > > proof-of-freshness in the signature itself. Fortunately the OpenPGP > > standard > > has something called "signature notation data" that allows you to add > > arbitrary > > (signed) data to OpenPGP signatures. In fact, I used to have a cronjob > > that > > periodically set my gpg.conf to include a recent blockhash as a > > proof-of-freshness with the notation bloc...@bitcoin.org > > <javascript:>=<blockhash> > > > > > > Agree. As I said, the best thing would be if a proof of freshness could be > part of every signed message. I only suggested proof of freshness as part > of the commit as a second-hand option since I didn't know about the > notational data support.
Ah good, I misread your original message. Glad we're on the same page! > > Even better would be if GPG had the ability to run a command on demand to > > get > > the value a notation should be set too, but as far as I know that feature > > doesn't exist yet. That said, I could easily add it to the OpenTimestamps > > Client as part of the git commit timestamping support. > > > > What exactly would you add to OTS git support? > Did you mean adding proof-of-freshness functionality to the git tag signing > override provided by OTS? I think that would be very useful. Basically, because the OTS git support is a wrapper *around* the gpg binary, it's easy for that wrapper to also pass the --set-notation option with a proof-of-freshness blockhash. This *is* a bit of a hack, but at least on a technical level it will work, and I can easily add a mechanism for that wrapper to get a recent block hash from the OpenTimestamps calendar servers. In fact, adding proofs-of-freshness is something I've been thinking about adding to OpenTimestamps anyway; the main reason I haven't already is that what exactly it proves is easily misunderstood. > Moreover, I think it would be useful to add something to > qubes-secpack/utils to help make GPG signatures with a suitably old block > hash as notational data. Yup, although a tricky part there is you of course need to communicate with the outside world to get such a blockhash, which makes this difficult to implement on a truly off-line system; I'll admit that it may very well be simpler to put the blockhash in the thing being signed (e.g. git commit) rather than in the signature as notation data under that circumstance. Though, that's another neat thing about the OTS git support: it works just fine with Qube's split-gpg support. It'll also work with the signature notation scheme as qubes-gpg-client-wrapper passes unknown options like the --set-notation option to GPG (that does smell like a possible security hole!). > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > > > btw, nice anti-spam measure! Thanks! I've had this signature for something like 10+ years, and you're maybe the second or third person to comment on it. :) -- https://petertodd.org 'peter'[:-1]@petertodd.org -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170607153851.GD13144%40fedora-23-dvm. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
