Subject: Re: draft-ietf-pkix-warranty-extn-01

From: Denis Pinkas <[email-masked]>
Date: Mon, 03 Jun 2002 11:28:27 +0200

Alice,

Thank you for inquiring. The new draft is still not adequate.

COMMENT 1

It is very questionable whether the implicit insurance model is appropriate.
The text says: " Usually, the subscriber pays for the extended warranty
coverage". The major issue is whether a subscriber pays a flat price that is
included in the price of the certificate or a price that is per insured
transaction which would be paid by the relying party. Implicitly the first
choice is being made but this choice is questionable.

COMMENT 2

It seems difficult to be able to take benefit of a warranty without proving
that there is a real damage. However, this would imply to disclose the
details of the transaction or the details of the damage. This is conflicting 
with privacy considerations.

End-users may be willing to disclose the amount of transaction that has been
guaranteed, but without providing the details. This does not seem possible
with that approach.

Another approach would be to obtain a warranty from a server to which only
the amount that is wished to be guaranteed would be disclosed. A signed
warranty would then be given.

COMMENT 3

WarrantyData contains:

       tcURL                TermsAndConditionsURL OPTIONAL  

"WarrantyData is defined as a URL that points to the terms and conditions of
the warranty.  The URL is provided using the TermsAndConditionsURL type,
which is an IA5 string."

In this document the warranty is said to be given by the CA. RFC 3280
states:

"   The CPS Pointer qualifier contains a pointer to a Certification
    Practice Statement (CPS) published by the CA.  The pointer is in 
    the form of a URI."

The Certification Practice Statement contains all the conditions, including
the terms and conditions of the warranty. So this extension is not needed as
soon as the CPS Pointer qualifier is being used.

However, these terms and conditions of the warranty are only human being
understandable, but not machine processable and this means that applications
will not be able to know how to take benefit of the terms and conditions of
the warranty. In particular is there a need to prove that the revocation
status of the certificate has been checked ? When this is the case, the
application should know whether an OCSP check, a DPV check or another kind
of check is needed. There is no information to be able to know this.

COMMENT 4

Normally claims about a warranty have to be presented a few days or weeks
after the damage. Insurance company do not take into account claims that are
too old. There is no indication for that time period in the document.

Would such a time period be indicated, the next point would be to make sure
that the damage really took place at that time. Going in that direction
would once again make necessary to disclose the details of the transaction
and also to place in the time scale that transaction. The use of a
time-stamp tokens would solve this last problem, but there would be a much
simpler solution: the use of a on-line warranty server. The date included in
the signed warranty would be the date of the transaction.

COMMENT 5

The text says:

"Once the value of fulfilled claims reaches the warranty currency amount,
then no further claim will be fulfilled. "

This is nice for the insurance company, but not for end-users !

This is not going to work nicely, unless on-line warranty server is being
used. In such a case the on-line warranty server could compute in real-time
the aggregated amount and then stop to offer the warranty when this amount
is being reached.

COMMENT 6

In the comments on the previous version, it has been mentioned that 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 imposes 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 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* extension rather than a warranty.
If the proposal was for a warranty disclaimer extension, then it would be
more appropriate. 

A much better title and abstract would be:

         Warranty Disclaimer Certificate Extension

  This document describes a certificate extension to explicitly state
  a warranty disclaimer from the Certificate Authority (CA) for a 
  certificate containing the extension.

COMMENT 7

The security consideration section states:

" The procedures and practices employed by the CA MUST ensure that the
  correct values for the warranty are inserted in each certificate that is
  issued."

Since this extension is optional, the MUST statement is not appropriate.   

CONCLUSION

The current proposal is missing to address several aspects which are even
not being discussed in the security considerations section. The first
impression is that this field is useful, but once a closer look is given,
the warranty is really a fake one. Of course it is well known that
warranties are to be well advertised by insurance companies, but never
granted because you have not seen a small sentence at the back of the
contract in small gray characters on a gray background.

Such "small" sentences are:

 - the conditions to get advantage of the warranty 
   (i.e. what needs to be presented, like transaction details and
   certificate status check),

 - the time before which the claims have to be presented.

A major issue which is not mentioned at all is the problem of the privacy of
the transaction.

As indicated above, there are many dangers to include such an extension and
such dangers are not advertised, even in the security considerations
section. When they will be, it will then be questionable whether the
advantages of such an extension will be worth the disadvantages.

Should this extension be maintained, it is proposed to transform it into a 
Warranty Disclaimer Certificate Extension. This would indicate the
transaction amount above which there is no warranty at all.

Denis

> Hi folks,
> The revised draft on certificate warranty extension was issued to the list
> last week, addressing the first round of comments, and there have been no
> comments back.  Is everyone satisfied with it now, with the revisions?  I
> know some were not thrilled with the I-D but decided they could live with
> it, given it is optional.  Some also thought it was more a legal matter -
> The I-D was also posted to the ABA list, and received few comments; these
> too have been taken into consideration.
> 
> 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: Juergen Brauckmann <[email-masked]>
Date: Mon, 03 Jun 2002 12:22:33 +0200

Hi Denis.

> with privacy considerations.

Why should it be a privacy problem? In paper-world you are already
forced to disclose details on your damage if you want to get a refund
from an insurance. If you want money, you have to tell why.

Why is it necessary to object against this procedure when it is about
electronic transactions?

> warranty would then be given.

How can a warranty server solve the problem that someone is forced to
tell details about transactions if he wants to take benefit of a
warranty?
 
Regards,
   Juergen

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 03 Jun 2002 14:41:30 +0200

Juergen,

> from an insurance. If you want money, you have to tell why.

Not necessarilly. I have to tell how much. A good example is a payment
guaranted by a smartcard. An inquiry is made for a certain amount of money
and the warranty is granted for that amount. You do not have to tell which
goods have been purchased.

> Why is it necessary to object against this procedure when it is about

See above.

> tell details about transactions if he wants to take benefit of a

The amount can be guaranted for a given date, irrespective of the nature of
the goods or the service being purchased.

Denis

---

From: "todd glassey" <[email-masked]>
Date: Tue, 4 Jun 2002 10:35:05 -0700

Isn't the warranty specific to the RPA/CPS type agreements.

I said this a number of times. What is really missing is a unified global
PKI process/parameter negotiation protocol.

Todd