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

["Alice Sturgeon" <asturgeon@xxxxxxxxxx>]

Denis,

You pose some provocative questions, as usual.  Please see my responses
below.

Thanks,


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

Office:  613-232-2350
Mobile: 613-291-0331


-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On
Behalf Of Denis Pinkas
Sent: Tuesday, July 08, 2003 11:19 AM
Cc: ietf-pkix@xxxxxxx
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt


>       Title           : Internet X.509 Public Key Infrastructure Warranty
Certificate Extension
>       Author(s)       : D. Linsenbardt, S. Pontius, A. Sturgeon
>       Filename        : draft-ietf-pkix-warranty-extn-03.txt
>       Pages           : 8
>       Date            : 2003-6-27

Here are my comments on this draft.
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 ?
No.
Does this mean that a relying party will get a warranty without a contract
signed with the CA ?
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?
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.

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

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

4 - Is the "Relying party Agreement" a document to signed by the parties or
not ? This should be said.
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.

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

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 ?
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.).

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

8 - The document is not mature enough and its added value is still
questionable.
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