<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Um. I hav the new key, and there is no problem with that - as I have
said, it is clearly the Tails developer key, by all indicators. The
data on the old key page is just for those who have used the older
key. On the other hand, the ISO verification using the signature
file produces the anomalous string I have quoted. You pointed me to
a Debian list, but the string is not listed on the Tails site.
Regarding verification, it says: <br>
<p><i>If you see the following warning:</i></p>
<i>
</i><i>
</i>
<pre><i>Not enough information to check the signature validity.
Signed on ... by <a class="moz-txt-link-abbreviated" href="mailto:tails@boum.org">tails@boum.org</a> (Key ID: 0x58ACD84F
The validity of the signature cannot be verified.
</i></pre>
<i>
</i>
<p><i>Then the ISO image is still correct, and valid according to
the Tails signing
key that you downloaded. This warning is related to the trust
that you put in
the Tails signing key. See, </i><i><a
href="https://tails.boum.org/doc/get/trusting_tails_signing_key/index.en.html">Trusting
Tails signing
key</a></i><i>. To remove this warning you would have
to personally </i><i><span class="definition"><a
href="https://en.wikipedia.org/wiki/Keysigning">sign</a></span></i><i>
the Tails signing key with your own key.</i></p>
<a class="moz-txt-link-freetext" href="https://tails.boum.org/download/index.en.html#download.verify-the-iso-image-using-other-operating-systems">https://tails.boum.org/download/index.en.html#download.verify-the-iso-image-using-other-operating-systems</a><br>
<br>
This is not the result I have, and the statement lacks any such
string; the ID shown is the Tails developer key (as I have said,
imported and verified). So what of this anomalous string, which you
apparently located on a Debian list? Bear in mind, the Tails iso,
downloaded several times from different locations, checksums fine,
and I have of course also downloaded the asc and sig files numerous
times, including through TOR, easy given their tiny size. If the Iso
is a fraud, I need to know that, though if that is the case it is
hard to see how I am going to get a genuine copy after so many
attempts. If the sig-iso output is actually correct, what the hell
is it doing on an obscure Debian list, and why on earth have Tails
misstated the verification data? <br>
<br>
Thanks again. <br>
<br>
<br>
<div class="moz-cite-prefix">On 26/05/2015 22:17, Juan Miguel
Navarro Martínez wrote:<br>
</div>
<blockquote cite="mid:5564E305.5090503@gmail.com" type="cite">
<pre wrap="">The information about Tails key was given in this post about the
transition from the old to the new one:
<a class="moz-txt-link-freetext" href="https://tails.boum.org/news/signing_key_transition/index.en.html">https://tails.boum.org/news/signing_key_transition/index.en.html</a>
You can compare the IDs/Fingerprints which the ones you have, but I can
tell you yours matches.
L:
</pre>
<blockquote type="cite">
<pre wrap="">Thanks. If that is the case, it should certainly be listed on the Tails
site; I found no mention of the string there, when I last checked, only
that of the developers key from the Tails site (you can download it
there yourself):
User-ID:
Tails developers (offline long-term identity key) <a class="moz-txt-link-rfc2396E" href="mailto:tails@boum.org"><tails@boum.org></a>
Validity:
from 2015-01-18 14:17 through 2016-01-11 14:17
Certificate type:
4,096-bit RSA
Certificate usage:
Signing EMails and Files, Certifying other Certificates
Key-ID:
58ACD84F
Fingerprint:
A490D0F4D311A4153E2BB7CADBB802B258ACD84F
Neither can it be found among the IDs (see Technical Details):
DBB802B258ACD84F/98FEC6BC752A3DB6/3C83DCB52F699C56
Nor does it match anything stated in sig-iso verification. That was the
whole point :)
On 26/05/2015 04:37, Juan Miguel Navarro Martínez wrote:
</pre>
<blockquote type="cite">
<pre wrap="">L:
</pre>
<blockquote type="cite">
<pre wrap="">3) I will also try trusting the Tails key using my own key; still,
Gpg4Win does offer the ability to " completely trust" a key without
using your own, and even when this is the case, the key fails to
appear in Kleopatra's trusted field, also an apparent bug. If the
trusted field only admits keys when signed with your own, this
should be made clear.
</pre>
</blockquote>
<pre wrap="">
You can give a trust level using command-line but it won't affect
Kleopatra "Trusted keys" list, it only will show if you sign it with
your own key.
I would try and confirm it but I'm having some problems here.
</pre>
<blockquote type="cite">
<pre wrap="">4) This still fails to account for the unidentified string (short
and post-key-imported long), unmatched to anything on the Tails
site, the real issue. Can anyone account for this string
(/0xBA2C222F44AC00ED9899389398FEC6BC752A3DB6)?
</pre>
</blockquote>
<pre wrap="">
That's Tails developers signing subkey:
<a class="moz-txt-link-freetext" href="https://paste.debian.net/183806/">https://paste.debian.net/183806/</a>
See the second key fingerprint, it matches the 0xFingerprint key ID
format you typed.
_______________________________________________
Gpg4win-users-en mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gpg4win-users-en@wald.intevation.org">Gpg4win-users-en@wald.intevation.org</a>
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-freetext" href="https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en">https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en</a>
_______________________________________________
Gpg4win-users-en mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gpg4win-users-en@wald.intevation.org">Gpg4win-users-en@wald.intevation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en">https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>