Qualified Certificate Request

[Anne & Lynn Wheeler]

Philipp Gühring wrote:
> Regarding the requirements for qualified certificates, the only obstacle we 
> still have is the problem, that CAcert has to make sure, that the private key 
> for the certificate is generated and stored securely in a SmartCard, or 
> another Hardware Token.
> 
> Since the users should be able to issue the certificates at home, we need a 
> technical solution to make sure, that the private key is from within a 
> SmartCard, when we receive a certificate request.

aads chip strawman
http://www.garlic.com/~lynn/index.html#aads

took a different approach ... the key pair is generated during the
power-on chip test process ... before the wafer is even sliced and diced
and the public key becomes an attribute of the chip (along with some
number of other individual chip specific integrity characteristics).

the resulting digital signature from the token isn't intended to
represent who you are ... it is intended to provide "something you have"
authentication ... aka the verification of the digital signature then
implies that the individual has access to and use of the corresponding
private key (and the specific hardware token that contains it). the
private key is never divulged and the public key and the digital
signature represent characteristics of the "something you have"
authentication.

the public key can be registered ... and there is a service that allows
a relying party to retrieve the integrity characteristics of the
hardware token associated with the public key.
http://www.firstdatasecure.com/

the issue is that the majority of the existing business processes go to
a great deal of trouble binding an identity to some set of business
process characteristics. the incremental issue for the majority of the
business processes in the world ... isn't with respect to who an
individual is ... but what are all the integrity and assurance
characteristics associated with the actual authentication business
processes.

the overall integrity and assurance characteristics associated with
hardware token public key digital signatures ... includes (at least) the
current time-varient characteristics of the specific chip (apparently
identical hardware tokens might have different chip generations with
different assurance characteristics depending on the date/time of the
manufactor of the specific chip), the key length, the particular digital
signature algorithm, the environment in which the digital signature
occured, whether the hardware otken performed a digital signature with
or w/o an associated PIN entry or with or w/o an associated biometric entry.

I've frequently asserted in the past that some number of PKI-oriented
interests have muddled and obfuscated the fundamental assurance issues
that most business processes have a real need-to-know ... and attempted
to substituted things that certification authorities might be doing when
 certification of information for inclusion in a digital certificate.
However, for the majority of things that have been talked about for
stuff that goess into certificates (like information for x.509 identity
certificates) ... is stuff that duplicates operations by long existing
and well established business process relationship management
infrastructures.

One might conjecture that since most such PKI-oriented deployments
didn't provide the components of the end-to-end actual authentication
environment (hardware tokens, singing environments, validation
environments) ... that it was in their interest to maximize the
perceived value of the (mostly redundant and superfluous digital
certificates duplicating existing business process of long existing and
well established relationship management infrastructures) digital
certificates and minimizing the perceived value of the really important
assurance components of interest to relying parties.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com