John Noerenberg <jwn2(_at_)qualcomm(_dot_)com> writes:
However, our goal is not to go too far afield with PGP.
Right.
Clearly CMR is a contentious issue within this group (and
elsewhere). Rightly or wrongly, there is a perceived need for it by
some who nevertheless wish to encourage greater use of cryptography
to protect their organization's communication from others.
More secure alternatives where presented which achieve the same
functionality. See: http://www.dcs.ex.ac.uk/~aba/cdr/
Interoperability is important, but so is security.
My view is that the protocol we produce should never mandate CMR.
But it would be wise to document a means to implement it for those
willing to risk potential limitations on their interoperability with
others.
This is an interoperability issue, I think it is important that
different versions and different vendors implementations which are
compliant with the OpenPGP standard can talk to each other.
PGP Inc's pgp5.5 can be set up to prevent interoperability -- turn on
strict policy enforcer setting -- it will bounce mail without second
recipient.
This compatibility issue needs to be resolved.
So far, I see arguments on both sides of the issue.
Yes, there are.
It is possible to implement functionality extensions interoperably
outside the standard in that a proprietary extension can be used only
for communications between so enabled software. The same kind of hack
to distinguish recipient type can be used as is currently used to
distinguish between things like pgp2.x, cryptix2.2.2 and pgp5.x -- the
keys have different version numbers.
We're not that far apart in our attitude here.
I suggest that the standard should document an extension mechanism to
avoid more of these problems.
For example there is already a symmetric key negotation being
discussed with capabilities or preferences being indicated by flags
attached to public keys.
Could not ARR capability be indicated with such a flag? Then if the
sender is not advertising the abilitiy to comply with additional
recipient requests, policy enforcers will know to not bounce mail, and
we retain interoperability.
The existing pgp5.5 for business implementation would then be
compliant, so long as the strict policy enforcer option is not used.
Or, an alternative is to define in the standard that implementations
which do not support the ARR request send garbage in the second
recipient field to ensure compatibility with pgp5.5. (This
immediately guarantees interoperability -- future implementations
(such as pgp6.0) -- can then make use of the ARR extension flag on
public keys).
I think it is important that the standard should document an extension
mechanism to avoid more of these problems.
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`