Date: Fri, 12 Jan 2018 03:54:12 -0500
From: Peter Todd <pete@petertodd.org>
To: Cory Fields <lists@coryfields.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180112085412.GA8088@savin.petertodd.org>
References: <CAApLimjGy6TCd7kg8RKkuGqAZTfcuNSfsrDowEsEcbEnM_0rzg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
Content-Disposition: inline
In-Reply-To: <CAApLimjGy6TCd7kg8RKkuGqAZTfcuNSfsrDowEsEcbEnM_0rzg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] New Bitcoin Core macOS signing key
Precedence: list


--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 12, 2018 at 12:04:44AM -0500, Cory Fields via bitcoin-dev wrote:
> To verify, you can use something like:
> openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose=
 any
>=20
> - "ignore_critical" setting tells openssl to ignore the Apple-specific
> critical extensions that it doesn't understand.
> - "-purpose any" allows the "purpose =3D=3D smimesign" check to be
> skipped. This would otherwise fail because this certificate is only
> authorized to sign code, not arbitrary messages.
>=20
> By now, the signature will probably fail to validate because the
> certificate has expired.

Note that you may need to add -noverify as well if your openssl doesn't have
the Apple Certificate Authority in the CA list.

While a clunky way to do it, you can use the `-signer` option to tell OpenS=
SL
to write the signer's certificate to a file. That certificate can then be
compared to the one from the repo, which was still in the repo as of the
(signed!) v0.15.1 tag.


Fun fact: OpenTimestamps has git integration, which means you can extract a=
 OTS
proof from 2016 for that certificate from the repo:

    $ git checkout v0.15.1
    $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem share/ce=
rts/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b823=
6775e4
    $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots
    Assuming target filename is 'share/certs/BitcoinFoundation_Apple_Cert.p=
em'
    Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016 EDT

Homework problem: write a paragraph explaining how the proof generated by t=
he
above three commands are crypto snakeoil that proved little. :)

> The signed message below is timestamped on the Bitcoin blockchain
> using OpenTimestamps. See the attached ots file containing the
> timestamp proof. If the attachment gets scrubbed and doesn't make it
> to the list, don't be afraid to nag Peter Todd about a mail-friendly
> format for these proofs :)

Ha! Fortunately even the mailing list archives at lists.linuxfoundation.org
seem to contain the attachment just fine.

But anyway, I'd suggest using base64:

AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEITeD8FWBXd613LkHPt3JyrZBKamczrmmf
NLwSJohkYfDwEB35DezwYGb4KePty9TSWRcI//AQjTiBNRdo5I7oIeLjkGhQuAjxBFpXqSbwCN+N
8xIdwxQG/wCD3+MNLvkMji4taHR0cHM6Ly9hbGljZS5idGMuY2FsZW5kYXIub3BlbnRpbWVzdGFt
cHMub3JnCPEgijKAmyu82BuY9WL4Ags9TuzOph/XJBC6zUYZNW2Kv14I8SDyd3rD94qsLgkTPUlF
nA3SbabHilzJcHkrlGbYL+MaBgjxINCDuse4CSogHVUKQ9WaRrYkExs8PMx8O11OoVhj5ydJCPAg
y3ZstDNn/6b32WO12ZprF9zhb6VfGUl9spxU5k5eirgI8SBwa20AdPHR6oLcSdnogmPmUpWEd+n1
ky2dhWKvqZwJ/AjwIBYprQWyepSdvr1Ber0DD1eP66d4l1+138SZw7/fIflPCPAgTXOIKaeMbmNj
oO6Q/6SoX7ksCKOjkt284KYyI/ELaVgI8VkBAAAAAc1gOrgz+6mCizItuiE8bQ4foKYwCz0sB9lG
7gj/kK9fAAAAAAD9////Ag9aLAAAAAAAFgAU4gDd5F6wUprr6G4WBg+5sQkAi1YAAAAAAAAAACJq
IPAEuq8HAAgI8SAQbNEWckYQhxlLHC1aYxnyzHgxatOXQCOkQGgXe7CV7wgI8SDvEAaFSJ6unpLU
CvJzUpe2ISKMquT7kvQlvOam3SbgdggI8SBKKOTuNlh0TqP0wxy+BvCN8HgXFj/CQvJm/r9061dC
XggI8CBjdeDoADpZAb6CHjryDthP/BPcKVcMNiu+KAHIfgdDfAgI8CBuq4+F9RGpuGjFp7YU0WyH
mohtNWCv1oiDAvm6TAZeXAgI8CCI0tiLN7YMP2HtPKIm72bDi6OoFduzG0TQ1n7hEjEvvQgI8CBm
oIe62AVnwyFp6mZ37TuP0JsBHuazibGEgBKgB2xSTAgI8CDbi0srCkqentfGfk+HgBPLllDWN/mU
p4HsOQBoiDB3HwgI8SBpOitFwKhqpvNNL2SzSAxmCDIRpIpq+Kp5x774ovXexggI8SAtBMNMgP/r
L2MztJ9H43LYDRM3jGt8mbbG4Ji2+5z1rQgI8CAoVuz4NodKzCGU5c0hdBWon6T7TuMN5lA1IIOB
UF+5+QgIAAWIlg1z1xkBA7vfHvAQ5vjVlfmkli0Jsy9r6Zl5EAjxBFpXqSXwCGWEIRA/ovvQ/wCD
3+MNLvkMjiwraHR0cHM6Ly9ib2IuYnRjLmNhbGVuZGFyLm9wZW50aW1lc3RhbXBzLm9yZwjxIPEX
gnzr8J36EGTnlaF/N3bvWi0cmhlkt1b/TVIBZuCHCPEgKqjwAWBXRj1MC6oVZK6P7MBuaB5VnC+S
CpN4pfoQNJcI8CB166rXsYFaNJvQD0b6PvcK02KauHQ0G6h3dyO5NoLE1QjwIOXfM7LRnV2CFLYU
AC6uWB3K28jnM7chsxQiPXQvOmE/CPEgWmgM4iyrpd8Ip/Vs0bPeC1mdH/fgEOO+fLCR0Ae8OH0I
8CAebOJrI00jNjqWLJNxFLZaO4tY69kEKHx6AvrjoQqNzgjxWQEAAAABqY/4nDzgexnxwERsA6RG
QKS4pzagJAciBvkAbejv8mwAAAAAAP3///8CGrg4AAAAAAAWABQNuE08uA4/5oWDRYPWIW0HNrwS
ZgAAAAAAAAAAImog8AS2rwcACAjwIGQuGBXXZjCZPN527NmlDPNE7DY5jznNp8UauCoSRe3UCAjx
IPnKxEUG7HPVIm2RehYqhROpmLrZuPtr4MuMKoX+xTT1CAjwID9qxx7kHhzJrzDeZPXsvaCdQCX3
mVqkyBzlIG/Rz0TPCAjxIFHQruGgLpotZScpYu9Ou9EUmeqmizOmW77hqP04oN5/CAjwIKqKpmbK
V3weRNXWLDAWVcr0bXZndaq6th6b8dy5mjoeCAjwIA2RHHGChLN8t1f7rJJRowlLp1F3XLGD2kqK
k5M3K4c3CAjxIBwP3futX+WjxgkAS0d2TGxiyUoKMFT6bmG2o4zwmz/4CAjwIJmhwnqv64SuTiSQ
atRL1udPduUsJ6qevzrJiiuYaRuSCAjxINEU34ZeVioiqA4bBJJU8HMVlWdyYYXFnZRZ0lsKCJvc
CAjxIPjnINA1faJ/WYxuV0KSUceoHWd4EltavqltfDjTjQhcCAjwIOJixScSNRwwkg68C4HSMeRM
K5YKNh1phfaY3Du/0i68CAgABYiWDXPXGQEDt98e

On Linux, the `base64 -d` command will decode the above just fine.

The _real_ issue is that asking the user to cut-n-paste that PKCS7-encoded
message is problematic, as differences in whitespace and line endings will =
make
the verification fail. Works fine on Linux, but would probably have failed =
on
Windows.

What's nice about OpenPGP's "clearsigned" format is how it ignores whitespa=
ce;
a replica of that might be a nice thing for OTS to be able to do too. Though
that's on low priority, as there's some tricky design choices(1) to be made=
 about
how to nicely nest clearsigned PGP within OTS.


1) For example, I recently found a security hole related to clearsigned PGP
recently. Basically the issue was that gpg --verify will return true on a f=
ile
that looks like the following:

    1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a  foo-v=
2.0.tar.gz
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  foo-v=
1.0.tar.gz
    -----BEGIN PGP SIGNATURE-----

    <snip pgp stuff>
    -----END PGP SIGNATURE-----

The system I was auditing then did something like this to verify that the f=
ile
was signed:

    set -e # exit immediately on error
    gpg --verify SHA256SUMS.asc
    cat SHA256SUMS.asc | grep foo-v2.0.tar.gz
    <do installation>

While it makes it a bit less user friendly, the fact that PKCS7's encoding =
made
it impossible to see the message you signed until it's been properly verifi=
ed
is a good thing re: security.

And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh isn't
vulnerable to this mistake. :)

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaWHevAAoJECSBQD2l8JH7FeUH/3BzbohIGMCz0Gr/wZpoz3qr
3eO4SMer15N19p2Y4M7tK6D2S+kknk9AwpdG79o/pmaSEb8cwhtMGtKqYLgmQZ5Q
Gcnzpugyo0VQP+xlLPCD/Us6MpGJrY6LYQxEooR3GNfAypr8DkFRxLaO+tu+tuI/
BjfX7wJez1tYD24hgQJJenUSOdpnm1P/bBkGSJpDT4Yigo7aFLVmuPyGA9l3c/4H
twtJTx9+PnahwbBTBPwQJsaRsL5ACUSjLwWVWK7I4nM3BMsvHtWUWDOHXG1EUOj9
nCN455/MQ+WHlCTfPHjWmUs4fBqBj9LUoD4BP0sZ7+d0MoN7mmzhaQf8Cwj2uSg=
=0GbP
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--