thomasv@mac.com (Thomas Vincent) writes:
PKI is generally used for authentication and verifying the integrity
of the data. The authorization is stored in the directory (LDAP) and
or the application. It is hard to give you a complete answer when we
don't know what the operating systems your using are. The fact that
the digital certicate is on a USB token is irrelevant. The computer
will simpley look at that as just another device aka. hard drive.

PKI is a messy business right now with a bunch of vendors (ENTRUST)
trying to create stovepipe solutions. Basically because they know
that PKI is largely becoming a commidity not something unique.

A quick search of google turns up a ton of information on the
subject.

original PKINIT for kerberos was simple digital signature
authentication along the lines of DSA or ECDSA (fips186) where
the public key was registered in lieu of a pin/password
(certificateless and PKI-free operation)

the client asserts a userid or account, the server possibly sends some
sort of (random) challenge (countermeasure for replay attacks), the
client digitally signs the challenge (with their private key) and
returns the digital signature. the server verifies the digital
signature with the public key on file.

this preserves the existing business processes but eliminates the
threats associated with shared-secrets and static data authentication.
In addition to kerberos certificateless authentication scenarios (no
PKI) there are also RADIUS certificateless authentication scenarios
again where public key registration has been substituted for
pin/password (shared-secret) registration and digital signature
authentication is used in lieu of exchanging shared-secret.

the original PKI/certificate based model was to address the offline
email scenario between parties that had not previously communicatede
(scenario from the early 80s). Somebody dials up their local
(electronic) post-office, exchanges email, and hangs up. They possibly
now have an email from some party they never previously communicated
with. The issue was how to perform any sort of authentication when
they had no other recourse as to information about the originating
party (and no previous knowledge of the originating party). This is
basically the "letter of credit" business model from the sailing ship
days (when there was no online, electronic, and/or timely
communication mechanism to obtain information about total strangers).

the early 90s so evoluation of x.509 "identity" certificates. The
issue for "trusted third parties" issuing such x.509 "identity"
certificates was what possibly information would be of use to
future relying parties possibly doing performing authorizations based
on the information content of an x.509 "identity" certificate. There
was a trend to steadily increase the amount of information identity
content perceived as increasing the value of such x.509 "identity"
certificates and therefor increasing the possible perceived value
of PKI and "trusted third party" certification authorities.

The issue in the mid-90s was the growing realization that these x.509
identity certificates, overloaded with significant identifity
information, represented significant liability and privacy issues.
As a result, there was some retrenchment to "relying-party-only"
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

basically certificates containing only something like an account
number and a corresponding public key. However, it was trivial to show
that such relying-party-only certificates were redundant and
superfluous since the issuer, certification authority, and relying
party already had the registered public key on file.

of the places that such relying-party-only certificaets appeared
was in the financial industry for use with financial transactions.
Here not only was it possible to show that such certificates were
redundant and superfluous (i.e. the customer's financial institution
already had the customer's public key on file so sending back a copy
of the public key; contained in the digital certificate, appended to
every financial transaction was unnecessary) but the other aspect
was that it represented enormous payload bloat. The nominal payment
transaction is on the order of 60-80 bytes the nominal
relying-party-only digital certificate was on the order of 4k-12k
bytes. Appending such a relying-party-only digital certificate to ever
payment transaction represented a factor of one hundred times increase
in the size of the transaction. Furthermore, the only purpose for
appending a digital certificate to the transaction sent to the
customer's financial institution was so that the customer's
financial institution would have a copy of the customer's public key
(which they already have when they registered the public key
originally).

given that there is an existing relationship between two parties
and/or the two parties have online, electronic, timely communication
access to information about the other party PKI and digital
certificates tend to be redundant and superfluous. It is possible to
use existing business processes simply upgrading the technology to
directly register a public key (in lieu of a pin, password, or other
shared secret) for authentication purposes.

The issue isn't so much one about new technology but the trusted
third party certification model drastically changes the business
process model and was originally intended for an offline world
that hardly exists any more.

Part of the problem with the trusted third party PKI certification
authority model is the business and contractual
relationships. Normally a relying party has a direct contract and/or
an implied contract (based on exchange) of value with any certificaton
authority. In the trusted third party PKI certification authority
model the exchange of value is typically between the "key-owner"
and the certification authority (i.e. the key owners buys a
certificate). However, the use of the certificate is by the
relying-party that is performing the authentication and the
relying-party can have no direct or indirect contractual relationship
with the certification authority.

In the federal gov. PKI scenario GSA attempted to get around this
mismatch in the trusted third party certification authority business
model by creating the legal fiction that the certification
authorities were agents of the federal gov (i.e. GSA has a contract
with the certification authorities saying that they are operating on
behalf of the federal gov.). Then when some federal gov. agency does
something based on relying on the information in such a digital
certificate they have some possible legal recourse if the proper
processes weren't followed. However, there have been quite a number of
deployed and proposed PKI infrastructures where there were no
provisions for creating any sort of business obligation by the
certification authorities to the relying operations that were
dependent on the information in certificates.

thomasv@mac.com (Thomas Vincent) writes:
PKI is generally used for authentication and verifying the integrity
of the data. The authorization is stored in the directory (LDAP) and
or the application. It is hard to give you a complete answer when we
don't know what the operating systems your using are. The fact that
the digital certicate is on a USB token is irrelevant. The computer
will simpley look at that as just another device aka. hard drive.

PKI is a messy business right now with a bunch of vendors (ENTRUST)
trying to create stovepipe solutions. Basically because they know
that PKI is largely becoming a commidity not something unique.

A quick search of google turns up a ton of information on the
subject.

original PKINIT for kerberos was simple digital signature
authentication along the lines of DSA or ECDSA (fips186) where
the public key was registered in lieu of a pin/password
(certificateless and PKI-free operation)

the client asserts a userid or account, the server possibly sends some
sort of (random) challenge (countermeasure for replay attacks), the
client digitally signs the challenge (with their private key) and
returns the digital signature. the server verifies the digital
signature with the public key on file.

this preserves the existing business processes but eliminates the
threats associated with shared-secrets and static data authentication.
In addition to kerberos certificateless authentication scenarios (no
PKI) there are also RADIUS certificateless authentication scenarios
again where public key registration has been substituted for
pin/password (shared-secret) registration and digital signature
authentication is used in lieu of exchanging shared-secret.

the original PKI/certificate based model was to address the offline
email scenario between parties that had not previously communicatede
(scenario from the early 80s). Somebody dials up their local
(electronic) post-office, exchanges email, and hangs up. They possibly
now have an email from some party they never previously communicated
with. The issue was how to perform any sort of authentication when
they had no other recourse as to information about the originating
party (and no previous knowledge of the originating party). This is
basically the "letter of credit" business model from the sailing ship
days (when there was no online, electronic, and/or timely
communication mechanism to obtain information about total strangers).

the early 90s so evoluation of x.509 "identity" certificates. The
issue for "trusted third parties" issuing such x.509 "identity"
certificates was what possibly information would be of use to
future relying parties possibly doing performing authorizations based
on the information content of an x.509 "identity" certificate. There
was a trend to steadily increase the amount of information identity
content perceived as increasing the value of such x.509 "identity"
certificates and therefor increasing the possible perceived value
of PKI and "trusted third party" certification authorities.

The issue in the mid-90s was the growing realization that these x.509
identity certificates, overloaded with significant identifity
information, represented significant liability and privacy issues.
As a result, there was some retrenchment to "relying-party-only"
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

basically certificates containing only something like an account
number and a corresponding public key. However, it was trivial to show
that such relying-party-only certificates were redundant and
superfluous since the issuer, certification authority, and relying
party already had the registered public key on file.

of the places that such relying-party-only certificaets appeared
was in the financial industry for use with financial transactions.
Here not only was it possible to show that such certificates were
redundant and superfluous (i.e. the customer's financial institution
already had the customer's public key on file so sending back a copy
of the public key; contained in the digital certificate, appended to
every financial transaction was unnecessary) but the other aspect
was that it represented enormous payload bloat. The nominal payment
transaction is on the order of 60-80 bytes the nominal
relying-party-only digital certificate was on the order of 4k-12k
bytes. Appending such a relying-party-only digital certificate to ever
payment transaction represented a factor of one hundred times increase
in the size of the transaction. Furthermore, the only purpose for
appending a digital certificate to the transaction sent to the
customer's financial institution was so that the customer's
financial institution would have a copy of the customer's public key
(which they already have when they registered the public key
originally).

given that there is an existing relationship between two parties
and/or the two parties have online, electronic, timely communication
access to information about the other party PKI and digital
certificates tend to be redundant and superfluous. It is possible to
use existing business processes simply upgrading the technology to
directly register a public key (in lieu of a pin, password, or other
shared secret) for authentication purposes.

The issue isn't so much one about new technology but the trusted
third party certification model drastically changes the business
process model and was originally intended for an offline world
that hardly exists any more.

Part of the problem with the trusted third party PKI certification
authority model is the business and contractual
relationships. Normally a relying party has a direct contract and/or
an implied contract (based on exchange) of value with any certificaton
authority. In the trusted third party PKI certification authority
model the exchange of value is typically between the "key-owner"
and the certification authority (i.e. the key owners buys a
certificate). However, the use of the certificate is by the
relying-party that is performing the authentication and the
relying-party can have no direct or indirect contractual relationship
with the certification authority.

In the federal gov. PKI scenario GSA attempted to get around this
mismatch in the trusted third party certification authority business
model by creating the legal fiction that the certification
authorities were agents of the federal gov (i.e. GSA has a contract
with the certification authorities saying that they are operating on
behalf of the federal gov.). Then when some federal gov. agency does
something based on relying on the information in such a digital
certificate they have some possible legal recourse if the proper
processes weren't followed. However, there have been quite a number of
deployed and proposed PKI infrastructures where there were no
provisions for creating any sort of business obligation by the
certification authorities to the relying operations that were
dependent on the information in certificates.