-----BEGIN PGP SIGNED MESSAGE-----
In <slrn659cj5(_dot_)19k(_dot_)lutz(_at_)taranis(_dot_)iks-jena(_dot_)de>, on
10/27/97
at 03:25 PM, lutz(_at_)taranis(_dot_)iks-jena(_dot_)de (Lutz Donnerhacke)
said:
* 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.
I MUST STRONGLY disagree here. This is a format RFC it should not be
dictating how that format is implemented. If I chose to have my app
default to using 1 RSA key pair it is above and beyond the scope of this
RFC to tell me otherwise let alone what information my application must or
must not provide to the user. If in the Appendix you wish to put
application recommendations that is fine but the wording as you have it
now is unacceptable.
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.
Once again you are taking the spec into territory it has no place being.
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.
Why?
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!
You need descriptions on how to interface with the servers using the
different network protocols not how the internals of those servers work.
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?
Depends on the application. I think that you are being too e-mail centric
in your thinking and thus limiting the applicability of the spec.
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.
There is no place in the RFC for dictating how the application interfaces
with the user. I am unaware of any other RFC's that do so.
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?
- --
- ---------------------------------------------------------------
William H. Geiger III http://www.amaranth.com/~whgiii
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html
- ---------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNFS6mI9Co1n+aLhhAQHA+QP/XLgrAuVCsdCWgWEqIyJsDC832sXobMqj
5BlwgjM79XVihA0BcAKNpV3us4fbr4YKXNW25+DpT4YokqRgKFRBRMFedIg4+2no
s3gJBXlTqhUJgVzIz/gmd7SNz522zKYpe1ff+/rIYLlM9ItVA2k/dgRxNXpmoNqL
IJRW6qrMIsM=
=2mnJ
-----END PGP SIGNATURE-----