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

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 5 Aug 2003 11:49:57 +0200

Although I generally agree with Denis' analysis, I see some problems
with the deployment of Warranty Extensions occurring already at the
conceptual level:

If we take widely used transaction services like on-line banks, eBay
etc., they supply their end-users (customers) with some kind of
"Client Security Solution" and "End-user Agreements", that users
have to accept before getting access to the service(s).

Such End-user Agreements typically describe transaction limits,
warranties, mutual responsibilities etc.

Q: What would be the benefit for such a service to move (or duplicate)
parts of the "End-user Agreements" down to the "Client Security
Solution", in the [rare] case the latter is based on X.509 certificates?

/anders

----- Original Message ----- 
From: "Denis Pinkas" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 29, 2003 12:37
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt

Alice,

Please see my responses below.

Comments on warranty-extn-03.txt (June 2003)

1- On page 2. The text mentions: "A relying party that has a warranty from a
CA".

Does this mean that a relying party must have a contract with the CA to get
advantage of the warranty ?
[Alice] No.

Does this mean that a relying party will get a warranty without a contract
signed with the CA ?
[Alice] Yes.

Does this extension allow to make the difference between the case of a
signed contract and the case of an unsigned contract where the guarantees
could be different?

[Alice] No. If there are any differences in the T&C pertaining to a 
contractual arrangement, these differences will be outside of, beyond the 
scope, and not pertinent to, the warranty offered in the certificate.  It 
applies equally to all relying parties, whether or not a contract has been 
signed.

[Denis] Then say something like: "Whether or not relying parties have signed 
agreements with CAs, the CA will provide Terms and Conditions for this 
warranty which relates to its liability."

2 - The difference between the base warranty and the extended warranty is
not crystal clear.

How can a relying party know whether it can have the benefits of the base
warranty or of the extended warranty ?

If the extended warranty is present, then the relying party has the benefit
of the extended warranty.  In short, if it is present, then the relying
party knows that the relying party has the benefit of the extended warranty
by its presence alone.  The syntax shows that the extended warranty MAY be
present:
  Warranty ::= CHOICE  {
        none                 NULL,            -- No warranty provided
        wData                WarrantyData  }  -- Explicit warranty

    WarrantyData ::= SEQUENCE  {
        base                 WarrantyInfo,
        extended             WarrantyInfo OPTIONAL,
        tcURL                TermsAndConditionsURL OPTIONAL  }

If the tcURL is present, a human being might understand the terms and
conditions (if he can understand the local language used), but a computer
program will not be able to do so. This means that computers cannot
understand the difference.

[Alice] The computer does not need to know what is in the T&C.  If the tcURL 
is present, it is optionally for the benefit of the human reader. Perhaps 
you could suggest some text to clarify this in the I-D if you still think it 
is needed.

[Denis] Then say something like: "Warranty extensions are only aimed for 
human interpretation and contain data that is inappropriate for computer 
based verification schemes, the warranty extension MUST NOT be an active 
component in automated certification path validation."

3 - There is no security on the information placed at the tcURL parameter
since no hash of the terms and conditions is being used. These conditions
could change overtime and relying parties would not be able to demonstrate
that they have changed.

[Alice]
It seems to me that the time stamp on the certificate would suffice to place
the warranty in a point of time at which the specified terms and conditions
applied; there is no need for the extension to demonstrate that as this is
covered by the certificate itself.  This is no different from the
paper-based world in that if an insurance policy changes its terms, it
cannot do so retroactively to the detriment of clients who have paid for a
specific coverage, unless it notified the clients and compensates them
accordingly.

[Denis] The problem is that the CA could change the policy and the relying 
party will be unable to demonstrate that the policy has changed. A 
time-stamp token over the certificate would not help. A time-stamp token 
over the T&C would help, but the relying party does not necessarily have 
access to one TSU. The hash approach is much simpler.

4 - Is the "Relying party Agreement" a document to signed by the parties or
not ? This should be said.

[Alice]
Use of the term "Relying Party Agreement" is no different from its normal
usage, just as "Certificate Policy" is used in the same context without any
change to the meaning from normal usage, as per RFC 2527 and its successor.
In other words, defining the terms, either Relying Party Agreement or
Certificate Policy is not necessary to the understanding of this extension.

[Denis] The term "Relying Party Agreement" is confusing. Use a wording like 
"Terms and Conditions for Relying parties" which does not imply that there 
is an agreement signed but that unilaterally the CA provides terms and 
conditions. Relying parties may like them or not. If they disagree with 
them, then this is still "Terms and Conditions for Relying parties".

5 - The WarrantyValidityPeriod is insufficient. Usually there is a period to
claim for a compensation which must be made X months or Y days after the
date of the event which created the damage. It is thus not possible to ask
for a warranty during e.g. the whole validity period of the certificate.
Another time period parameter is missing.

[Alice]
This is exactly what the validity period is stating: that the warranty is
valid for a specified time, which is either the validity period of the
certificate, or another, specified time using the parameters as defined in
the I-D.  It is presented and offered this way, so there is no need for
another validity parameter.  If an offeror wanted to specify a time within
which claims could be made, then a shorter time period than the validity of
the certificate can be used.  This is unlike the paper-based world in the
sense that insurance policies are normally of long duration, whereas this
extension is associated with a certificate that normally has a validity of
two-three years.

[Denis] The semantics of the warranty validity period is not defined ! There 
is a need to define more precisely what "the warranty validity period" is. 
Here is a proposal along my original text. If it does not fit, please 
propose an alternative:

" The warranty validity period is a time period to claim for a compensation 
which must be made X months or Y days after the date of the event which 
created the damage. It is unrelated to the certificate validity period."

6 - The wType offers only two types of warranty: aggregated and per
transaction.

"Aggregated" means that that once the value of the fulfilled claims reaches
the maximum warranty amount, then no further claim will be fulfilled.

"Per transaction" means that each claim is handled independently but no
individual claim can exceed the maximum warranty amount.

Each type has its own problems:

"Aggregated" is like a race where late claimants will get no compensation at
all because they were not "fast enough". It is questionable whether such a
race condition will be acceptable.
It should be understood that aggregation applies to one warranty and one
claimant.  This is analogous to the paper-based world.  When you are covered
by warranty for X product or service, e.g., health insurance, there is often
an upper limit (viz. the "value") up to which claims will be met for each
claimant; i.e., one insured person.
"Per transaction" means that the CA cannot compute the maximum amount of
money that it may have to give away. Which insurance company will ever
insure a risk for which an upper limit cannot be computed ?

[Alice]
The T&C, as noted in section 1, as covered by insurance, will specify the 
maximum. The type of warranty selected depends on the nature of the 
transactions, the parties to the transactions (e.g., individuals, large 
institutions, etc.).

[Denis] What I am asking for is to allow a combination of both types, which 
is currently not possible. See below again.

None of these schemes is acceptable. Some combination should be allowed:

   - a maximum amount per transaction, and
   - a maximum amount per certificate with a maximum time period
     to claim for a compensation after the date of the event
     (no race problem implied).

7 - The content of the security consideration should be augmented to
indicate the difference between what a computer program can do and a human
being can do with this extension.

[Alice]
I would have thought this to be blindingly obvious.  We would, however, be
quite willing to consider some proposed words to address this, if you do
think it is necessary.

[Denis] If my text proposal related to comment 2 is inserted, then this is 
no more needed.

8 - The document is not mature enough and its added value is still
questionable.

[Alice]
We believe that it is mature.  Its value may be questionable to those who do
not want to use it, but given that it is (a) proposed as Informational and
(b) always non-critical, surely its availability for use is innocuous for
those that do not want to use it.  For those who do want to use it, and we
have heard from quite a number who do, it will be useful and valuable.  As
in section 1: "When a certificate contains a warranty certificate extension,
the extension MUST be non-critical, ..."

[Denis]
As you can see, we have progressed, but several issues still need to be 
addressed.

Denis

---

From: "Alice Sturgeon" <[email-masked]>
Date: Wed, 13 Aug 2003 06:10:06 -0400

Hello Denis,
Please see my comments inserted below, as [AS2], to distinguish from the
first set of replies to your original comments.

Alice

Alice Sturgeon
Chair, Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC 1/SC 27
and
System Policy Architect & Manager of Standards
SPYRUS

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Denis Pinkas
Sent: Tuesday, July 29, 2003 6:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt

Alice,

[AS2] Alternatively, to make the same point, it could remain implicit.

[AS2] But this is not necessarily true. It may be that the RP (i.e., the
human) has to go to a T&C document if the extended warranty is present, if
the RP wants to know what exactly is in the T&C, but there should be the
option of not going to the T&C.  If the extended warranty is not present (as
noted in the syntax, it is optional), then there is no reason that the
extension could not be processed by the computer. Therefore, the warranty
extension is NOT "only aimed for human interpretation...".  This may be
irrelevant to the point of automated certificate path validation, because
the extension is non-critical.

[Alice]

[AS2] A hash function on the T&C?

[Alice]

[AS2] Maybe so, but the RP has the option of not using or relying on the
certificate. As I said before, this is normal terminology, and should not be
confusing; it is not being used with a different meaning.

[Alice]

[AS2] What if the warranty validity period is indeed the same as the
certificate validity period? This was the scenario assumed to be most
likely, as it is stated in s.2.2, and therefore the option was created to
allow for a reduction in size of the extension by having NULL in warranty
validity period in the case where it was the same as the certificate
validity period.  When it is not the same as the certificate validity
period, then the parameters available for warranty validity period can be
used.

[Alice]

[AS2] You have a good point. We may need some clarification in s.2.2 to
explain exactly what the currency amount means.  This is clearly stated (and
obvious) with respect to aggregate, but not so with per-transaction.  It
should be indicated that there will be a maximum total of per-transaction
claims, which would be standard practice, and necessary for the ongoing
health of the CA.  The total warranty offered for per-transaction claims
could be expressed as a new parameter indicating number of per-transaction
claims before the maximum would br reached, which would be simple to
calculate since the per-transaction maximum is stated; e.g., a sub-line
after the per-transaction type code, number of transactions as a maximum.

[Alice]

[AS2] Still willing to consider a proposal, but as you can see from my
response to your comments on point 2, I don't think this is quite right.

[Alice]

[Denis]

[AS2] Yes, we have made progress.

Denis

---

From: "todd glassey" <[email-masked]>
Date: Wed, 13 Aug 2003 08:44:24 -0700

----- Original Message ----- 
  From: Alice Sturgeon 
  To: Denis Pinkas 
  Cc: [email-masked] 
  Sent: Wednesday, August 13, 2003 3:10 AM
  Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt

  Hello Denis,
  Please see my comments inserted below, as [AS2], to distinguish from the first set of replies to your original comments.

  Alice

  Alice Sturgeon

  -----Original Message-----
  From: [email-masked]
  [mailto:[email-masked]]On Behalf Of Denis Pinkas
  Sent: Tuesday, July 29, 2003 6:38 AM
  To: [email-masked]
  Cc: [email-masked]
  Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt

  Alice,

This is why I suggested that a T&C or Policy Negotiation protocol was needed. In fact any "deal" struck between the parties that references the indemntiy deal provided by one of the parties or a third-party indemnity provider, does in fact need to be uniquely referenceable and I agree with Alice that a hash of the approved T&C's that make up the the offering and accfptance of the reliance contract are enforcable. That means in any manner that a contractual relationship are to be codified by some set of digital transactions all the terms and conditions must be stated and agreed to ahead of time. 

Further, if the CA is to change any of these terms it MUST also notify all parties which may mean there is a notification responsibility from the reseller or party offering the indemnity services to the client or recipient of the services.

The real question is how to in a data-efficient manner to be able to represent these contract provisions or agreements, and as I suggested some time ago an OID Discovery Process is in order since OID's are the obvious method of making this work.

  [Alice] The computer does not need to know what is in the T&C.  

But more importantly the COmputer CANNOT know anything. It has no concious mentality, no realization of "I think therefore I am" and so under US and all other law that I can see, the computer is only a presentation service for a commercial process (in this instance) and the computer is not the Agent so it, itself, needs none of this.

Which brings us to one of the flaws in the Warranty Process model - is it for computers or people? - If its a mechanism for CA's to advertise and accept commerce bnased on what indemnity offerings they have, then there is no need for any Human Readable parts. If its a digital T&C negotiation process, and the Human is particularly specific to this protocol's operations then the URL makes sense. If its both then, we will likely have confusion unless there is some receipt process added for displaying the T&C's in any given digital transaction.

  If the tcURL

  [AS2] But this is not necessarily true. It may be that the RP (i.e., the human) has to go to a T&C document if the extended warranty is present, if the RP wants to know what exactly is in the T&C, but there should be the option of not going to the T&C.  If the extended warranty is not present (as noted in the syntax, it is optional), then there is no reason that the extension could not be processed by the computer. Therefore, the warranty extension is NOT "only aimed for human interpretation...".  This may be irrelevant to the point of automated certificate path validation, because the extension is non-critical. 

  [Alice]

YES!

  [Alice]

  [AS2] Maybe so, but the RP has the option of not using or relying on the certificate. As I said before, this is normal terminology, and should not be confusing; it is not being used with a different meaning. 

  [Alice]
  another validity parameter.  If an offeror 

you mean the Indemnetor right?

  wanted to specify a time within

This is at best a slippery slope.

  [AS2] What if the warranty validity period is indeed the same as the certificate validity period? This was the scenario assumed to be most likely, as it is stated in s.2.2, and therefore the option was created to allow for a reduction in size of the extension by having NULL in warranty validity period in the case where it was the same as the certificate validity period.  When it is not the same as the certificate validity period, then the parameters available for warranty validity period can be used.  

  [Alice]

  [AS2] You have a good point. We may need some clarification in s.2.2 to explain exactly what the currency amount means.  This is clearly stated (and obvious) with respect to aggregate, but not so with per-transaction.  It should be indicated that there will be a maximum total of per-transaction claims, which would be standard practice, and necessary for the ongoing health of the CA.  The total warranty offered for per-transaction claims could be expressed as a new parameter indicating number of per-transaction claims before the maximum would br reached, which would be simple to calculate since the per-transaction maximum is stated; e.g., a sub-line after the per-transaction type code, number of transactions as a maximum. 

  [Alice]

  [AS2] Still willing to consider a proposal, but as you can see from my response to your comments on point 2, I don't think this is quite right. 

  [Alice]

  [Denis]

  Denis