Bill Stewart <stewarts(_at_)ix(_dot_)netcom(_dot_)com> writes:
Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> writes:
I vote this does not go in.
If this goes in, everyone will be arguing for their favourite
extension of the day to go in, and there will be a messy political
argument, so lets please get this draft out without further argument.
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. Ian
Brown experimented and found that pgp5.0 knows how to reply to the
second recipient on a pgp5.5 for business generated key with ARR
(Additional Recipient Request) attached to the userid. So the
backwards compatibility is there.
However the only software currently which can generate keys with ARRs
so far is pgp5.5 for business.
and probably even if it only appeared in 5.5, then accepting key
records containing it should be part of the standard, though I
strongly agree that any semantics of what to do about it shouldn't
be in the standard.
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.
To guarantee compatibility, your choices as implementor are:
- send garbage in second recipient field
- send valid second recipient
This:
- 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.
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?)
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.
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.
Another approach may be:
Define an extension structure, and allocate an extension of "ARR/CMR"
for PGP Inc's method. Perhaps kludge some feature of the current
message format which PGP is using in their pgp5.5 for business keys to
indicate this capability, even.
Then people who don't want ARR for security and political reasons can
interoperate.
Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`