Subject: Recommendation on subject matching rules needed..

From: "Vainikainen Saku EINT" <[email-masked]>
Date: Sat, 15 Mar 2003 02:06:18 +0200

> My question is: Why is a *cert* being used for *personal*
> file protection (i.e., "from/to self", as opposed to 
> protection of the file when it is communicated from one 
> entity to another)?  It would seem that certs are the wrong 
> tool for this job.  *Bare* keys (keypairs or secret keys, 
> perhaps derived from a passphrase) seem to be the right tool.
>
> ...
>
> All-in-all, it seems that a better solution would be to store
> a bare secret key on the smartcard and use that to protect 
> his files, doesn't it?

Yes - this sounds reasonable when the same person is always encrypting
and decrypting the file, but the disk/folder/file encryption systems
need multi-user capabilities, ie. more than one person is required to
access the encrypted file.

If you use secret keys to encrypt the data for let's say 20 persons,
your data bloats 20-fold, or of course you could generate a session key
for bulk encryption of the data and just use personal secret keys to
encrypt that key for each user. You still have to somehow identify the
"legal" users of the encrypted disk/folder/file, instead of
trial-and-error decryption. What better way to do this than
certificates.. ?

This applies to hybrid encryption also: bare keypairs are not enough
since trial-and-error decryption is resource consuming, thus not wise.

Of course one could insert some checksums or whatever constant data to
the first encrypted block to make the trial-and-error decryption faster,
but this would also introduce a good way for a brute force key quesser
to figure out the secret key.. No good.

And passphrases still need to be broadcast/transmitted to and remembered
by all users, and it is not wise to use the same passphrase for all
encrypted data, so they are no good.

Saku.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 18 Mar 2003 01:25:26 +1200

"Vainikainen Saku EINT" <[email-masked]> writes:

>Sounds good, but I suppose we still need to select the keys somehow
>(using the certs) through the CryptoAPI CSP and RSA CrypTokI interface,
>so that the applications are satisfied.

It looks like you've been painted into a corner by the selection of software
you have to use.  The solution using other software is fairly simple, but
if you're stuck with using CryptoAPI and have various other constraints I
don't really know what you could do, sorry.  I guess saying "Don't do that
then" isn't much help :-).

Peter.

---

From: "Vainikainen Saku EINT" <[email-masked]>
Date: Tue, 18 Mar 2003 14:16:28 +0200

> It looks like you've been painted into a corner by the 
> selection of software you have to use.  The solution using 
> other software is fairly simple, but if you're stuck with 
> using CryptoAPI and have various other constraints I don't 
> really know what you could do, sorry.  I guess saying "Don't 
> do that then" isn't much help :-).

Yep. Although I don't know of any other non-proprietary
crypto-interfaces that have "widespread" application support so I don't
really see another way around the problem other than put pressure on the
application vendors.

And putting this pressure would be greatly helped by you guys at IETF
PKIX & SMIME if you would draft up a paper about the subject. It could
be part of SMIME specs but I would like to see it a part of PKIX specs,
since the same issue is present when building certification paths during
certificate verification process, as well as when making the call wether
to trust the presented CA certificate or not..

Saku.