Subject: RE: OCSP and LDAP

From: [email-masked]
Date: Sun, 5 Jan 2003 14:01:25 -0700

the certificate typically contains some assertions (age, address, name,
address, affiliation, etc) .... OCSP & CRLs are about the degree of
possible staleness of the assertions/information contianed in the
certificate .... not actual information itself

because the information is certified in the certificate ... at some time in
the past .... by definition ... you aren't going to see dynamic information
.... information in a certificate is about static information as of the
time the certificate is created. OCSP & CRLs doesn't represent actual
information .... it represents information about possibly how stale the
static information is ... not the static information itself.

so a characteristic of the certificate offline paradigm is static
information as of some point in the past. Online, real-time OCSP ...
doesn't provide current &/or dynamic information .... it just provides some
indication of how stale the static information in the certificate is.

An online, real-time infrastructure has the opportunity to transition to
providing online, real-time, current, & dynamic information .... not
limiting itself as to an opinion as to the degree of staleness contained in
the static certificate.

The business issue .... is that going to the trouble & expensive of having
an online, real-time infrastructure .... can be leveraged to provide
real-time, online (& dynamic) information.

So as in some other scenario (non payment card) .... was the issue of gov.
granting business licenses of various kinds.  The brain-dead translation is
to give them a gov. signed certificate representing that offline, paper
license. Now people that want timely information in the non-electronic
world .... go to online, real-time ... by calling and/or visiting the
various agencies (better business bureau, local gov. office, etc) and check
on the status of the license. Actually what most people do when doing
real-time checks on a business .... isn't just that the business license is
still valid ... but how many complaints, what kind of complaints, what kind
of recommendations, disposition of complaints, any fines, etc.  If they are
going to all the trouble of having a real-time check .... they aren't after
the OCSP version .... if they are going to all the trouble of a real-time
check ... they want the real-time, dynamic data version of the informattion
(not the old fashion, offline, static & possibly stale version of the
data).

My assertions has not been that certificates (offline, static, stale
information) are useless .... my assertions have been that if you are going
to the trouble of having a real-time, online infrastructure .... that the
value of that real-time online infrastructure is significantly enhanced by
offering higher value information .... like real-time dynamic information.
It isn't limited to the payment industry (lets say all electronic commerce)
or licensing (all gov. sanction activities) .... I claim that for nearly
all certification scenarios involving online, real-time ... the
infrastructure goes to the trouble of having real-time dynamic data.

Lets take another example ... driver's license. If you get stopped .... the
typical real-time, online response isn't about whether the license is
revoked or not (that is trivial subset) .... it is how many traffic
citations/warrents are outstanding .... number of parking tickets, and
potentially some number of other pieces of real-time, dynamic information.

The issue isn't whether offline, static, stale certified infomration is
useless. The issue is that in going to the trouble of having online,
real-time facilities .... there is the ability and the value proposition to
support online, teal-time dynamic information ... rather than offline,
static stale information.

All instances that I can think of where somebody is going to the trouble of
some real-time, online checking .... they are getting real-time dynamic
information ... not just a simple opinion about the possible degree of
staleness of static, offline information.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

                          "Ambarish                                               
                           Malpani"     To:      <[email-masked]>,    
                    <ambarish@malpa        "IETF PKIX" <[email-masked]>        
                            ni.biz>     cc:                                       
                                        Subject:      RE: OCSP and LDAP           
                         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                      [email-masked]
http://www.malpani.biz

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Sunday, January 05, 2003 6:53 AM
> To: Anders Rundgren
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; 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
>
>
> [email-masked] 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
>
>
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 6 Jan 2003 00:08:49 +0100

<snip>

>potentially some number of other pieces of real-time, dynamic information.

No problems.
The licensee authenticates to the "traffic police server" which uses
OCSP to verify that the TTP-issued license is not revoked. 
Assuming the license was OK the server then invokes other
"authorities" for any additional information needed using the 
identity as given in the license (certificate).  The result is returned
as a nicely formatted screen on the officer's PDA.  Except for
the fact that the screen is static [:-)], I don't see any particular
staleness here.  Unless for the *possible* reliance on CRLs
you have a problem with.  But CRLs are just an option.

But you do have a point.  To put a lot of potentially stale information 
in a certificate is a bad idea.  "Employee certificates" is an example
of a broken scheme as they vouch for not less than three things: 
An individual, an organization, and an unspecified [= totally useless]
association between these two entities.  Here I really believe that your
on-line, real-time paradigm will become the norm.

<snip>

Anders