So, an executive summary of your responses appears to be "EKMI leaves
all the hard/impossible problems to be solved by components that are out
of scope".
As such, I'm not seeing much value.
Anyway...
Arshad Noor wrote:
Ben Laurie wrote:
OK, so you still have a PKI problem, in that you have to issue and
manage client certificates. How is this done?
One man's meat .... :-). (I don't necessarily view this as a problem
Ben. I've built up a career and a small business in the last 9 years
doing just that.)
Nevertheless, to answer the question, the PKI deployment is not part
of the SKSML prtocol (other than the WSS header that carries the XML
Signature and/or XML Encryption of the SOAP Body), but it is part of
an EKMI. (EKMI = PKI + SKMS). A company deploying an EKMI must have,
or must build a PKI and deploy the client/server certificates separately
from the SKMS.
While this might be viewed as a problem for some/many companies in the
short-term, I fully anticipate that vendor implementations of SKMS will
integrate with PKI software to manage this process seamlessly in the
future.
PKI out of scope...
I do not believe this is the case. DRM fails because the attacker has
physical possession of the system he is attacking.
Which is why we are recommending that SKMS clients use hardware based
modules (be it TPMs, smartcards, HSMs, etc.) to generate and store the
Private Key used by SKMS client to decrypt the symmetric keys. While
even these can be attacked, the problem is now in a different domain
than the SKSML protocol.
...impossibility of solving DRM problem out of scope...
EKMI's goals are not to provide bullet-proof security. It has more
modest ambitions - to provide a management framework for incremental
security, targeted at the right resource: the data, rather than the
network.
Are there any even vaguely modern systems that target the network for
security, or is this a straw man?
What I meant to say is that EKMI's goal is to protect the data and not
the network.
...goals the same as pretty much all cryptographic protocols...
If it is up to them, then why bother with this verification process?
This sounds like yet more security theatre to me.
I'm not sure which verification process you're referring to.
No, this is not security theater. EKMI does not guarantee anything, nor
does it promise unbreakable anything. Everything in EKMI is a choice.
You get to choose the strength of your keys, your PKI, your policies,
your procedures and your implementation. All we're offering is a tool
that does something specific to the extent that the specifications and
the technology allows. Nothing more, nothing less. If you - as a
cryptographer - say that AES-156 will do X under these conditions, then
EKMI will support X under those conditions. EKMI only adds the ability
to manage a large number of keys centrally, and to ease many of the
administrative burdens we see that large-scale key-management can cause.
Everything it does is constrained by the limitations of the underlying
technology components, polices and practices. But you still have to
make the choice.
...security out of scope and scope out of scope.
Is there anything other than key escrow that's actually in scope?
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]
