-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ian Grigg, <iang(_at_)systemics(_dot_)com>, writes regarding the critical bit:
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.
The claim seems to be that the critical bit will lead to annoying software
which pesters the user to upgrade. But this would not necessarily happen.
There is no more reason to tell the user about an unknown packet with
a critical bit than to tell him about an unknown packet without the
bit set. Either way, upgrading might be a good idea as it will add some
(inherently unknown) functionality. All the critical bit changes is
the default handling of the signature containing the unknown packet.
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
things broken.
The purpose of the critical bit is to make it easier to add extensions
to the meaning of signatures. One thing we have found in 5.X is the
difficulty of trying to maintain backwards compatibility with old versions
of PGP. We want to try to avoid this in the future by designing so that
future implementations will have an easier job being backwards compatible.
The critical bit greatly increases the flexibility and ease of adding
new features without breaking old implementations. You can create new
kinds of signature qualifications, which would otherwise be interpreted
wrongly by old code. For example, suppose we hadn't thought of adding
signature expirations and we wanted to add a field for that purpose.
Issuing a signature with an expiration field will be dangerous because
old software won't understand the expiration part and will treat it
as valid even when it has expired. This breaks the security model.
By setting the critical bit we make the old software ignore signatures
with expirations rather than treating them as lasting forever.
It's a matter of whether the old software errs on the secure side versus
on the risky side. The critical bit increases security by making the
software err conservatively.
Hal said:
- On a self-signature, ignore the key if you don't understand the
subpacket type. This is because the self-signature may be
saying something important qualifying the meaning of the key or
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 don't understand why this simple rule is so troublesome. But even if
this particular case seems difficult, the more general rule of ignoring
signatures with unknown critical subpackets should be straightforward
enough. (The self-signature rule would then follow automatically if we
adopted the convention of not using userids that were lacking self-sigs,
as Lutz has suggested.)
I would suggest that the Criticality bit be dropped.
This will limit the scope of future expansions. Designers who want to
add new semantics to signatures (e.g. see the SPKI work, PolicyMaker,
or any of the many research projects on trust models) will find their
options limited. They will probably have to create new kinds of signature
packets just so that old software will ignore their signatures. This will
lead to redundancy, with different signature packets defined with the
same or similar semantics, solely to prevent old software from treating
the signatures the wrong way.
The critical bit is a benefit to future designers. It helps to make
the spec more robust and able to accommodate future needs. It does not
add much complexity to just ignore signatures which have unrecognized
critical subpackets. It will be a useful feature.
Hal Finney
hal(_at_)rain(_dot_)org
hal(_at_)pgp(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBNHxkmMDh8jnv1nHwEQJlAwCfaXg6+bvIszQDAJVScfV1+GKYI2cAoIOM
7C3k4euDQBHHtg3HRVhFPYTB
=ne6R
-----END PGP SIGNATURE-----