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@xxxxxxxxxx > >>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@xxxxxxxxxxxx /\/\|=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!
Attachment:
signature.asc
Description: This is a digitally signed message part
