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

From: "Alice Sturgeon" <[email-masked]>
Date: Sun, 1 Sep 2002 07:49:11 -0400

Denis, Lynn, and others,

Denis, you wrote: "While, as you say, the basic intent of
the proposed extension is building confidence in e-business, in reality it
would build a FALSE confidence in e-busines, then doing more harm that
benefits. I disagree that processing only the amount field allows to build
confidence."

This seems to be the crux of our disagreement. I do believe that the
extension will add confidence in e-business. Its presence alone provides
some modicum of assurance that the matter of warranty for transactions has
been addressed. This in and of itself gives any RP confidence in the
transaction.

You wrote: "Incorporating static warranty conditions in a
certificate is not appropriate or would be appropriate only if there would
be some kind of on-line check done afterwards. The information would only be
used, to know whether or not it makes sense to do perform an on-line check
or not (and where). However, this is not the meaning of the proposed
extension."

You're right that this is not the purpose of the extension. Checking
afterwards is not necessary to fulfill the purpose of the extension which is
to show that some kind of warranty does exist for the transaction and/or the
certificate in use.  That in itself is sufficient.  It can also be easily
processed by the asn.1 syntax.

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.

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     613-232-2350
Cell:         613-291-0331

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 1 Sep 2002 17:48:51 +0200

Alice,

>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

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 02 Sep 2002 12:50:08 +0200

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

---

From: "Alice Sturgeon" <[email-masked]>
Date: Thu, 5 Sep 2002 17:12:38 -0400

Denis and Anders, I appreciate your comments; they are helpful in keeping to
the right path.

One point that I took issue with was Denis' to the effect that the intent of
the I-D is not clear.  It is in fact stated in the first couple of
paragraphs and I would have thought it quite clear. It is to provide a
degree of confidence to RPs in e-business and electronic transactions. PKI
is seriously not yet understood; there exists some mistrust amongst
potential users about the mechanisms, not necessarily the security
mechanisms per se because these are relatively transparent to a user, but
generally in electronic exchanges involving some value.

I also have a problem with Anders' statement that you cannot "roll-back"
authentication events.  True technically (actually, technically either true
or false depending on mechanisms); in a legal or policy context isn't this
what non-repudiation prohibits? That is, without non-repudiation, you can
"undo" an authentication event (the authentication can be repudiated, or
'undone').

I'm looking forward to being able to discuss issues about the I-D at the
Atlanta IETF meeting.  I'm sure others will as well, since there have been a
number of respondents to the I-D posting.  Just FYI, my unaudited (but
trustworthy : - )) count shows 5 supporters, 3 objectors, 2 abstainers, and
2 still considering and undecided.

Alice

P.S. Denis, I'm happy to have been the source of bringing you and Anders to
like thinking!

Alice Sturgeon
Chair

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: September 2, 2002 6:50 AM
To: [email-masked]
Cc: Anders Rundgren; [email-masked]; [email-masked]
Subject: Re: draft-ietf-pkix-warranty-ext-01

Alice,

Regards,

Denis