[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-pkix-warranty-ext-01
Alice,
> Hi folks,
> Several issues were raised at the IETF meeting on the proposed warranty
> extension I-D that may warrant some discussion on this list.
>
> Issue # 1: Should the warranty be an aspect of certification policy? If
> so, policy qualifiers would indicate the amount of coverage.
> The reason for a warranty program is that a CA is not an insurance company
> and therefore cannot issue a policy of insurance in favor of the subscriber.
Whether or not the insurance is direct or subcontracted is not the main
point. The insurance is provided by the CA because the CA pays for it.
> The CA will take out a certificate insurance policy with a licensed
> insurance company. Different certificates will have different certificate
> policies and therefore will have a different risk profile.
Since the certificate policy describes ALL aspects of the policy, if two
certificates have the same CP then then have the same insurance and warranty
limits.
As RFC 3280 states: "Optional qualifiers, which MAY be present, are not
expected to change the definition of the policy".
> The insurance
> company will cover each certificate and type of certificate issued. Hence
> the insurance company will sit behind the operations of the CA to cover the
> extended warranty program. There will be a contractual relationship between
> the CA and the subscriber, likely through the use of a Subscriber
> Agreement. With respect to the relying party, the subscriber, if the
> subscriber opts for the extended warranty, has the opportunity to extend the
> financial trust relationship between them. A relying party in encountering
> a certificate warranty program will know that an insurance company is
> covering the CA for any claims that fit within the warranty program.
"any claims that fit within the warranty program". This is not
understandable or machine processable. This is not visible in the warranty
amount but this is even more important than the amount. So it is very
questionable why the amount should be made visible and machine processable
whereas the conditions of the warranty are not. I am not saying that it
should be done visible as well, but this is more an argument to say that the
amount only is quite insufficient.
So my conclusion would be: we could have a direct pointer to the terms and
conditions of the warranty. These terms and conditions can be subcontracted.
The single adantage is a direct pointer so that a human being can read the
terms and conditions and *not* to automate the processing of that
information. If some processing is needed, it has only to be done against
the OID of the CP.
The support of the warranty concept could be limited to a Certificate
Warranty qualifier. It could be defined as follows:
The Certificate Warranty qualifier contains a direct pointer to a subpart
of the Certification Practice Statement (CPS) published by the CA. The
pointer is in the form of a URI. Processing requirements for this
qualifier are a local matter.
Thus, we do not need an extension for the warranty.
> Consequently certain warranties will be dealt with in the CP but it will not
> deal with the extended warranty. For example, the amount of compensation
> available would likely not be covered as the same CP for different types of
> certificates (e.g., usages) could have different extended warranty amounts.
> It is up to the subscriber to select the program.
> Warranty may be an aspect of certification policy, just as liability and
> disclaimers of liability and/or warranty. It is not necessary or
> appropriate to define a new policy qualifier (nor would it covered in the
> two policy qualifiers specified in RFC 3280 (s.4.2.1.5), the CPS URI pointer
> and User Notice), because it is defined in the proposed extension. The
> warranty extension may include the amount of coverage, or it may point to a
> specific document in which coverage is specified. That could be a narrowly
> focused Terms and Conditions, it could be Subscriber/Relying Party
> Agreements, or it could be a CP. The revision of RFC 2527 covers issues of
> warranty, and allows the statement of warranty in the CP and/or in
> subscriber/relying party agreements. Note: 'The degree to which a relying
> party can trust the binding embodied in a certificate depends on several
> factors. These factors include the practices followed by CA in
> authenticating the subject; the CA's operating policy, procedures, and
> security controls; the scope of the subscriber's obligations (for example,
> in protecting the private key); and the stated responsibilities and
> liability terms and conditions of the CA (for example, warranties,
> disclaimers of warranties, and limitations of liability).' [s.1.1]
> Note also: section 4.9.6: Representations and Warranties - 'This
> subcomponent can include representations and warranties of various entities
> that are being made pursuant to the CP or CPS...'
>
> Issue # 2: There has been concern expressed that IETF standardization of
> this proposed certificate extension could lead to proposals to standardize
> on other extensions, possibly many extensions. If proposals come forward,
> then they should be considered on a case-by-case basis. We should not
> arbitrarily or gratuitously prohibit, or even discourage, proposals for
> standardization on any aspect of certificates and PKI in general. Where one
> person does not see a need for standardization, another might; if the case
> for standardization is sufficient, then it should be allowed. We saw a
> strong need for standardizing in the area of warranty, and so proposed this
> standard for an extension.
ETSI TS 101 862 defines in section 4.2.2 "Statement regarding limits on the
value of transactions" the following:
=============================================================================
The limits on the value of transactions, for which the certificate can be
used, if applicable, may be indicated using the statement defined in this
clause. The codes are defined in ISO 4217 [9].
This optional statement contains:
· an identifier of this statement (represented by an OID);
· a monetary value expressing the limit on the value of transactions.
esi4-qcStatement-2 QC-STATEMENT ::= { SYNTAX QcEuLimitValue IDENTIFIED
BY id-etsi-qcs-QcLimitValue }
-- This statement is a statement by the issuer which impose 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.
QcEuLimitValue ::= MonetaryValue
MonetaryValue::= SEQUENCE {
currency Iso4217CurrencyCode,
amount INTEGER,
exponent INTEGER}
-- value = amount * 10^exponent
Iso4217CurrencyCode ::= CHOICE {
alphabetic PrintableString (SIZE 3), -- Recommended
numeric INTEGER (1..999) }
-- Alphabetic or numeric currency code as defined in ISO 4217
-- It is recommended that the Alphabetic form is used
id-etsi-qcs-QcLimitValue OBJECT IDENTIFIER ::= { id-etsi-qcs 2 }
=============================================================================
This extension does not say that a warranty exists under a given amount but
instead that no warranty applies above a given amount. This makes a *big*
difference.
> Issue # 3: ETSI tried to specify warranty information, and ETSI was never
> able to reach consensus.
??? Quite a strange statement. ETSI TS 101 862 has been endorsed by ETSI
members unanimously.
> While awaiting background on the discussions in ETSI, it is worthwhile
> noting that the ETSI standard that is being/has been discussed on this issue
> (ETSI 101 862 - Qualified Certificate Profile) says nothing about warranty,
> insurance, liability or disclaimers of such. The only related aspect is the
> inclusion of an optional statement on the monetary limit for which a
> certificate may be used (pursuant to 1999/93/EC). It has been noted that
> this optional statement is virtually the same as an explicit warranty
> disclaimer, but we would argue that it is insufficient to give adequate
> confidence to a relying party, by being implicit.
As indicated, the intent is to say: no waranty applies *above* that amount.
For the details of the waranty that *may* apply below that amount see the
details of the CP or CPS.
> Issue # 4: Would any CA be willing to make warranty cover the subscriber
> actions as well as the CA actions? If so, the relying party would be better
> served.
Not sure I understand the issue here.
> Whether a CA would make a warranty that covers subscriber actions is outside
> the scope of this proposed I-D. This proposed extension covers a CA's
> warranty provision. It is, of course, possible that a CA would insure
> against subscriber folly, but it is considered unlikely. Think about it:
> the only case in which a CA might be willing to cover the actions of its
> subscribers would be in a closed, high-assurance infrastructure; in that
> case, however, subscribers will also be the relying parties (and vice
> versa), so the matter is academic. In an open infrastructure, even a
> high-assurance one with user hardware security modules (tokens), the CA
> cannot control all the actions of subscribers nor ensure that subscribers
> will do everything right (i.e., protect their private keys). Other parts of
> the certificate, obviously, constrain the actions of all parties, in terms
> of certificate usage, applications, etc. etc. The warranty extension need
> not address all concerns; that is not its purpose. Its purpose is to give
> the relying party (a) confidence in the backing of the certificate (as well
> as confidence in the CA, in that the CA specifies in warranty coverage its
> own confidence in the system), and (b) an avenue for compensation in the
> event that the CA causes harm through failure to conform to its own
> specifications.
If this document is going to progress (in the direction of a policy
qualifier rather than an extension), it should be clearly indicated that the
warranty that is provided only covers errors committed by the CA when
issuing or revoking certificates, but by no means indicates the monetary
amount on some account related to the certificate subject. This is however
what relying parties are really interested in ! This insurance cannot be
provided by the CA but rather by party independent from the CA, e.g. a bank
or an insurance company. This warranty would need to be obtained on-line
using some protocol.
What is even more important is the format of the warranty rather than the
details of the protocol, so that relying parties can "understand" not only
the amount of the insurance but also all the terms and conditions that are
related to that amount. PKIX WG is likely not the right WG to define such a
protocol.
Any idea about which IETF WG would be able to "host" such a work item ?
Denis
> 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