[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Using XKMS to extend IPSEC PKI support and reduce complexity



[This is the substantive response for those who don't want to read
my responses to Steve's trolls and ad-hominem, those that do can
find them in my other post]

> Phill, you have never been a contributor in the IPsec area. Your 
> comments in recent messages illustrate ignorance of the history of WG 
> activities on which you now choose to comment. I don't find that 
> constructive. We're trying to simplify IKE. if you propose support 
> for XKMS as yet another PKI technology, that hardly amounts to 
> simplification. If you suggest it as a replacement for the other 
> technologies, that would call for discarding the PKI support that 
> most vendors (that support PKI in IKE) already implement, which also 
> seems questionable unless you can argue that XKMS is better in all 
> respects.

That is not the proposal I made.

Suggesting that IPSEC rip out support for PGP and SPKI is a non-
starter. The probability of reaching consensus on the point is nil.
Even if there were the possibility of consensus I would not
support such a proposal.

XKMS provides a practical way to achieve two objectives, first to
allow IPSEC to be used with the full politically correct set of PKI.

Second and more important it means that vendors that currently 
support very limited X.509 PKI can advance to provide full PKI 
support without the significant increase in their code base and 
configuration complexity that would entail.


At present IPSEC implementations are being used for the limited
purpose of securing VPNs. Many do not support certificate chaining,
I do not know of any that support the full PKIX stack.

I do not believe that an expensive router has any business
performing PKIX path math or public key cryptography. It is like 
using a Ferrari to deliver milk.

Delegating key exchange to another box also makes sense. 

		Phill

Phillip