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

From: "Tom Gindin" <[email-masked]>
Date: Mon, 3 Jun 2002 11:37:05 -0400

Russ:

      Since this structure is specified in an ISO standard, but it seems to
be fairly subject to misunderstanding, I would still recommend putting in
the sentence I suggested below ("The actual monetary value in the named
currency unit, when amtExp10 is present, is amount divided by 10 to the
(amtExp10) power".).  There is clearly nothing to be done about the format
specification or even the field name.  IMHO, that field name is more
naturally interpreted in Juergen's way than otherwise.

            Tom Gindin

"Housley, Russ" <[email-masked]> on 06/03/2002 11:29:12 AM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    Juergen Brauckmann <[email-masked]>,
       [email-masked], Pkix <[email-masked]>
Subject:    Re: draft-ietf-pkix-warranty-extn-01

Tom & Juergen:

This form of representing monetary values was not invented by the authors
of this specification.  I it is used many different places, and it is
specified in   ISO 4217 [1].

Russ

[1]     ISO. Codes for the Representation of Currencies and
           Funds," ISO 4217. 1995.

At 05:16 PM 5/31/2002 -0400, Tom Gindin wrote:

>       Juergen:
>
>       This depends on the interpretation of the text.  There are two ways
>to resolve this.  Either the amtExp10 field should have a different range
>(perhaps (-6..MAX)) or amtExp10 is to be interpreted as a resolution
>exponent only, so the actual value is amount / 10**amtExp10.  The example
>points towards the second option.
>       If the second of these options is to be taken, the wording must
>change.  I suggest adding after the sentence defining amtExp10 an extra
>sentence as follows: "The actual monetary value in the named currency
unit,
>when amtExp10 is present, is amount divided by 10 to the (amtExp10)
power".
>Anyway, why is this value an exponent base 10?  Not that long ago, one of
>the world's principal hard currencies had two minor units, 1/20 and 1/240,
>and I'm not sure there aren't some similar cases still around.  It could
be
>called minorUnitDivisor and the value would just be amount /
>minorUnitDivisor.
>
>             Tom Gindin
>
>
>Juergen Brauckmann <[email-masked]>@mail.imc.org on 05/31/2002
>09:15:27 AM
>
>Sent by:    [email-masked]
>
>
>To:    [email-masked]
>cc:    Pkix <[email-masked]>
>Subject:    Re: draft-ietf-pkix-warranty-extn-01
>
>
>
>Hi.
>
>How should extendedWarranty be used? Perhaps you can give an example?
>
>Format of the currency field in CurrencyAmount: There is at least one
>standard ("ETSI qualified certificate profile") I know of which
>recommends use of a PrintableString and the alphabetic code from ISO
>4217.
>
>The example in chapter 2.2 is wrong:
>  "$48,525.50 (in US dollars) is represented as:
>      currency =      840
>      amount   =  4852550
>      amtExp10 =        2"
>
>That's wrong. 4852550 * (10 ** 2) is 485,255,000. I guess you wanted to
>say that amtExp10 is -2, but you cannot do that because it has to be >=
>0.
>
>Regards,
>    Juergen

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 03 Jun 2002 11:40:37 -0400

Tom:

I am not arguing against explanatory text, but I am suggesting that we not 
invent another means of describing monetary values.

Russ

---

From: "Alice Sturgeon" <[email-masked]>
Date: Thu, 13 Jun 2002 08:46:46 -0400

Suggest we revise the draft to add the explanatory note, with the proper
reference to ISO IS 4217.  This should clarify this matter.  Given that the
ISO standard provides an international interpretation for monetary codes, it
would be prudent to adhere to that standard.  (I assume there is a revision
to this 1995 standard in the works, to address the common European
currency.)
It might be helpful as well to add a short appendix that provides a complete
example of use of the warranty extension.

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 Housley, Russ
Sent: June 3, 2002 11:41 AM
To: Tom Gindin
Cc: Juergen Brauckmann; [email-masked]; Pkix
Subject: Re: draft-ietf-pkix-warranty-extn-01

Tom:

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 13 Jun 2002 15:21:49 +0200

Alice,
 
> to this 1995 standard in the works, to address the common European

The currency coding for the euro is:  EUR (978).

Denis

BTW, I have not seen yet a response to my comments on this document.

---

From: "Alice Sturgeon" <[email-masked]>
Date: Thu, 13 Jun 2002 13:18:53 -0400

Denis,
I had not yet responded to your, as always, insightful comments, because I
have been mulling them over, and consulting with colleagues.  But since you
ask ...

COMMENT 1:
You wrote:
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.

[AS] Seems to me it would be very difficult, if not impossible, to charge a
per-transaction fee to a relying party in any scenario simply because the
relying party may not be known to the other parties in the transaction.  It
is possible, for example, to have anonymity or at least pseudo-anonymity in
transactions, and if that were the case, how could a relying party be
charged in any effective manner?
That point aside, the warranty extension does explicitly apply to a fee to
the subscriber, or to the CA - it is not necessarily charged to the
subscriber.  (The CA may decide to absorb the cost of insurance itself on
behalf of its customers; this is a distinct possibility in a competitive
environment.)  If the warranty extension is present and populated by other
than NULL, then the CA is providing a warranty, either base or extended.
Who pays for it is, for the purposes of the warranty extension, irrelevant
because this point will be addressed in the terms and conditions.  One
assumes that a subscriber, on subscribing to the CA's service, will be
informed of the warranty T&C including whether or not there is a fee to the
subscriber.  The syntax in the proposed extension really does not imply or
dictate a fee regime.

COMMENT 2:
You wrote:
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.

[AS] Juergen's comments on this point, and your response:
[JB] 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.
[DP] Not necessarily. I have to tell how much. A good example is a payment
guaranteed 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.
[JB] Why is it necessary to object against this procedure when it is about
electronic transactions?
[DP] See above.

[JB] 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?
[DP] The amount can be guaranteed for a given date, irrespective of the
nature
of the goods or the service being purchased.

[AS] With respect to privacy, isn't this addressed in the exchange above?
In some cases, it may be necessary to disclose transaction details, just as
in the paper world it is necessary to disclose pertinent information in
order to submit an insurance claim.  In other cases, the warranty may simply
be for a certain amount of money, usually a small-ish amount, and for this
amount, it is sufficient only to show that there was injury or damage (e.g.,
a transaction not completed), even without absolute proof.  This is
certainly the case in the paper world; for example, most credit card
companies accept their customer's claim of not having made a particular
transaction, if it is not too big.

COMMENT 3:
You wrote:  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.

[AS] The T&C may not necessarily be contained in the CPS; it may be a
separate document.  This is likely to be true in particular when the fee is
charged to the subscriber.  Then it would be a part of the subscriber
agreement or RPA.  Wherever they are, the warranty information needs to be
human-readable and need not necessarily be machine-processable, except to
the extent that they form part of the certificate (thus the standard ASN.1
format).  What is important is that the certificate users are aware of and
understand the T&C of the warranty.  The need to check revocation status of
the certificate applies to the certificate generally, and is not specific to
the warranty extension, and therefore need not be addressed within the
warranty extension.  The I-D states that the validity period of the warranty
will, in the vast majority of cases, be the same as the validity period of
the certificate, in which case the NULL option is selected.  In the rare
cases when the validity periods are different, it is obvious although
unstated in the I-D that the validity period of the warranty will be shorter
than that of the certificate itself (since a warranty will not apply to an
expired certificate).

COMMENT 4:
You wrote:
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.

[AS] Again, I believe this information would more usefully be contained in
the T&C, not in the certificate and the warranty extension.  This is similar
to health insurance schemes, which tell the subscriber about deadlines for
submission of claims in the booklet the subscriber receives on joining the
scheme.
A time-stamp is a good idea, but, again, this is not a requirement unique to
the warranty extension.
Previous comments on privacy, concerning disclosing details of transactions,
also apply here.

COMMENT 5:
You wrote:  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.

[AS] I agree this may be preferable to the insurance company, but you have
to agree this is standard insurance-business practice!  Your point on
aggregation is, I would say, outside the scope of the certificate.  It is
similar to the health insurance scheme analogy - If I am insured for health
services up to a certain amount (and with a deductible, which hasn't been
mentioned yet!), then if I submit a claim that is higher than that amount
(e.g., annual physical is covered but I have two physicals in one year), the
insurance company will not reimburse above the amount insured.  From my way
of thinking, then, this does not need to be managed on-line.

COMMENT 6:
You wrote:  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.

[AS] There is a substantive link between a qc and the warranty extension in
the sense that providing a warranty may enhance trust in the certificate and
the transactions in which it is used, which of course is the primary motive
of the qc as expressed in the EU Directive and specified in RFC 3039.  The
qc statement, represented by an OID, takes decision-making out of the
warranty-extension setting.  If the OID incorporates an established limit,
then when present this is the limit guaranteed.  This is a "warranty" up to
a specified value, and a "disclaimer" above that limit.  The intent is to
provide a warranty, and not to "disclaim" it, but to set a limit on it.  In
that sense, then, it is a warranty extension and not a warranty disclaimer
extension.  This may be a matter of whether the glass is half-empty or
half-full.

COMMENT 7:
You wrote: 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.

[AS]  What is optional is using the extension itself.  IF it is used, then
it must be used properly.  The option is in its use, not in how to use its
parameters.  If you think it would make this more clear, then we could add a
statement at the start of the Security Considerations to the effect that the
extension is optional, but that if it is used, then the syntax and structure
must be used in accordance with the parameters set out in this document.

Your 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.

[AS] The point of the extension is to avoid that common misperception of
"the fine print".  The warranty extension serves to show users immediately
in the certificate, first, that there is a warranty, and, second, what the
T&C pertaining to that warranty are, exactly how to find them and how to use
them.  This should be much more beneficial to the user community than having
no reference whatsoever to the existence of a warranty, and having to rely
instead on combing through all the sections of a CPS to find out whether or
not a warranty is given.
Again, several of the points you mention will be found, in the extension
(e.g., validity period = NULL), then in the certificate (validity period),
or in the T&C which may be the RPA, other subscriber agreement, or CPS, and
to which the RP or subscriber is directed from the extension.
The warranty extension is optional.  It will be beneficial to those CAs and
their insurers that wish to take advantage of it, and explicitly offer a
warranty to their subscribers.

Thank you again for your detailed and thoughtful comments.  Sorry to take so
long to respond - the old grey cells needed time to absorb it all!

Alice Sturgeon
Chair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Denis Pinkas
Sent: June 13, 2002 9:22 AM
To: [email-masked]
Cc: Pkix
Subject: Re: draft-ietf-pkix-warranty-extn-01

Alice,

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 14 Jun 2002 08:05:40 -0400

Denis & Alice:

I asked someone in the insurance field about this point.  I was told that 
policies are written in the fashion supported by the model in the proposed 
extension.  However, there are also policies written using the model that 
Denis proposes. A warranty certificate extension seems appropriate in one 
model, but not the other.  I do not think that it would be possible to 
craft a warranty certificate extension for the model that Denis advocates.

In my opinion, it is not our role to impose specific insurance 
model.  Rather, we should define standards that support the models that are 
actually used.

I suggest that additional text be added to the Introduction that describes 
the insurance models where this extension is useful.  Further, it should 
point out that per-transaction insurance could be obtained, but that it is 
not covered by this extension.

Russ

>[DP] COMMENT 5: