Arshad Noor [EMAIL PROTECTED] writes:
Ben Laurie wrote:
As such, I'm not seeing much value.
That may be because you are a cryptographer. If you were the CSO, an
Operations Director, or an Application Developer in a company that had
to manage encryption keys for 5,000 POS Terminals, 10,000
On Sun, 3 Aug 2008, Arshad Noor wrote:
A more optimistic way of putting this, Ben, is to state that EKMI allows
domain-experts of underlying components to address the complex issues of
their domain in ways that they deem best, while providing value on top
of those components. I see no reason to
Perry E. Metzger wrote:
There are existing deployed solutions like Kerberos that scale far
beyond that and work just fine, and actually address all the things
this protocol seems to leave as an exercise to the reader. And yes,
they're in use in real companies at gigantic scales. (Indeed,
Cat Okita wrote:
... or in other words, EKMI leaves all of the hard/impossible problems
to be solved by somebody else. I'd have to agree with Ben that I'm
not seeing the value add of an additional layer of complexity.
I view EKMI as using the best tools the cryptographic community has to
Arshad Noor [EMAIL PROTECTED] writes:
That said, Kerberos clearly has the benefit of 20+ years of research
and use in the field. However, there are two fundamental differences
between SKSML and Kerberos, IMHO:
1) The design goals for Kerberos were very different from SKSML. The
former
Perry E. Metzger wrote:
That said, kerberos tickets can persist even in the face of
disconnects, so once you've connected tickets can survive as long as
you wish.
But, can the tickets be used for anything useful when the
network does not exist?
I agree that when the network comes back, the
With the caveat that I am reading mail in
reverse order (i.e., panic-mode), I do have
to say one thing and it isn't even to mount a
stirring defense of Kerberos, which does not
need defending anyhow...
The design space for practical network security
has always been:
I'm OK
You're OK
Arshad Noor [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
That said, kerberos tickets can persist even in the face of
disconnects, so once you've connected tickets can survive as long as
you wish.
But, can the tickets be used for anything useful when the
network does not exist?
If you
Perry E. Metzger wrote:
Arshad Noor [EMAIL PROTECTED] writes:
- after all people didn't really need DBMS's 30 years
ago because they could do all the data-management operations
inside each application quite well, thank you!
I think that comparing the advance SQL made with SKMS seems a bit
[EMAIL PROTECTED] writes:
The design space for practical network security
has always been:
I'm OK
You're OK
The Internet is a problem
A gathering storm of compromised machines, now
variously estimated in the 30-70% range depending
on with whom you are talking, means that the
Tim Hudson [EMAIL PROTECTED] writes:
I think that Arshad's point here is an argument that externalising
key management handling from normal application logic is a valid one
but that it is also equally applicable to existing Kerberos
environments.
I don't think a point beyond externalisation
Perry E. Metzger wrote:
SKMS is vaporware that leaves all
the hard parts of the specification out.
An open-source implementation has been available for 2 years.
A new version will be available next year that will implement
the current OASIS draft and whatever useful comments the
Public Review
[EMAIL PROTECTED] wrote:
With the caveat that I am reading mail in
reverse order (i.e., panic-mode), I do have
to say one thing and it isn't even to mount a
stirring defense of Kerberos, which does not
need defending anyhow...
The design space for practical network security
has always been:
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
Ben Laurie wrote:
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.
A more optimistic way of putting this, Ben, is to state that EKMI allows
domain-experts of underlying components to address
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.)
Arshad Noor wrote:
Ben Laurie wrote:
Arshad Noor wrote:
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.
I find the question difficult to
Florian Weimer [EMAIL PROTECTED] writes:
Let me rephrase my remark: The trust anchor is conceptually separate
from a root CA certificate.
Conceptually yes, in the same way that the Soviet constitition was
conceptually quite liberal and protective of individual rights.
In practice, no. Look at
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
Ben Laurie wrote:
Arshad Noor wrote:
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.
I find the question difficult to understand. Before I
* Arshad Noor:
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.
As
* Peter Gutmann:
[1] Show of hands, how many people here not directly involved with X.509 work
knew that the spec required that all extensions in CA root certificates
(trust anchors in recent X.509 jargon) be ignored by an implementation?
So if you put in name constraints, key
* Arshad Noor:
The author of an article that appeared in InformationWeek this week
(June 30, 2008) on Enterprise Key Management Infrastructure (EKMI):
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937
states the following:
There are, of course, obstacles
Florian Weimer [EMAIL PROTECTED] writes:
* Peter Gutmann:
[1] Show of hands, how many people here not directly involved with X.509 work
knew that the spec required that all extensions in CA root certificates
(trust anchors in recent X.509 jargon) be ignored by an implementation?
So
* Peter Gutmann:
Florian Weimer [EMAIL PROTECTED] writes:
* Peter Gutmann:
[1] Show of hands, how many people here not directly involved with X.509
work
knew that the spec required that all extensions in CA root certificates
(trust anchors in recent X.509 jargon) be ignored by an
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
Peter Gutmann wrote:
Pat Farrell [EMAIL PROTECTED] writes:
At CyberCash, where we had real RSA/DES in the system, we found that users
want convenience, not security
I think that's phrasing it a bit badly, it'd be better put as without
usability, you won't have users (see the Tor paper
Perry E. Metzger [EMAIL PROTECTED] writes:
The problem, Peter, is that people who don't know you may mistake your
sarcasm for agreement with misconception in the article Arshad quoted.
What, me, sarcastic? Never!
The point is not that fools (often including us) haven't built monstrous
At 8:28 PM -0400 7/1/08, Perry E. Metzger wrote:
[EMAIL PROTECTED] (Peter Gutmann) writes:
Perry E. Metzger [EMAIL PROTECTED] writes:
No. In fact, it is about as far from the truth as I've ever seen. No real
expert would choose to deliberately make a protocol more complicated.
IPsec.
[EMAIL PROTECTED] (Peter Gutmann) writes:
(Actually even that doesn't really explain something like IKE... :-).
Having been peripherally involved in the causation change for IKE, let
me confess that it was caused by human stupidity destroying the
alternatives. The author of the much cleaner
On Wed, Jul 02, 2008 at 07:25:36AM -0400, Perry E. Metzger wrote:
[EMAIL PROTECTED] (Peter Gutmann) writes:
(Actually even that doesn't really explain something like IKE... :-).
Having been peripherally involved in the causation change for IKE, let
me confess that it was caused by human
On Wed, 2 Jul 2008, Peter Gutmann wrote:
| Date: Wed, 02 Jul 2008 12:08:18 +1200
| From: Peter Gutmann [EMAIL PROTECTED]
| To: [EMAIL PROTECTED], [EMAIL PROTECTED]
| Cc: cryptography@metzdowd.com, [EMAIL PROTECTED]
| Subject: Re: Strength in Complexity?
|
| Perry E. Metzger [EMAIL PROTECTED
Jack Lloyd [EMAIL PROTECTED] writes:
Having been peripherally involved in the causation change for IKE, let
me confess that it was caused by human stupidity destroying the
alternatives. The author of the much cleaner spec asserted copyright
and control over it, and fearing lawsuits, people
Perry E. Metzger wrote:
Jack Lloyd [EMAIL PROTECTED] writes:
Out of curiosity, was this other spec Photuris?
Sadly. That situation was long and complicated and I'd prefer not to
go into it -- and I'd prefer actually if others didn't either, as it
is much more about humans and non-security
There are, of course, obstacles that must still be overcome by EKMI
proponents. For example, the proposed components are somewhat simple
by design, which concerns some encryption purists who prefer more
complex protocols, on the logic that they're more difficult to break
into.
Let me
Hal Finney wrote:
An example where this concern might arise would be an overly simplistic
protocol that used AES in ECB mode - simple by design, while the
encryption purist advocated GCM, more difficult to break into but
more complex. Now, I'm sure EKMI is not doing things this way but it
is
Perry E. Metzger [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Peter Gutmann) writes:
(Actually even that doesn't really explain something like IKE... :-).
Having been peripherally involved in the causation change for IKE, let me
confess that it was caused by human stupidity destroying the
Peter Gutmann wrote:
For most crypto protocols, usability is job #8,107,
right after did we get the punctuation right in the footnotes for the third
appendix?.
Usability disasters such as DNSSEC are more common than strictly
cryptographic disasters such as wifi. DNSSEC is near impossible to
Pat Farrell [EMAIL PROTECTED] writes:
At CyberCash, where we had real RSA/DES in the system, we found that users
want convenience, not security
I think that's phrasing it a bit badly, it'd be better put as without
usability, you won't have users (see the Tor paper Challenges in deploying
The author of an article that appeared in InformationWeek this week
(June 30, 2008) on Enterprise Key Management Infrastructure (EKMI):
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937
states the following:
There are, of course, obstacles that must still be
Arshad Noor [EMAIL PROTECTED] writes:
In light of the recent discussions about experts in cryptography, I thought
I'd ask this forum to comment on the above author's statement: is this true?
Do cryptography experts deliberately choose complexity over simplicity when
the latter might provide the
Perry E. Metzger [EMAIL PROTECTED] writes:
No. In fact, it is about as far from the truth as I've ever seen. No real
expert would choose to deliberately make a protocol more complicated.
IPsec. Anything to do with PKI. XMLdsig. Gimme a few minutes and I can
provide a list as long as your arm.
Steven M. Bellovin wrote:
I did see one possible red flag in
the article: the key server verifies the client request, then
encrypts, digitally signs, and escrows the key in a database.
Escrowed keys are potentially *very* dangerous, but without knowing
just what's being stored and how it's
[EMAIL PROTECTED] (Peter Gutmann) writes:
Perry E. Metzger [EMAIL PROTECTED] writes:
No. In fact, it is about as far from the truth as I've ever seen. No real
expert would choose to deliberately make a protocol more complicated.
IPsec. Anything to do with PKI. XMLdsig. Gimme a few minutes
44 matches
Mail list logo
