<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Finally, the sum data for Tails is as follows: <br>
    <br>
    Sha 256 Checksum:
    a32009af6d65cdc158bb4592f28f64147bbc5c9468693a413333dd7999f93592<br>
    Constituent RSAs: DBB802B258ACD84F, 98FEC6BC752A3DB6 and
    3C83DCB52F699C56<br>
    Key IDs (asc and sig files): 58ACD84F and 752A3DB6<br>
    Primary key fingerprint: A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2
    58AC D84F<br>
    Subkey fingerprint: BA2C 222F 44AC 00ED 9899 3893 98FE C6BC 752A
    3DB6<br>
    <br>
    <div class="moz-cite-prefix">On 29/05/2015 02:56, L wrote:<br>
    </div>
    <blockquote cite="mid:5567C74D.3080407@riseup.net" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      And now successfully preceded by Key (asc) importation. Indeed,
      now the output shows both primary (key) fingerprint and sub (sig)
      fingerprint, as well as the RSA (absent from GUI execution). A few
      notes, then, for anyone to whom it may concern: <br>
      <br>
      1) The Gpg4Win GUI is faulty, and a cause of much trouble. It
      cannot be used in verification to gain the data available with the
      command line, though the key (asc) importation will provide
      immediate access to ID, fingerprint, and RSAs. <br>
      2) The Gpg4Win GUI cannot produce sha256sums: an alternative
      application is required. (For this I used RapidCRCUnicode, in its
      Portable Apps form.)<br>
      3) Online command lists for Gnu command line are also misleading.
      Do not run gpg.exe, and precede commands by two hyphens not one.
      The only two commands really required are import and verify: "gpg
      --import [path, key (ie. asc) file)]" and "gpg --verify [path, sig
      file] [path, data file]", along with trusting and signing. Include
      full paths to asc, sig and data files. External locations appear
      to be unworkable (I lack much experience in command line to
      explain why, but perhaps this is a command line limitation).<br>
      4) If the Tails key (asc file) is imported using the GUI, this
      should produce the expected data (as above, origin Tails
      developers - dates, ID -58ACD84F - primary key fingerprint-
      A490D0F4D311A4153E2BB7CADBB802B258ACD84F - and constituent RSAs -
      DBB802B258ACD84F, 98FEC6BC752A3DB6 and 3C83DCB52F699C56). <br>
      5) "Completely Trusting" the key will not have it appear in the
      Trusted keys field (a bug or misdescription). <br>
      6) If the sig and iso are verified using the GUI after key
      importation, this will produce only the Tails subkey fingerprint
      (BA2C222F44AC00ED9899389398FEC6BC752A3DB6: the one that was
      located on a Debian list, but fails to be mentioned on the Tails
      site). <br>
      7) If the key (asc file) is imported using the command line, it
      will show origin and key ID (Tails Developers, 58ACD84F). <br>
      8) If the sig and iso are verified using the command line without
      initial key importation, they will show part of the RSAs, seen in
      the subkey fingerprint (752A3DB6). <br>
      9) If the sig and iso are verified after key (asc) importation,
      they will show "Good signature", and the origin (Tails
      Developers), and both primary and subkey fingerprints (A490 D0F4
      D311 A415 3E2B B7CA DBB8 02B2 58AC D84F and BA2C 222F 44AC 00ED
      9899 3893 98FE C6BC 752A 3DB6). <br>
      <br>
      I hope that aids anyone who encounters the problems I did, should
      they locate these notes, and perhaps suggests a number of
      rectifications needed to the Gpg4Win and Tails data. <br>
      <br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 29/05/2015 01:24, L wrote:<br>
      </div>
      <blockquote cite="mid:5567B1C3.9070604@riseup.net" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        I've tried the command line execution, finally with success (ie.
        actually attempts to verify iso-sig). I get the sign date and an
        RSA ID (752A3DB6) identifiable to the Tails RSAs available in
        the key (ie. asc file) (98FEC6BC752A3DB6). It does not, and as
        far as I can see will never, produce what the Tails instructions
        say it should, despite the Debian list number (I know Tails is
        based on Debian, but still). Along with checksum, which I did
        with another app, that will have to do: it shows the copy is
        genuine and comes from Tails dev. <br>
        I suggest to the Tails site people that these issues should be
        addressed (warnings regarding Gpg4Win and checksums, and
        whatever is going on with the verification ID data). <br>
        <br>
        El<br>
        <br>
        <br>
        <br>
        <div class="moz-cite-prefix">On 27/05/2015 00:36, L wrote:<br>
        </div>
        <blockquote cite="mid:55650369.1080108@riseup.net" type="cite">
          <meta content="text/html; charset=windows-1252"
            http-equiv="Content-Type">
          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 moz-do-not-send="true" 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 moz-do-not-send="true"
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
                  moz-do-not-send="true"
                  href="https://en.wikipedia.org/wiki/Keysigning">sign</a></span></i><i>
              the Tails signing key with your own key.</i></p>
          <a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Gpg4win-users-en@wald.intevation.org">Gpg4win-users-en@wald.intevation.org</a>
<a moz-do-not-send="true" 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>
          </blockquote>
          <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
Gpg4win-users-en mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Gpg4win-users-en@wald.intevation.org">Gpg4win-users-en@wald.intevation.org</a>
<a moz-do-not-send="true" 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>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Gpg4win-users-en mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Gpg4win-users-en@wald.intevation.org">Gpg4win-users-en@wald.intevation.org</a>
<a moz-do-not-send="true" 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>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
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>
    <br>
  </body>
</html>