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

From: [email-masked]
Date: Fri, 19 Apr 2002 07:23:04 -0400

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-warranty-extn-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-warranty-extn-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 30 Apr 2002 14:59:05 +0200

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