Subject: RE: draft-ietf-pkix-warranty-ext-01

From: Peter Williams <[email-masked]>
Date: Mon, 09 Sep 2002 11:23:57 -0700

I helped review the first warranty program, for Michael
Baum's Public Certification Service concept. Whilst I dont 
believe its useful for IETF to focus on
warranties, I do believe clarifiation of just
what a CP-based warranty is is useful.

I dont expect users to ever really understand the
difference in the legal model between certification, 
representation, warranty, insurance, reliance, etc.

What they do need to understand however is

1. The common notion of first-come-first-served 
payout-limits (which means they may get a shock when multiple 
parties all claim for the limited cash)

2. Warranty execlusions are often structured such that
few can ever make a valid claim. These warranties
are just marketing gimics, to puff trustworthiness.
Valuable warranties are transactional, by banks or
Japanese trading houses like Mitsui. They really
dont function as an adjunt to authentication.

Conclusion: If IETF proceeds, the result should be at most
an informational RFC.

N.B.

My comments - as a practitioner - may sound harsh on public 
CAs. Warranties are appropriate - they just dont have in practice 
the direct  benefits that are marketed. The costs of the 
protection plans' insurance is essentially just 
an indirect tax on providing core trustworthiness of
a TTP-grade CA.

-----Original Message-----
From: Denis Pinkas
To: [email-masked]
Cc: Anders Rundgren; [email-masked]; [email-masked]
Sent: 9/2/02 3:50 AM
Subject: Re: draft-ietf-pkix-warranty-ext-01

Alice,

I concur with many of the arguments raised by Anders. It is very scarce,
but
this time it happened, thanks to your draft. :-) 

I believe that sufficient arguments have been raised against the
progression
of this draft, as it stands, which does not even explicitly states, for
a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely,
only 
errors made by the CA personal or attributed to the CA during the
management
of the certificate, e.g. at the time of registration of the subject,
when
issuing the certificate, when handling revocation requests or when
making
available revocation status information.

Regards,

Denis

> Alice,
> 
> >Lynn observed that the world of financial risk management is moving
past
> >per-transaction model.  The proposed extension offers an aggregate
model.
> >Also Lynn wrote: "and any migration to an offline paradigm with
> >> both support for per transaction as well as aggregation risk/limits
> >> obsoletes the requirement for the certificate."
> >That's true; that's why the extension is useful.  If total risk,
i.e.,
> >aggregated transactions, is the primary worry of the insurance
industry then
> >the aggregate model would be appropriate.
> 
> This sounds pretty dangerous as it gives no value to an RP which may
be just
> one of several thousands of RPs which just received a purchase order
> from a company that is on the edge of filing for bankruptcy.
> 
> If it is of no value to RPs, the only purpose left for the
warranty-extension
> is for a CA to insert its liability limit in a machine-readable
> format.  Is this really interesting as any liability above zero is
likely
> to be accompanied by a non-machine-interpretable agreement?
> 
> Is the intent, that the moment a transaction is received that exceeds
> the liability limit, an alert is to be sent to the legal department?
> Depending on the liability agreement this may be too late
> as lower-amount transactions may be equally uncovered.
> 
> Actually it would IMO better be a part of the CA-certificate to
> declare what it stands for in terms of liability.
> 
> Regarding warranted purchase orders, I have serious problems
> understanding what a CA-issued warranty could possibly cover except
> for a liability for having certified the wrong entity which is now
making
> fake orders.  But IMHO such a warranty is equally applicable to
> authentications, as incorrect such are even worse as you cannot
> "rollback" authentication events.
> 
> For pure financial transactions, there are already solutions in place
> since ages ago, like bank-warranties, remburses and pre-paid orders.
> 
> cheers,
> Anders