extra dashes in PGP-related blocks?

When people have been posting their public keys, or encrypted address
blocks, to various lists I'm on, all of the "-----BEGIN whatever..." lines
seem to have a "- " preppended to them. So, for instance, they look like:

- -----BEGIN PGP MESSAGE-----
Version: 2.6.2
[stuff]
- -----END PGP MESSAGE-----

I'm guessing if I really sent a block like that to a remailer, the remailer
would hork because of the prepended "- "s.  I know that sometimes people's
public keys they've posted to a list look like that, and when I try to add
them to PGP, it horks, and I've got to go into a text editor and remove the
"- ", and then add it to my keyring.

Does anyone know what it is that's putting in these "- "s, why it's putting
them in, and how to stop it?

>> From: Jonathan Rochkind
>
>When people have been posting their public keys, or encrypted address
>blocks, to various lists I'm on, all of the "-----BEGIN whatever..." lines
>seem to have a "- " preppended to them. So, for instance, they look like:
>
>- -----BEGIN PGP MESSAGE-----
>Version: 2.6.2
>[stuff]
>- -----END PGP MESSAGE-----
>
>I'm guessing if I really sent a block like that to a remailer, the remailer
>would hork because of the prepended "- "s.  I know that sometimes people's
>public keys they've posted to a list look like that, and when I try to add
>them to PGP, it horks, and I've got to go into a text editor and remove the
>"- ", and then add it to my keyring.
>
>Does anyone know what it is that's putting in these "- "s, why it's putting
>them in, and how to stop it?

pgp is putting those extra "- " pieces in (guess you didn't read all
your pgp docs :-),  it does that so that it can tell the difference between
pgp begin/end blocks and other stuff, kinda like sendmail "quoting" lines
beginning with a dot with an extra dot.  the difference here is that
sendmail removes any leading dots before delivery and pgp doesn't after
removing a signature.  yeah, you do have to load it into an editor but
mailing something to a remailer shoud not "hork" it.  the pgp running on
the remailer will just "- " the stuff and include it literally.

follow?

-- 
--< "CYBERBOY" >--
andrew@ml.com (Andrew Brown)
Phone: 1.212.449.0088
Fax:   1.212.449.8612

-----BEGIN PGP SIGNED MESSAGE-----

To: andrew@riskdev.ml.com (Andrew Brown)
cc: jrochkin@cs.oberlin.edu (Jonathan Rochkind), cypherpunks@toad.com
Subject: Re: extra dashes in PGP-related blocks? 

> >> From: Jonathan Rochkind
> >
> >When people have been posting their public keys, or encrypted address
> >blocks, to various lists I'm on, all of the "-----BEGIN whatever..." lines
> >seem to have a "- " preppended to them. So, for instance, they look like:
> >
> >- -----BEGIN PGP MESSAGE-----
> >Version: 2.6.2
> >[stuff]
> >- -----END PGP MESSAGE-----
> 
> pgp is putting those extra "- " pieces in (guess you didn't read all
> your pgp docs :-),  it does that so that it can tell the difference between
> pgp begin/end blocks and other stuff, kinda like sendmail "quoting" lines
> beginning with a dot with an extra dot.  the difference here is that
> sendmail removes any leading dots before delivery and pgp doesn't after
> removing a signature.  yeah, you do have to load it into an editor but
> mailing something to a remailer shoud not "hork" it.  the pgp running on
> the remailer will just "- " the stuff and include it literally.

Uhh, this is not at all true.  When PGP verifies a message, it will
strip out the quoting dashes in the output.  This is documented in RFC
822 (I think) about quoting messages.

Just run the message through PGP and it will strip out the first level
of quoting in the output message, and you should be able to then run
PGP on the rest of the message as well.

This is not a bug, it is a feature to let PGP know *WHAT* was being
signed, so that nested PGP clearsigned-messages don't interfere with
each other.  If it didn't quote, then if I wanted to clearsign a PGP
message, the output would look something like:

- -----BEGIN PGP SIGNED MESSAGE-----

stuff here

- -----BEGIN PGP SIGNED MESSAGE-----

more stuff here

- -----BEGIN PGP SIGNATURE-----
inside signature
- -----END PGP SIGNATURE-----

- -----BEGIN PGP SIGNATURE-----
outside signature
- -----END PGP SIGNATURE-----

If you have this, how do you deal with it?  This is the same as the
paranteses-matching-problem: If you are trying to match opens with
closes, you have the problem that you could always have so many opens
that you overrun your counter before you get to any closes!

So, PGP uses the RFC-822 quoting mechanism to quote internal messages.
This is perfectly legal.

As for MIME: If you are using PGP to secure MIME objects, you should
take the _OUTPUT_ from PGP and send that back into the MIME reader.
MIME should NOT be going inside the PGP block.  So, the behavior you
are seeing is perfectly reasonable for a broken mail-reader!  Fix your
mail reader to run the PGP-secured message through PGP, and then run
the output through MIME, and you will be fine!

Enjoy!

- -derek

         Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory
       Member, MIT Student Information Processing Board (SIPB)
    Home page: http://www.mit.edu:8001/people/warlord/home_page.html
       warlord@MIT.EDU    PP-ASEL     N1NWH    PGP key available

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQBuAwUBLuzEuDh0K1zBsGrxAQFcUgLDB1WGn7TQTf4+8FgYyszcNHgcMQTcVd3w
aTXunh0K7vPjos4JkVl4p5MQkNICjDxNC2KkgQkxeIs7Yy8VgaACSwIfhDrxs3+K
gMalhp2FHO3S/ZvnIo7RSmk=
=btQx
-----END PGP SIGNATURE-----

>> From: Derek Atkins
>>
>> pgp is putting those extra "- " pieces in (guess you didn't read all
>> your pgp docs :-),  it does that so that it can tell the difference between
>> pgp begin/end blocks and other stuff, kinda like sendmail "quoting" lines
>> beginning with a dot with an extra dot.  the difference here is that
>> sendmail removes any leading dots before delivery and pgp doesn't after
>> removing a signature.  yeah, you do have to load it into an editor but
>> mailing something to a remailer shoud not "hork" it.  the pgp running on
>> the remailer will just "- " the stuff and include it literally.
>
>Uhh, this is not at all true.  When PGP verifies a message, it will
>strip out the quoting dashes in the output.  This is documented in RFC
>822 (I think) about quoting messages.
>
>Just run the message through PGP and it will strip out the first level
>of quoting in the output message, and you should be able to then run
>PGP on the rest of the message as well.
>

but is a remailer (or pgp) smart enough to take the output from checking
a signature and run pgp over it again?  is it going to know to take something
and pass it through pgp until pgp can't do anything with it any more? i think
that's the problem that jrochkin was addressing.  he has a pgp encrypted
message and then signs it and then wants to mail it to a remailer so that the
remailer can decrypt the message but it won't ecause the encryption is
nested...

wasn't that it?

-- 
--< "CYBERBOY" >--
andrew@ml.com (Andrew Brown)
Phone: 1.212.449.0088
Fax:   1.212.449.8612

$400 million in gold bullion counter-intelligence FBI colonel Kennedy
Treasury Honduras jihad Rule Psix Legion of Doom terrorist Khaddafi
Uzi South Africa Peking

-----BEGIN PGP SIGNED MESSAGE-----

To: andrew@riskdev.ml.com (Andrew Brown)
cc: jrochkin@cs.oberlin.edu (Jonathan Rochkind), cypherpunks@toad.com
Subject: Re: extra dashes in PGP-related blocks? 

> but is a remailer (or pgp) smart enough to take the output from checking
> a signature and run pgp over it again?  is it going to know to take something
> and pass it through pgp until pgp can't do anything with it any more? i think
> that's the problem that jrochkin was addressing.  he has a pgp encrypted
> message and then signs it and then wants to mail it to a remailer so that the
> remailer can decrypt the message but it won't ecause the encryption is
> nested...

Why would it have to?  A plain remailer takes the input you give it,
and replays it to the output.  It doesn't modify the message in any
way, so there is no problem.

A remailer that signs a message should take what you send it (no
matter _HOW_ you sent it), sign that message wholesale, and then send
out the signed message.  This means that if you send it a PGP-signed
message, the output message will have two signatures -- the outer
signature being the signing remailer, and the inner signature (which
is quoted by PGP at the remailer) is the signature on the original
message.

This is the correct behavior, and _SHOULD NOT_ be changed.

An anonymizing remailer _might_ want to take the output of a PGP
message and pass that into the output, but that is a different
function altogether.

I dont understand why a plain remailer should have to know anything
about PGP if it is just doing remailing, and in any case it should
never have to verify a PGP-signed message, unless that is the purpose
of the remailer.  And even if that IS the case, it should only unwrap
the OUTERMOST wrapping from PGP -- it *SHOULD NOT* recursively try to
collapse the PGP armors.  That is NOT a remailer's job.

- -derek

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQBuAwUBLuzSYzh0K1zBsGrxAQGR3gLDBxPn9cmWWvWwyRdlcYUlRs5LqMHjMkRa
lmOggyb2QmFS1+vEqJ2a1oUxdLJHzNcH4JxjBplDKASmG19Ixvkt1nIjkwGi3yzN
J02drrVGYJqs426qnQhxI8E=
=B6In
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

>> From: Jonathan Rochkind
>
>My problem was that a user would send me their public key, inside of a
>signed message, and the "BEGIN PUBLIC KEY" stuff would have the "- " on it.
>Which means that before I can add it to my keyring, I've got to edit out
>the extra "- "s, and then save it in a file, and then pass it through PGP,
>instead of just passing the original message though PGP, or using the Mac
>"copy" command on a part of the message and sending that through PGP.
>Or someone sends me an encrypted address block inside a signed message, and
>I've got to do the same before I can use it.

but wait!  you can't actually verify the outer sig until you extract the key
from inside the signed message?  that's a bit more complicated.  pgp will
actually recognize a key embedded inside an armored, signed message but it won't
(i don't think -- warlord?) play with the key other than tell you it is one.

what these people should probably be doing is signing their public keys with
their private keys to provide the same functionality (almost).  what you have,
otherwise, really is a two step process.  you will have to strip off the outer
sig layer to get the the key.

>I now understand why PGP does what it does, but it's still a pain. Perhaps
>the ideal mail reading program would run my incoming mail through PGP
>before I even saw it, so I wouldn't have this problem. Well, actually not.
>My ideal mail reader would check the signatures before I saw them, but
>would also leave them intact on the message, so I could re-check them
>myself manually if I wanted.  Oh well.  It's not a limitation on
>functionality of any kind, just on convenience.

i believe if you used emacs to read your mail, you might get that sort of
functionality since it's very user-customizable (is that a word?).  i wrote
myself a little perl wrapper to handle signing/encrypting outbound messages
so that i don't have to type all the options and redirect the output or move
output files.  it's a one person thing.  to each his own.  i prefer to read
my mail in a very un-adulterated form and i do all my sig verifying and
decrypting by hand too.  i'm weird that way.

apologies to warload, you are right (imho) about the fundamental behavior of
remailers.  they shouldn't do things like that except perhaps atttemp to
remove the outer armor layer if it is an encrypting/decrypting remailer.

peas and goobles!

- -- 
- --< "CYBERBOY" >--
andrew@ml.com (Andrew Brown)
Phone: 1.212.449.0088
Fax:   1.212.449.8612

BATF plutonium AK-47 Kennedy colonel nuclear munitions Legion of Doom
smuggle World Trade Center arrangements strategic PLO Rule Psix Ortega

-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBLuzxy7AuBPCxVEQ9AQGylAQAtrcF0ra1aG94Wnac3QFIVL1kmiOsNlGj
zCMDAQxXExnBf5UhGct+EkDfO20kZAr2cgYwP5CH3YdcmKJ6J2nk9dvJaujZ2Dhf
hPpug+uqnGC7R7V0ZsCcq9onpgYW+9lS4Do+EG1MIfz7j5pg541HBoBVBXOpKRXo
nPPB+9OTkLw=
=xOk1
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

To: andrew@riskdev.ml.com (Andrew Brown)
cc: jrochkin@cs.oberlin.edu (Jonathan Rochkind), cypherpunks@toad.com
Subject: Re: extra dashes in PGP-related blocks? 

> but wait!  you can't actually verify the outer sig until you extract
> the key from inside the signed message?  that's a bit more
> complicated.  pgp will actually recognize a key embedded inside an
> armored, signed message but it won't (i don't think -- warlord?) play
> with the key other than tell you it is one.

Actually, PGP wont even do that.  If the key is not in your keyring,
it will complain about not finding it and output the de-armored
message.  If you want to add the key, you need to run it through PGP
once to de-armor it, save off the output, and then add that output
message to your keyring.

> what these people should probably be doing is signing their public
> keys with their private keys to provide the same functionality
> (almost).  what you have, otherwise, really is a two step process.
> you will have to strip off the outer sig layer to get the the key.

This is exactly what people should do.  People should _never_
clearsign a public key block.  If you want to sign it, sign the key
inside the keyblock.  When someone clearsigns a keyblock, they are
making two passes over it to create it, which requires you to make two
passes to read it in!

- -derek

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQBuAwUBLuz4Lzh0K1zBsGrxAQGSTgLDBtb7BWTSXbk5s8taH+2V8/MHpz/1BYIi
AesXunQmFmJ+WXGNHbkfDK5CF2VzwiYyBaDxTkY90PwEV7cUAoNg3yCI8QJbsGX/
ZkO1kxTih46a1LucIe6U4EE=
=Ov0C
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----


> From: Derek Atkins
>> but wait!  you can't actually verify the outer sig until you extract
>> the key from inside the signed message?  that's a bit more
>> complicated.  pgp will actually recognize a key embedded inside an
>> armored, signed message but it won't (i don't think -- warlord?) play
>> with the key other than tell you it is one.
>
>Actually, PGP wont even do that.  If the key is not in your keyring,
>it will complain about not finding it and output the de-armored
>message.  If you want to add the key, you need to run it through PGP
>once to de-armor it, save off the output, and then add that output
>message to your keyring.

yep, you're right (like i'm surprised or something, judging from your handle)
pgp won't recognize it if you don't have it on your keyring.  i do work from
a sun and play at home on a linux system.  i have too many keys at home to
make my play testing easy and i got caught in that trap.  it's just too easy
to add a login and start playing with pgp in a simulated multi-user
environment that doesn't have the pitfalls of the real world.

- -- 
- --< "CYBERBOY" >--
andrew@ml.com (Andrew Brown)
Phone: 1.212.449.0088
Fax:   1.212.449.8612

genetic Soviet fissionable plutonium DES Kennedy nuclear terrorist
Waco, Texas NSA Qaddafi Marxist FSF ammunition South Africa

-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBLu0aY7AuBPCxVEQ9AQF7mwP9GY+DQtdjPLrF6XS+yJIXXhCaZELt1cDl
HHscvAeJL1SQplYcrmCtE5N2QLPVtQh5Dty/6qjYZ21fs4nA5CrK+6Z0Mxfxqc4V
eSKk1OVvtT6HjcNx7cFzNjrF0C8eWcnpd256Zgdjfn6DhSY4Jal9X+w4MZiSvCQS
MRYy6GvfQho=
=xCcd
-----END PGP SIGNATURE-----

THUS SPAKE jrochkin@cs.oberlin.edu (Jonathan Rochkind):
# 
# Does anyone know what it is that's putting in these "- "s, why it's putting
# them in, and how to stop it?

They're part of RFC934 and they are the correct standard way to 
encapsulate messages inside messages, short of using MIME.
Many mailers produce & handle these correctly.  

The extra "- " are due to "Character-Stuffing the Encapsulation Boundary".
What you&we need is filters to extract encapsulations that unstuff
nested encapsulations.

Relevant excerpt from RFC934 follows.    --strick

--
--
--


Network Working Group                        Marshall T. Rose (Delaware)
Request for Comments: 934                       Einar A. Stefferud (NMA)
                                                            January 1985

              Proposed Standard for Message Encapsulation

  ...

Message Encapsulation

  ...

   Definitions: a draft forwarding message consists of a header portion
   and a text portion.  If the text portion is present, it is separated
   from the header portion by a blank line.  Inside the text portion a
   certain character string sequence, known as an "encapsulation
   boundary", has special meaning.  Currently (in existing
   digestification agents), an encapsulation boundary (EB) is defined as
   a line in the message which starts with a dash (decimal code 45,
   "-").  Initially, no restriction is placed on the length of the
   encapsulation boundary, or on the characters that follow the dash.

  ...

      2.3. Encapsulated Messages

      Each encapsulated message is bounded by two EBs: a pre-EB, which
      occurs before the message; and, a post-EB, which occurs after the
      message.  For two adjacent encapsulated messages, the post-EB of
      the first message is also the pre-EB of the second message.
      Consistent with this, two adjacent EBs with nothing between them
      should be treated as enclosing a null message, and thus two or
      more adjacent EBs are equivalent to one EB.

  ...


Character-Stuffing the Encapsulation Boundary

   It should be noted that the protocol is general enough to support
   both general forwarding of messages and the specific case of digests.
   Unfortunately, there is one issue of message encapsulation which
   apparently is not addressed by any forwarding agent (to the authors'
   knowledge) in the ARPA-Internet: what action does the forwarding
   agent take when the encapsulation boundary occurs within a the text
   portion of a message being forwarded?  Without exception, this
   circumstance is ignored by existing forwarding agents.

   To address this issue, this memo proposes the following
   character-stuffing scheme: the encapsulation boundary is defined as a
   line which starts with a dash.  A special case is made for those
   boundaries which start with a dash and are followed by a space
   (decimal code 32, " ").

      During forwarding, if the forwarding agent detects a line in the
      text portion of a message being forwarded which starts with the
      encapsulation boundary, the forwarding agent outputs a dash
      followed by a space prior to outputting the line.

      During bursting, if the bursting agent detects an encapsulation
      boundary which starts with a dash followed by a space, then the
      bursting agent does not treat the line as an encapsulation
      boundary, and outputs the remainder of the line instead.

   This simple character-stuffing scheme permits recursive forwardings.

  ...

--
--
--
  strick <...!{ihnp4,akgua,allegra,gatech}!techwood.org!strick>


  echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
                                           --keithv@cs.berkeley.edu(?)

--