RE: A PKI Question: PKCS11-> PKCS12

[lynn.wheeler@xxxxxxxxxxxxx]

the categories were respect to business processes and business requirements
.... there has been recent thread in this mailing list somewhat touching on
the fact that technology implementations and business requirements might
not necessarily match up very well ... as well as some number of people
working with PKI understanding that there are fundamentally different
business processes and business requirements using the same technology.

Note that it is somewhat mute issue with regard to software PKI
implementations .... the possible business requirements don't see a lot of
differences until you get to hardware token and then there can be a real
issue of whether or not the private key is ever divulged. Also from a
business continuity stand-point .... there can be short-cuts in many of the
secrecy protocols involving date-in-flight (including email) ... it is
long-term encryption involving data-at-rest where non-replicated keys  can
become serious business risk (and single-points-of-failure). Nominally
email is immediately decoded and possibly NACK'ed if there is a problem
(like my private key is broken), aka email is much more of a data-in-flight
business operation.

Not having replicated keys for protected, encrypted data-at-rest business
assets is analogous to not taking backups and having business continuity
plans. Several  years ago, there was some study that of the businesses that
didn't have disk backups of business data when there was hard disk failure
... half filed for bankruptcy within the first 30 days (after the disk
failure). Loss of hardware-token/key for critical business assets protected
by encryption ... effectively can represent equivalent loss of the data.

With regard to SLL merchant authentication with merchant server domain name
certificates for SSL ... the CA signing serves most of the authentication
function with the merchant key serving the encryption function (for key
exchange) .... with somewhat the caveat that if the merchant can decrypt
the key exchange it also has an implied authentication  Any other activity
with regard to merchant key is somewhat protocol chatter ... i.e.

1) if the merchant certificate validates (with the CA key) and the domain
name matches  there is first level of authentication (CA key is an
authentication business process)

2) if the merchant can decrypt the key-exchange from the client (and
correctly respond with encrypted message) .... then there is pretty good
proof that the merchant is the corresponding entity from #1.(merchant key
is a encryption business process).




<hal.lockhart@xxxxxxxxxxxxx> at 11/28/2001 9:37 am wrote:



> PKI key operations can be put into two categories .... authentication
> (digital signatures) and secrecy/privacy (encryption).


I know this is the orthodox theory, but in practice IETF PKI protocols and
applications make this difficult or impossible. Generally one key is used
for Authentication and Key exchange, effectively encryption.


That's how TLS and IKE work. Just try using two keys with Outlook.


Hal