Re: PKI: the end
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 03/22/05
- Next message: Tom St Denis: "Re: 3DES on a network card: Intel Pro/100S"
- Previous message: Martin Carpenter: "Re: PKI: the end"
- In reply to: Jean-Luc Cooke: "Re: PKI: the end"
- Next in thread: Anne & Lynn Wheeler: "Re: PKI: the end"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 22 Mar 2005 07:50:28 -0700
Jean-Luc Cooke <jlcooke@engsoc.org> writes:
> PKI infers only the 2nd of your factors above. PKI doesn't require any
> biometric or password unless you go out of your way to add it in.
>
> I saw you went into this a bit later in your post with some references
> to your site. But you're extrapolating requirments from your view of
> how the technology should be deployed.
>
> What's with the "business process" terminology? PKI isn't a
> "business process" it's a branch of mathematics. Examples of
> "business process" are:
asymmetric cryptography is technology. public/private key
infrastructure is a business process application of asymmetric
cryptography that specifies one of the keys of a asymmetric
cryptography key-pair is to be kept consistantly private. the
convention of consistantly maintaining the privacy of a specific key
in an asymmetric cryptography key is a business process specification.
a relying-party, relies on the belief that the business process
specification is being followed when assuming that the verification of
a digital signature with a public key implies the "something you have"
authentication (i.e. some entity uniquely is in possession of the
corresponding private key).
the convention of consistantly maintaining the privacy and
confidentiality of a specific key of a asymmetric key pair is a
business process, not a technology. the measures used to maintain the
privacy and confidentiality of a private key may be technology.
asymmetric cryptography is technology.
the convention of consistantly maintaining the privacy and
confidentiality of a specific key of a public/private key pair is a
business process. the assumption by a relying-party that the
verification of some encoded pieces of data (called a digital
signature) by a specific key of a asymmetric key pair (called a public
key) implies "something you have" authentication is a business
process. the business process defines the requirements of consistantly
maintaining the privacy of a specific key in an asymmetric key pair as
part of the business infrastructure where a relying-party can assume
that the verification of a "digital signature" with a "public key"
implies "something you have" authentication (from 3-factor
authentication paradigm) dependent on some entity being uniquely in
possession (access and use) of the corresponding "private key".
there might be other business process mechanisms that might also be
specific as part of a 3-factor authentication paradigm (aka a specific
authentication infrastructure may not include three unique factors for
determining authentication, but a specific authentication
infrastructure may be characterized using the 3-factor authentication
paradigm).
as part of a basic public/private key authentication infrastructure,
the relying parties are assuming that the business process
requirements for consistantly maintaining the privacy and
confidentiality of a specific key (the "private key") are being met
(just because he is told to assume it).
A relying party might also be told that they could assume that as part
of a specific authentication infrastructure, a "private key" is
uniquely housed in a specific kind of hardware token (say as opposed
to an encrypted file). In such a case, the relying party might infer a
higher level of integrity and confidence in the associated
authentication events (and for example, the relying party might be
willing to approve large value transaction amounts than they would if
they assumed the overall infrastructure had lower integrity
characteristics).
The residence of a private key in a hardware token can be considered
technology. The ability for a relying party to assume
"a private key is housed in a specific kind of hardware token with a
specific level of hardware integirty and that the specific private key
is, in fact, kept unique and private to a specific entity"
is a characteristic of the relying parties belief in the associated
(authentication) business process operation.
Various kinds of authentication business process requirements that a
relying party could reliably assume to exist might be:
* specific key of an asymmetric cryptography key-pair is
consistantly, and reliably kept private and confidential.
* specific key is uniquely and reliably housed in a hardware
token of specific integrity characteristics, that the key(s)
were generated internally inside the hardware token and there
are no provisions for a specified "private key" to be exported
from the token
* a specific hardware token only operates in a specific
way when a pin or password has been provided to the token
* a specific hardware token only operates in a specific
way when a biometric value is matched to a template
inside the token
the ability for a relying party to assume "from the verification of a
digital signature with a specific public key" might imply any of the
above conditions to be true, is a characteristic of business process
... not just the technology.
a business process can be any operations or sequence of steps that the
parties have aggreed it to be. keeping a specific key of an asymmetric
cryptography key pair, reliably and consistantly private and
confidential isn't an attribute of the asymmetric cryptography
technology, it is an attribute of the public/private infrastructure
business process (which makes use of assymmetric cryptography
technology).
in my original posting ... i may have created some confusion by
sometimes referring to an authentication infrastructure within the
context of a 3-factor authentication paradigm ... by just typing
3-factor authentication ... w/o intending to mean that all three
factors were actually involved in any specific authentication
infrastructure instance and/or deployment.
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
- Next message: Tom St Denis: "Re: 3DES on a network card: Intel Pro/100S"
- Previous message: Martin Carpenter: "Re: PKI: the end"
- In reply to: Jean-Luc Cooke: "Re: PKI: the end"
- Next in thread: Anne & Lynn Wheeler: "Re: PKI: the end"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|