Re: [IETF-PKIX] Reliance limits in statutes

[berlen@xxxxxxxxxxxxxxxxxx]

In the italian draft legislation there is nothing like that; the only thing which is required for a CA
to operate is
to have a society form and available capital equal to that needed in Italy to operate as a Bank; this
recalls the liability
question, but not related to a specific certificate, but to the CA as a whole.

Bob Jueneman wrote:

> >What a reliance limit exactly is?
> >I know the Italian legislation which is going to be approved, where it seems there is nothing which
> >sound like what you need.
>
> Several people have asked "what's a reliance limit", so I guess I should
> have provided a definition.
>
> The Utah Digital Signature Act provides a means of limiting a
> CA's liability (and presumably the subscriber's liability), by putting
> a "Reliance Limit" in the certificate as a way of indicating the
> monetary value or upper limit of a transaction that might be
> considered "commercially reasonable":
>
> "46-3-309 Recommended reliance limits and liability
>
> (1) By specifying a recommended reliance limit in a certificate,
> the issuing certification authority and the accepting subscriber
> recommend that persons rely on the certificate only to the
> extent that the total amount at risk does not exceed the
> recommended reliance limit."
>
> Paragraph (2) of that section goes on at some length to define
> the limits of liability that would apply to a CA that is licensed under
> the Utah statute, and how someone can recover from the CA in
> the event someone is harmed. The Utah regulations also require
> that a CA provide a "suitable guaranty" in the form of surety bond
> or irrevocable letter of credit in an amount that is a percentage
> of the aggregate amount of the reliance limit of all currently valid
> certificates issued, in order to back up such liability limits. C.f.
> http://www.commerce.state.ut.us/web/commerce/digsig/act.htm,
> section 46-3-310 and 310.
>
> There are, of course, a number of problems that could occur in
> anything other than a closed loop system where the CA becomes
> involved in validating every certificate -- the CA normally has no
> knowledge of how many times the subscriber uses his digital
> signature, and even the subscriber may have no idea how many
> times even a given signature is validated, e.g., on a piece of
> operating system code signed by Microsoft, or a Java applet signed
> by some web server. Even if the Reliance Limit is 1 penny, the
> CA's liability is potentially infinity squared in that case.
>
> Nonetheless, even in an open loop, open PKI system, some
> form of caveat or limitation on a certificate is probably better than nothing.
>
> To date, no CA I am aware of includes a Reliance Limit attribute extension
> in their certificates. VeriSign in their CPS does claim an overall liability limit
> on a per certificate basis based on their certificate class, but they don't
> refer to it in their certificate, except by incorporating by reference their CPS.
> Whether such an aggregate liability limit would hold up in court without some
> form of statutory authority is an interesting question.
>
> We are considering  including a optional Reliance Limit attribute extension
> in certificates which our CA toolkit will produce, and at present I'm thinking
> about specifying both a per transaction and per certificate liability cap or
> reasonableness indicator, denominated in a particular ISO-country currency
> (user's choice), or perhaps in troy ounces of gold. When and if we do so, we will
> post an informational RFC defining the syntax and semantics of the attribute
> (along with others we are defining) so that browser vendors and others will know
> how to display the attribute. The attribute could be Critical or non-Critical at the
> user's choice, although marking it Critical would obviously limit interoperability.
>
> Although putting such an attribute into a certificate wouldn't be particularly
> difficult, translating the input screens and the corresponding display screens
> into all of the foreign languages that Novell supports worldwide does involve
> some effort, so the question is whether such a concept is worth implementing
> on a world-wide basis.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> bjueneman@novell.com
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."



--
____________________________________________________________________
Oronzo Berlen                   | tel. 080.635-2112
Olivetti Ricerca                | fax. 080.635-2089
S.S. 271 Contrada la Marchesa | Email:berlen@olivettiricerca.it
70020 Bitritto (BA)             |