Subject: Re: Last Call: 'Warranty Certificate Extension' to Informational RFC

From: Denis Pinkas <[email-masked]>
Date: Thu, 23 Oct 2003 14:17:22 +0200

On August 26, I sent a reply to the last call sent by the IESG on 
draft-ietf-pkix-warranty-extn-03.txt. It is copied below. Since then, 
nothing happened officially.

I met with Alice Sturgeon yesterday in Paris and we had a talk together. She 
told me that she has also been surprised to see the IESG last call, since 
she was ready to post a new draft 04 to answer my comments. Since she saw 
the IESG last call, she abstained to post it.

Since then, she received comments from the IESG and she needs to post a new 
draft.

I would appreciate if the situation could be clarified either by the 
Security Area Directors or by the PKIX co-chairs.

Denis

============================================================================

>> The IESG has received a request from the Public-Key Infrastructure 
>> (X.509) WG to consider 'Internet X.509 Public Key Infrastructure 
>> Warranty Certificate Extension' <draft-ietf-pkix-warranty-extn-03.txt> 
>> as an Informational RFC.

>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send any comments to the
>> [email-masked] or [email-masked] mailing lists by 2003-08-26.

> I am quite surprised to see that the IESG received a request from the 
> PKIX chairs while a discussion still takes place on the PKIX mailing 
> list on the document.
> 
> The last response from the lead editor (Alice Sturgeon) is dated August 
> 13. She recognizes that at least some "clarifications" are needed.
> 
> The e-mail is duplicated below and exhibits that there is good progress 
> but still no consensus on the document.
> 
> At least some changes to the June version (version 3) are expected 
> before the document can be published.
> 
> Regards,
> 
> Denis
> 
> Note: I am back from holidays, just today (i.e. August 26 th).
> 
> =============================================================================== 
> 
> 
> 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,
> 
> 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."
> 
> [AS2] Alternatively, to make the same point, it could remain implicit.
> 
> 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."
> 
> [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.
> 
> 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.
> 
> [AS2] A hash function on the T&C?
> 
> 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".
> 
> [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.
> 
> 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."
> 
> [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.
> 
> 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).
> 
> [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.
> 
> 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.
> 
> [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.
> 
> 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.
> 
> [AS2] Yes, we have made progress.
> 
> Denis
> 
> 
>> File(s) can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt
>>
> 
>