ietf-openpgp
[Top] [All Lists]

Re: MUST versus SHOULD in application decisions

1997-10-27 08:26:28
* Ian Grigg wrote:
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.

Yes, you are right. But not a all issues.

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.

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 SHOULD NOT occur on public keyservers. If such a key arrives
over the Internet, a warning SHOULD 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.


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.

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.

 Firstly, to say anything about what goes on a public keyserver is
outside the scope of this standard (I think - correct if wrong).

Keysserver are ontopic in this draft at chapter seven. It is needed to
provide automatic requests. I do need descriptions on http, email, dns and
lapd servers!

 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.

Anti-GAK features implemented in software are the best results this draft
can generate. If 70% of deployed software actively prevent snooping, it is
impossible to build GAK systems.

 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.

Put it on the right server: Your company's server. Storage keys are for your
local enviroment only, arn't they?

 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.

Sure? Think about deployment.

 Fifthly, a "MUST produce a warning" excludes many operational
scenarios:  scripts, batch jobs, experienced users, new applications,
....

There is no part claiming: 'The user MUST read.'
If we do not point out the security problems. Several implementations will
hide them from users because clicking is easierer than thinking.

On a broader issue, I am very happy to see that the CMR packets have
been dropped from mention in the standard.

They are still there. I choosed a form PGP Inc. can live with.

I think we have to be fair
and also not accept the CDR alternative for inclusion or mention in the
standard.

There is a need for recovery on storage keys. Several people urged me to
include shared secrets....

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.

Why not doing it now with two additional paragraphs?

<Prev in Thread] Current Thread [Next in Thread>