Subject: RE: OCSP and LDAP

From: [email-masked] (Peter Gutmann)
Date: Sun, 5 Jan 2003 21:58:07 +1300

I wrote:

>I think one of the reasons why there aren't more complaints about CRLs is
>because so many apps only pay lip service to revocation checking, so it
>doesn't really matter if it doesn't work proprely ("We go through the motions
>because the CA policy requires it"/"It's turned off by default, but we can
<claim it's there"/"We realise the CRL is almost always out of date, but our
>accounting processes should catch any problems"/etc are all excuses I've
>heard).

Before someone leaps in here with the obvious "Well, DoD PKI users (or
something similar) do check CRLs, so they must be OK", what I was referring to
was the civilian masses who are expected to adopt PKI at some point.
Government users are a special case in that they have infinite resources to
throw at a project, can be ordered to use CRLs (or to charge a machine-gun),
and various other things that don't apply to the masses.

I realise that you can always dig up some user somewhere to illustrate some
point ("DoD users use X.400 email, so it must be OK"), but that's not a good
example of what the masses are doing.  I'm not going to be able to sell X.400
to commercial users on this basis, and a semi-functional validity checking
mechanism supplying out-of-date information is also rather a hard sell to
people.  When I hear users who do actually care about checking certs (for
example ones using them for medical EDI) say things like "We rely for the most
part on the hospitals to control access, and in any case it's no worse than
the existing paper-based system", I can see why PKI is a hard-sell.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 5 Jan 2003 22:04:25 +1300

I realise that you can always dig up some user somewhere to illustrate some
point ("DoD users use X.400 email, so it must be OK"), but that's not a good
example of what the masses are doing.  I'm not going to be able to sell X.400
to commercial users on this basis, and a semi-functional validity checking
mechanism supplying out-of-date information is also rather a hard sell.  When
I hear users who do actually care about checking certs (for example ones using
them for medical EDI) say things like "We rely for the most part on the
hospitals to control access, and in any case it's no worse than the existing
paper-based system", I have to worry about how long they'll continue listening
to PKI advocates telling them how wonderful it's all going to be...

Peter.

---

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

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:      <[email-masked]>,    
                                  biz>        "IETF PKIX" <[email-masked]>        
                              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                      [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: [email-masked]
Date: Sun, 5 Jan 2003 16:50:05 -0700

but the whole point of an offline credential containing certified
information is i can reference it offline. if i'm online .... i don't need
a certificate.

in the non-certificate model .... i assert that i have account number #xxx
and sign the assertion with hardware token.

that is sent off to the online infrastructure and it pulls up #xxx and
verifies the signature with the public key in the online record.

the state of the account and all related information is pulled from the
account. there is no offlne certificate containing any certified stale,
static information.

in the payment transaction ... i make two assertions that I have account
number #xxx and that i'll pay xyx .... I sign that assertion .... it is
sent off .... the account #xxx is pulled up .... it checks the signature
with the public key in the account record .... it checks the status of the
account and decides about the payment and returns yes/no as to the payment
(and whatever other information). No offline certificate with certified
stale, static information is needed.

for the license ... I make an assertion that i have license #abc and sign
the assertions with a hardware token. the police sends off the assertions
.... which verifies the public key and pulls up the record .... either
direclty containing all the real-time, fresh, dynamic, and/or aggregating
information .... or contains enuf information to aggregate all the
information. still no offline certificate with certified stale, static
information is needed  The police is using the online, realtime, fresh,
dynamic, and/or aggregated information. The police doesn't have to resort
to a offline credential containing a stale, static subset of the online,
realtime, fresh, dynamic and/or aggregated information. It is purely an
artificial contrivence to claim that a offline certificate with stale
static information provides any added value at the point when all of the
online realtime, fresh, dynamic and/or aggregated information is available.

i only need a certificate with stale, static information for offline
operations where i don't have access to online, real-time, fresh, dynamic,
and/or aggregated information. If I have a superset of the stale, static
information in a certificate .... then the certificate is redundant and
superfluous for that operation. If the certifcate is redundant and
superfluous .... then an OCSP operation that gives an opinion about the
staleness of the redundantant & superfluous stale, static information is
also redundant and superfluous.

If the value proposition is such that I always resort to the online,
real-time, fresh, dynamic and/or aggregated information .... then for those
value propositions an offline certificate with stale, static information is
always redundant and superfluous. If the offline certificate with stale,
static information is always redundant and superfluous ... then it would
follow that an OCSP for a redundant and superfluous certificate is also
redundant and superfluous.

so there is slight vulnerability issue here. not only is the certificate in
somebody's position subject to being stale static information ... but it is
also potentially subject to counterfeiting (picture, name, address, birth
date, etc). for low value operations with little risk .... the risk of
counterfeited license is low. For high value operations with potentially
more risk .... the "real" information is stored under strong security at
the appropriate agency. The thing that is in somebody's hand is purely a
stale, static offline copy of the real information stored online someplace.
The law enforcement are bringing up the "real" information when they go
onlne .... the stuff in your hand is basically a r/o stale, static copy
purely for low value, low risk, offline operations.

the claim that in an online environment .... that it is sufficient to have
an authentication mechanism .... it isn't necessary in a real online
environment to have any r/o, stale, static copy of the real information
carried around on your person in a certificate for use in offline
operations. If there are no offline operations .... then r/o, stale, static
copies designed for use in offline operations are redundant and
superfluous. For online operations, r/o, stale, static copies designed for
offline use are redundant and superfluous when the real, online, fresh,
realtime, dynamic and aggregated information is available.

                                                                                    
                    "Anders Rundgren"                                               
                    <anders.rundgren@     To:      "Ambarish Malpani"               
                           telia.com>        <[email-masked]>,                
                                             <[email-masked]>           
                     01/05/2003 04:08     cc:      "IETF PKIX" <[email-masked]>  
                                   PM     Subject:      Re: OCSP and LDAP           

<snip>

>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.

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

---

From: [email-masked]
Date: Sun, 5 Jan 2003 17:04:22 -0700

the driver's license in your hand isn't the real driver's license .... it
is a r/o, stale, static copy made at some time in the past. the real
driver's license is in some agency's database record. the issue about
whether the real license is valid or not is stored there also. all the
dynamic, fresh, aggregated, and/or realtime data is stored there ... or is
pointed to by that record (if you want all the online, realtime, fresh,
dynamic and/or aggregated information ... you have to read the real
"license" record).

for low value &/or low risk operations ... the static, stale copy that you
hold will be sufficient. for situations that justify the cost of an online
transaction ... to get the real-time, fresh, dynamic, and aggregated real
information ... they go online to get the real information.

somebody types in a driver's license number to the online system ... it
could just spit back just a simple yes/no regarding the staleness of the
static, r/o copy in the person's possesion. however, if somebody is going
to the trouble of going online .... they type in the driver's license
number to the online system .... and they get back the real license, with
all the real-time, fresh, dynamic, and/or aggregated information. any
information claims by the r/o, static, stale copy in the person's position
.... at that point are redundant and superfluous.

---

From: [email-masked]
Date: Sun, 5 Jan 2003 17:15:37 -0700

... aka ... i never said you can't have a certificate with r/o stale,
static subset copy of the real information ....
i just said that in an online environment whre you have the real-time,
fresh, dynamic, &/or aggregate of the
real information ... then the r/o stale, static, subset copy is redundant
and superfluous.

for a particular business/value operation, if the r/o stale, static, subset
copy is redundant and superfluous ... then it seems to follow that an OCSP
transaction giving an opinion about the staleness of tedundant and
superfluous information is also superfluous.

---

From: [email-masked]
Date: Tue, 7 Jan 2003 06:42:20 -0700

as been mentioned before ... it is relatively simple to see the information
in certificates as form of distributed read/only cache entries ... with
lots of similarities to cpu caches, database caches, filesystem caches,
distributed/network databases, distributed/network filesystems, etc.

the data in the certificates is stale by defintion ... if it wasn't ... it
wouldn't be necessary to have an OCSP that basically is asking if it is too
stale.

some ten plus years ago i was at a acm sigmod conference and asked somebody
what this x.500 stuff was ... and was told it is a bunch of networking
types trying to re-invent 1960s database technology.

random past refs:
http://www.garlic.com/~lynn/aadsmore.htm#time Certifiedtime.com
http://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds
of trust
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's
Untangling Authentication
http://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook
to SET Standard
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key?

---

From: [email-masked]
Date: Wed, 8 Jan 2003 05:37:17 -0700

on the other hand ... there some book someplace that makes the claim that
relational set the state-of-the-art back 20 years.

I was somewhat involved having done some support infrastructure for
system/r and then involved in the technology transfer of system/r from sjr
to endicott for sql/ds (before the technology transfer back from endicott
to stl for db2 .... note that SJR/bld28 & STL/bld90 are like 10 miles apart
.... with both SRJ/STL on the west coast and endicott nearly on the east
coast).

slightly related:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

some archeological tales:
http://www.garlic.com/~lynn/2000.html#18 Computer of the century
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?
http://www.garlic.com/~lynn/2001d.html#44 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#44 SQL wildcard origins?
http://www.garlic.com/~lynn/2002g.html#60 Amiga Rexx
http://www.garlic.com/~lynn/2002h.html#17 disk write caching (was: ibm
icecube -- return of
http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we
need it?
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002k.html#9 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002l.html#71 Faster seeks (was Re: Do any
architectures use instruction
http://www.garlic.com/~lynn/2002n.html#36 VR vs. Portable Computing
http://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and
literature
http://www.garlic.com/~lynn/2002q.html#32 Collating on the S/360-2540 card
reader?
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

[email-masked] on 1/7/2003 10:52 pm wrote:

I've used that explanation too :-).  The conversion went something like
this:

Other person: "Why is X.500 so special?  Why is no-one else doing this?"

Me: "Get your favourite book on database technology and look up
     'Hierarchical databases'".

[Time passes]

Other person: "I looked in several books.  Many didn't mention it at all,
               and one had a half-page historical note saying it's
something
               that was obsoleted by better technology more than two
decades
               ago".

Me: "Exactly".

Peter.

---

From: [email-masked]
Date: Wed, 8 Jan 2003 05:51:10 -0700

total trivia:
from the previous aadsm5 references to:
http://www.garlic.com/~lynn/95.html#13

two of the people in the conference room went on to the small client/server
startup involved in this thing called SSL & HTTPS ... one had been involved
in the tech. transfer from SJR to Endicott for SQL/DS and one had been
involved in the tech transfer from Endicott to STL for DB2.

Of all the people in the meeting .... I believe only one is still working
for the same employer they were then ... and that case isn't exactly
considered employee ... most recently there has been some stuff about him
getting ready to compete with some sailing team from "down under".