[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OCSP and LDAP
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.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
"Anders Rundgren"
<anders.rundgren@ To: "Ambarish Malpani"
telia.com> <ambarish@xxxxxxxxxxx>,
<lynn.wheeler@xxxxxxxxxxxxx>
01/05/2003 04:08 cc: "IETF PKIX" <ietf-pkix@xxxxxxx>
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