[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OCSP and LDAP
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
>
>
>