Subject: RE: A challenge

From: [email-masked]
Date: Mon, 10 Feb 2003 17:18:09 -0700

in fact ... any trusted source for the key can be used to validate the
signature. a major point of the certificate is a business process that
binds something else to the meaning of the signature (especially in an
offline environment when there aren't recourse to online authoritative
reference).

in the asuretee scenario ... the same hardware token (key) can be
registered (aka the registration authority business process) with multiple
different authoritative agencies .... potentially providing different
bindings for signatures based on the context that the signature is used in.

in the encryption scenario (as opposed to the digital signature case), the
sender already needs to have a table of public keys (which may or may not
be in certificate form .... or stored already in un-encoded form for
convinient usage) ... and must select the recipient's public key from the
table.

a similar process is also possible in the digital signature case for
something like a x9.59 financial transaction .... the financial instituion
can have pre-decoded the certificate and stored it in the account record at
the time the consumer registers the account. It is then no longer necessary
for the client to transmit the certificate as part of a digitally signed
x9.59 financial transaction.

discussion of previously registered certification .... as well as (digital
signature) certificates that have been compressed to zero bytes
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2  Relying-Party
Certification Business Practices

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

"Simon Tardell" <[email-masked]> on 2/10/2003 8:35 am wrote:

Anders,

> To have redundant certificates in case the CA goes haywire
> seems like a very peculiar solution and will force users to
> select the proper certificate.  Which is?

Not at all. A signature is made with a key, not a certificate. As long
as the identity of the certificate is not signed into the message, any
certificate that corresponds to the right key can be used to validate
the signature. The certificate may  be sent with the signed message or
obtained from somewhere else. It is largely the headache of the
verifier.

The certificate that is used to verify the signature may even be issued
after the signature is made. (And in fact, this would be a reasonable
possible consequence of having CA redundancy -- after some time it could
happen that both CAs that certify a certain key-identity-binding are
replacement CAs deployed after the first signatures were made with the
card)

For some reason the common paradigm is to let users chose a certificate
associated with a key to imply the key. This practice requires the
certificate to be present at the client. Or rather, *a* certificate. The
certificate could be e.g. a self-signed cert (issued by the smart card
itself at production time just to supply a GUI handle to applications
looking for, and to supply a subject name for the end entity to claim,
if the application needs one). This would remove the need to ever update
the smart card. Or, as Sun would say, the network is the computer.

Simon

Simon Tardell, cell +46 70 3198319, [email-masked]