Subject: RFC and then...? draft-ietf-pkix-warranty-extn-01.txt

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 3 Jan 2003 14:29:57 +0100

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