Arshad Noor wrote:
Florian Weimer wrote:
* Arshad Noor:
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937
On a more serious note, I think the criticism probably refers to the
fact that SKSML does not cryptopgrahically enforce proper key
management. If a participant turns bad (for instance, by storing key
material longer than permitted by the protocol), there's nothing in the
protocol that stops them.
Thank you for your comment, Florian.
I may be a little naive, but can a protocol itself enforce proper
key-management? I can certainly see it facilitating the required
discipline, but I can't see how a protocol alone can enforce it.
Any examples you can cite where this has been done, would be very
helpful.
I find the question difficult to understand. Before I could even begin
to answer, you'd have to define what "proper key management" actually is.
That said, EKMI (from my brief reading) has a view of key management
that is only "proper" in quite constrained circumstances. In particular,
keys are available to participants other than those who are
communicating, which is general considered to be a very bad idea. This
is fine if you are a corporation wanting to achieve escrow, of course.
Though that can be done without requiring a central server to remember
all the keys, of course.
The design paradigm we chose for EKMI was to have:
1) the centralized server be the focal point for defining policy;
2) the protocol carry the payload with its corresponding policy;
3) and the client library enforce the policy on client devices;
In some form or another, don't all cryptographic systems follow a
similar paradigm?
Well. You said "centralized server". Many cryptographic systems don't
have one of those.
Also, the idea of a client library enforcing policy is DRM all over
again. Which, as we all know, will never work.
So, in short: no, they don't.
Arshad Noor
StrongAuth, Inc.
P.S. Companies deploying an EKMI must have an external process in
place to ensure their applications are using "verified" libraries
on the client devices, so their polices are not subverted.
Ha ha. Like that's going to work. Even if we assume that libraries are
verified (fat chance, IMO), how are you going to stop, for example,
cut'n'paste? Employees reading things out over the phone? Bugs? Etc.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.links.org/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
