Strength in Complexity?

[Ben Laurie]

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 majordomo at metzdowd.com