|
Alice et al.
To create a standard in the IT-sector it is
actually rather easy, and I'm sure that you
without too much troubles can get the warranty extension through the IETF
processes.
But, the real problem is [always] to get any major
use of a standard.
In this particular case the "critical mass" problem
is very hard as it requires both CAs, core software makers, and
application makers to think this is a great idea. Unless VeriSign, and
similar market-leaders have expressed some support for this extension, I think
it will from a usage-point of view fail, because why would anybody
implement a non-technical ("soft") option that only a minor percentage
of CAs are likely to support?
Another problem is that this option is anything
but trivial to implement in a useful way. If this is going to be
transparently supported by interactive client/browser-side signatures, featuring
pop-up dialogs etc, this probably even creeps into the core signature API and
processes.
Added to that we have the principal difficulties
mentioned by me and Denis.
A CA liability extension OTOH is an unilateral
CA-decision to deploy, that since it should just be like an in-line agreement,
does not require any application-level RP-software support. When I think
of it, the only reasonable place for a liability extension is in a CA
certificate, as it is during the "trust installation/CA acceptance" phase,
you should be made aware of CA conditions. To have different liabilities
in EE-certificates would be counterproductive, as it would then require the same
kind of extensive and also slightly "yucky" software support, as imposed by
the warranty-extension.
Best Anders Rundgren Senior Internet e-Commerce Architect |