RE: Recommendation on subject matching rules needed..

["Vainikainen Saku EINT" <Saku.Vainikainen@xxxxxxxx>]

> >This is how we do it. And this is why the decryption does not work 
> >since the new enc cert gets a new serial number, ie. the encryption 
> >cert gets reissued, ie. the encryption key pair gets 
> recertified, ie. 
> >cert hash changes. One cannot change the contents of a certificate 
> >without generating a new certificate serial number, ie. issue a new 
> >certificate.
> 
> But why is this a problem?  If you get something addressed to 
> the old cert, you use the old key to decrypt.  If it's for 
> the new cert, you use the new key.  In fact there isn't even 
> any need to keep the old cert around if it's decrypt-only, 
> you mention PKCS #15, well that stores all the index info you 
> need with the key, so you don't need the cert at all.

Yes, but then we need to store encryption key and certificate chains.
Our smartcard has only limited space available, so we would need to
recover the old encryption keys and certificates to PKCS#12 files or
other software tokens. Then again the software tokens tend to be a bit
difficult since you have to store them somewhere (disk/cd-rom/whatever,
preferrably a read-only media) to deliver them to the user.

Then in order to use the keys, the user has to import them to his/her
user profile or disk to have them available. And since roaming profiles
are not so common (at least in our environment) copies of the keys
(along with automatic password managers memorizing the passphrases) lay
around in multiple workstations, which is not good in sense of privacy.

Unfortunately most of the software we are using uses Microsoft
CryptoAPI, which hides all PKCS#15 info quite efficiently, thus forcing
the software to use the key usage info stored in the certs.
 
> >Our card has following PKCS#15 key usages on the private keys:
> 
> Have you actually tested all the combinations with your 
> software?  That is, added two certs that differ only in 
> encryption vs.signature usage and then see what the app does 
> if asked for a signature or encryption cert?  Some of the 
> people I pointed out problems to were surprised at the 
> problems, since things seemed to work OK (meaning that the 
> app just grabbed the first key it found and used that, so 
> everything appeared to work fine).

No - since we issue only one cert per key at a time, and we don't issue
multiple certificates with identical serial numbers. And the apps we are
using allow us to choose the certificate (=key) to be used, although
they do some filtering based on key usage information found in the
certificates.

Saku.