At 04:05 PM 10/11/95 EDT, Jueneman(_at_)gte(_dot_)com wrote:
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.
3 points bob:
(a) do you consider the RFC COST and RSA Commercial Hierarchy operating
commercially ?
do you consider the several thousand Netscape merchants (with v1 server
certs)
commercial users?
(b) I'm after discussion of the countermeasures involved in 1422, rather
than its
concept of operations for PEM. Particularly, the minimisation of CA
masquerade
damage. As chains become required to fanout operating authority,
controls have
to be enforced for real, not on paper. CA administrators are going to make
exceedingly bad policy enforcement instruments, I fear.
(c) The VISA/Microsoft concept of an STT credential, versus a certificate
(even though
a credential is what we are all familar with technically as a cert) is a
very
specific semantic shift designed for a closed-purpose, payment-specific,
key management framework in which the handling of liability is quite
different
to the philosophy which you have espoused for open systems for years,
and seems (by your own words) to behind the Mastercard/GTE/... SEPP work.
Thankyou for spending the time to write the SEPP response yesterday. I, for one,
learned from you alot both about SEPP, and commercial security design processes.
I hope its correct to use pem-dev for this topic, rather than the focussed
agenda
ietf-pkix list.