Peter, I can't help rising to the bait.
We are seeing here - in practice - that when a security system is deployed for
commerce/payment purposes, its absolutely critical that measures be available
to>prevent attacks on the trust relations. This is what 1422 minimises.
Well, yes and no. Yes, it tried, and there is no doubt that a workable system
based on 1422 could be fielded. However, it became painfully obvious that the
name-subordination rules simple were insufficient to support almost any kind of
commercial operation. That's the major reason why X.509 v3 had to be
introduced, and why MOSS probably won't succeed without adopting v3 as the
mandatory standard. It seems very unlikely that a major CA will issue v1 certs
-- there is not a good enough way to control the CA's liability.
On the other hand, the MasterCard SEPP spec is a good example of an
international CA hierarchy that mandates a particular trust mechanism. Are you
arguing that adding a PEM-style IPRA would add any significant amount of value?
You still have the difficulty of distributing the root key using out-of-band
techniques, and frankly I would trust MasterCard or Visa a LOT more than I
would trust Jeff Schiller or anyone else in the Internet Society to run a
top-level CA. (Not that I have anything against Jeff -- he's a spendid fellow.
But his pockets aren't deep enough, by about 4 orders of magnitude.)
A big issue here is, also, whether the 1421 ENCRYPTED processing rules are
important, also, for commerce/payment based on asymmetric key management.
This is another big difference between MOSS and PEM.
I must have missed that detail. What is your point?
Do you believe RSA/DSA/DH-based commerce/payment systems are viable without
the objectives of RFC 1422,
Yes, at least as stated.
or the authentication before decryption rule
of 1421/1422?
I'll have to go back and read the spec again. I don't recall that rule, and in
fact would have thought that it operated the other way around.
On my other points, do you believe a 1422 CA company can really face upto
commercial operating reality without being prepared to enforce its policies,
possibly legally?
Any CA can enforce its policies vis a vis its subscribers via contract and
threat of suit. This applies in particular to any subordinate CAs that are
certified, and has nothing to do with how certificates are issued (hardware or
software). The REAL question is how the CA can prevent relying parties from
holding the CA liable for accidental mistakes of identification, given the
rather loose identification systems our society has chosen. That, in my
opinion, takes carefully worded legal notices that the relying party cannot
avoid seeing, and is one of the most important reasons I have been arguing for
the inclusion of such liability limiting language in the certificate itself for
the last 10 years.
Bob
Robert R. Jueneman
GTE Laboratories
1-617-466-2820 Office
1-508-264-0485 Telecommuting