Subject: RFC 3281 ASN.1 Errata

From: "Housley, Russ" <[email-masked]>
Date: Fri, 12 Jul 2002 16:40:51 -0400

Hi.

I just want to make everyone aware of a typo in the ASN.1 module in RFC 
3281.  There is a comma in the wrong place, and it it quite simple to fix.

INCORRECT LINE:

                 version        AttCertVersion  -- version is v2,

CORRECT LINE:

                 version        AttCertVersion,  -- version is v2

Russ

---

From: "Alice Sturgeon" <[email-masked]>
Date: Wed, 24 Jul 2002 17:41:07 -0400

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

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 31 Jul 2002 17:13:20 +0200

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

> 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

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

> 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

 ??? Quite a strange statement. ETSI TS 101 862 has been endorsed by ETSI
members unanimously.

> 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.
 
> actions as well as the CA actions?  If so, the relying party would be better

Not sure I understand the issue here.

> event that the CA causes harm through failure to conform to its own

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