Subject: RE: draft-ietf-pkix-warranty-ext-01

From: [email-masked]
Date: Fri, 06 Sep 2002 01:57:20 +0000

Alice,

Some points/suggestions:

1.)  There is a minor typo on page 5, para 2, line 1.

The ‘if’ in the line (copied below) should probably 
be 'of'.

 "CurrencyAmount is a SEQUENCE if three integers.  
Together the integers..."
 
2.) The draft says:
"The extension definition supports two alternatives: 
aggregated and per-transaction." 

Often, it is desirable to limit both the per transaction 
liability as well as the aggregated liability.  e.g. 
$100.00 max per transaction with a $500.00 max for the 
life of the certificate.  I would recommend that this be 
accommodated.

3.) I recall hearing some noise in the past about a 
Certco patent on issuing ANY kind of warranty where a RP 
uses a certificate to determine the warranty.  ...or 
something along those lines.  Do you know if this ID is 
(or is not) hampered by this patent? 

Others on the list have questioned whether this ID is 
really a necessary thing.  I happen to think that such 
an extension can be put to good use and may facilitate 
automated validation of an electronic transaction in 
some cases.  It certainly does no harm.   That said, 
there will be situations where the requirements are too 
complex to be handled by such an extension to any degree 
of usefulness. (like Identrus - which had a multi-
currency, cross jurisdiction, per transaction setting of 
warranty cost and value based on dynamic lookups of caps 
and collateral, etc) For such complex systems, the best 
place to handle warranty statements is the CP or some 
related document and not a certificate extension.  

Khaja

> 
> Denis and Anders, I appreciate your comments; they are 
helpful in keeping to
> the right path.
> 
> One point that I took issue with was Denis' to the 
effect that the intent of
> the I-D is not clear.  It is in fact stated in the 
first couple of
> paragraphs and I would have thought it quite clear. It 
is to provide a
> degree of confidence to RPs in e-business and 
electronic transactions. PKI
> is seriously not yet understood; there exists some 
mistrust amongst
> potential users about the mechanisms, not necessarily 
the security
> mechanisms per se because these are relatively 
transparent to a user, but
> generally in electronic exchanges involving some value.
> 
> I also have a problem with Anders' statement that you 
cannot "roll-back"
> authentication events.  True technically (actually, 
technically either true
> or false depending on mechanisms); in a legal or 
policy context isn't this
> what non-repudiation prohibits? That is, without non-
repudiation, you can
> "undo" an authentication event (the authentication can 
be repudiated, or
> 'undone').
> 
> I'm looking forward to being able to discuss issues 
about the I-D at the
> Atlanta IETF meeting.  I'm sure others will as well, 
since there have been a
> number of respondents to the I-D posting.  Just FYI, 
my unaudited (but
> trustworthy : - )) count shows 5 supporters, 3 
objectors, 2 abstainers, and
> 2 still considering and undecided.
> 
> 
> Alice
> 
> P.S. Denis, I'm happy to have been the source of 
bringing you and Anders to
> like thinking!
> 
> 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
> 
> 
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: September 2, 2002 6:50 AM
> To: [email-masked]
> Cc: Anders Rundgren; [email-masked]; ietf-
[email-masked]
> Subject: Re: draft-ietf-pkix-warranty-ext-01
> 
> Alice,
> 
> I concur with many of the arguments raised by Anders. 
It is very scarce, but
> this time it happened, thanks to your draft. :-)
> 
> I believe that sufficient arguments have been raised 
against the progression
> of this draft, as it stands, which does not even 
explicitly states, for a
> naive reader, what the warranty is about.
> 
> The warranty is concerned with the liability of the 
CA, more precisely, only
> errors made by the CA personal or attributed to the CA 
during the management
> of the certificate, e.g. at the time of registration 
of the subject, when
> issuing the certificate, when handling revocation 
requests or when making
> available revocation status information.
> 
> Regards,
> 
> Denis
> 
> > Alice,
> >
> > >Lynn observed that the world of financial risk 
management is moving past
> > >per-transaction model.  The proposed extension 
offers an aggregate model.
> > >Also Lynn wrote: "and any migration to an offline 
paradigm with
> > >> both support for per transaction as well as 
aggregation risk/limits
> > >> obsoletes the requirement for the certificate."
> > >That's true; that's why the extension is useful.  
If total risk, i.e.,
> > >aggregated transactions, is the primary worry of 
the insurance industry
> then
> > >the aggregate model would be appropriate.
> >
> > This sounds pretty dangerous as it gives no value to 
an RP which may be
> just
> > one of several thousands of RPs which just received 
a purchase order
> > from a company that is on the edge of filing for 
bankruptcy.
> >
> > If it is of no value to RPs, the only purpose left 
for the
> warranty-extension
> > is for a CA to insert its liability limit in a 
machine-readable
> > format.  Is this really interesting as any liability 
above zero is likely
> > to be accompanied by a non-machine-interpretable 
agreement?
> >
> > Is the intent, that the moment a transaction is 
received that exceeds
> > the liability limit, an alert is to be sent to the 
legal department?
> > Depending on the liability agreement this may be too 
late
> > as lower-amount transactions may be equally 
uncovered.
> >
> > Actually it would IMO better be a part of the CA-
certificate to
> > declare what it stands for in terms of liability.
> >
> > Regarding warranted purchase orders, I have serious 
problems
> > understanding what a CA-issued warranty could 
possibly cover except
> > for a liability for having certified the wrong 
entity which is now making
> > fake orders.  But IMHO such a warranty is equally 
applicable to
> > authentications, as incorrect such are even worse as 
you cannot
> > "rollback" authentication events.
> >
> > For pure financial transactions, there are already 
solutions in place
> > since ages ago, like bank-warranties, remburses and 
pre-paid orders.
> > cheers,
> > Anders