-----BEGIN PGP SIGNED MESSAGE-----
5.2.2 Signature packet
[...Subpacket definitions...]
8 - key usage (REQUIRED)
...
Storage keys MUST NOT be used in communication. They SHOULD be droped
from keyrings outside the desired storage enviroment to avoid message
key recovery. They MUST NOT occur on public keyservers. If such a key
arrives over the Internet, a warning MUST be produced and the key MUST
be droped (prefered) or disabled locally.
Group keys for communication encryption may be set up by a company to
address encrypt company readable e-mail to. Software MUST produce a
warning, if a group key is used. Group keys are for encryption of
communication only. Keys combining an other purpose to a group key
MUST NOT be generated and MUST NOT be accepted.
The same key usage subpacket MUST occur on every self-signature
certificate. If other user IDs specify a different key usage, the key
MUST be disabled.
I think this language is too strong. When you are talking about
protocols, then the word "MUST" makes sense. But when you are talking
about application decisions, there is the likelyhood of different ways
of thinking, and then we need to be more flexible.
For example, to say that "They MUST NOT occur on public keyservers" is
too constraining.
Firstly, to say anything about what goes on a public keyserver is
outside the scope of this standard (I think - correct if wrong).
Second, by stating such policy decisions, we now have to add in these
decision choices to the software, elsewise "public keyservers" will not
be of much use for private purposes.
Thirdly, I might invent an application where I have some externally
accessible storage such as an Internet data store on the web, and I
might want to push the keys for that onto public servers. I'm
hypothesizing here; one thing I have learnt is that you should never
constrain the future generation from using your inventions in ways you
yourself didn't have the capability to grasp. Likewise, don't try to
constrain the programmer's mindset with rules.
Fourthly, some of this language assumes a resolution to the CMR/CDR
debate, and that, being political, is not something that a standard
should try and influence.
Fifthly, a "MUST produce a warning" excludes many operational
scenarios: scripts, batch jobs, experienced users, new applications,
....
Where application decisions (and politics) are concerned, I would hope
to see the strongest terms limited to "SHOULD do" rather than "MUST
do." Then it can be considered expert advice, not protocol law.
On a broader issue, I am very happy to see that the CMR packets have
been dropped from mention in the standard. I think we have to be fair
and also not accept the CDR alternative for inclusion or mention in the
standard. Both of these proposals are still too young to be
incorporated in the base standard, both remain undeployed to any
extent. Also, there is plenty of mileage in what the standard is trying
to achieve - existing practice and formats - without getting into these
areas, which could presumably be codified as separate add-on RFCs if so
desired.
- --
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com
-----BEGIN PGP SIGNATURE-----
Version: Cryptix 2.21
iQCVAgUANFNAZJUdDk1bRs+FAQFE/gQAmuVpMfMnY/gv4UpP2nMbR7hrami6akk1
IVkKYIC88UcLb6lhpHA2AUtoEpXh6wMeRpXri72JJ/nM8ETQaIHYkm8P+NpgL5Y0
CH3ogxZngdHVmcghz1+GsU9D7BkOscV+utsf9NRxxpb6ip7XCY0s31tXXzXEBN+o
YSdOBTZSQo4=
=TgBj
-----END PGP SIGNATURE-----