Adam Back wrote:
The bad news is that, while the Criticality Bit is only sketchily
documented, it sounds like part of a CMRist plot, to make use of the
ARR mandatory if the recipient requests it
I see the problem -- ouch -- if a vendor choses to, they can make
their software mark ARRs as critical and old software will say that
the self signature failed. Which could result in the software not
using the key.
I think the fact that doing so introduces compatibility problems
protects us from this happening, a vendor's corporate customers may
get irate when they are unable to communicate with OpenPGP compliant
implementations due to such a purposely introduced incompatibility.
Nope, just the reverse. Your comment above has helped me see what Bill
was talking about.
Introducing compatibility problems in this way can be solved by
upgrading to the latest release, so it becomes a tool for migrating your
user base onto the new software. The technique is to make the software
basically work, so as to limit the downside. MS are the masters of
knowing which bugs not to fix. Mathematically, look to epidemic theory,
which says something to the effect that if each instance causes k people
to upgrade, where k is some number greater than 1 (i.e., 1.1) then it
will work. Of course, it also works a lot better if you can offer a few
new features with the upgrade.
This is not the effect that is occurring with the pgp5.0, as that has
IMHO failed, because it is practically incompatible. I'm not saying
pgp5 has failed, just that you need to consider other models. The
result with pgp5.0 is that if you upgrade, you won't be able to talk to
all your non-upgraded contacts at all, so you won't upgrade. (I'm not
entirely sure what is going on here, but I think what happens is that as
soon as the RSA keys get any of the extra packets added to them, it
appears that 2.6 will reject them in a variety of ways. I've tried with
3 different people to get comms between 2.6 (and Cryptix) and pgp5.0.
No joy yet.).
In the case of the Criticality bit, you will still have comms, but the
various MUAs will alert you to problems, which is ideal. No loss of
functionality, but an annoying reminder to upgrade every time you talk
to someone :-) On this basis alone, I think we'd like to avoid a
standardised "please upgrade me" virus.
I think the issue here surrounds the nature of the extension. Normally,
if one wanted to hack in and add the <i>whatiwant</i> feature, one would
do it in such a way that the feature was innocuous to older
non-conforming software. So the feature has to be an addition, without
which the sum is unchanged from the older standard.
In the new packets as discussed here, the PGP Inc whatiwant feature is a
*subtraction* in that it applies some limit to the power of the
signature. Now, you can't take something away, and then put it back
whilst talking to those that don't understand the new mathematics. PGP
Inc people have recognised this, and have added an additional feature
that says "on any subtraction, reject the lot." If everybody
understands that there is a subtraction going on, then at least if they
can't put back that which was lost, then they can consider the whole
- On a self-signature, ignore the key if you don't understand
subpacket type. This is because the self-signature may be
saying something important qualifying the meaning of the key
how it is intended to be used by the owner. If you don't know
what he's saying, it's safest not to use the key.
This is trouble piled upon trouble. Trying to set this sort of
behaviour up in complex software is tricky, and is best avoided unless
you're well paid to do precisely that (and I hope the folks at PGP Inc
are indeed well paid). Putting it into a standard is equivalent to
institutionalising software failures.
I would suggest that the Criticality bit be dropped.
(there _is_ the semantics issue of what the program should do if it
understands the Additional Recipient Request and doesn't feel like
Well a cypherpunk or pro privacy advocate's PGP patch / implementation
can do one of a number of things:
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com