[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OCSP and LDAP
the thesis was that OCSP could provide a status indication as to the
staleness of the static information in a certificate designed for offline
operation.
an online service can provide almost any level of real-time, fresh,
dynamic, and/or aggregated information.
For a value business operation using online, real-time, fresh, dynamic,
and/or aggregated information (that is a superset of the stale, static
information in a certicate designed for offline operation) ... then both
the certificate becomes redundant and superfluous and therefor an OCSP
transaction as to the degree of staleness of the stale, static information
becomes superfluous.
furthermore ... it has been trivial to show that for an operation involving
transfer of money .... that the actual transaction for the transfer of
money can be piggy-backed with the online, real-time, fresh, dynamic and/or
aggregated information operation ... at effectively no additional cost ....
and that then both a certificate and any OCSP are redundant and superluous.
I can have online, real-time, fresh, dynamic, and/or aggregated information
operation. Such information is a superset of offline, static, stale
certificate-based information. If i'm using the online, real-time, fresh,
dynamic, and/or aggregated information .... then the offline, static, stale
certificate-based information is redundant and superfluous.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
"Ambarish Malpani"
<ambarish@malpani. To: <lynn.wheeler@xxxxxxxxxxxxx>,
biz> "IETF PKIX" <ietf-pkix@xxxxxxx>
Sent by: cc:
owner-ietf-pkix@ma Subject: RE: OCSP and LDAP
il.imc.org
01/05/2003 12:15
PM
Hi Lynn,
Not sure why you associate OCSP with stale information. The
responder can have as current information as you choose to provide
it.
Once again, I believe it makes sense to have the interaction
between the CA and the VA be CRLs. If there is more
current information you have (than is present in the CRL), it
makes sense to have that information at the VA for use until a
new CRL is produced.
Ambarish
P.S. We have also had people use their OCSP responder to provide
more than just certificate revocation information (eg. payment
authorization) using extensions to OCSP.
---------------------------------------------------------------------
Ambarish Malpani 650.759.9045
Malpani Consulting Services ambarish@xxxxxxxxxxx
http://www.malpani.biz
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of
> lynn.wheeler@xxxxxxxxxxxxx
> Sent: Sunday, January 05, 2003 6:53 AM
> To: Anders Rundgren
> Cc: ambarish@xxxxxxxxxxx; ietf-pkix@xxxxxxx; madwolf@xxxxxxxxxxxxxxx;
> owner-ietf-pkix@xxxxxxxxxxxx; Peter Gutmann
> Subject: Re: OCSP and LDAP
>
>
>
>
> but as been discussed in other venues ... it is not only the cost ... but
> also who pays (how does the money flow). does a consumer pay for
> checking a
> merchant's certificate as part of access the merchant's website ....
which
> might otherwise be free access? A merchant (as the relying party)
> might pay
> when checking the status of a consumer's certificate .... but does a
> consumer (as the relying party) pay when checking the status of a
> merchant's certificate.. Also ... as in other merchant/consumer
> e-commerce
> discussions .... a merchant's interest in the status (real-time or not)
of
> a consumer's certificate is only incidental to whether the bank says that
> the merchant gets paid.
>
> now the other business flow as a certificate, offline, stale paradigm is
> pushed towards an online, real-time model .... there is a question of
what
> point does the paradigm switch. In the original offline credit-card
> paradigm .... the transition to online, real-time .... bypassed the
> real-time checking on whether the offline, stale credential was still
good
> ... and/or whether the stale assertions in the offline credential
> was still
> good .... but whether the real-time assertions were valid.
>
> The model in the certificate ... is that there are some
> assertions that are
> inserted into a stale, static certificate at some time in the
> past .... and
> for OCSP ... you do real-time checks to see if the stale, static past
> assertions still hold. The model that credit-cards went to .... was doing
> real-time checks on real-time assertions ... not real-time checks on
> real-time stale, static assertions.
>
> The distinction is that the payment card paradigm in moving to online ...
> bypassed the intermediate paradigm of real-time checks on past, stale,
> historic, static assertions (contined in the certificate) .... and went
> directly to real-time checks on current, real-time assertions, aka the
> credit-card industry in transitioning to online .... could have continued
> to preserve the offline paradigm with real time checks (like OCSP does
for
> certificates) .... which is equivalent to a real-time check to see if the
> consumer still has a valid account. However, the payment card industry
in
> transitioning to online discovered that they could significantly leverage
> the utility of having real-time, online checking .... that instead of
> having real-time, online checking of stale, static information ....
> significantly increase the utility of having real-time checking of
> real-time information.
>
> So the credit-card industry skipped the OCSP-analogous step of having a
> real-time infrastructure for checking of stale, static data (aka does an
> account still exist), and significantly improved the utility of having an
> online, real-time infrastructure ... and performing real-time checking of
> what the merchant is really interested in .... will they get
> paid. An issue
> is whether the value of having a real-time online infrastructure is
> significantly depreciated if it is just being applied to checking
> status of
> static, stale information .... when for effectively the same
> infrastructure
> costs .... it can be used for real-time, online checking of real-time
> dynamic information (under the assumption that real-time checking of
> real-time dynamic information tends to have more value than real-time
> checking of static, stale information).
>
> ... i believe that the charge/chost at supermarket check-out for
> debit card
> transaction doing real-time checking for sufficient funds for the
> transaction (rather than just checking if the account still exists)
> as well as scheduling the transaction .... the charge/cost for
> both/combined ... is on the order of your projected lookup costs.
>
> If the online, real-time validation of real-time dynamic assertion
(rather
> the real-time validation of static, stale assertion) can be bundled with
> the actual execution of real transaction .... and be bundled for
> essentially the same cost of doing just online, real-time lookup
> of static,
> stale data .... then it would imply that static, stale data paradigm
would
> be somewhat redundant and superfulous in an online, real-time
environment.
>
> --
> Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
>
>
> anders.rundgren@xxxxxxxxx on 1/5/2002 2:44 am wrote:
>
> I agree with Peter.
>
> I don't think OCSP in a not so distant future have to be more technically
> costly than accessing a web-page. Including a signed answer.
>
> Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is
> "comparable to putting a stamp on a letter".
>
> Personally I don't think the VA-business model has much future as it
> complicates they way parties interact. It essentially requires two or
> three global VA-networks in the world to function and that seems very
> unlikely to happen. It feels like the VA business model is crafted
> according to the lines of credit-card authorizations, but that is a
rather
> different type of business IMHO.
>
> Pardon the slightly orthogonal input, but business & technology do have
> rather interesting connections...
>
> Anders
>
>
>