On Tue, 2006-01-31 at 14:55 -0600, Michael Yep wrote:
This did not sign properly
I got a message : gpg command line and output:,C:\\gnupg\\gpg.exe
--charset utf8 --batch --no-tty --status-fd 2 --verify,gpg: CRC error;
c8aba6 - dc3c8a,gpg: quoted printable character in armor - probably a
buggy MTA has been used
Hmmm... What MUA where you using?
This looks to be a "Content-Transfer-Encoding" issue. If it's not
nested the GPG signature has no MIME "Content-Transfer-Encoding". If
it's nested within an S/MIME signed wrapping, it's been set to and
encoded "Content-Transfer-Encoding: quoted-printable". The encoding is
correct but your MUA failed to unencode it before trying to verify it.
So GPG complains that it ran into a quoted-printable escape, which it
did (but it's certainly not the MTA's fault here). So the question is,
did Evolution make an error when it encoded the GPG signature
quoted-printable or did the receiving MUA make the error when it failed
to honor it. This is exactly the kind of compatibility errors one might
expect.
Michael H. Warfield wrote:
> I guess it would have helped if I had actually flipped the S/MIME bit
> BEFORE hitting send. The previous message did not have the S/MIME
> signature. This one should. :-( I doubled checked it this time...
>
> Mike
>
> On Tue, 2006-01-31 at 15:32 -0500, Michael H. Warfield wrote:
>
>>On Tue, 2006-01-31 at 23:47 +1030, Tim wrote:
>>
>>>On Mon, 2006-01-30 at 23:36 -0600, Arthur Pemberton wrote:
>>>
>>>>1) Can I do both SMIME and PGP in my emails?
>>
>>>I wouldn't think so. A signature is added to a message as confirmation
>>>that the message hasn't been tampered with, therefore its based on the
>>>message contents.
>>
>>>Conjecture, because adding a signature adds to the contents: If you
>>>were to add one then the other, the first signature would try to
>>>proclaim the message to be okay. The second signature added would try
>>>to proclaim the message with the first signature, in combination, to be
>>>okay. But adding the second signature changed the message, so anyone
>>>trying only to use the first signature (because that's all that their
>>>client supported) would see the message had been changed (by the second
>>>signature).
>>
>> This message should be signed by both S/MIME and PGP, so, yes, it's
>>"possible". In this case, the signatures do nest in a nested
multipart
>>MIME hierarchy. The message body is encoded quoted-printable in one
>>MIME part. The encoded part is then signed and the signature is in
>>another MIME part. That assemblage is nested in another MIME part which
>>is then S/MIME signed and that forms another MIME part.
>>
>> Message ----
>> Mime S ----
>> Mime P ----
>> Body
>> Mime P ----
>> GPG signature on Body
>> Mime P ----
>> Mime S ----
>> S/Mime Signature on Mime P
>> Mime S ----
>> Message ----
>>
>> Now, why anyone would want to do this, I don't know. But it obviously
>>is possible and Evolution will, obviously, do it. In theory, this
>>should work. No guarantees about any and all clients being able to read
>>and verify it, however. Evolution certainly handles it. I've seen
>>enough compatibility problems between varying clients just withing pure
>>PGP/GPG and within pure S/MIME to have any expectations here.
>>
>> My S/MIME certificate is signed by the
CACert.org, <
www.cacert.org>,
>>root certificate. Maybe we'll see who can verify either with what...
>>
>> Mike
>>--
>>fedora-list mailing list
>>fedora-list(a)redhat.com
>>To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-list
>>
--
Michael Yep
Development / Technical Operations
RemoteLink, Inc.
(630) 983-0072 x164
GPG Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x126439D9
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw(a)WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 |
http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!