Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt

From: "Tom Gindin" <[email-masked]>
Date: Thu, 2 May 2002 12:23:23 -0400

Yuri:

      I agree with you and most of the people who've sent in comments that
a warranty from the CA to a single RP or a set of RP's has more evident
reason to be in a certificate than a warranty from the CA to the subject.
However, a warranty from the CA to an RP (or one which limits liability to
all RP's combined) does have some use in a certificate.
      It seems to me that there are several plausible limits which a CA
could impose on its liability:
1     A limit per transaction. This is currently defined as a QCStatement.
2     A limit for all transactions to a given relying party.  This is
fairly similar to the first one.
3     A limit for all transactions to a legally associated set of relying
parties (say all RP's employed by the same corporation), which is also
similar to first case.
4     A global limit for transactions to all relying parties combined.
      Quite evidently, the last of these is most favorable to the CA and
least favorable to the relying parties.  From an RP's standpoint, its main
advantage is that it's better than a statement in the CPS which says "we
aren't liable".
      As should be evident, I think the WarrantyType field in the draft
should have four values rather than two, since "aggregated" could mean any
of the last three cases.

            Tom Gindin

"Yuriy Dzambasow" <[email-masked]>@mail.imc.org on 05/02/2002 10:00:05
AM

Sent by:    [email-masked]

To:    "Michael Myers" <[email-masked]>, "Al Arsenault"
       <[email-masked]>, "Housley, Russ" <[email-masked]>,
       "Denis Pinkas" <[email-masked]>
cc:    "pkix" <[email-masked]>
Subject:    Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt

I agree with Mike and Al.  In my opinion, warranties make more sense if
they
are provided by the CA to the RP.  In addition, I think it makes more sense
to handle these sorts of warranties through contracts, and not through
certificate extensions.

Yuriy

----- Original Message -----
From: "Michael Myers" <[email-masked]>
To: "Al Arsenault" <[email-masked]>; "Housley, Russ"
<[email-masked]>; "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Wednesday, May 01, 2002 8:39 PM
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt

>
> Al,
>
> If I'm reading you correctly, I agree the WG should go
> cautiously here.  This is inherently a legal issue which is
> beyond our reach as technologists.  It's more within the scope
> of our friends at ISC.
>
> Mike
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Al Arsenault
> > Sent: Wednesday, May 01, 2002 4:25 PM
> > To: Housley, Russ; Denis Pinkas
> > Cc: pkix
> > Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
> >
> >
> >
> > The more I think about this, the more I sort of agree
> > with Denis.  It's not
> > clear to me what good this extension is.  It
> > indicates a relationship
> > between a subscriber and a CA, NOT an RP and a CA or
> > an RP and a subscriber.
> > Therefore, what good is it?  Why do I as an RP care -
> > or even have to know -
> > for how much a CA will indemnify the subscriber if
> > something goes wrong?
> > That's the kind of thing that can easily be covered
> > in some sort of contract
> > between the CA and subscriber, not in the certificate.
> >
> > This extension may give me as an RP a hint that
> > "well, the CA has at least
> > this much insurance/cash in the bank, and is willing
> > to fork it over to the
> > subscriber if need be, so I can start my lawsuit by
> > asking for at least this
> > much in damages". But I can't see any real use to it.
> >
> > So I'm not a big fan of pushing this forward; I think
> > it will likely cause
> > more confusion than anything else among the non-PKI-astute.
> >
> > All that being said, since it's all optional and I
> > don't actually have to
> > implement it, I really won't fight too strongly
> > against it, if somebody else
> > thinks that there's an actual use case.
> >
> >         Al Arsenault
>
>