draft-ietf-pkix-warranty-ext-01

["Alice Sturgeon" <asturgeon@xxxxxxxxxx>]

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

Issue # 3: ETSI tried to specify warranty information, and ETSI was never
able to reach consensus.
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.

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



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