Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt

From: "Housley, Russ" <[email-masked]>
Date: Wed, 01 May 2002 13:17:55 -0400

Denis:

It seems to me that the warranty in this case does have to do with the 
relationship between the CA and the subscriber.  If a replying party is 
harmed, they will go after the CA (assuming that the subscriber has 
vanished or is a less attractive target).  The CA will likely have 
insurance to back up the warranty, and this extension indication the terms 
of that warranty.

Russ

At 02:59 PM 4/30/2002 +0200, Denis Pinkas wrote:

>Comments on the Warranty certificate extension
>
>Before looking at the technical details of the warranty, it is important to
>make sure that practical cases can be solved. Since a warranty is mentioned,
>legal considerations cannot be left aside.
>
>The current proposal states that "the certificate warranty provides an
>extended monetary coverage for the legal liability of the CA, in favor of
>the *subscriber*".
>
>The problem is that the warranty should also apply in favor of one or more
>*relying parties*. Are the relaying parties going to complain to the
>subscriber only and will then the subscriber makes arrangement with the CA
>only ?
>
>For the extreme cases where there are, let us say, 10.000 plaintiffs each
>one claiming for a damage of 1.000 $ and when the upper limit of the
>warranty will be altogether, for example, 100.000 $ (called "aggregated
>damage" in the draft). What would be the criteria to reimburse the
>plaintiffs ? Since the total damage is 10.000.000 $, are only 10 % of the
>first plaintiffs to be reimbursed ? or will a random choice will be done
>among the 10.000 plaintiffs ? Since the warranty is for the subscriber and
>not for the plaintiffs, will the subscriber deal with the 10.000 plaintiffs
>directly ?
>
>The second point is that no conditions to get advantage of the warranty are
>mentioned. Should a relying party only check the revocation status of the
>certificate ? Should the relying party check the certificate against a
>validation policy ? What kind of proof of its checking should the relying
>party present to the CA;  or to the subscriber ? An OSCP response? A DPV
>response ? Should the details of the transaction involved be provided ?
>
>For all these reasons, the difficulty of use of such an extension is very
>questionable.
>
>Now, it should be noticed that such a similar extension has already been
>defined in ETSI TS 101 862. This extension takes advantage of the
>qcStatement defined in RFC 3039 and specifies a statement regarding limits
>on the value of transactions.
>
>This optional statement contains:
>
>- an identifier of this statement (represented by an OID);
>- a monetary value expressing the limit on the value of transactions.
>
>This statement is a statement by the issuer which impose a limitation on the
>value of transaction for which this certificate can be used to the specified
>amount (MonetaryValue), according to the Directive 1999/93/EC of the
>European Parliament and of the Council of 13 December 1999 on a Community
>framework for electronic signatures, as implemented in the law of the
>country specified in the issuer field of this certificate.
>
>In fact the Directive is requiring (in Annex I) a field to specify "limits
>on the value of transactions for which the certificate can be used, if
>applicable". The reason for that field is specified in the Directive in
>these terms:
>
>"The certification-service-provider shall not be liable for damage arising
>from use of a qualified certificate which exceeds the limitations placed on
>it".
>
>The text does *not* say: "The certification-service-provider *shall be*
>liable for damage arising from use of a qualified certificate which *meets*
>the limitations placed on it".
>
>So it is more a *disclaimer of warranty* rather than a warranty. If the
>proposal was for a warranty disclaimer extension, then it would be more
>appropriate. In such a case it would not be necessary to indicate the
>conditions to meet to get the warranty since there would be no warranty.
>
>It is doubtful that an off-line indication in a certificate will be the
>right answer to a problem that is commonly solved using an on-line protocol
>(e.g. money withdrawal on an ATM).
>
>Denis
>
>
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509) 
> Working Group of the IETF.
> >
> >         Title           : Warranty Certificate Extension
> >         Author(s)       : D. Linsenbardt, S. Pontius
> >         Filename        : draft-ietf-pkix-warranty-extn-00.txt
> >         Pages           : 7
> >         Date            : 18-Apr-02
> >
> > This document describes a certificate extension to explicitly state
> > the warranty offered by a Certificate Authority (CA) for a the
> > certificate containing the extension.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-00.txt

---

From: Al Arsenault <[email-masked]>
Date: Wed, 01 May 2002 19:24:59 -0400

The more I think about this, the more I sort of agree with Denis.  It's not
clear to me what good this extension is.  It indicates a relationship
between a subscriber and a CA, NOT an RP and a CA or an RP and a subscriber.
Therefore, what good is it?  Why do I as an RP care - or even have to know -
for how much a CA will indemnify the subscriber if something goes wrong?
That's the kind of thing that can easily be covered in some sort of contract
between the CA and subscriber, not in the certificate.

This extension may give me as an RP a hint that "well, the CA has at least
this much insurance/cash in the bank, and is willing to fork it over to the
subscriber if need be, so I can start my lawsuit by asking for at least this
much in damages". But I can't see any real use to it.

So I'm not a big fan of pushing this forward; I think it will likely cause
more confusion than anything else among the non-PKI-astute.

All that being said, since it's all optional and I don't actually have to
implement it, I really won't fight too strongly against it, if somebody else
thinks that there's an actual use case.

        Al Arsenault

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 1 May 2002 17:39:54 -0700

Al,

If I'm reading you correctly, I agree the WG should go
cautiously here.  This is inherently a legal issue which is
beyond our reach as technologists.  It's more within the scope
of our friends at ISC.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Al Arsenault
> Sent: Wednesday, May 01, 2002 4:25 PM
> To: Housley, Russ; Denis Pinkas
> Cc: pkix

---

From: Michael Ströder <[email-masked]>
Date: Thu, 02 May 2002 10:42:56 +0200

Michael Myers wrote:
 > beyond our reach as technologists.

This is the only reasonable conclusion. I'd like to add that it's 
also a business issue.

Because I'm lazy I just repeat my posting already sent to this
list in a similar thread (see below).

Ciao, Michael.

-------- Original Message --------
Subject: Re: Q: Where should do I put a max amount in a X.509v3
certificate?
Date: Mon, 11 Mar 2002 15:55:22 +0100
From: Michael Ströder <[email-masked]>
Reply-To: [email-masked]
CC: [email-masked]
References: <[email-masked]>

Tom Gindin wrote:
 >
 > Since this "purchase limit" is intended as a constraint on
 > signed orders, and those are signed by PKC's rather than AC's,
 > the constraint needs to go into the PKC. I also don't think the
 > syntax is very complex

I'd suggest to thoroughly discuss a business model first before
thinking about technical aspects (not on PKIX list off course). 
 From some discussion I remember that most drafts for something 
like this just didn't fit into how financial institutions are 
working (although the institutions were committed
to use this particular PKI ;-).

So defining technical specifications was completely useless
because there was no working business model behind it.

Ciao, Michael.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 02 May 2002 13:58:40 +0200

Russ,

> insurance to back up the warranty, and this extension indication the terms

In that case the certificate warranty will be in favor of the *relying
party* rather than the subscriber.

Now, the basic question is still whether such a field is a warranty or 
a disclaimer of warranty above some amounts, and whether it is needed at
all.

This also still leaves open the question about what shall be presented by 
the RP to the CA to possibly get advantage of the warranty.

Since the proposed extension is an optional element, these (complex)
conditions related to the warranty should *not* be part of the Certificate
Policy.

Denis

---

From: "Yuriy Dzambasow" <[email-masked]>
Date: Thu, 2 May 2002 10:00:05 -0400

I agree with Mike and Al.  In my opinion, warranties make more sense if they
are provided by the CA to the RP.  In addition, I think it makes more sense
to handle these sorts of warranties through contracts, and not through
certificate extensions.

Yuriy

----- Original Message -----
From: "Michael Myers" <[email-masked]>
To: "Al Arsenault" <[email-masked]>; "Housley, Russ"
<[email-masked]>; "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Wednesday, May 01, 2002 8:39 PM
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 02 May 2002 09:44:19 -0400

Al & Denis:

Maybe the language needs to be made more clear, but that is not what I 
think this proposed extension is about.  The second paragraph in the 
Introduction says:

   The certificate warranty provides an extended monetary coverage for
   the legal liability of the CA, in favor of the subscriber.  The
   certificate warranty primarily concerns the use, storage, and reliance
   on a certificate by a third party and the CA.  It is common for a CA
   to limit liability by establishing reliance limits on the use of a
   certificate.  It is not uncommon for a CA to attempt through
   contractual means to exclude its liability entirely.  However, this
   has the effect of undermining the confidence that commerce requires to
   gainfully use certificates.

I think that this means the third party (the RP in your notes) can go to 
the CA to file a claim against the warranty.  The RP says: "I relied on the 
certificate that you issued, and I was harmed, therefore I expect to be 
compensated."  The warranty extension will tell the RP the extent of the 
possible compensation.  Knowing this up front, the RP can decide whether to 
enter into a business transaction or not.  The whole point, as I see it, is 
to allow automation of as many of the risk-related decisions as possible.

Russ

---

From: "Yuriy Dzambasow" <[email-masked]>
Date: Thu, 2 May 2002 12:06:15 -0400

Russ:

----- Original Message -----
From: "Housley, Russ" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>; "Al Arsenault"
<[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Thursday, May 02, 2002 9:44 AM
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt

> to allow automation of as many of the risk-related decisions as possible.

I still think contracts are the more effective way of handling this.  Then
again, and as Al said, since this is an optional extension, I'm not going to
argue it much.  If other folks think its useful...fine.

Yuriy

> > > >Before looking at the technical details of the warranty, it is
important
> >to
> > > >subscriber only and will then the subscriber makes arrangement with
the
> >CA
> > > >among the 10.000 plaintiffs ? Since the warranty is for the
subscriber
> >and
> > > >The second point is that no conditions to get advantage of the
warranty
> >are
> > > >This statement is a statement by the issuer which impose a limitation
on
> >the
> > > >from use of a qualified certificate which exceeds the limitations
placed
> >on

---

From: Michael Ströder <[email-masked]>
Date: Thu, 02 May 2002 19:17:25 +0200

Yuriy Dzambasow wrote:
> 
> I still think contracts are the more effective way of handling this.

Yes! Especially since contracts cover a certain business case.

Ciao, Michael.

---

From: "Alice Sturgeon" <[email-masked]>
Date: Fri, 3 May 2002 18:36:00 -0400

Hi folks,
While I agree with Yuriy that warranty provisions need to be covered in
contract, the existence of an extension in the certificate can serve to
highlight the warranty provisions and to facilitate risk management through
automation of certain decisions.  For a third party, it can be useful to
have salient information right in the certificate, where it is clearly seen,
and a decision more easily made.  The extension can point to terms and
conditions (T&C), in much the same manner that a certificate contains a
pointer to the CP and CPS.  While doing so, the certificate also contains
the most salient points of CP/CPS in the various fields, such as validity
period, usage, etc (I won't mention non-repudiation!) - the most important
aspects of the system and applications, right up front and visible for
users.  The warranty extension can serve this same purpose.  The analogy was
made on the ABA list about warranties for tires, and that this proposed
extension was analogous to the warranty being found on the inside of the
tire.  A more correct analogous statement would be that the warranty appears
on the *outside* of the tire for all to see.
It is unrealistic to expect an RP to go through contractual T&C when the RP
wants to rely on a certificate.  It is much more realistic, more practical,
to put the most salient points right into the certificate.  No need, then,
to go searching for a related document, nor to search through the T&C
legalese.  Yet the contractual T&C are not absent but clearly referenced.
Note that the very first statement in the I-D Abstract is: "This document
describes a certificate extension to explicitly state the warranty offered
by a CA for the certificate containing the extension."  Key word, I think,
is "explicitly".
Previous contributions have also noted the similarities of this proposed
extension to EU Directive 1999/93/EC, consequent IETF RFC 3039, and ETSI TS
101 862, concerning express statements of limitations on value of
transactions and consequent limitation of liability of a CA (for
transactions exceeding the express limitation).  Perhaps some language
clarity is in order to address the comments concerning warranty provision
versus warranty disclaimer, and warranty in favour of the subscriber versus
the meaning of the warranty to the relying party.  Assuming successful
clarification, the proposed extension can be useful, as a succinct statement
to those involved in the transaction, to highlight warranty protection to
all parties.
Some suggested changes:
Introduction, para. 2:
The certificate warranty provides an extended monetary coverage for the
legal liability of the CA, in favor of the subscriber. [Delete ", in favor
of the subscriber".] The certificate warranty primarily concerns the use,
storage, and reliance on a certificate by a third party and the CA. [Change
to: "by a subscriber, a relying party and the CA".]
Introduction, para. 3:
Add a new last sentence: "A relying party may have redress from a CA
depending on the conditions for such redress expressed in either the CA's
Certificate Policy or the CA's insurance policy, or both.  Where the relying
party and the subscriber are the same entity, then the terms and conditions
of the insurance policy clearly cover the entity; however, where the relying
party is not a subscriber to the CA, then any redress will be available only
through the conditions expressed in the CP and the CA's insurance policy, if
any.  Risk for a non-subscriber relying party may be reduced by the presence
of a warranty extension with an explicit warranty stated.  The warranty
extension in the process automates this aspect of risk management for the
relying party (whether subscriber or non-subscriber)."

It has been noted that the overall intent is to enhance trust in the
transactions and to facilitate automation of certain risk management
decisions.  Look at the proposed syntax for the extension:  first is a
choice between no warranty provided and explicit warranty.  If the choice is
the first - no warranty provided - then that immediately tells relying
parties several things, amongst them, first, that this cannot be a Qualified
Certificate as proposed by the EU Directive and defined by 3039.  A
certificate that contains the second choice should be recognizably more
trustworthy, and may be sufficient for a relying party to trust it.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Yuriy Dzambasow
Sent: May 2, 2002 12:06 PM
To: Housley, Russ; Denis Pinkas; Al Arsenault
Cc: pkix
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt

Russ:

----- Original Message -----
From: "Housley, Russ" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>; "Al Arsenault"
<[email-masked]>

Yuriy

important
the
subscriber
warranty
on
placed

---

From: Michael Ströder <[email-masked]>
Date: Sat, 04 May 2002 13:33:10 +0200

Alice Sturgeon wrote:
> automation of certain decisions.

Sorry, but this assumption about "automation of certain decisions" 
is totally wrong. You should talk to a financial worker about how 
complex warranty/credit decisions are - not to speak of resolving 
conflicts with claims, privacy problems etc. It simply does not 
work in such a simple automatic way.
Been there, *not* done that. ;-)

Personally I don't want to hold anybody back from defining such an 
extension. If someone has spare cycles he/she can do that for 
personal fun but should not be disappointed if it turns out not be 
useful at all for anything serious.

Ciao, Michael.