Re: MUST versus SHOULD in application decisions

[lutz@xxxxxxxxxxxxxxxxxxx (Lutz Donnerhacke)]

* 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?