At 11:50 AM 10/29/1997 GMT, Adam Back wrote:
Realistically, PGP Inc. does get a bit of extra slack in OpenPGP.
In particular, if the field really was defined in 5.0 (not necessarily
used, but defined),
Yes it's defined in that the software knows what to do with it.
Do you know which file it's defined in in 5.0 source?
I dredged around in there for a while and didn't see anything
that looked quite like it, but there's a lot of source there.
This approach to extensions leads to compatibility problems -- you
send to sales(_at_)acme(_dot_)com and it will bounce your mail if it is set up
strictly.
The PGP Inc. SMTP filter offers a medium-wide range of options;
it can be set to reject unencrypted mail, or reject encrypted mail,
or reject unsigned mail (of course it can't decrypt, so it can only
tell whether unencrypted mail is also unsigned), etc.
If the administrator doesn't write adequately explanatory bouncegrams,
unlucky senders are going to get hosed anyway.
In particular, one of the postings I read on this list said that if
the sender's PGP public key ring doesn't already have the CMRK key,
it will ignore the CMRK KeyID request, so you'll get hit with this anyway.
To guarantee compatibility, your choices as implementor are:
- send garbage in second recipient field
- send valid second recipient
Unfortunately, it does look like the new format uses 64-bit KeyIDs
for these fields, and a 0xdeaddeaddeadbeef attack is a few billion
times harder than a 0xdeadbeef attack, which could otherwise fool it :-)
- ignore additional recipient request (it does say "request"), and
have confused users who can't interoperate even though both using
OpenPGP compliant appliactions.
doesn't seem very good from an interoperability point of view, unless the
standard says that pgp5.5 should not bounce mail.
PGP5.5 doesn't handle mail, so it can't bounce it. SMTP filters do,
and they're outside the scope of OpenPGP. Mail User Agents may
call PGP, but by then it's delivered, though I suppose the MUA could
bounce it if PGP returns an appropriate failure code, like "Can't decrypt".
(Returning predictable and useful failure/success indicators _is_
part of OpenPGP's scope.)
The correct way to implement extensions I think is to detect extension
capability based on public key, and only use it where it is available.
(Such as SMTP extensions, browser capability negotiation, SSL
algorithm negotiation, etc). Same as symmetric cipher capability
flags in public keys (which are already defined -- I think?)
Do you mean look up the extension information in some keyserver?
Or do you mean what it sounds like you mean, which is determine
whether to use a given extension based on flags in the public keys records?
If the latter, that's _precisely_ what the CMR feature _does_...
This approach to extensions would dictate that pgp5.5 policy enforcer
SMTP agent would only ever bounce mail where the keys indicated they
were generated by software which advertises being capable of
understanding ARRs.
The PGP5.5 message format doesn't differentiate between recipients
who were included because the sender wanted them or because of ARRs,
and the PGP Inc. implementation of the SMTP incoming enforcer can't tell.
On the other hand, the only people who would install such a silly thing (:-)
are companies whose users have been told to use PGP Business Version>=5.5,
and if you _want_ to enhance the filter to check each KeyID, it'll find
their CMRK recipient KeyIDs and be happy.
I guess there's still the outgoing email policy enforcer, which
_could_ hang on to each outgoing encrypted message while it tries to find
the KeyID on some keyserver that may not even be accessible to it
to make sure the recipient doesn't mind that the sender's company
kept a copy of the outgoing mail, but it sounds impractical to implement.
I'm mostly surprised, because you seem to have agreed with 2/3 - 4/5 of
what PGP5.5 CMR does, and I thought you were more vehemently against it
than I am....
It might be worth documenting, or making suggestions in the standard
on a method to implement extensions, so that we don't get more
problems like this.
Yep. I'm especially annoyed at this one, since we _had_ the source
and basically nobody noticed these features were there until PGP
announced what PGP 5.5 did with them, and I'm not sure if anybody
even noticed the more blatant ViaCrypt GAK features until then.
(But I did send you my copy of the source using cheap slow-mail :-)
Then people who don't want ARR for security and political reasons can
interoperate.
OpenPGP definitely shouldn't encrypt to ARRKs without some indication from
the sender that it's OK, whether it's a command-line flag or checkbox
or failing to drag the red blinking icon out of the dialog box
or config file / preferences setting or something. [Yeah, yeah,
in another of my rants I argue that OpenPGP doesn't have a mechanism
for indicating _to_ the user that this is going on, since a GUI
is really out of its scope and it may be running non-interactively,
and putting an indication that it did it into the output file isn't
enough control, but it probably always has some parameter input capability.]
-----BEGIN PGP ENCRYPTED MESSAGE-----
Comment: Eavesdropper 0x12024561111 wanted a copy
Comment: Eavesdropper 0x16503264930 wanted a copy
Comment: Nosy, aren't they; hope you don't mind.
a043950a3945093450935934a9503495-034950394503459aa
Thanks!
Bill
Bill Stewart, stewarts(_at_)ix(_dot_)netcom(_dot_)com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639