"Kipp E.B. Hickman" says:
Clearly you and I disagree on a fundamental point. Which is more important? Securing the document or securing the transport of the document. I believe that today's problem for commerce is securing the transport.
I believe there is a fundamental problem of understanding here -- it does not seem that you understand how store and forward email works. Securing just the transport is less than useless.
Solving this currently widespread problem makes the Internet a friendlier place for commerce. It allows sensitive information to be transported privately.
No, it does not -- it just means that some links can't be read. On the other hand, PEM/MIME-PEM *ALREADY* keep people from reading no matter whether the link is open or not open.
Let's pretend for a moment that you are right. IPSP is the way to go, today, and that silly us, we should have used it. So now I go to my site manager, and say:
Please replace all that fancy expensive network hardware with new ones that speak IPSP so that we can do private communications with...
You don't have to replace any hardware. More ignorance on your part.
So who can I talk to? Name one router that speaks the secure protocols you are documenting?
Each and every one routes it today. I have routed swIPe packets over the commercial internet -- and of course I couldn't control any of the intervening routers. Your comments indicate that you are totally unaware of how IPSP is designed to work. You are ignorant and foolish. You could at least read a document or two before making statements that make you sound stupid. I read your documents. You could at least read other peoples -- but that would naturally require that you even realize that other people have done work on this topic.
Even were transport layer security needed, there are many other protocols for doing the exact same thing -- your solution is hardly new or interesting. Why not use an existing one instead of rolling Yet Another One? Of course, as I've repeatedly mentioned, network layer security is being used by many people today and will be standardised very soon -- probably before SSL.
We never claimed the solution was new or interesting. However, it is a solution.
Yet Another Solution. Why not invent your own internet protocol? After all, it would be a "solution".
You must have missed a line in the spec:
#define SSL_CK_RC4_WITH_MD5 0x01 #define SSL_CK_RC4_EXPORT40_WITH_MD5 0x02 #define SSL_CK_RC2_CBC_WITH_MD5 0x03 #define SSL_CK_RC2_CBC_EXPORT40_WITH_MD5 0x04 #define SSL_CK_IDEA_CBC_WITH_MD5 0x05
Gee, I was under the impression that that was CODE, not SPEC.
Not true. Distinguished names can be bulky, but you don't have to use them that way.
What other way could you use?
They can be made to map into DNS names trivially,
How? Name a single methodology.
Please define a solution that is:
distributed reliable supports an unforgeable name to public-key mapping standard not-bulky not-expensive
I will be the first to sign up and buy one. The market exists.
Use DNS for key distribution. Use IPSP (soon to be standardized -- SSL isn't standard either) for the packet layer. Use some variant of Photuris for key distribution. All the software in question is publically available or will be and will run on a wide variety of platforms. Perry