Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- OCSP and LDAP
- OCSP and LDAP
- OCSP value proposition
- OCSP and LDAP
- OCSP and LDAP
- OCSP and LDAP
- OCSP and LDAP
- OCSP and LDAP
- OCSP and LDAP
- OCSP and LDAP
- X.500, LDAP Considered harmful Was: OCSP/LDAP
- Kansas kicks of satewide PKI project
- Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
- A challenge
- A challenge (addenda)
- A challenge
- A challenge
- A challenge
- A challenge
- A challenge
- surrogate/agent addenda (long)
- A challenge
- Encryption of data in smart cards
- Certificate Policies (was Re: Trivial PKI Question)
- Encryption of data in smart cards
- Certificate Policies (addenda)
- How effective is open source crypto?
- How effective is open source crypto?
- How effective is open source crypto? (addenda)
- How effective is open source crypto? (bad form)
- How effective is open source crypto? (aads addenda)
- How effective is open source crypto? (bad form)
- How effective is open source crypto? (bad form)
- How effective is open source crypto? (bad form)
- How effective is open source crypto? (bad form)
- How effective is open source crypto? (bad form)
- How effective is open source crypto? (bad form)
- How effective is open source crypto?
- The case against directories
OCSP and LDAP
Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 07:52 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ambarish@xxxxxxxx, ietf-pkix@xxxxxxxx, madwolf@xxxxxxxx,
"Peter Gutmann" <pgut001@xxxxxxxx>
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 stale, static 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
stale, static information).
... i believe that the charge/cost 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 stale, static 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 stale, static data .... then it would imply that stale,
static data paradigm would be somewhat redundant and superfluous in an
online, real-time environment.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
anders.rundgren@xxxxxxxx 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
OCSP and LDAP
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 02:01 PM
To: "Ambarish Malpani" <ambarish@xxxxxxxx>
cc: "IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: RE: OCSP and LDAP
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, stale, static
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, stale, static 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, stale, static 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
on 01/05/2003 12:15 PM wrote:
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@xxxxxxxx
http://www.malpani.biz
OCSP value proposition
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 02:33 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ambarish@xxxxxxxx, ietf-pkix@xxxxxxxx, madwolf@xxxxxxxx,
"Peter Gutmann" <pgut001@xxxxxxxx>
Subject: OCSP value proposition
ok, i'm a RP sitting here with a credential that contains some
certified stale, static information .... that was designed to support
an offline paradigm.
The RP believes there is some business/value operation involved which
has some risk issues with the staleness of the information in the
certificate.
A OCSP transaction provides the RP with some feeling as to the degree
of staleness .... in theory to better mitigate risks associated with
the value operation.
My assertions are
1) a online transaction can provide real-time, fresh, dynamic, and
aggregated information (which is a superset of the stale, static
information contained in the certificate) for approximately the same
cost as a transaction about the staleness of the static certificate
information. furthermore nearly every business/value operation in
existence has some form of real-time, fresh, dynamic and aggregated
information (for those mired in certificate paradigm ... view the
online, real-time response containing this information as a one-time,
immediately expiring certificate).
2) the superset of the stale, static information with real-time,
fresh, dynamic, and aggregated information provides better quality
risk management than an opinion as to the staleness of the certificate
static information (at effectively the same cost).
3) given the same cost .... and greater value information for better
risk management .... the cost/benefit analysis would nearly always
benefit the real-time, fresh, dynamic aggregated response compare to
an opinion about the degree of static information staleness.
4) the real-time, fresh, dynamic and aggregated information
potentially provides the ability to piggy-back an actual business
transaction as part of the underlying online operation (for little or
not additional cost) .... this is the payment scenario.
5) for cost/benefit of risk management associated with real-time,
fresh, aggregated, and/or dynamic may represent such a compelling
business justification that all operations become online. For
environment with all online operations, using real-time, fresh,
aggregated, and dynamic information, then an offline certificate with
stale, static information (that is a subset of real-time, fresh,
aggregated and dynamic information) become totally redundant and
superfluous. Certificates are at least redundant and superfluous for
those transactions involving real-time, fresh, aggregated, and/or
dynamic operations (if RP is getting the real-time superset
information ... then the stale, static, subset information isn't
needed).
So the question I believe was a value proposition for OCSP that
1) involves value that justifies having online, real-time
infrastructure
2) doesn't involve payments or money (as per somebody else's earlier
posting since it has already been shown that money infrastructure does
a piggy-back transaction based on real-time, fresh, dynamic, and
aggregated information).
3) only requires an opinion as to the staleness of static information
(yes/no)
4) has no incremental business justification for real-time, fresh,
dynamic and/or aggregated information.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
OCSP and LDAP
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 02:45 PM
To: "Ambarish Malpani" <ambarish@xxxxxxxx>
cc: "IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: 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 superfluous.
I can have online, real-time, fresh, dynamic, and/or aggregated
information operation. Such information is a superset of offline,
stale, static certificate-based information. If i'm using the online,
real-time, fresh, dynamic, and/or aggregated information .... then the
offline, stale, static certificate-based information is redundant and
superfluous.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
OCSP and LDAP
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 04:50 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Ambarish Malpani" <ambarish@xxxxxxxx>,
"IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: 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 redundant and 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 for 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 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 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
stale, static copies designed for use in offline operations are
redundant and superfluous. For online operations, 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" on 01/05/2003 04:08 PM wrote:
>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
OCSP and LDAP
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 05:04 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Ambarish Malpani" <ambarish@xxxxxxxx>,
"IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: Re: OCSP and LDAP
the driver's license in your hand isn't the real driver's license
.... it is a 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 stale, static 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 stale, static,
static copy in the person's position .... at that point are redundant
and superfluous.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
OCSP and LDAP
Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/05/2003 05:15 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Ambarish Malpani" <ambarish@xxxxxxxx>,
"IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: Re: OCSP and LDAP
... aka ... i never said you can't have a certificate with stale, static,
subset copy of the real information .... i just said that in
an online environment where you have the real-time, fresh, dynamic,
&/or aggregate of the real information ... then the stale, static,
subset copy is redundant and superfluous.
for a particular business/value operation, if the stale, static,
subset copy is redundant and superfluous ... then it seems to follow
that an OCSP transaction giving an opinion about the staleness of
redundant and superfluous information is also superfluous.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
OCSP and LDAP
Refed: **, - **
From: Lynn Wheeler
Date: 01/07/2003 06:42 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Ambarish Malpani" <ambarish@xxxxxxxx>,
"IETF PKIX" <ietf-pkix@xxxxxxxx>
Subject: Re: OCSP and LDAP
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?
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
OCSP and LDAP
Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/08/2003 05:37 AM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: ambarish@xxxxxxxx, anders.rundgren@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: OCSP and LDAP
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
ptut001@xxxxxxxx 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.
OCSP and LDAP
From: Lynn Wheeler
Date: 01/08/2003 05:51 AM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: ambarish@xxxxxxxx, anders.rundgren@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: OCSP and LDAP
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 back 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".
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
X.500, LDAP Considered harmful Was: OCSP/LDAP
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/26/2003 10:46 PM
To: Dean Povey <povey@xxxxxxxx>
cc: ambarish@xxxxxxxx, anders.rundgren@xxxxxxxx,
Tony Bartoletti <azb@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"Hallam-Baker, Phillip" <pbaker@xxxxxxxx>,
pgut001@xxxxxxxx, povey@xxxxxxxx
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
my original suggestion for SSL "certificates" stored in DNS .... was
to just use signed something slightly more than signed public keys. as
opposed to full x.509 asn.1 encoded certificates ... and piggyback it
with the ip-address response. that easily fits within the 512-byte
limit. if you want additional information .... you do the more
detailed queries for the additional information associated with a
domain name ... however you don't get all the additional information
that might be bound to a domain name unless you expressly ask for it.
to some extent because certificates bind information statically at
some point in the past with possibly no real anticipation for all the
uses it might be put ... there is a tendency to try and pack as much
as possible in the static binding. going to a much more dynamic
infrastructure would mitigate significantly trying to maximize value
of a static information certificate binding (and thereby creating
worst case payload bloat for all cases).
nslookup example ...
> help
Commands: (identifiers are shown in uppercase, [] means optional)
NAME - print info about the host/domain NAME using default server
NAME1 NAME2 - as above, but use NAME2 as server
help or ? - print info on common commands
set OPTION - set an option
all - print options, current server and host
[no]debug - print debugging information
[no]d2 - print exhaustive debugging information
[no]defname - append domain name to each query
[no]recurse - ask for recursive answer to query
[no]search - use domain search list
[no]vc - always use a virtual circuit
domain=NAME - set default domain name to NAME
srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2, etc.
root=NAME - set root server to NAME
retry=X - set number of retries to X
timeout=X - set initial time-out interval to X seconds
type=X - set query type (ex. A,ANY,CNAME,MX,NS,PTR,SOA,SRV)
querytype=X - same as type
class=X - set query class (ex. IN (Internet), ANY)
[no]msxfr - use MS fast zone transfer
ixfrver=X - current version to use in IXFR transfer request
server NAME - set default server to NAME, using current default server
lserver NAME - set default server to NAME, using initial server
finger [USER] - finger the optional NAME at the current default host
root - set current default server to the root
ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to FILE)
-a - list canonical names and aliases
-d - list all records
-t TYPE - list records of the given type (e.g. A,CNAME,MX,NS,PTR etc.)
view FILE - sort an 'ls' output file and view it with pg
============================
also some discussion in rfc2151/fyi30, Internet & TCP/IP Tools &
Utilities, Section 3. Finding Information About Internet Hosts and
Domains).
http://www.garlic.com/~lynn/rfcidx7.htm#2151
2151
A Primer On Internet and TCP/IP Tools and Utilities, Kessler G.,
Shepard S., 1997/06/10 (52pp) (.txt=114130) (FYI-30) (Obsoletes 1739)
from above:
One additional query is shown in the dialogue below. NSLOOKUP examines
information that is stored by the DNS. The default NSLOOKUP queries
examine basic address records (called "A records") to reconcile the
host name and IP address, although other information is also
available. In the final query below, for example, the user wants to
know where electronic mail addressed to the hill.com domain actually
gets delivered, since hill.com is not the true name of an actual
host. This is accomplished by changing the query type to look for mail
exchange (MX) records by issuing a set type command (which must be in
lower case). The query shows that mail addressed to hill.com is
actually sent to a mail server called mail.hill.com. If that system is
not available, mail delivery will be attempted to first
mailme.hill.com and then to netcomsv.netcom.com; the order of these
attempts is controlled by the "preference" value. This query also
returns the name of the domain's name servers and all associated IP
addresses.
The DNS is beyond the scope of this introduction, although more
information about the concepts and structure of the DNS can be found
in STD 13/RFC 1034 [19], RFC 1591 [21], and Kessler [16]. The help
command can be issued at the program prompt for information about
NSLOOKUP's more advanced commands.
===
http://www.garlic.com/~lynn/rfcidx3.htm#1035
1035 S
Domain names - implementation and specification, Mockapetris P.,
1987/11/01 (55pp) (.txt=122549) (STD-13) (Updated by 1101, 1183, 1876,
1982, 1995, 1996, 2136, 2181, 2308, 2535, 2845, 3425) (DOMAIN)
http://www.garlic.com/~lynn/rfcidx5.htm#1591
1591
Domain Name System Structure and Delegation, Postel J., 1994/03/03
(7pp) (.txt=16481)
somewhat related discussions:
http://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#80 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
povey@xxxxxxxx on 1/26/2003 6:10 pm wrote:
While I don't disagree with your argument about X.500, there are real
practical problems with using DNS for storing Certificates (if that is
indeed what you mean by a DNS linked PKI). RFC2538 notwithstanding,
the problem is that storing large objects like Certificates in DNS
generally necessitates TCP transfers as they will exceed the magic 512
byte limit at which servers will generally truncate packets. Using TCP
means that DNS which is a generally stateless service, now has to keep
connection state with clients opening up all sorts of room for DOS and
simple performance problems with what is a critical service. In
addition, it is common for admins to configure firewalls so that TCP
DNS is filtered to prevent zone transfers.
Kansas kicks of satewide PKI project
From: Lynn Wheeler
Date: 01/29/2003 07:19 AM
To: Digital Signature discussion <DIGSIG@xxxxxxxx>
Subject: Kansas kicks of satewide PKI project
http://www.washingtontechnology.com/news/1_1/daily_news/19935-1.html
also
http://www.gcn.com/vol1_no1/daily-updates/21004-1.html
01/28/03
Kansas kicks off statewide PKI project
By Dipka Bhambhani
GCN Staff
Kansas today began issuing digital certificates to employees to use
with a planned statewide public-key infrastructure from VeriSign
Inc. of Mountain View, Calif.
Ultimately, Kansas plans to issue certificates to all its employees
for use on the PKI created by VeriSign Inc. of Mountain View, Calif.,
said Ron Thornburgh, secretary of state for Kansas. The statewide PKI
effort has been in development for six years with representatives from
15 organizations.
Kansas took a statewide approach to avoid having to integrate separate
systems later, said Janet Chubb, assistant secretary of state.
.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/05/2003 08:37 AM
To: Stephen Kent <kent@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, Olaf.Schlueter@xxxxxxxx,
pgut001@xxxxxxxx (Peter Gutmann)
Subject: Re: Antwort: Re: Real-time Certificate Status Facility for
OCSP - (RTCS)
i would claim in order to activate a digital signature, that the user
needs to perform the RA function ... sending a signed message
... nominally containing a copy of the public key and some other
identification information ... and this needs to be done regardless of
whether the private kye originates with the user or is pushed out to
the user. in the pre-push case, just because a private key push agency
.... also acting as a CA, happens to pre-push a copy of the
certificate prior to the RA function is an anomoly of the process.
in effect, what binds/activiates the digital signature process is the
RA operation .... not the certificate .... the existance of a
certificate is an implementation anomoly of the overall business
process.
my bias has always been that the digital signature binding process is
represented by the binding in the RA process .... independent of any
existance of a certificate used in scenarios for trusted key
distribution for offline environments ... aka the RA binding for the
digital signature proccess is independent of the existance of a
certificate as one means of representing that the RA business process
has occured. in my AADS claims, online methods of indicating that
valid RA process has been satisfied can be superior to generation of
certificates as a representation of a valid RA business process.
I would claim that the direct equating of certificates to valid
digital signatures contributes to the confusion. the RA binding
process is what is used for establishing the basis for valid digital
signatures. certificates (should be) just one method of representing
that such a RA binding business process has occured. The confusion
isn't that an agency can generate a private key and a certificate and
push both out to the end user .... the confusion is the automatic
acceptance that because a certificate exists ... it is equivalent to a
valid digital signature binding process; the certificate should be
just considered one way of representing a RA-binding process having
been performaned.
of course, random refs:
http://www.garlic.com/~lynn/x959.html#aads
as noted in other recent threads there is sometimes confusion of
asymmetric cryptography with the business processes of information
hiding/secrecy and the business process of digital signature
authentication. frequently for digital signatures, the business
process may require that the private key never be known by anybody
(and can only exist in a unique hardware token) .... while at the same
time information hiding/secrecy will require private keys be escrowed
(access to valuable corporate assets only accessable via a specific
private key will mandate escrow for business continuity purposes). the
technology is the same in both business processes .... but there are
different secrecy requirements with regard to the treatment of the
private key.
asymmetric crypto vis-a-vis public key business process
... hiding/secrecy and authentication/digital signature:
http://www.garlic.com/~lynn/2001g.html#14 Public key newbie question
http://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure)
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#78 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003b.html#30 Public key encryption
http://www.garlic.com/~lynn/2003b.html#41 Public key encryption
http://www.garlic.com/~lynn/2003b.html#64 Storing digital IDs on token for use with Outlook
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
kent@xxxxxxxx on 2/4/2003 7:02 pm wrote:
Olaf,
><SNIP>
>In Germany the german signature law is identifying a fourth case:
>4. the cert is in the repository, but not active yet (cert invalid,
>maybe valid in the future)
>
>This case is required (by law) if a CA issues not only certificates
>but private keys as well to the end user. Think of a bank producing
>and delivering a smartcard with keys and certificates on it to
>you. As long as you did not confirm the receipt of the card to the CA
>the CA must protect you by having the certificate "on hold" so during
>transport no valid signatures can be created. This may be handled by
>an "onHold" status on a CRL but is currently deployed in Germany
>using white list technology.
This seems an unnecessary complication. The CA could simply wait to
post the cert to a directory until the user acknowledges receipt.
I'm not in favor of adding complexity when there are other, simpler
solutions to a problem.
>The second reason why german electronic signature technology is
>requiring a white list check is another obligation by law, namely
>that it is not allowed to render correctly issued user certificates
>invalid due to a CA key compromise (or any other kind of CA ceases
>operation). This is again achieved with white list technology and
>status information signed by a key with independent security. RTCS
>would fit well in here.
My response to Simon addresses this issue, i.e., German law seems to
have mandated a solution to a problem that is not technically
justified, given the alternatives. PKIX is not in the habit of
setting standards to accommodate national level laws that may be ill
advised.
Steve
A challenge
From: Lynn Wheeler
Date: 02/10/2003 05:18 PM
To: "Simon Tardell" <simon@xxxxxxxx>
cc: "'Anders Rundgren'" <anders.rundgren@xxxxxxxx>,
"'Denis Pinkas'" <Denis.Pinkas@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"'Stephen Kent'" <kent@xxxxxxxx>, Olaf.Schlueter@xxxxxxxx
Subject: RE: A challenge
in fact ... any trusted source for the key can be used to validate the
signature. a major point of the certificate is a business process that
binds something else to the meaning of the signature (especially in an
offline environment when there aren't recourse to online authoritative
reference).
in the asuretee scenario ... the same hardware token (key) can be
registered (aka the registration authority business process) with
multiple different authoritative agencies .... potentially providing
different bindings for signatures based on the context that the
signature is used in.
in the encryption scenario (as opposed to the digital signature case),
the sender already needs to have a table of public keys (which may or
may not be in certificate form .... or stored already in un-encoded
form for convenient usage) ... and must select the recipient's public
key from the table.
a similar process is also possible in the digital signature case for
something like a x9.59 financial transaction .... the financial
institution can have pre-decoded the certificate and stored it in the
account record at the time the consumer registers the account. It is
then no longer necessary for the client to transmit the certificate as
part of a digitally signed x9.59 financial transaction.
discussion of previously registered certification .... as well as
(digital signature) certificates that have been compressed to zero
bytes
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 Relying-Party Certification Business Practices
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
"Simon Tardell" on 2/10/2003 8:35 am wrote:
Anders,
> To have redundant certificates in case the CA goes haywire
> seems like a very peculiar solution and will force users to
> select the proper certificate. Which is?
Not at all. A signature is made with a key, not a certificate. As long
as the identity of the certificate is not signed into the message, any
certificate that corresponds to the right key can be used to validate
the signature. The certificate may be sent with the signed message or
obtained from somewhere else. It is largely the headache of the
verifier.
The certificate that is used to verify the signature may even be
issued after the signature is made. (And in fact, this would be a
reasonable possible consequence of having CA redundancy -- after some
time it could happen that both CAs that certify a certain
key-identity-binding are replacement CAs deployed after the first
signatures were made with the card)
For some reason the common paradigm is to let users chose a
certificate associated with a key to imply the key. This practice
requires the certificate to be present at the client. Or rather, a
certificate. The certificate could be e.g. a self-signed cert (issued
by the smart card itself at production time just to supply a GUI
handle to applications looking for, and to supply a subject name for
the end entity to claim, if the application needs one). This would
remove the need to ever update the smart card. Or, as Sun would say,
the network is the computer.
Simon
Simon Tardell, cell +46 70 3198319, simon@xxxxxxxx
A challenge (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/11/2003 09:23 AM
To: "Simon Tardell" <simon@xxxxxxxx>
cc: "'Anders Rundgren'" <anders.rundgren@xxxxxxxx>,
"'Denis Pinkas'" <Denis.Pinkas@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"'Stephen Kent'" <kent@xxxxxxxx>, Olaf.Schlueter@xxxxxxxx,
epay@xxxxxxxx
Subject: RE: A challenge (addenda)
ref:
http://www.garlic.com/~lynn/aadsm13.htm#13
in fact, i would assert that is one of the short comings of mistaken
the certificate being the binding ... as opposed to representing the
business process of having done the binding.
in lots of businesses ... they will do their own binding business
process .... based on their own business requirements. that is
somewhat the appearance of the relying-party-only certificates as
opposed to the earlier, one-size-fits-all, identity x509 certificates.
the issue is that the relying-party-only certificates are very
analogous to a bank issuing a payment card .... originally one for
every account or type of account. this is in the old offline days
.... the merchant (standing in for the bank) in an offline environment
examined the card and checked it against a paper booklet negative list
mailed out once a month or so. in the transition to the online
environment, a magstripe was placed on the back of the certificate
.... and online transactions were being performed directly with the
bank. this representing somewhat of a schizophrenia identity for the
piece of plastic .... since it now carried the characteristics of
operating both in the offline environment (the plastic credential and
the paper booklet) or in an online environment (the magstripe on the
back).
From a consumer perspective ... the incomplete migration to totally
online .... has had a down side .... potentially tens of plastic cards
needing to be carried around. The magstripe is just on the verge of
not having to be unique. It still is shared-secret based (account
number and pins) which standard security requires unique shared-secret
for different security domains.
A migration to totally online and a migration to non-shared-secret
(say digital signature public key) would eliminate the security
requirement for 1) unique physical certificate/credential that is used
in offline situations by stand-in parties/merchants responsible for
examining the validity of the (plastic) certificate and 2) unique
shared-secret.
The assertion is then that a single hardware token performing digital
signature authentication can be used as binding device in multiple
different contexts (since there is not the uniqueness security
requirement that exists for shared-secret paradigms) and that the
token would only require a certificate representing each of those
binding contexts ... if the token were to be used in offline operations
(requiring validation by 3rd parties not having access to the
responsible binding authority). As long as the token was used in
online transactions involving the business process that was also the
binding authority .... or in business processes with entities that had
online access to the binding authority ... then certificates
representing such binding business processes are redundant and
superfluous.
So the scenario is some future environment that is extensively
digitally signature authentication oriented with some
token. Continuing to emulate the old offline paradigm where a unique
token/certificate exists for each context potentially means that
individuals carry hundreds of such tokens. This is somewhat analogous
to the evolving copy protection paradigm of the early 80s where each
application required that a unique floppy disk had to be inserted. If
this were to continue into todays environment an individual would
have hundreds of copy protection floppy disks .... and constantly
swapping floppy disks ... similarly one could imagine having hundreds
of hardware tokens and having to constantly swap them.
Now there is some possibility of just returning to the simple,
one-size-fits-all, identity x509 certificate. However, there is still
the idea of binding a person to a specific bank account. Just because
a person has a x509 identity certificate doesn't mean that they can
draw money from every account at every bank (or the existence of a
x509 certificate doesn't equate to being permitted to perform all
possible business operations). If there is a single certificate
... and it represents all possible binding operations ... then either
the information about all such bindings has to be carried in the same
certificate ... or the bindings have to be available at some online
location. So doing the mapping of the offline certificate paradigm to
an online binding environment .... would imply that some value from
the certificate is registered in the online binding
registry/account-record. However, if some value is to be registered
.... it is possible to have an account number and the binding registry
directly registers the public key. This bypasses the levels of
indirection involved in registering something about a certificate
which is offline representation of some other business process that
binds/registers something about the public key. If I were going
to register something about a certificate in an online binding
registry (say "is a specific entity entitled to withdraw money from
this specific bank account") .... and a public key certificate is just
an offline representation of some other online binding
registry/authority (that just possibly isn't always online or directly
accessible) ... I assert that it is possible to register the public
key directly and dispense with the levels of indirection related to
registering anything about the certificate.
So lots & lots of certificates ... each uniquely carrying some
collection of possible binding attributes (like permissions,
authorizations, etc). Or a few certificates .... that only carry a
very few binding attributes related to a public key. Then individual
operations carry online account records with the actual permissions
and a mapping to some value in a certificate. However, it is possible
in such situations to eliminate the indirection of registering the
certificate that maps to the public key ... and just register the
public key. Normally, levels of indirection help when they allow
change w/o affecting all the binding registries .... aka in the
internet domain name system .... I can use the host name www.something
... and not need to worry about it may having dozens of different ip
addresses that can change over time. However, if i'm dealing with a
certificate indirection infrastructure that I know is a direct mapping
to a single public key and the same certificate will never mask a
remapping to a totally different public key, then I can bypass the
certificate indirection and just record the public key.
One such situation would be a generic employee certificate .... there
are lots and lots of them .... all mapping to different public
keys. There is an environment that doesn't have (or need) direct
access to the online employee binding registry and only cares whether
somebody has a valid employee binding (represented by their generic
employee certificate) but doesn't actually care who the employee is
(and the situation is low-value enough that it doesn't require
real-time access to the real employing binding registry). However,
this has the down-side attribute that it represents the lots & lots of
certificate paradigm. a unique generic certificate is required for
each unique (low-value) domain (work, home, ISP login, specific
website, etc). As soon as something like ISP login requires specific
authorization information .... it is either in the certificate ... or
in an online account record. If it needs to register a unique value
from a certificate that is unique for each authorized public key
... then it can go ahead and register the public key directly and
dispense with any registering of anything related to a certificate
(and some other agency's binding operation).
An ISP family certificate would work if it listed a dozen different
public keys ... and the certificate could change the listed public
keys in a trusted and reliable way that the ISP need never be aware
that it was happening. However, in the internet domain name scenario
this works because it is an online registry .... there aren't these
offline credentials (representing the binding process) with long
lifetimes floating around that can go bad and potentially need
constant checking for revocation.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
A challenge
Refed: **, - **, - **
From: Lynn Wheeler
Date: 02/12/2003 01:47 PM
To: Torsten Hentschel <the@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, epay@xxxxxxxx
Subject: Re: A challenge
I assert that the traditional smartcards are somewhat like dinosours
... the signal just hasn't reached the brain yet.
I assert that the basic smartcard design point was during the '80s for
a portable computing device .... that predated the availability of
portable input/output capability. Basically you carried all the
computing around in the 7816 smartcard form factor and used it at
generic input/output stations. However, that market niche had
disappeared sometime in the early 90s with the advent of portable
input/output capability in the form of cellphones and PDAs. I would
guess that up to that point there had been tens of billions of dollars
in the technology that all had to be written off. To some extent the
smartcard continues on with a little bit life of its own .... in part
the investment has totally been written off .... and with zero-sum
budgetting .... even if you only could leverage the earlier investment
at a few cents on the dollar ... the technology continues to linger
around.
So one of the places to leverage essentially the 7816 investment was
supporting transferrable personality for cellphones. However, in the
past year or two there have been articles on the incremental cost that
providing such a reader represents in cellphone
manufactur. Furthermore, this transferrable personality implementation
still has several gaps .... the phone can be lost/stolen, there can be
physical/electronic failure in the smartcard, and even the contact
interface represents additional points of failure for the
cellphone. The story line went something like an online backup/restore
of the personality subsumes all the function of the smartcard as well
as addresses all the additional shortcomings .... while negating the
need for having the additional cost of the smartcard interface (as
well as eliminating a point of failure in the cellphone). The issue is
that even with only needing a few cents on the dollar (compared to the
original 7816 investment) .... the smartcard in the cellphone still
can't address all the requirements .... and the online back/restore
which does address all the requirements then, obsoletes the necessity
for the smartcard. And, as per the cellphone business discussions,
cellphone manufactures can save some additional pennies on the
cellphone manufactur as well as eliminating a point-of-failure (the
contact infrastructure for sliding the card in/out).
There is a requirement to possibly uniquely identify the use of the
cellphone. In the digital signature world ... that somewhat maps to a
hardware token with an on-chip generated key-pair .... and the private
key never leaves the device. This can be built into the cellphone
.... either as ROM in an existing chip .... or as a separate chip
somewhat like the TCPA strategy.
So a scenario is that as part of online restore into a new cellphone
.... either a previous key-pair is backed-up and restored .... or that
the device unique key is then re-registered in all the places that the
previous cell phone had been registered. And as per my previous post
in the thread ... the registration/binding business process is
actually independent of whether or not a certificate is issued ... aka
the original certificate design point (from somewhat the same '80s era
as original smartcard) was a way of representing the
registration/binding business process for an offline environment
(which had no direct access to the authoritative registry).
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
One problem is that even if the smartcard was purely restricted to the
protection and digital signature use of a private key .... there still
is the whole unresolved issue of lost/stolen devices ... and any
moving parts (even just slipping card in/out past contacts) are more
prone to failure than purely electronic operation. Note this is also
given as one of the reasons for the migration to ISO 14443 and away
from ISO 7816 is because of the mechanical failure issues
... especially in high-traffic areas. This brings up the whole issue
of possible competing contactless technologies coming to bear
.... 14443, 802.11, bluetooth, cellphone, etc.
some tcpa related discussions
http://www.garlic.com/~lynn/2002i.html#71 TCPA
http://www.garlic.com/~lynn/2002j.html#55 AADS, ECDSA, and even some TCPA
http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?
also
http://www.garlic.com/~lynn/x959.html#aads
has URL to a talk on assurance that i gave at the TCPA track at past intel developer's conference.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Torsten Hentschel on 2/12/2003 1:31 am wrote
Hi Anders,
... snip ...
> ============================================
> But frankly I see no future in smart cards of the type Germany
> is investing in. A mobile phone is such a tremendously
> more powerful "container" that allows users to do things
> that smart card owners cannot even _dream_ about. Since
> mobile phones are on-line by definition, static key and
> certificate schemes then become rather irrelevant.
> ============================================
Well, mobile phones contain smart cards, don't they?
I do absolutely not see the dead end here.
Kind regards,
Torsten
--
Torsten Hentschel
[The positions of mine as outlined above are not neccessarily
A challenge
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/13/2003 09:27 AM
To: epay@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, "Torsten Hentschel" <the@xxxxxxxx>
Subject: RE: A challenge
my previously post in this thread was more on the semantics of
certificates
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
rather than the most recent post
http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge
which is about 7816 contact smartcard. one of the issues is that 7816
also pretty much dictates the packaging and form factor. migration
away from 7816 contact to any of the contactless/wireless conventions
also can totally open up the packaging and form factor issues.
my certificate assertion wasn't that you can't have certificates
representing a binding/association registration process, my assertion
was that the certificates .... were actually that ... just a
representation of a binding/association registration process (along
with a side note that in an online environment the use of certificates
as a representation of the binding/association registration process
would frequently redundant and superfluous ... not that it wouldn't
work).
My primary points were 1) that it seems that sometimes that the
certificates are mistaken for the binding/associationr registration
business process ... as opposed to just a representation of the
binding/association registration business process (originally targeted
for recipients who would never have been involved in any
binding/assication registration business process) .... and 2) that
sometimes such semantic confusion can complicate processes with
regard to and which are addressing the binding/association
registration business process and which are addressing just the
management of things that represent that binding/association
registration business process (especially in an online environment
when having separate representations can be redundant and
superfluous).
However, just because something may be redundant and superfluous
doesn't mean that it can't work.
The issue in something like login .... is supposedly something has
been registered to allow login .... in the PKI/certificate case,
presumably what has been registered is some information that is bound
in a PKI certificate (name, serial number, etc) ... in addition, the
login process has the public key registration of acceptable
certification authorities (that can be used to validate acceptable
certificates to the login process). I've never claimed that doesn't
work ... I've just claimed that frequently it is possible to show
semantic equivalence between the login process registration of some
value out of a certificate and the login process registration of the
public key directly;
The PKI registration process provides a type of information mapping
indirection (somewhat like DNS provides a real-time mapping between
hostnames and ip-address) .... where the CA digital signature asserts
to the equivalence of the information (like a person's name or userid)
bound in a certificate and a public key. The login process then has a
set of registered CA public keys. In the PKI scenario, the login
process gets a signed message that has an appended digital signature
and an appended certificate. The login process finds the registered CA
public key and validates the certificate, it then uses the public key
in the certificate to validate the signed message. At this point it
presumably has a proven equivalence between the entity sending the
message and some bound information in the certificate (like a
name). The login process can then have its own registry that maps
between names found in certificates and userids .... and uses that to
establish a valid login for that userid. The informaiton assurance
mapping goes
I've never asserted that it doesn't work. I have asserted that in
situation where the login process has its own registery and mapping;
that directly registering an entity's public key bound to a userid
.... can be equivalent to a entity registering their public key with
a CA, the CA signing a certificate that equates a name in a
certificate with that public key, and then the login process
registering a name in a certificate bound to a userid. The issue isn't
that the levels of PKI information indirection (between public key and
userid) don't work, the point was purely that they may be redundant and
superfluous.
This is somewhat equivalent to the IETF pk-init draft for Kerberos
which provides for both certificate (aka PKI) based registration as
well as certificate-less based registration .... aka directly
registering the entity's public key. The business process of
registering a name from a certificate as equivalent to a userid
.... can be shown to be the same as directly registering a public key
as equivalent to a userid. The issue then is whether all the
additional business processes in support of the various registering
process providing information indirection between the name in the
certificate and the entity's public key provides real value or is
purely redundant and superfluous (given that there has to be a complex
infrastructure for not only creating the certificates .... but once
created these certificates now also have to be managed).
Now the intersection with certifications and smartcards (actually
hardwoare token) .... was whether there was a unique token/certificate
pair for every environment or whether there was one (or a very small
number of) token(s) could be used across a multitude of
environments. If the environment supported a registration process,
then the above assertion that public key can be directly registered
would support that the public key of a single token could be
registered in multiple environments. The counter-argument is some
future environment that has migrated to hardware token authentication
potentially requiring a unique token per environment and an entity
possibly having to manage hundreds of such tokens.
So an additional assertion is an ideal place for certificates is where
there isn't an additional registration process and the certificate is
sufficent for establishing both authentication as well as permissions
(aka all/any generic employee certificate gets an entity through the
door).
A corresponding scenario would be a system login that has no userid
directory/registration and when presented with a login message with an
attached certificate .... it is possible for the login process to
establish the complete user environment from just the contents of the
certificate (not requiring a userid directory/registration at all).
The problem is that tends to require a unqiue certificate for each
environment ... which may or may not imply a corresponding unique
hardware token. If it requires a unique hardware token, then the
future possibility is that people walk around with hundreds of
hardware tokens.
Moving it out of the digital signature domain but still in the area of
authentication might be biometrics. There is the possibility that a
login process directly registers a person's fingerprint in the userid
directory. The person then types in their userid and applies their
finger to a fingerprint sensor. I assert that the direct registration
of a person's fingerprint in a userid directory is equivalent to the
direct registration of a public key in the userid directory. However,
the downside is that a person's fingerprint is, in effect, a
shared-secret ... anybody copying the fingerprint representation and
being able to regenerate it can impersonate that entity. The upside of
public key registration is that it isn't a shared-secret, knowledge of
the public key isn't sufficient to impersonate.
So sort of a summary .... 1) understanding that the
binding/registration process is indenpendent of certificates that
represent that process can result in better designs dealing with the
two sepaate issues and 2) when there are additional registries (like
userid directories) it is possible to view certificates as a type of
information indirection and that such levels of indirection may be
redundant and superfluous (not that they can't work just that they are
redundant and superfluous).
some kerberos related threads:
http://www.garlic.com/~lynn/subpubkey.html#kerberos
and somewhat topic drift ... redundant and superfluous may represent
additional complexity and cost that are hard to justify. From recent
discussion about DNS, KISS, theory, and practice:
http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ... fyi
http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment
http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
tjones@xxxxxxxx on 2/12/2003 8:21 pm wrote:
For better, or worse, the current sc logon to o/s's uses a cert in the
sc. It could be argued that the sc really only needs to cache the
user's name in an insecure manner, but the point is that a PKI is used
to authenticate the user w/ the sc. It seems to work. It's hard to
imagine how it could be improved by some structure other than a PKI.
There is no biz rule associated w/ the authentication.
I doubt that u can argue that it does not work.
I am sure that a better sol'n is possible, that is always true.
So, let's just use sc w/ cert for logon authN. Ok? ..tom
A challenge
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/13/2003 10:22 AM
To: Al Arsenault <awa1@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
epay@xxxxxxxx, ietf-pkix@xxxxxxxx, Torsten Hentschel <the@xxxxxxxx>
Subject: Re: A challenge
the article from the cellphone manufactures .... that it was less
expensive to provide a mechanism to save the current personality and
load it into a new phone than it was to manufactur the slot for the
smartcard reader interface ... with a overall infrastructure cost
savings. the corresponding assertion was that the current smartcard &
smartcard interface was as inexpensive as it was because of the
significant investment that was made for generic, unbiquitous
smartcard use .... not solely restricted to cellphone
personabilities. and finally people could use the personality
save/restore to address issue where the smartcard is
lost/stolen/damaged.
My other assertion was that the existing operation may linger for some
time .... since the original smartcard investment has appeared to be
written off .... and smartcard use can essentially be had for a few
cents on the dollar. The transition to save/restore requires new
investment in the save/restore infrastructure .... which means that
the cost savings in eliminating the smartcard reader in cellphones
would have to cover the save/restore infrastructure investment (and/or
people find the additional benefit of having lost/stolen/damaged
coverage).
Note that the cost savings of using a common smartcard infrastructure
is so great that the cellphones and the simms share the same
manufacturing components .... down to simms being manufactured as
smartcards ... and then the simms punched out of the plastic smartcard
form factor. If the other uses of smartcards migrate to various
contactless/wireless paradigms for various reasons .... that could
mean that cellphone market segment would carry more of the smartcard
infrastructure costs (even at a few more cents on the dollar) making
it easier to justify the funding of a save/restore infrastructure
transition.
I didn't say smartcards were wrong. I said that they had a design
point based on the technology from the '80s ... and that changed by
the early '90s .... effectively making the technology assumptions and
requirements from the '80s no longer valid.
I wasn't making them (OSI comments) very loud in 1983 ... I was doing
some other things, although there were jokes about OSI being from
pre-1970s, telco, point-to-point copper, high error rate, low
bandwidth design point "people" ... aka by the time OSI standard was
passed it was also obsolete. While i was doing a little tcp/ip stuff
in the 1983 era .... it wasn't a primary focus and I didn't get
involved into any OSI issues into slightly later.
I was starting to get more vocal about OSI by possible 1985 .... I was
starting to become more vocal about it. By interop '88 I was pretty
vocal .... there were all these things in there with OSI, x.400,
complex monitoring. One of the things at interop '88 ... i would guess
that there was even some significant percentage of the IETF community
was supporting various of the alternate candidates to SNMP. I had a
couple workstations in booth kiddy-corner from the booth where case
was "officially" located ... and was able to get Case to install SNMP
on the workstations to demo .... even tho large portions of the rest
of the booths had various SNMP alternatives.
I was also on the XTP technical advisory board and working on HSP. The
majority of the people in X3S3.3 were giving us really bad time
because X3S3.3 had responsibility for standards related to OSI levels
3&4 ... and the official charter is that you can't have standards that
violate OSI levels 3&4. My response was 1) ISO & ANSI are already
totally schizophrenic because ethernet standard thru IEEE and
recognized as standard at ISO combined levels 1, 2, and part of 3
... i.e. the MAC interface includes a portion of routing from level 3.
HSP was going to go directly from transpart/level4 to LAN interface in
the middle of level3. Core X3S3.3 basically said that you couldn't
have protocol standard work in X3S3.3 that specified an interface to
MAC/LAN .... because that violated OSI. I've had more than a few
choice words about gosip also.
slightly related .... my wife and I were operating a backbone at the
time of NSFNET1/T1 bid ... and weren't allowed to bid ... but a NSF
audit of our backbone claimed it was at least five years ahead of all
the NSFNET1/T1 bids to build something new. We were also doing some
interesting/non-traditional things with crypto at the time ... but
that is another story. However we did come up also with 3-layer
architecture .... somewhat grew out of a response that my wife wrote
and presented to a certain TLA gov agency RFI for enterprise
distributed computing environment. That got us into trouble from
various factions that were trying to put the client/server genie back
into the bottle:
http://www.garlic.com/~lynn/subnetwork.html#3tier
OSI was possibly a bad choice to choose as an example. However,
something that I was really agitated about in the early 1980s
time-frame was that the traditional mainframe computing environment
was starting to commoditize .... first with mid-range computers and
then with PCs and workstations. Maybe another example is this thing
called electronic commerce.
lots of threads related to OSI "blech":
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
some recent discussions about interop '88
http://www.garlic.com/~lynn/subnetwork.html#interop
past threads about high speed networking in the '80s
http://www.garlic.com/~lynn/subnetwork.html#hsdt
http://www.garlic.com/~lynn/subnetwork.html#internet
http://www.garlic.com/~lynn/subnetwork.html#bitnet
random past specific mentions regarding gosip:
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom.
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2001e.html#17 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#6 YKYGOW...
http://www.garlic.com/~lynn/2002g.html#21 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet
http://www.garlic.com/~lynn/2002m.html#59 The next big things that weren't
http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Al Arsenault on 2/13/2003 5:43 am wrote:
Lynn,
Interesting message from you, as always. Fascinating predictions
on the future. Only a few issues need to be raised, IMHO. :-)
One of those issues relates to the whole "secure backup and
restore" or "secure download" of credentials. That's currently an
unsolved problem. Fortunately, IETF has a working group - SACRED -
addressing that issue. While SACRED started out a couple of years ago
with a lot of interest and enthusiasm, interest seems to have waned.
There are only a few people actively participating, and the group is
about to wrap up with its solution. While I am others hope that the
proposed solution will succeed and solve parts of the problem, it's
not a complete solution (e.g., it addresses only device - credential
server interactions; it doesn't support device - device operation).
So consider this message a plea for others interested in this area to
get involved in this work.
Until SACRED or some similar solution becomes widely implemented,
smartcards - e.g., SIMs or WIMs in phones - aren't going away. The
business model in many parts of the world relies on a large number of
customers replacing their handsets frequently. In many areas I'm
familiar with, it's common for a large set of people to replace their
handsets every few months, so that they always have the latest,
smallest, most colorful, "coolest" device. The whole notion of a
smart card supports this model, by allowing the user to get a new
handset and dispose of the old one while maintaining the same service
WITHOUT INTERACTING with the mobile operator, because those
interactions with the carbon-based life forms who staff the operator
outlets represent one of the highest costs in the system. With a
SIM/Smart card that can be moved from one handset to another, there's
no need to involve any other carbon-based life form. Since there's now
no way to securely move the credentials electronically that's widely
interoperable (lots of us have our own, somewhat proprietary schemes),
for most mobile operators/service providers the smart card remains the
method of choice.
An automated - read as "efficient and low cost" way to securely
register new devices into the system is also a requirement, and it's
also currently an unsolved problem. Oh, there are other standards
groups working on it, but I'm not sure they're going to have good
solutions any time soon.
So it's nice to sit here and make statements that "this technology
was just wrong, and 20 years from now everyone will acknowledge that
it's obvious", but tell me Lynn, how many statements about ISO
vs. TCP/IP did you make in 1983?
Al Arsenault
Diversinet Corp.
A challenge
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/14/2003 10:31 AM
To: Al Arsenault <awa1@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
epay@xxxxxxxx, ietf-pkix@xxxxxxxx,
Torsten Hentschel <the@xxxxxxxx>
Subject: Re: A challenge
one of the factors driving 7816 standardization/commoditization in the
'80s was that 7816 was a portable computing device ... but was
dependent upon somewhat ubiquitous deployment of (stationary)
input/output stations.
the spread of integrated portable input/output technology (cellphones
& pds) in the early '90s started to chip away at the original 7816
target market (i.e. portable computing devices w/o requirement for
ubiquitous input/output stations.
further eroding this target market is the spread of numerous
contractless/wireless technologies. a big part of the 7816
standardization was the requirement for physical interoperability
between the portable 7816 devices and the input/output
stations. contactless technologies enable arbitrary form-factors
.... further chiping away at the 7816 market segment. one of the
targets for iso 14443 is a current primary 7816 market segment,
point-of-sale .... where the contact infrastructure is showing
failures .... especially in high-traffic areas. contactless/wireless
breaks the requirement for form-factor specific implementation
(required by contact interoperability) and starts to allow
interoperability with devices regardless of their form factor.
for the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aadsstraw
in '98 timeframe, i had somewhat facetiously claimed that i would take
a $500 milspec part and cost-reduce it by two-orders of magnitude
while improving the integrity.
at an assurance panel in the TCPA track at the intel developer's
conference, i claimed that the chip met all the function/requirements
of the TPM (and was finalized much earlier) and was equivalent to the
best of integrity from gov. agencies. One of the TCPA people in the
audience commented that wasn't fair since I didn't have a committee of
200 people helping me. One of the people on the panel from a gov. TLA
replied that it was possibly true except in the area of radiation
hardening. other past tcpa related posts:
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#14 Challenge to TCPA/Palladium detractors
http://www.garlic.com/~lynn/aadsm12.htm#15 Challenge to TCPA/Palladium detractors
http://www.garlic.com/~lynn/aadsm12.htm#16 Feasability of Palladium / TCPA
http://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#63 Intertrust, Can Victor Shear Bring Down Microsoft?
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
A challenge
From: Lynn Wheeler
Date: Fri, 14 Feb 2003 11:12:15 -0700
To: epay@xxxxxxxx
Cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"Torsten Hentschel" <the@xxxxxxxx>
Subject: RE: A challenge
the point was offline from the registry
in login there is either
1) registry in the unit requiring logging in which contains a binding
between some identity and the permission's (i.e. what things can log
in and do).
2) or a purely ROM logging-in process that accepts any and all
certificates signed by some prespecified CA .... and will perform
whatever operations indicated by the certificate.
in previous posting outlining a logging in scenario where there is
some local registry in the device .... that is also certificate based
.... the local device registry has both the list of acceptable public
key certificates as well as some list of acceptable identification
information from one or more certificates. The person presents a
certificate, an attempt is made to validate the CA signature from the
list of valid CA public keys in the registry .... and then some
identification information contained in the certificate (say a
person's name) is used to look up a registry entry for "certificates"
that are allowed to log in and possibly their mapping to permissions
and authorization. The public key from the certificate can be used to
validate a signed message .... either before or after the lookup to
see if there is a userid registry entry that corresponds to some
identification field in the certificate (say person's name).
My assertion is that in the case where there is registry of valid userids
with a mapping to a value in the certificate .... the whole infrastructure
is equivalent to "information indirection" paradigm provided by the
certificate infrastructure.
Say I buy a mobile device .... and want to establish my "ownership" by
registering my certificate in the device as the true owner. So in the
device are:
1) table of CA public keys
2) certificate with my public key and maybe my name signed by one of
the CAs
3) login message
4) my signature on the login message
I assert that the levels of indirection can be totally eliminated by
instead replacing the table of CA public keys with a table of "owner"
public keys .... and mapping the table of "owner" public keys directly
to permissions.
The table of CA public keys are eliminated and replaced with a table
of owner "public keys". The registry mapping some certificate field
unique identifier to permissions is eliminated and instead the
registry of permissions are mapped directly to owner "public keys".
The information indirection provided by the CA PKI infrastructure and
the certificates are eliminated.
The issue with regard to being offline from the registry is where
there is no local registry which maps a certificate field to local
device permissions. The local device has no access to the registry
mapping certificate field to permissions ... and therefore must
totally rely on information within the certificate as to what
permissions are entitled.
This "offline" infrastructure has only a CA table of public keys in
the device. Certificates are presented signed by any of the acceptable
CAs. The device then extracts all permissions directly from the
certificate because it doesn't have online (or otherwise) access to
the registry of permissions for this device.
So my original assertion is that if the device has access (online or
otherwise) to the registry of permissions for the device .... the
indirection infrastructure provided by PKI certificate based operation
can be collapsed to replacing the CA table of acceptable public keys
with a separate registry of permissions to a single combined registry
table containing the acceptable public keys and the associated
permissions.
So looking at PKI from the reverse standpoint, a PKI is an extension
of the single combined registry table to a two level structure (in its
basic form). The simple door entry scenario previously described is a
singled combined registry table .... where the "owner" is directly
mapped to permissions. The permission "owner" is able to authorize
agents or surrogates by way of certificates. An "owner" can directly
enter by signing a message with their public key ... or they can
authorize others to enter by signing certificates containing the
surrogate/agent's public key. The door entry validates the surrogate
certificate as coming from a valid owner ... and then validates the
agent/surrogate's digital signature. The door entry system doesn't
require any access to any registry containing any information
regarding anything about the surrogate/agent.
The assertion is that anytime that the local environment needs a local
registry regarding specific surrogate/agent operation .... then the
certificates are a form of information indirection and likely
redundant and superfluous .... since the surrogate/agent's public key
can be directly added to the single permissions table. Logically
permissions are a single table. For arbritrary implementation reasons
the table of permissions for CA public keys .... may be implied
permission of only signing certificates for delegating authority to
surrogate/agents. However, the permission table may be expanded for CA
public keys to the type of delegation that specific CA can perform.
However, as soon as there has to be a local decision with regard to a
surrogate/agent permissions in a local registry directly accessable by
the device .... then I claim that the levels of indirection provided
by a certificate can be eliminated and the surrogate/agent's public
key be directly registered.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
tjones@xxxxxxxx on 2/14/2003 9:31 wrote:
Note that the point of logon is that mobile computers need to work
off-line.
So any logon proceedure needs to accomodate off-line as well as on-line.
As you point out, cert were designed in an off-line scenario. Seems to fit
the problem nicely.
If we don't have smart cards with certs in them, we need to put the cert
(binding) in every mobile device that would use that info.
That would assume that the mobile device was more secure than the smart
card/cert combo, and had more current info.
My experience w/ mobile devices, including cell phones, leads me to
believe that neither of these is true.
..tom
surrogate/agent addenda (long)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/14/2003 03:02 PM
To: epay@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, "Torsten Hentschel" <the@xxxxxxxx>
Subject: surrogate/agent addenda (long)
I claim that I can model an operational environment in terms of
entities and permissions (for simplification attributes are also
modeled as a kind of permission).
Registry is defined to be the method that an operational environment
uses to map entities to permissions. A registry may be a single
operational thing or it may be made up multiple things both explicit
and implicit.
Digital signatures and public keys are used to authenticate entities
to the operational environment. The operational environment uses
public keys in the registry to represent entities (since they are
unique to the authentication of the entity). The mapping between
public keys and permissions is a function of the registry entry.
CA/PKI further extends the kinds of permissions to "delagation". A CA
entity/public key is given the permission of delegation.
A CA uses its own registry to provide a mapping between entities,
public keys, and permissions. A CA then signs a stale, static copy of
some of the fields in its registry and calls it a certificate.
An operational environment can authenticate delegated permissions from
a signed certificate by using the public key of a CA entity from its
own registry. Just for some convention I'll call delegation entities:
surrogates/agents. Full blown PKI defines the possibility of a
multi-level delegation as a trust hierarchy.
So my repeated assertion is that if the operational environment
accesses a surrogate/agent registry entry (local, remote, online, etc)
then the corresponding surrogate/agenty certificate can be shown to
be redundant and superfluous.
So, I've managed to explain this redundant and superfluous
characteristic in a number of different ways:
1) a registry entry can contain anything that a certificate can
contain, therefor all fields that can occur in a certificate can also
be placed in a surrogate/agent registry entry. Also, for every field
that can exist in a certificate can be placed in a registry
entry. When all fields from a certificate are placed in a registry
entry, the certificate can be compressed to zero bytes. These
certificates aren't actually redundant and superfluous, they are just
zero bytes.
2) the creation of a registry entry for a surrogate/agent is
equivalent to a registration authority business process. anything that
is done during a CA's RA process can be done during the creation of a
registry entry for the surrogate/agent. If necessary, this can be
viewed as caching the certificate in the surrogate/agent registry
entry. Then while the certificate isn't strictly redundant and
superfluous, any transmission of the certificate is redundant and
superfluous since the operational environment already has access to
the cached entry. This is especially useful when the inclusion of a
certificate in a transmission represents a painful bloating of the
total transmission size.
3) when there is a directly accessable registry entry (local, remote,
online, etc) for a surrogate/agent, then the certificate may just
represent information indirection .... somewhat like DNS system
mapping of hostname to ip-address. the registry entry contains some
value that can be matched to a field in the certificate. This provides
a indirection mapping between the permissions in the registry entry
and the entity's public key in the certificate (authenticated &
deligated by the CA signatures and the CA entry in a directly
accessable registry entry). However, since any value that can occur in
a certificate can also be placed in the registry entry, the public key
from certificate entry can be directly placed in the surrogate/agent
registry entry, eliminating the indirection provided by the
certificate and making the use of the certificate redundant and
superfluous.
4) an operational environment may require direct access to a
surrogate/agent registry entry (local, remote, online, etc) because of
permissions expressed in terms of aggregation information (information
that is maintained in the registry entry that represents information
aggregation and is a difficult paradigm for a stale, static
certificate) or permissions expressed in terms of real-time or near
real-time information (again difficult paradigm for a stale, static
certificate).
5) If a stale, static certificate provides an identifier that is used
to index a surrogate/agent registry entry (local, remote, online, etc)
then it is also possible to include the same identifier as part of the
message digitally signed by the surrogate/agent. As before, such a
surrogate/agent registry entry can include anything that a certificate
can include, including the public key of the surrogate/agent. By
directly placing the public key in the surrogate/agent registry entry,
and directly accessing the surrogate/agent registry entry using an
identifier from the signed message, then the signed message can be
authenticated using the public key from the directly accessed
surrogate/agent registry entry. The directly accessed surrogate/agent
registry entry can contain any other field that might exist in the
certificate, including all possible permission values. Since the
digital signed message can be authenticated without having to resort
to the certificate and since the directly accessed surrogate/agent
registry entry can contain any field that a certificate can contain,
the stale, static certificate transmitted as part of the message is
redundant and superfluous.
The simplest scenario for a stale, static certificate is in an
operational environment that only accesses a CA delegation registry
entries and permissions are solely established on the basis of the
contents of the CA registry entry and the contents of the
certificate. This is the employee certificate that is used for door
entry. The door entry operational environment only contains the public
key of one or more CAs. The door is opened purely based on being able
to validate the CA's signature on the certificate and then validate
the employee's signature using the public key in the certificate. For
opening the door, there is no recourse to any employee specific
entry. This is the typical "offline" door operation typical of low
value situations. Higher value door operations tend to be "online" in
the sense that they directly access employee specific registry
information. Such online permission entry can be based on timely
information (like has the employee been fired within the past couple
hours) or aggregation (what other things has the employee done in the
recent past). It is in the accessing of the employee registry entry
(local, remote, online, etc) for timely and/or aggregated information
that makes the use of the stale, static certificate redundant and
superfluous.
Similarly a portable device can either be "offline" in the sense that
its operation is totally determined from just a CA public key registry
and a stale, static certificate (and doesn't have direct access to the
surrogate/agent registry entry). Lets say there are large number of
"public" portable device and anybody can utilize any device so long as
they have a valid certificate for device useage. However, a
certificate can become redundant and superfluous if the device has a
surrogate/agent specific registry entry that it references (since it
is possible to register any information that might be found in a
certificate, in a surrogate/agent registry entry). A portable device
that might contain a surrogate/agent specific registry entry might be
a owner-specific paradigm (i.e. the surrogate/agent registry entry in
the device corresponds to the owner). A onwer-specific paradigm could
be implemented with certificates if the certificate contained the
device specific identifier. The device would only work when a
certificate was presented that contained the device-specific
identifier in one of the certificate fields.
Lets say we are looking at a hardware token implementation as keys for
automobiles. For an owner specific paradigm there can be a
certificate/PKI based implementation or a certificate-less based
implementation. In the PKI-based implementation the automobile's
internal permission registry table contains one or more CA public
keys. The car starts for any hardware token that has a digital signed
certificate that specifies the specific automobile serial number and
authenticated by any of the CA public keys (and of course the hardware
token signs a valid message that is authenticated from the public key
in the certificate). The certificate-less implementation replaces the
CA public keys in the automobile's internal permission registry table
with public keys of the owner's hardware tokens. Then only the
directly listed hardware tokens are able to start the automobile. In
the certificate-less scheme, there would be a administration mode used
in conjunction with a valid hardware token to add/delete public keys
in the automobile's registry.
In the PKI-based implementation for "owned" automobile operation, it
becomes somewhat more problamatical to invalidate hardware tokens (aka
certificates) for the automobile. One method would be to create
registry entries for invalidated certificates (aka public key/hardware
token). However, I would assert as soon as surrogate/agent specific
entries are required for invalidated public keys .... then the
infrastructure has been established making certificate-less operation
KISS (aka stale, static certificates being redundant and
superfluous). Just create a positive list/registry of public keys
.... possibly totally eliminating the delegation permission associated
with CA public keys. The automobile registry than has permissions
like administrative mode, start automobile, open trunk, open doors,
etc for each public key (aka hardware token).
It is problamatical whether CA public keys would be retained in the
automobile registry solely associated with manufacture and service
operation. Standard automobile operation would be straight
certificate-less with the owner's hardware tokens being directly
registered in the automobile's registry table. However, there might be
non-ownership related permissions like various service
operations. There could be a manufacture CA delegation permissions
associated with service operation and independent of automobile
serial/identification. The manufacture's public key would be in the
automobile's table with delegation permissions. The manufacture would
sign public key certificates for service operations, enabling service
specific permissions for all cars from the manufacture.
However, CRLs really become a nightmare in this situation. I would
contend that a much KISS solution is that the service operation goes
online with the manufacture (in much the same way that POS terminal do
online transaction) and that the automobile authenticates the service
operation by accessing the manufacture's online database. The
manufacture's public key is still in the automobile registry .... not
for purposes of validatting certificates but for purposes of
validating online communcation with the manufacture for authentication
of real-time service organization delegation. As a result, the
operation is online with direct access to registry entries for service
organizations and therefor service organization certificates are
redundant and superfluous.
past references regarding compression of certificates to zero bytes:
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
past references to methodology of registry operation caching certificate kind of information (making certificate transmission redundant and superfluous)
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm4.htm#8 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC)
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
http://www.garlic.com/~lynn/2003.html#52 SSL & Man In the Middle Attack
past discussions of stale, static certificate issues vis-a-vis aggregated/timely information:
http://www.garlic.com/~lynn/aadsmail.htm#vbank Statistical Attack Against Virtual Banks (fwd)
http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs
http://www.garlic.com/~lynn/aadsmore.htm#client2 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsm2.htm#arch4 A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aadsm2.htm#availability A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aadsm2.htm#mauthauth Human Nature
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm4.htm#01 redundant and superfluous (addenda)
http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
http://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki24 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsmail.htm#variations variations on your account-authority model (small clarification)
http://www.garlic.com/~lynn/aepay2.htm#aadspriv Account Authority Digital Signatures ... in support of x9.59
http://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS
http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#x9flb12 LB#12 Protection Profiles
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay6.htm#dspki3 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
http://www.garlic.com/~lynn/aadsm12.htm#20 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt
http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#0 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#2 OCSP value proposition
http://www.garlic.com/~lynn/aadsm13.htm#3 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#6 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
http://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/98.html#0 Account Authority Digital Signature model
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#42 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
http://www.garlic.com/~lynn/2001.html#67 future trends in asymmetric cryptography
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#40 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
A challenge
Refed: **, - **, - **
From: Lynn Wheeler
Date: 02/16/2003 05:56 AM
To: Al Arsenault <awa1@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>, epay@xxxxxxxx,
ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx,
Torsten Hentschel <the@xxxxxxxx>
Subject: Re: A challenge
somewhat addenda to question about '83 OSI .... while iso/x3s3.3
couldn't have a work item for standard that violated OSI (i.e. HSP,
high-speed protocol .... direct from level4/transport to LAN/MAC
interface which sits in the middle of level3/network) .... x3s3.3
could have a work item that studied HSP.
note also that IP also violated OSI ... since it is a layer that sits
between level4/transport layer and level3/network layer .... the
inter-networking layer. however, IETF doesn't have any qualms about
having IP interface directly to LAN/MAC.
as before ... internet archeological references fro