Hi,
  I have a situation. We need to encrypt database connection information
like server name, user id and password. I was thinking of X509 digital
certificate and cryptography. Unfortunately this should work as a offline
solution. I have used digital certificates that was verified by certificate
authority. Being an offline solution I dont know if the X509 digital
certificate can be used by cryptography services to encrypt. Can anyone help
me please, or suggest me a good way to encrypt user id and passwords in a
offline solution.

Thanks,

Hello Gaja,

what do you mean by offline? client and CA don't have a network connection??

This is not an issue, you don't need a network connection for encryption.
The only thing that could happen is, that if you validate certificates, the
APIs want to connect to the CA to retrieve an online CRL (Certificate Revocation
List) - but you can control that via attributes in CAPICOM or X509Chain (.NET
2.0).

just try it :)

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

Show quoteHide quote

Hi Dominick,
    Yes, the client will not have a network connection to the CA, the reason
why using the certificate as encryption key is a challenge.

    I am limited to .NET 1.1 at this point, so using 2.0 is not an option.

Thanks,

Show quoteHide quote

Hello!
You wrote  on Sat, 6 Aug 2005 10:22:03 -0700:

G>     Yes, the client will not have a network connection to the CA, the
G> reason why using the certificate as encryption key is a challenge.
G>     I am limited to .NET 1.1 at this point, so using 2.0 is not an
G> option.

Take a look at PKIBlackbox (freeware, http://www.eldos.com/sbb/desc-pki.php)
then. It provides support for X.509 certificates and CRLs.

With best regards,
Eugene Mayevski

Hello Eugene,

or use CAPICOM - a COM wrapper for CryptoAPI from Microsoft.

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

G>> Yes, the client will not have a network connection to the CA, the
G>> reason why using the certificate as encryption key is a challenge. I
G>> am limited to .NET 1.1 at this point, so using 2.0 is not an option.
G>>
Show quoteHide quote

I just wonder how could people trust their secrets to some propriatery
"blackbox" only because provided free binaries?!?

Like, hey - how in the word do you know that the next version of that
"blackbox" would not send our your secrets to Ukranian mafia or something
(in case if current version doesn't do that already)?
Not speaking of the fact that whole solution was designed by people with
clearly unsuficient previous experience in cryptography...

If I need to trust someone -
I trust Phill Zimmermann, or Eric Yong/Tim Hudson. (esp. because I can see
the code).
I can trust Microsoft's binaries - they has too much public attention to
openly screw their cryptographic solution.

....but to some "blackbox" from a person that only two years ago wrote that
"the certificate contains a public key, which is later used by the client to
sign a session key"... (the link could be provided on request, or just
search google for quoted excerpt).

-Valery.
http://www.harper.no/valery


Show quoteHide quote

Gaja wrote:
the whole point of digital certificates was to provide authentication
in an offline environment where the two parties had no previous
communication. it is usually possible to trivially demonstrate that in
any kind of online environment and/or environment where the parties
have existing, ongoing relationships ... that digital certificates are
redundant and superfluous.

the core technology is asymmetric key cryptography ... a pair of keys,
what one key encodes, the other (of the key pair) decodes. This is in
contrast to symmetric key cryptography where the same key both encrypts
and decrypts.

a business process has been defined call public key ... where one of an
asymmetric key pair is labeled as public and made freely available, the
other of the key pair is labeled private, kept confidential and never
divulged.

another business process has been defined called digital signature.
basically callculate the hash of a message or document and encode it
with a private key. The message and digital signature are transmitted
together. The recipient recalculates the hash of the message, decodes
the digital signature (with the corresponding public key) and compares
the two hashes. If they are the same, then the recipient can infer:

1) the message hasn't been altered (since the original digital
signature)
2) "something you have" authentication, aka the digital signature
originated from somebody that had access and use of the corresponding
private key

in the case where parties have ongoing relationship ... they can have
the other party's public key stored in their trusted public key
respository. in the online situations, parties may have online access
to trusted repository of public keys. In either case, there is no need
to have digital certificates.

Digital certificates are a business process to somewhat to address the
"letters of credit" authentication paradigm from the sailing ship days.
They were targeted at the offline email environment of the early 80s,
the local (electronic) post-office was dialed, email exchanged,
connection hung up ... and the recipient then might be dealing with
first time communication from a complete stranger.

The solution (from the "sailing ship" days before electronic, online
communication) was to have individuals extend their trusted public key
repositories to include the public keys of Certification Authorities.
Strangers now take information, their public key (and hopefully proof
they have access to the corresponding private key) to a certification
authority. The certification validates the supplied information and
creates a digital certificate that contains the person's supplied
information and their public key ... which is digitally signed by the
Certification Authority.

Now in the case of first-time communication from a complete stranger,
they digitally sign the message, and transmit the message, their
digital signature and the digital certificate (they acquired from the
certification authority).

The recipient, instead of directly verifying the stranger's digital
certificate (using a public key from their trusted public key
repository), verifies the certification authority's digital signature
(on the supplied digital certificate) using the certification
authority's public key (which has hopefully been preloaded into the
recipient's trusted public key repository). If the certification
authority's digital signature verifies (on the supplied digital
certificate), then the recipient can take the originator's public key
(from the supplied digital certificate) and use it to verify the
digital signature on the message.

The objective is that the recipient can trust the certification
authority's digital signature and also finds the ancillary information
in the certificate (and certified by the certification authority)
meaningful and useful.

One of the problems from the early 90s was that of what information
might be useful in an x.509 identity certificate. In most cases, the
certification authorities wouldn't know who the future recipients a
stranger might wish to communicate ... and therefor what information
that they might find useful. There was some direction to grossly
overload the x.509 identity certificates with enormous amounts of
personal information.

By the mid-90s, some institutions were starting to realize that x.509
identity certificates, grossly overloaed with personal information
represented significant privacy and liability issues. As a result, you
saw some institutioins retrenching to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

basically containing some sort of database lookup value and a public
key. The recipients were also the certification authority, they
basically registered an individuals public key in an existing online
institutional relationship management infrastructure and issued a
digital certificate containing an index to the corresponding entry in
the relationship management infrastructure.

the issue was that it became trivial to demonstrate that
relying-party-only certificates were redundant and superfluous, in part
because they violated the basic original premise justifying digital
certificates ... first time communication between two strangers. more
fundamentally, it was trivial to show that the recipient
(relying-party) already had all the information contained in the
digital certificate ... and therefor the digital certificate provided
no information that the recipient didn't already have.

another aspect, was in some of the financial transaction scenarios, the
replying-party-only certificates also represented enormous payload
bloat (in addition to being redundant and superfluous). A overhead for
a typical relying-party-only certificate of the period could be 4k-12k
bytes. The typical financial transaction message size is on the order
of 60-80 bytes. The payload bloat overhead of appending
relying-party-only certificates to such messages was on the order of
one hundred times (for something completely redundant and superfluous).

To address this issue there was some activity to define a compressed
digital certificate (hoping to get into the 300-600 byte range). In
this particular situation, instead of showing that it wasn't necessary
to append a redundant and superfluous relying-party-only digital
certificate ... it was possible to demonstrate that a perfectly valid
compression technique was to eliminate all fields from the digital
certificate that were known to be in the possession of the recipient.
Since it could be demonstrated that all fields in a digital certificate
were already possessed by the relying party, it was possible to
compress such a digital certificate to zero bytes. So rather than
demonstrating that it was necessary to append a redundant and
superfluous digital certificate ... it was also possible to demonstrate
that a zero-byte digital certificate could be appended.

<l***@garlic.com> wrote in message
Show quoteHide quoteLynn,
Cool to see you in microsoft.public.dotnet.security :D



The fact that PKI failed to be universal solution to secure communication,
doesn't diminish fact that PKI has certain quite tangible value for certain
scenarios, like supporting Enterprise wide key-management and secure
communications related tasks. There are plenty situation when non-PKI
key-management infrastructures and protocols simply can't be used due to
inherent limitations -- e.g. Kerberos fails to work with occasionally
connected systems (e.g. connected once per week or so).


-Valery.

http://www.harper.no/valery

Valery Pryamikov wrote:
there are lots of scenarios where it is possible to have institional
management of public keys for authentication purposes ... especially as
part of overall online operational infrastructure.

PKI, certification authorities, and digital certificates ... were
specifically designed to address the offline, disconnected, first-time
communication between strangers where the recipient (relying-party) had
no other recourse about information.

The original pk-init draft for kerberos just had public keys registered
in lieu of passwords ... and performing digital signature verification
(in lieu of password comparison). It wasn't until later that they also
allowed for entity totally unknown to kerberos to be able to present a
digital certificate as part of authenticated to kerberos.
http://www.garlic.com/~lynn/subpubkey.html#kerberos

Possibly one of the most prevalent internet oriented authentication
function is radius (i.e. in use by the majority of ISPs for
authenticating their clients when they connect). This has been
primarily a password based infrastructure ... however there have been
radius enhancements where public keys are registered in lieu of
passwords and digital signature verficiation is done in lieu of
password checking
http://www.garlic.com/~lynn/subpubkey.html#radius

in both cases it is possible to integrate public key authentication
into the permission and overall relationship management infrastructure
w/o having to resort to a redundant and superfluous, duplicate
relationship management infrastructure represented by PKI,
certification authorities, and digital certificates.

The basic issue issue for public key and digital signatures is
straight-forward authentication ... integrated into overall existing
business practices that manage the entity, their access, their
permissions, etc.

Typically, PKIs have represented independent infrastructures,
independent of overall system operation. However, it is possible to do
straight-forward public key and digital signature authentication
integration into existing infrastructures w/o having to resort to
redundant and superfluous PKIs, certification authorities, and digital
certificates.

A simple sanity check:

if the system infrastructure has some table of entities along with
related authorizations and permissions ... that is critical to the
operation of the system ... then it is possible to add public key and
digital signature verification to that infrastructure w/o having to
resort to an independent PKI, certification authority, and digital
certificates.

the PKI, certification authority, and digital certificates were
targeted at infrastructures that didn't have existing relationship
management infrastructures. a sanity test of whether or not a PKI is
redundant and superfluous ... is if the digital certificate provides
all the necessary information to the operating infrastructure (all
entity information, all permissions, all access control, all
authorization) w/o the operating infrastructure needing to reference
any other information ... then the digital certificate, certification
authority, and PKI isn't redundant and superfluous.

If the operating infrastructure simply uses information in a digital
certificate to reference (the "real") repository of entity,
permissions, authorizations, and/or access control ... then it is
usually trivial to demonstrate that the digital certificate is
redundant and superfluous (usually by showing that the public key can
also be registered in such a respository). Showing that the digital
certificate is redundant and superfluous ... then it will follow that
the certification authority is redundant and superfluous and also PKI
is redundant and superfluous.

<l***@garlic.com> wrote:
Show quoteHide quoteI always enjoy reading your posts in sci.crypt and cryptography mailing
list! I know your position regarding PKI and I know that you are really good
argumenting your points. There is no doubt that PKI dream as such has failed
to fulfill its purposes. That if you look at each concrete function
supported by PKI - it is always possible to find some better solution...
However, one thing that is very important with PKI is its "standard" part.
It's just as with any other standards. like take for example XML. Is XML the
best possible way of solving problems of semi-structured data on the web?
Absolutely not! It has lots of drawbacks, starting with inability to simply
combine multiple documents into one single document by concatenating them
together... It's easy to argue that XML is over-engineered and too damn
complex (just as it is with PKI). However, whenever we talk about whether or
not we should use XML in real-life applications - the answer is definite
Yes! . Because being a standard gives a lot of ready to use tool, solutions
and practices for solving problems much easier, faster and reliable than it
would be with any home-made replacement of XML regardless of how good this
home-made solution would be at solving some of the drawbacks of XML...

The same thing concerns PKI. It's not perfect; it failed to fulfill PKI
dreams started by Kohnfelder's thesis. One of the biggest problems is that
there is no such thing as universal trust and PKI simply failed to be
adjustable to wide and complex model of trusted/semi-trusted relations of
reality. However it is good in close environment involving several trusted
parties and/or as enterprise-wide Keys Infrastructure solution. And being a
standard is actually a very positive part! If I would have to choose between
two solutions, where the first relies on PKI and other relies on home-made
protocol, I would without a doubt choose former as long as later doesn't
rely on some proven standard (or backed by a well earned reputation). Big
problem with insecurities of nowadays software solution is that it is too
common for most of developers to downplay complexities of designing secure
protocols/security solutions. When I see home-made solution with proprietary
secure protocol, that just gives me shivers and I always advise to stay as
far away from them as possible. However, when developer is given standard -
they will try to rigorously follow it (esp. when they are not very
proficient with underlying mechanisms <grin>).

So, my point is that it is very good to argue against standards (and PKI
particularly) in academic groups - that will ensure that newer and better
standards will be developed later-on. But it is different thing to advice
against using standards in programmers groups without providing proven and
feasible alternatives, because that could negatively affect security of
future software systems.



-Valery.

http://www.harper.no/valery

Valery Pryamikov wrote:
the issue isn't arguing against standards ... the issue is explaining
the fundamental design point of tools ... so if you are finding it
difficult to tighten a nut with a hammer ... you understand that the
hammer was met for hammering nails ... not tightening bolts.

i've seen numerous situations where somebody esposes PKI as the answer
before even knowing what the problem is.

A trivial scenario is that there are lots of standards & actual
deployments involving digital signatures w/o certificates; in fact, one
can claim that the fundamental underpinnings of PKIs involve layering
certificates on top of underlying digital signature standards (that are
certificateless).

If you are using tools ... it can assist if you understand the
fundamental functioning of the tools. basic digital signature standards
(w/o certificates) allow ("something you have") authentication between
two parties.

certificates & PKI were layered on top of the underlying digital
signature standard ... to address the scenario with first time
communication between strangers.

There have been attempts to expand digital certificate use so that they
were required for all authentication. This resulted in lots of hype and
promise ... but also significant numbers of unsuccesful deployments. I
claim that the unsuccesful deployments weren't short-comings in the
technology ... it was attempting to use a tool for something that it
wasn't intended to be used for. Putting it another way ... there were
fundamental business process conflicts attempting to use a tool for
something it was never designed to do (like using a hammer to tighten a
nut).

the original question implied a question about the business process
applicability of using digital signature in offline situations... as
opposed to the environment they have been used to. understanding the
nature of the tool can help in understanding its applicability to
different situations.

recent related postings from cryptography mailing list.
http://www.garlic.com/~lynn/aadsm20.htm#29 How much for a DoD X.509
certificate?
http://www.garlic.com/~lynn/aadsm20.htm#30 How much for a DoD X.509
certificate?
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love

<l***@garlic.com> wrote:
It's a bit embarrassing for me to admit that until now I didn't even check
the original question ;-). But I don't think it was question about business
process applicability, but rather a sign of complete misconception. My
understanding of original question is that op was asking about a way of
protecting piece information that is used by some service (daemon) from
everyone else using this computer, including administrator/root (because if
it was only about protecting against unprivileged users of this computers -- 
simple access control would be more than enough). Of course PKI is
completely irrelevant here!... but any other encryption related technology
is irrelevant here as well... Since service/daemon requires protected
information in clear text, which means that decryption key must be
accessible to that service on that computer, but that automatically makes
this secret key to be accessible to administrator/root of this computer as
well. The op's problem as it is, is more close to DRM than to anything else
(i.e. store secret key, and cipher text in one place and hope that nobody
will be able to put them together).

I also think that X509 certificate appeared in the original question due to
simple fact that many people was introduced to encryption by it's appliance
to e-mail and unfortunately, there are many people who's understanding of
encryption didn't evolved much further than that <grin>.



great posts! I've read them earlier this week+last week (when you posted
them to cryptography mailing list). I really appreciate you posting great
stuff.



-Valery.

http://www.harper.no/valery

Valery Pryamikov wrote:
Show quoteHide quoteremember in my context, i described asymmetric cryptography as
technology and
public keys, digital signatures and PKIs as all business processes
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for
offline solution
http://www.garlic.com/~lynn/2005n.html#43 X509 digital certificate for
offline solution

.... so a case study from another PKI scenario where the relying-party
is offline and/or doesn't have realtime direct contact with the
certification authority (which somewhat turns out to actually be the
original design point for PKIs ... the offline situation where the
relying-party doesn't have realtime, online and/or local resources for
resolving information regarding first time communication with a
stranger).

crica 1999, one of the major PKI certification authorities approached a
large financial operation and convinced them that they needed to deploy
a PKI infrastructure enabling their customers to do online, internet
account transactions. This was a financial operation that had
significantly in excess of 10 million accounts.

the scenario went:

1) the financial institution would register a customer public key for
every account

2) the financial institution would transmit the resulting updated
account database to the certification authority

3) the certification authority would munge and re-arrange the bits in
each account record ... producing one digital certificate for each
account record.

4) after a couple hrs, the certification authority would return all the
recently produced digital certificates to the financial operation ...
which would then store them in the appropriate account record and
convey a copy to the appropriate customer

5) the customers would then generate digitally signed account
transactions, package the account transaction, the digital signature
and their copy of the digital certificate and transmit it over the
internet to the financial operation.

6) the financial operation would pull the account number from the
transaction, retrieve the corresponding account record, verify the
digital signature using the public key in the account data base ... and
NEVER have to make any reference to the digital certificate at all

the financial operation had spent nearly $50million on integrating a
PKI infastructure when it dawned on somebody to do the complete
financials.

they had already agreed that the certification authority would get
$100/annum/account for the production of (redundant and superfluous)
digital certificates that need NEVER actually be used.

doing the complete financials resulted in somebody realizing that the
financial operation would be paying the certification authority
$100m/annum per million accounts (or $1b/annum per 10 million accounts)
for redundant and superfluous digital certificates that would NEVER
actually be used ... aka certificateless operation (other than the
internet payload for continously transmitting the
digital certificates hither and yawn)
http://www.garlic.com/~lynn/subpubkey.html#certless

the financial operation eventually canceled the project and took the
$50m hit.

this was actually a relying-party-only certificate scenario
http://www.garlic.com/~lynn/subpubkey.html#rpo

where the operational account contains all the information about the
entity and the entity's public key (as well as copy of the entity's
public key and a stale, static copy of a subset of the entity's
operational information in the form of a digital certificate).

this is offline, from the standpoint of the relying-party not needing
to contact the certification authority when processing a digitally
signed transaction ... in part, because the relying party actually has
all the real-time operational information as part of executing the
transaction (and NEVER actually needs to reference the redundant and
superfluous, stale, static digital certificate).

however, the certification auhtority was originally expecting to be
paid $100m/million-accounts (well in excess of billion dollars) per
annum for the redundant and superfluous, stale, static (and need NEVER
be referenced) digital certificates.

now, a number of operations have used tamper-resistant hardware tokes
(USB dongles) as repository for protecting the confidentialty of
private keys. This becomes truely a "something you have" operation ...
since the hardware tokens perform operations using the embedded private
key ... but the private key never exists outside of the confines of the
token.

human operators and other agents can still compromise any system useage
involving the private keys ... which is an overall system security
integrity issue. however, the private keys are never divulged ...
eliminating the system security confidentiality issue with regard to
the private keys ... and crooks can't obtain the private keys and setup
a counterfeit operation impersonating the original system (possibly
unknown to the original operation).

this is my frequent refrain that most operations treat public key
operation as a "something you have" authentication ... aka the party
has accesws and use of the corresponding private key. When purely
software implementation is used ... there typically are attempts to
closely emulate real hardware token operation ... however software
emulation of hardware tokens have several more threats, exploits and
vulnerabilities compared to real hardware tokens.

one way of looking at this issue is where does the security perimeter
lay. the security perimeter for a hardware token ... tends to be the
physical space of the token. the security perimeter for a software
emulated hardware token may be all the components of the computer where
that software is running.

for financial environments ... like PIN-debit ... there are external
tamper resistent hardware boxes that do all PIN related processing for
the financial institution. PIN are entered in the clear at POS
terminals and ATMs ... but then immediately encoded. From then on, they
never appear in the clear. the backend gets the transaction and sends
it to the box .. and gets back some answers ... but standard operation
never sees the PIN in the clear.

the (security) integrity of the backend systems might be comprimized by
insiders ... but you don't find insiders harvesting PINs from the
backend systems (i.e. security confidentiality) and using them in
impersonation attacks with counterfeit transactions.

part of this is that security integrity compromises tend to be a lot
more difficult than security confidentiality compromises (copying the
data). security integrity compromises also tend to leave a lot more
traces back to the people responsible ... compared to security
confidentiality compromises.

one of the claims that we've frequently made with respect to aads chip
strawman
http://www.garlic.com/~lynn/index.html#aads

for public key operation, was being free from having to worry about the
ins & outs of PKIs and digital certificates .... we were able to
concentrate on the fundamental threats and vulnerabilities of the
actual operation of public key processes. For instance, a very
fundamental threat and vulnerability is the integrity and
confidentiality of the private key. If i was looking at wanting to pay
$100/annum on stuff associated with public key operation ... I might
consider it much better spent on hardware tokens than on digital
certificates.

in fact in the security proportional to risk scenarios ... slightly
related (i.e. grading the integrity levels of hardware tokens for use
with operations involving different levels of risk) ... slightly
related
http://www.garlic.com/~lynn/2001h.html#61

i.e. we've take it as a given that the integrity of the
originating/remote environment is taken into account when evaluating a
transaction for authorization. this includes the risk level associated
with whether or not a real hardware token is being used and if a real
hardware token is being used ... the evaluated, integrity of that token
(which might change over time as technology changes). For a large
percentage of the business processes in the world, we assert that the
integrity level of the remote end is of more importance the a lot of
personal information about the remote entity (which the vast majority
of operations already have on file ... so it is of little interest to
duplicate such information in digital certificates).

so another simple test ....

i would assert that the integrity level of the originating environment
(software token or hardware token and the assurance level of such
token) is one of the primary pieces of information that would be of
interest to a relying-party ... right up there with what is the public
key. so a real buisness oriented digital certificate would not only
give the public key ... but also provide the integrity level of the
environment protecting the private key.

when i examined x.509 fields several years ago ... i couldn't find one
that provided the integrity level of the private key protection
although some have simple flag that can be used to indicate whether it
is software private key or hardware token private key. how many
certification authorities have you heard of that have a process of
checking whether they are certifying a software private key or a
hardware token private key?

the literature has lots of stuff about the integrity level of
public/private keys based on the number of bits in the key ... but I
haven't seen anything on the integrity level of private key protection
.... and/or writeups on applications that even make decisions based on
whether they find they are dealing with a software private key or a
hardware private key.

another indication was a couple years ago, i was giving a talk on the
importance of the privatey key protection integrity level ... and
somebody in the audience (from some gov. agency) said that if i would
provide the full definition they would see that it was added to x.509v3
standard.

<l***@garlic.com> wrote:
Show quoteHide quoteThis is really interesting case study that clearly demonstrated problem of
misplaced trust and dirty play of that "one of the major certification
authorities"...

For all means, financial institution could have set up their own CA for that
project... and of course blind signatures could pass better for
relying-party-only scenarios... but I don't know about their options to
license blind signatures at that time ( great that the patent expired now
-Valery.
http://www.harper.no/valery

Valery Pryamikov wrote:
ref:
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for
offline solution
http://www.garlic.com/~lynn/2005n.html#43 X509 digital certificate for
offline solution
http://www.garlic.com/~lynn/2005o.html#2 X509 digital certificate for
offline solution

but an extremely fundamental characteristic is that setting up a
certification authority serves no useful purpose.

it wasn't a case of misplaced trust ... there was absolutely no
requirement for trust propogation (represented by the existance of a
digital certificate, certification authority, and PKI).

an extremely fundamental principle of PKIs and certification authority
is a trust concept, involving trust propogation, where one party is
certifying information for the benefit of other parties.

this was purely a digital signature authentication situation

it did not involve any requirement for the financial infrastructure to
certify any information for the benefit for any other institution.

there is no other institution involved.

a certification authority is able to proove something ... typically by
verifying the information with the authoritative agency for the
information being certified. PKI and digital certificates encapsulate
the information that is being certified ... creating a trust
propogation information where the information can be trusted by other
parties.

in this situation the financial infrastructure is the authoritative
agency for the information ... they don't need anybody else ... or even
themselves, creating a stale, static certification of some information
that they already know.

i've repeatedly asserted that digital certificates are analogous to the
"letters of credit" from the sailing ship days (a bank certifying some
information for other parties).  In this particular case, we would have
a bank president writting a "letter of credit" addressed to themself
.... say, giving the person's current account balance (at the time the
letter was written). The next time the person comes into the bank to
talk to the bank president, they have to present the "letter of credit"
that the bank president had written to themself, listing
the person's stale, static bank balance at the time the letter was
written. The bank president then approves withdrawals against the
account (w/o checking the current account balance) based on each
individual withdrawal being less than the account balance listed in the
letter of credit that the bank president wrote to themself possibly a
year earlier.

.....

all they needed was basic digital signature authentication. there was
no requirement for the financial infrastructure to certify any
information for the benefit of any other institution ... and therefor
no requirement for a certificate authority generating digital
certificates which represent the certification of some information by
one institution for the benefit of some other party.

the purpose of a digital certificate is that one party certifies some
information for the benefit of some other party.

the financial operation is the authoritative agency for the information
that they are interested in ... every transaction has to reference the
account record that is the master copy of all the information.

a stale, static digital certificate containing a small subset of
information in the account record is redundant and superfluous. in
fact, the digital certificate only contained a database lookup
reference to the actual information ... which is also contained in the
actual account transaction message, making any digital certificate not
only redundant and superfluous but also serves no useful purpose.

the technology is asymmetric key cryptography, what one key (of a
key-pair) encodes, the other key decodes (differentiating from
symmetric key cryptography where the same key both encrypts and
decrypts).

a business process is defined called public key ... where one key is
identified as "public" and made freely available. the other key is
identified as private", kept confidential and never divulged.

a business process is defined called digital signature. a hash of the
message is calculated and encoded with the private key. the recipient
recalculates the hash, decodes the digital signature with the
corresponding public key and compares the two hashes. if the two hashes
are the same, then the recipient can assume:

1) that the message hasn't changed since the digital signature was
originally calculated

2) "something you have" authentication, i.e. the origin entity had
access to and use of the corresponding private key.

....

note that blind signatures allow for relying party to know something is
true w/o actually needing to bind it to some entity. the issue for
account-based transactions is that you actually want to authenticate
that the originating entity is an entity authorized to execute
transactions against the account.

blind signatures show up in situations like anonymous, electronic cash.
an anonymous person spends some electronic cash ... the relying party
wants to know that the electronic cash is valid w/o needing to
establish anything about the spending entity.

three factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

for account-based authentication, it doesn't need to establish who you
are ... however, it does need to establish that the entity is an entity
authorized to perform specific account operations.

blind signature schemes aliminate binding to an entity and can be used
where authentication isn't required ... simply validity/truth of the
message.

account-based operations requires (authentication) binding of the
entity to the account ... but can be privacy agnostic ... as in the
case of some of offshore annonymous bank acount ... use of the bank
account is pure authentication w/o any identification. there may or not
be identification to open the account, but only authentication is
needed for using the account (not identification). this is one of the
issues raised in the x9.59 financial transaction standard
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy

some blind signature references:
http://citeseer.ist.psu.edu/pointcheval96provably.html
http://en.wikipedia.org/wiki/Blind_signature
http://www.tiscali.co.uk/reference/dictionaries/computers/data/m0051357.html
http://www.rsasecurity.com/rsalabs/node.asp?id=2339
http://www.emergentchaos.com/archives/001511.html

l***@garlic.com wrote:
Show quoteHide quoteref:
http://www.garlic.com/~lynn/2005o.html#5 X509 digital certificate for
offline solution

another fundamental principle of PKIs, certification authorities, and
digital certificates ... is not only is it targeted at trust
propogation ... where the certification authority is certifying some
piece of information for use by other parties ... but the purpose of
the digital certificate is to represent the certified information to
the relying party ... when the relying party

1) has no other means of certifying the information themselves,

2) is not able to directly contact the authoritative agency responsible
for the information being certified

3) is not able to directly contact the certification authority
responsible for certifying the information.

aka ... the digital certificate provides trusted information when the
relying party doesn't have the information themselves and/or has no way
of directly accessing the information (aka a trust propogation
scenario).

repeating the bank president scenario ... and the business process
analogy between digital certificates and letters of credit from the
sailing ship days ... the bank president writes the letter of credit
with their right hand ... and then proceeds to transfer the letter of
credit from the right hand to their left hand .... because obviously
there is no other way for the bank president's left hand to know what
the bank president's right hand is doing.

Thanks Lynn! it definitely was a very informative. ...
I'm now digesting all the information that you presented here ;-).

-Valery.
http://www.harper.no/valery

Authorization against AD using MC++
Bad Data error in DES encryption
Securing a control assembly against use of foreign assemblies
sn.exe exit code documentation ?
Create an Event Log on a Least Privilege User Account
Why defaultcredential doesn't use the impersonated user?
Java security api - DCE 128bit encryption with .NET
SecurityException: Request Failed on CreateInstanceAndUnwrap
Decrypt file in VB6 encrypted in vb.net
<identity impersonat=> problems.